jwillikers has quit [Remote host closed the connection]
mrnuke_ has quit [Read error: Connection reset by peer]
mrnuke has joined #u-boot
mmu_man has quit [Ping timeout: 265 seconds]
aquijoule__ has joined #u-boot
akaWolf has quit [Ping timeout: 272 seconds]
akaWolf has joined #u-boot
aquijoule_ has quit [Ping timeout: 246 seconds]
LeSpocky_ has joined #u-boot
LeSpocky has quit [Ping timeout: 252 seconds]
vagrantc has joined #u-boot
mranostaj has quit [Ping timeout: 252 seconds]
mranostaj has joined #u-boot
vagrantc has quit [Quit: leaving]
agust has joined #u-boot
redbrain has joined #u-boot
redbrain has quit [Ping timeout: 252 seconds]
ceene has left #u-boot [Leaving]
frieder has joined #u-boot
LeSpocky_ is now known as LeSpocky
redbrain has joined #u-boot
jtf has quit [Quit: WeeChat 2.6]
fdanis_away is now known as fdanis
jtf has joined #u-boot
tnovotny has joined #u-boot
mranostaj has quit [Ping timeout: 265 seconds]
mranostaj has joined #u-boot
guillaume_g has joined #u-boot
sszy has joined #u-boot
ilunev has joined #u-boot
matthias_bgg has joined #u-boot
ladis has joined #u-boot
ladis_ has joined #u-boot
ladis_ has quit [Client Quit]
ladis has quit [Client Quit]
ladis has joined #u-boot
mmu_man has joined #u-boot
frieder has quit [Remote host closed the connection]
alpernebbi has joined #u-boot
frieder has joined #u-boot
ladis has quit [Quit: Leaving]
ladis has joined #u-boot
jwillikers has joined #u-boot
Duality is now known as Guest5276
Guest5276 has quit [Killed (copper.libera.chat (Nickname regained by services))]
Daulity is now known as Duality
pi___ has joined #u-boot
<milkylainen>
hmm. rules/Kconfig can't be local? I tried to copy Kconfig to my local rules directory. But changes wouldn't bite unless I edited the lib/ptxdist/rules/Kconfig?
<milkylainen>
Opps
<milkylainen>
Wrong channel. :)
mmu_man has quit [Ping timeout: 265 seconds]
frieder has quit [Ping timeout: 252 seconds]
frieder has joined #u-boot
mmu_man has joined #u-boot
matthias_bgg has quit [Ping timeout: 246 seconds]
hanetzer has quit [Quit: WeeChat 3.0.1]
brujah has joined #u-boot
<replayer76>
what is the best way to debug when kernel is loaded and uboot runs start_kernel, but then immediately resets
<replayer76>
?
hanetzer has joined #u-boot
hanetzer has joined #u-boot
hanetzer has quit [Changing host]
ilunev has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rfs613>
replayer76: do you see "Starting kernel..." message? How about "Uncompressing Linux..."?
<replayer76>
rfs613: i see "starting kernel", it is a fit image and succesfully loaded (i guess), uboot also gives some info on the image, last i see from uboot before it resets is "accumulated time"
<rfs613>
replayer76: looks like 'accumulated time' is from u-boot, this should come just before "Starting kernel..."
<replayer76>
the image is 64bit linux kernel, "booted" with bootm, booting a 64bit bzimage works though with zboot, also booting 32 bit kernels with or without fit does work
<rfs613>
replayer76: oh, so x86 platform, seems that one prints "Starting kernel..." first, then bootstage "accumulated time".
<mrnuke>
replayer76: When I get such problems, I usually have to bust out the JTAG and step through it wth GDB
<rfs613>
before resorting to that, I would try commenting out the call to dm_remove_devices_flags(DM_REMOVE_ACTIVE_ALL) in arch/x86/lib/bootm.c line 50.
<rfs613>
it might not apply on all systems, but I found recently that this shuts down the serial port, so following printf()/debug() prints do not appear.
<mrnuke>
if you do decide to go all leroy jenkins on it with GDB, it might help to get the debug symbols: https://paste.debian.net/1203802/
<sjg1>
replayer76: is this x86?
<replayer76>
sjg1: yes, kindof, it is currently 32bit uboot and 64 or 32 bit kernels with different format (fit, bzimage)
<sjg1>
So you are loading a 64-bit kernel in a FIT?
<replayer76>
i try to, this is the combination which is not working
<sjg1>
replayer76: Did you see x86-fit-boot.txt ?
<replayer76>
sjg1: i did, i build the fit images according to this file, and at least the 32bit fit image is working
<sjg1>
rfs613: That sounds like a bug. The serial port should not have the DM_FLAG_ACTIVE_DMA or DM_FLAG_OS_PREPARE flags set, so should not be removed before booting Linux
<sjg1>
replayer76: Hmm can you paste the full boot load and also objdump -h vmlinux ?
<sjg1>
replayer76: *full boot log
torez has joined #u-boot
<rfs613>
sjg1: it seemed odd to me too. And as far as I can tell, the uart has neither of these flags set.
guillaume_g has quit [Quit: Konversation terminated!]
redbrain has quit [Quit: leaving]
<sjg1>
rfs613: Would you minding taking a look? It does sound like a bug
<rfs613>
sjg1: i've been doing that in fact, and now I'm more confused ;-)
<marex>
and well, there are arbitrary rules to the commit messages and so on, kind of like picking a password for a website with bad validator (has to be long, but not too long , must have a digit, but not larger than 5 , special character but not comma etc )
<marex>
I guess I will just stick with checkpatch for now :)
<sjg1>
marex: I still wonder if the bits of ATF that are useful should move into SPL, before ATF becomes its own bootloader with devicetree, driver model, etc.
<marex>
sjg1: yes and no
<marex>
sjg1: I have an idea how to go about it
<marex>
sjg1: I think we want some xPL self-contained PSCI implementation which can be started from fitImage either by U-Boot running in EL3 _before_ starting Linux OR by SPL in falcon-mode
redbrain has joined #u-boot
<sjg1>
replayer76: I haven't got a log from when I last tried. I wonder if the VMA being so high is normal? Is linux expecting to copy the kernel there? It didn't used to
<sjg1>
replayer76: Can you enable the early console in linux?
<sjg1>
marex: OK. I heard that ATF can boot linux by itself now! Soon it will have multitasking :-)
vagrantc has joined #u-boot
<marex>
sjg1: arm64 mandates minimal PSCI implementation, that's what I think we should aim for
<marex>
iopaniuk: mrnuke: ^
<mrnuke>
marex: what the frog was wrong with kernel style commit messahges that a hoard of doofuses had to create a conflicting spec for this?
<mrnuke>
"feat: of strength, or is ti strength of feet"
<mrnuke>
marex: I agree with having some infrastructure for PSCI. Then boards could plug in their own PSCI drivers -- maybe using DM
<marex>
mrnuke: actually no, all you need is to turn CPU cores on/off, the rest is SCMI and that is the next step (if ever)
<marex>
mrnuke: and cpu core on/off is generic arch code
<marex>
mrnuke: I would rather let linux handle all the rest, instead of hiding it in any firmware
<mrnuke>
marex: if CPU on/CPU off is generic arch code, what prevents linux from doing it itself?
<sjg1>
rfs613: Which board is this? There must be something horribly wrong
<sjg1>
rfs613: Current tests are in dm_test_remove_active_dma() and dm_test_remove_vital()
<sjg1>
rfs613: You could add a check for your device in device_remove() and see why it is removing it. E.g. flags_remove() should return -EKEYREJECTED in your case, I think
<sjg1>
marex: Sounds good to me
ladis has quit [Quit: Leaving]
<marex>
mrnuke: there is some virtualization constraint, search for xen
matthias_bgg has quit [Quit: Leaving]
<rfs613>
sjg1: it's an out-of-tree board (might be looking to fix that...) based on RZ/N1D SoC from Renesas.
<rfs613>
sjg1: i've debugged device_remove(), the serial output stops after calling uclass_pre_remove_device(), which in this case invokes serial_pre_remove(), which in turn calls stdio_deregister_dev()
<rfs613>
sjg1: so I guess if I disabled CONFIG_SYS_STDIO_DEREGISTER this will also fix the problem...
replayer76 has quit [Ping timeout: 246 seconds]
<rfs613>
I've got this enabled thanks to having CONFIG_USB_KEYBOARD=y
<rfs613>
sjg1: right, confirmed, when I disable CONFIG_USB_KEYBOARD and CONFIG_SYS_STDIO_DEREGISTER, no more missing prints.
<rfs613>
so, this does seem like a bug, but I don't know what the right fix is ;-)
<rfs613>
sjg1: looks like I can fix it by adding a check for dev == gd->cur_serial_dev
replayer has joined #u-boot
<sjg1>
rfs613: Well uclass_pre_remove_device() is called after the check of flags_remove(), so we still need to know why flags_remove() is returning 0 (indicating that the removal is allowed). It should not, as I understand it
<rfs613>
sjg1: flags_remove() check is after uclass_pre_remove_device()
<rfs613>
oh, looks like that got changed between 2020.07 that i'm using, and the current version...