ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
mraynal has quit [Read error: Connection reset by peer]
mraynal has joined #armlinux
torez has quit [Quit: torez]
frieder has quit [Ping timeout: 248 seconds]
c1728p9 has quit [Read error: Connection reset by peer]
frieder has joined #armlinux
shailangsa has quit [Remote host closed the connection]
NonaSuomy has joined #armlinux
NonaSuomy has quit [Ping timeout: 240 seconds]
Lucanis has quit [Ping timeout: 252 seconds]
sibis5 has joined #armlinux
iivanov has joined #armlinux
Sledge has quit [Ping timeout: 246 seconds]
javierm has quit [Ping timeout: 246 seconds]
sibis has quit [Ping timeout: 246 seconds]
nbd has quit [Ping timeout: 246 seconds]
sibis5 is now known as sibis
aposm has quit [Ping timeout: 246 seconds]
mriesch has quit [Ping timeout: 246 seconds]
buZz has quit [Ping timeout: 246 seconds]
mriesch has joined #armlinux
aposm has joined #armlinux
buZz has joined #armlinux
javierm has joined #armlinux
Sledge has joined #armlinux
buZz is now known as Guest6260
nbd has joined #armlinux
Pali has joined #armlinux
luispm has quit [Quit: Leaving]
Pali has quit [Ping timeout: 272 seconds]
mraynal has quit [Remote host closed the connection]
mraynal has joined #armlinux
matthias_bgg has joined #armlinux
monstr has joined #armlinux
djrscally has joined #armlinux
apritzel has joined #armlinux
apritzel has quit [Ping timeout: 260 seconds]
sszy has joined #armlinux
apritzel has joined #armlinux
tre has joined #armlinux
<arnd> ukleinek: I have not tested in the past few weeks, so they are probably regressions. We used to get these only with CONFIG_KASAN_STACK enabled, but that should not be part of allmodconfig
nsaenz has joined #armlinux
bps has joined #armlinux
bps has joined #armlinux
bps has quit [Changing host]
luispm has joined #armlinux
<ukleinek> arnd: CONFIG_KASAN_STACK=y for allmodconfig
<arnd> oh, I wonder how that happened
<arnd> does the problem go away if you turn it off?
cleger has joined #armlinux
headless has joined #armlinux
<ukleinek> arnd: a build it just running to verify that
<ukleinek> and I'm not surprised it's on. allmodconfig does =m for everything modular and =y for the rest, doesn't it?
<ukleinek> build succeeded without CONFIG_KASAN_STACK
<arnd> ukleinek: IIRC we had a dependency in KASAN_STACK that turned it off by default for allmodconfig
<arnd> bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST
<arnd> so if COMPILE_TEST is enabled, the option should be invisible, and COMPILE_TEST should always be on for allmodconfig
<ukleinek> arnd: and because of default y if CC_IS_GCC this invisible option is enabled?
alexels has joined #armlinux
saiprakash has joined #armlinux
sudeepholla has quit [Ping timeout: 256 seconds]
saiprakash has quit [Quit: Client closed]
cbeznea has joined #armlinux
Guest6260 is now known as buZz
headless has quit [Quit: Konversation terminated!]
snalty_ has quit [Ping timeout: 248 seconds]
iivanov__ has joined #armlinux
iivanov has quit [Ping timeout: 240 seconds]
snalty has joined #armlinux
iivanov has joined #armlinux
headless has joined #armlinux
iivanov__ has quit [Ping timeout: 276 seconds]
sudeepholla has joined #armlinux
NonaSuomy has joined #armlinux
headless has quit [Quit: Konversation terminated!]
elastic_dog has quit [Ping timeout: 240 seconds]
<Xogium> marex, ukleinek, bencoh: found the leak in irssi with the help of a friend ^^ it has been present for the past 22 years
<Xogium> irssi leaked memory every time an ignore was matched in its cache
NonaSuomy has quit [Ping timeout: 260 seconds]
<Xogium> only problem is it will be an absolute nightmare to port to 1.3.x... Breaking ABI changes
<ukleinek> Xogium: so just drop all /ignores :-)
<ukleinek> TIL irssi is already >= 22 years old.
<Xogium> nah, not happening
<Xogium> :D
<Xogium> so it was there since the dawn of time, fun. Reminds me of that bug I tracked and which ended up being so old that it predated the dawn of git history in the kernel
<jn> ah, when git blame shows 2.6.12-rc2 :)
<jn> "Let it rip!"
<Xogium> yeah
<hanetzer> so, I have 5 plls. they have their main rate (FOUTVCO = 24Mhz * fbdiv / frac), and 5 divided rates (POSTDIV = foutvco / div1 / div 2 and FOUT1-4 which are POSTDIV divided by 2,4,6 and 8). should fout1-4 be registered as fixed factor children of POSTDIV ?
<Xogium> jn: something to do with how panic() being called without a prior condition like an oops would actually let linux exit its own infinite loop after said panic, due to preemption
<Xogium> I could ping a dead board over the network
<jn> Xogium: i think i vaguely remember you talking about that bug
<Xogium> yeah that was completely mad..
matthias_bgg has quit [Ping timeout: 276 seconds]
<Xogium> I was also beyond confused, because of the intermitant way it seemed to happen, but that had only one explanation, the fact that sometimes the process pinging my hardware watchdog was on cpu 0, so keeping the system going, and sometimes on cpu 1, which caused it to reboot
<jn> hanetzer: sounds reasonable enough. how do fout1 etc. end up being used? are they selectable at peripheral clock muxes?
<hanetzer> jn: usually they're the parent of a mux or a gate.
<hanetzer> for instance, the sys_axi clock can either take its rate from vpll2's fout2, epll's fout1, or the 24Mhz osc clock
<hanetzer> based on a two-bit mux in the clock hw
<hanetzer> (0b00 24Mhz, 0b01 epll fout1, 0b10 vpll2 fout2)
<ukleinek> Xogium: is there already an issue or even a patch for that irssi leak?
<hanetzer> sometimes these are divided again :P
<hanetzer> for instance, the fephy out/sata alive clocks are epll fout1 / 5
<jn> hanetzer: which SoC was this again? some HiSilicon thing?
shailangsa has joined #armlinux
<hanetzer> jn: yeh, specifically the hi3521a
<hanetzer> after learning that the include/dt-bindings/*.h file is append-only I've decided to start further down the clock tree for organization purposes.
<jn> hm, i have a Hi3520DV100 on my pile of stuff to hack
NonaSuomy has joined #armlinux
<hanetzer> oh hey, I know that chip.
<hanetzer> what kernel version does it run?
<jn> gotta say, the documentation (from travellinux) isn't even bad, just written in chinese
<hanetzer> I also know that site :P
<hanetzer> yep, I have their sdk on hand.
<jn> unfortunately, the kernel is silent, only uboot announces itself https://github.com/neuschaefer/linux/wiki/AHB780XTB-Digital-Video-Recorder
<hanetzer> ah i had this board, or something close. fried it on accident.
torez has joined #armlinux
Lucanis has joined #armlinux
<hanetzer> jn: yeah I have the linked travelinux datasheet in english
<jn> oh cool!
<hanetzer> looks like a 3.0.x kernel
<hanetzer> got somewhere you'd like me to upload the files or should I just use filebin ?
<jn> any filehost is fine
<hanetzer> sure. gimme a bit.
<hanetzer> https://filebin.net/06urq3x3w51cnlv7 it'll be here once it uploads (724mb)
<jn> o.O that's massive
<hanetzer> lotta pdf docs en/cn, and the bsp.
<jn> ah, i see, a whole archive of stuff
<jn> thanks in advance!
<hanetzer> most of the stuff on these chips are standard primecell parts
<jn> that's good
<hanetzer> i've been working on a qemu model of the chips I have. intent is to use qemu's trace and logging functionality to basically do mmiotrace on their blobby stuff.
<jn> makes sense
<hanetzer> its also been a bit helpful since there are some blocks of mmiospace marked as 'reserved' which have stuff going on in them.
<hanetzer> even their gpl code is a bit *grimace*
matthias_bgg has joined #armlinux
<ukleinek> ..ooOO(724 millibyte are not even one byte :-)
<jn> about six bits ;)
<Xogium> also for what its worth, I couldn't manage to run valgrind on arm
<Xogium> disInstr(arm): unhandled instruction: 0xEC510F1E cond=14(0xE) 27:20=197(0xC5) 4:4=1 3:0=14(0xE)
<Xogium> ==534== valgrind: Unrecognised instruction at address 0x4cc4208.
<Xogium> ==534== at 0x4CC4208: _armv7_tick (in /usr/lib/libcrypto.so.1.1)
<jn> Xogium: was that on a raspberry pi with a relatively standard userspace (raspbian-like)?
<ukleinek> Xogium: valgind on arm < v7 is known to be broken
<Xogium> sigh
<ardb> Xogium: openssl uses SIGILL trapping to detect which crypto instructions are implemented
<Xogium> jn: it was on stm32mp157, with userspace compiled with buildroot. But I guess.. erk
<jn> IIRC, Raspbian, for a while, had a weird custom memcpy or something that switched endianness or something
<jn> Xogium: ah, i see
<Xogium> broken indeed
<HdkR> SIGILL trapping in valgrind is still not working last I tested
<ukleinek> stm32mp157 is armv7, so at least the issue I have in mind shouldn't be a stopper
<Xogium> I even tried to turn off thumb2 thinking it was possibly it
<hanetzer> yeh, arm before v7 was a bit of a trainwreck
<ardb> try setting OPENSSL_armcap=0 in your environment
<ardb> or =1 given that you should have a NEON unit
<Xogium> yes I do have neon
<Xogium> yeah, 0 worked. Lets try 1
<hanetzer> jn: if'n you're interested ##linux-hisi exists
<jn> joined :)
<Xogium> aye, 1 works too.. What does that do, exactly ?
<ardb> it overrides the detection of the supported instructions
<ardb> =1 means you have NEON but no AES, SHA-1 or SHA-2 instructions
<Xogium> nice
<Xogium> thanks :)
<ardb> yw
<Xogium> oh my god
<Xogium> valgrind on stm32mp1 is slow x
<Xogium> took like 5 minutes for irssi to connect ot my servers lol
sudeepholla has quit [Ping timeout: 260 seconds]
sudeepholla has joined #armlinux
punit_ is now known as punit
<Xogium> but once you're in the speed is actually kind of okay
<ukleinek> Xogium: so the problem research is still ongoing?
<Xogium> yep, we indeed found that leak
<Xogium> but its still leaking here
<Xogium> but yeah.. 209 MB of ram used out of 434 available
monstr has quit [Remote host closed the connection]
elastic_dog has joined #armlinux
elastic_dog has quit [Client Quit]
elastic_dog has joined #armlinux
jlinton has joined #armlinux
tre has quit [Remote host closed the connection]
headless has joined #armlinux
nsaenz has quit [Quit: Leaving]
c1728p9 has joined #armlinux
sudeepholla has quit [Ping timeout: 276 seconds]
sszy has quit [Ping timeout: 240 seconds]
cleger has quit [Remote host closed the connection]
Tokamak has joined #armlinux
Pali has joined #armlinux
<NonaSuomy> trying to boot linux on a sony prs-t1 I got a busybox console but getting an error that it can't find a vcom value that it needs I found this script that points to an app named epd_fb_test. Just wondering if anyone knows if there is something similar on all other platforms or is this app an in house custom job on sony.
<NonaSuomy> raw ascii in the app looks like this
mraynal has quit [Remote host closed the connection]
apritzel has quit [Ping timeout: 240 seconds]
Amit_T has joined #armlinux
frieder has quit [Remote host closed the connection]
darkapex has joined #armlinux
luispm has quit [Quit: Leaving]
jeeeun has quit [Quit: The Lounge - https://thelounge.chat]
jeeeun has joined #armlinux
mraynal has joined #armlinux
jeeeun has quit [Quit: The Lounge - https://thelounge.chat]
jeeeun has joined #armlinux
nsaenz has joined #armlinux
alexels has quit [Quit: WeeChat 3.5]
sudeepholla has joined #armlinux
c1728p91 has joined #armlinux
jlinton has quit [Quit: Client closed]
c1728p9 has quit [Ping timeout: 240 seconds]
apritzel has joined #armlinux
<rfs613> NonaSuomy: seems it might be printed on the display? 2nd reply at https://www.mobileread.com/forums/showthread.php?t=64483
<rfs613> instead of using an (analog) potentiometer, they probably use an ADC, so now software sets the voltage.
<NonaSuomy> People sid the data exists @ dd if=/dev/mmcblk2 of=/initrd/mnt/sd/Vcom_OLD.img skip=15876 count=1 bs=1024 cat Vcom_OLD.img BW1118073202953 BU1156245100493 148427352023999 PVI6inchC118C 60 2460 AudioOK 2012/05/21-14:53:11
<NonaSuomy> Basically trying to figure out where it's trying to load this from tps65180_display_enable fail to read vcom from eMMC. -1
<NonaSuomy> so I can provide it to it.
<NonaSuomy> linux-2.6.35.2-20140522-2\linux-2.6.35.2-20140522-2\linux-2.6.35.2\drivers\video\mxc\mxc_epdc_fb.c
<NonaSuomy> This error "mxc_epdc_fb mxc_epdc_fb: Unable to enable DISPLAY regulator.err = 0xffffffff" after that one comes from there
<NonaSuomy> ./* 2011/1/19 FY11 : Added function to read/write VCOM. */
headless has quit [Quit: Konversation terminated!]
Amit_T has quit [Quit: Leaving]
<NonaSuomy> That link is interesting for the fact of the companies name PVI and you see that in the values above PVI6inchC118C which C118C is listed on the flex cable
<NonaSuomy> 6 inch E-ink LCD (PRS-T1/NOOK Simple/ KOBO N905A/B/C) ED060SCE (LF)C1 RET60C4026(C118) E4K0C6B82M4VS5374AY -2.46
jlinton has joined #armlinux
nsaenz has quit [Remote host closed the connection]
<NonaSuomy> That image shows the vcom voltage on the flex cable but it doesn't seem to corrispond to those values above
<NonaSuomy> BW1118073202953 BU1156245100493 148427352023999
<NonaSuomy> maybe some kind of encoding
<NonaSuomy> VCOM -2.46
torez has quit [Quit: torez]
<NonaSuomy> ltc3589-regulator.c
<NonaSuomy> oops wrong one tps65180-regulator.c https://pastebin.com/raw/ZBqCbXTp
<marex> Electrophoretic Display Controller (EPDC)
<marex> epd_fb ... EPD framebuffer
iivanov has quit [Remote host closed the connection]
iivanov has joined #armlinux
iivanov has quit [Ping timeout: 240 seconds]
<NonaSuomy> makes sense now how to disassemble those values
<marex> those values make no sense, where do they come from ?
<marex> board file platform data ? driver ?
<NonaSuomy> as shown above they were extracted eMMC.
<NonaSuomy> rawdatatable.c
<NonaSuomy> I would assume they decode them into usable values
<NonaSuomy> you can see in the above 3 files sony's custom comments listed like
<NonaSuomy> #include <linux/mmc/rawdatatable.h>
<NonaSuomy> ./* 2011/05/30 FY11 : Supported to read vcom from eMMC. */
<NonaSuomy> rawdatatable.h
<NonaSuomy> This may make some sense why it's failing...
<NonaSuomy> this is the data from a stock boot
<NonaSuomy> when I do that on my customized busybox recompile kernel I get # cat /sys/module/rawdatatable/parameters/rawdata_param
<NonaSuomy> (null)
<NonaSuomy> wonder if I can write those values there.
<marex> well if the driver reads something from block device, look at the code ?
c1728p91 has quit [Quit: Leaving]
<NonaSuomy> "Going by this Guide (where I got most info from) the compressed image of Androids root file system is part of a boot image residing on a partition. The T1 however seems to follow a different approach with a stand-alone root fs image in form of raw data on the unpartitioned area."
<NonaSuomy> There is about 26MB of raw space at the start of the eMMC which is where those values seem to come from following that information.
benh has quit [Remote host closed the connection]
benh has joined #armlinux
<NonaSuomy> '/sys/module/rawdatatable/parameters/rawdata_param' is read only
<NonaSuomy> :(
matthias_bgg has quit [Ping timeout: 248 seconds]
<marex> that hardware isn't android, so it is unlikely the same thing
<marex> just look at what the hacked up driver does, it probably reads data from some offset
<NonaSuomy> ...
<NonaSuomy> I pasted the offsets and explained about the raw 26MB of information.
<NonaSuomy> Also this hardware *is android.
<NonaSuomy> it runs 2.2.1
matthias_bgg has joined #armlinux
<NonaSuomy> I wonder how it loads the data into rawdata_param and why it's dumping (null) in there now maybe because I'm loading from the SDCard slot now and some hardcoded value is set to mmcblk2 (eMMC) and not mmcblk0 (SD)
djrscally has quit [Ping timeout: 240 seconds]
Antitrack has quit [Quit: WeeChat 2.9]