<sjg1>
Kwiboo: I even added a test to CI based on it
<sjg1>
Tartarus: Oh, I know the problem
<sjg1>
Tartarus: I actually found this last weekend with the ChromeOS stuff, but didn't turn it into a patch. Basically when you have a usb keyboard, USB gets inited early. Then bootstd does it again :-(
<sjg1>
Tartarus: Let me see if I can fix it...
thopiekar has quit [Ping timeout: 240 seconds]
thopiekar has joined #u-boot
<apteryx>
Tartarus: thanks
<sjg1>
Tartarus: Good news about kernel CI. We really need to close the loop
<Kwiboo>
sjg1: with CONFIG_LEGACY_IMAGE_FORMAT=y armbian gets a little bit closer to boot: ** Script length: 3180, Unknown command '#' - try 'help', Boot failed (err=1)
<Kwiboo>
guessing the boot script contains a comment that is run :-)
<sjg1>
Kwiboo: Hmm yes I just got the same error
<sjg1>
Kwiboo: I suppose this is a regression somewhere
zibolo has quit [Ping timeout: 240 seconds]
zibolo has joined #u-boot
<sjg1>
Kwiboo: Oh I bet it is CONFIG_HUSH_PARSER
<Kwiboo>
sjg1: yep, with CONFIG_HUSH_PARSER=y it can start kernel
<sjg1>
Kwiboo: We did a lot of messing around with default options and I never went back and tested rockpro64 after that
<sjg1>
Kwiboo: USB is hopelessly slow on rockpro64
<sjg1>
Kwiboo: What board and media are you using?
ikarso has quit [Quit: Connection closed for inactivity]
goliath has joined #u-boot
runcom has joined #u-boot
camus has quit [Quit: camus]
camus has joined #u-boot
runcom has quit [Ping timeout: 240 seconds]
apritzel_ has joined #u-boot
runcom has joined #u-boot
runcom has quit [Ping timeout: 256 seconds]
Laurence_b has joined #u-boot
apritzel_ has quit [Ping timeout: 256 seconds]
camus has quit [Quit: camus]
Kevin` has quit [Ping timeout: 240 seconds]
stipa has joined #u-boot
persmule has joined #u-boot
naoki has joined #u-boot
naoki has quit [Client Quit]
Laurence_b has quit [Ping timeout: 245 seconds]
<marex>
sjg1: Tartarus: got any hint how to debug failure to start in SPL with LTO enabled , which does NOT occur with LTO disabled ?
<marex>
with LTO enabled , not even a peep
<marex>
with LTO disabled, SPL starts normally
<Tartarus>
You can disable LTO per obbject with -fno-lto
<Tartarus>
Do that to narrow down where things are failing in
<sjg1>
marex: Check things like linker lists and events are not dropped from the image. Although I think Tom fixed linker lists with LTO
<sjg1>
Kwiboo: Do you know why USB is so very slow on rockpro64? It is barely usable
<marex>
sjg1: hum, it does use the standard armv7a linker file, not a custom one
<marex>
but yes, there is size difference in the SPL indicated by readelf
<marex>
is there some way to diff symbols easily ?
<Tartarus>
sjg1: OK, I grabbed your 4 patches and rebuilt for rockpro64-rk3399 and good news, bootcmd no longer oopses, bad news Armbian on mmc1 isn't booted, but good news Fedora on USB is
<Tartarus>
marex: I would suggest disabling LTO for things under arch/ and board/ and if it boots then, start narrowing down the file that leads to failure
<Tartarus>
There's likely something "funny" being done in one of those files, and just wrong enough that LTO trips it up
<Tartarus>
(like those "data" not ".data" sections you fixed the other day)
<marex>
Tartarus: how do you do that 'disable LTO for things under ...' ?
<Tartarus>
CFLAGS_foo.o += -fno-lto
<marex>
Tartarus: I tried that but maybe I didn't do that just right
<marex>
hum, there is also a bulk way for dirs, I tried that too
<marex>
no dice
<Tartarus>
Ugh, I know there's a way
<Tartarus>
Adam Ford did it as part of debugging LTO on some of the first boards to support it
<marex>
I know there is
<marex>
I used that, didnt help me narrow it down either
<marex>
Tartarus: that still works on single files btw
<Tartarus>
Yes
<Tartarus>
Sorry, to be clear, I mean for debugging the problem
<Tartarus>
remove from single files
<Tartarus>
then narrow it down to which file it's failing from
<Tartarus>
Then see if something sticks out as maybe a problem
<marex>
Tartarus: there is too many files to do that , esp. if you still dont know which file is the culprit
<marex>
you can do it for whole dirs too
<marex>
also does not help
<Tartarus>
It's not that many files? And it's _probably_ on some file that's not been used with LTO in SPL before
<marex>
or rather, there is some subdir-cflags-y where you can just stick -fno-lto at the end
<Tartarus>
So arch/arm/lib/ should be fine
<Tartarus>
but maybe it's one of the board files
<Tartarus>
or arch-specific ones
<Tartarus>
I assume you enabled debug uart stuff and still get nothing
<marex>
no, I didn't use debug uart yet
<Tartarus>
Oh, I'd pop in debug uart and see where it's getting to
<Tartarus>
that might narrow down to what file(s) to disable LTO on
<marex>
but again, I inhibited LTO for very much every root dir with subdir-cflags, which did not help
<marex>
thats one option, jtag is another
<marex>
but I do detect size difference in the SPL, by like 1 kiB
<marex>
so I would like to know where that is coming from
<Tartarus>
You're sure it disabled LTO? Sorry, I missed that you had figured that part out.
<Tartarus>
I would go with debug uart yes, next, to see where things are failing
<Tartarus>
sjg1: Lemme know if you have more ideas about why armbian doesn't start for me, on MMC. It ought, since mmc1:1 /boot/boot.scr exists, but I didn't try and force it by hand
<Kwiboo>
sjg1: I can see that the usb2 ports on rockpro64 stay in usb full speed (12mbit) instead of high speed (480mbit), will see if some work-in-progress patches related to rk3328 and rk-inno-usb2 also can fix that
vagrantc has joined #u-boot
Kwiboo has quit [Ping timeout: 240 seconds]
Kwiboo has joined #u-boot
jaganteki has joined #u-boot
mmu_man has joined #u-boot
tlwoerner_ has quit [Quit: Leaving]
mmu_man has quit [Ping timeout: 240 seconds]
<__ad>
marex: looking into that qemu pit timer, just to understand, was there a specific reason you didn't used the interrupt ?
<marex>
__ad: which interrupt ? :)
<__ad>
pit0 timer interrupt handler
<marex>
__ad: somehow I suspect the reason was, interrupt was not implemented
<marex>
__ad: but I might be wrong
<marex>
__ad: but uh ... maybe because U-Boot is not using interrupts if that's the new timer driver you are talking about
<__ad>
marex: yes, that is, seems. I am trying to use the interrupt now, not generated any pit0 interrupt
<marex>
__ad: why the interrupt ?
<marex>
is there any benefit to that ?
ikarso has joined #u-boot
<__ad>
to timeticks++
<marex>
what is that used for ?
<__ad>
when called get_ticks(), ticks should be a u64 counter
<marex>
and the timer is 16bit ?
<marex>
the uboot timer implementation is some truly grotesque convoluted code :)
<marex>
but there was something to handle 32bit->64bit timer up-conversion already
<marex>
maybe you need 16bit->32bit one now
<__ad>
the counter reg is 16bit, yes. get_ticks() returns a u64. Actually, i am testing a watchdog driver, i have totally crapped up cyclic function time, and also, sleep 1 returns immediately.
<marex>
ah
<__ad>
so was trying to change the timer using the pit0 interrupt. But the interrupt seems never generated, likely not impleemnted
<__ad>
fish is ready, going to dinner :)
<marex>
__ad: lemme ask again, pit0 is the old timer or new timer driver ?
<marex>
I guess the new one ?
<marex>
I know the old one isnt implemented in qemu for sure
<marex>
the new one should be, but I cannot tell whether the interrupt line is wired correctly anywhere
<__ad>
pit0 is the one used from you, since the older (dma timer) is not implemented, as for your comments in the patch
<marex>
yep
<marex>
__ad: you can always look into qemu hw/ directory
<marex>
__ad: that's where qemu implements all the m68k stuff
<marex>
heck you can even add printf() there and see what the other side does ;)
<__ad>
yes, checking there. After dinner will be bavck on this. Thanks !