Zapy has quit [Read error: Connection reset by peer]
matthias_bgg has joined #u-boot
Zapy has joined #u-boot
redbrain has joined #u-boot
matthias_bgg has quit [Quit: Leaving]
jordemort has joined #u-boot
redbrain has quit [Ping timeout: 272 seconds]
<jordemort>
hi - i am having trouble booting a FIT image over TFTP. assume i am a complete fool and have no idea what i'm doing. i keep on running into `ERROR: new format image overwritten - must RESET the board to recover` - full log is here: https://gist.github.com/jordemort/9ec5b2bb0f5797c9d6e2a1f02e35af88
<jordemort>
my image is very large (35 meg) and i understand just barely enough to think that i'm overwriting something important in the process of loading it, and tweaking loadaddr might help? but i've tried playing with different tweaks to loadaddr and/or passing a different address to tftpboot and i either end up with the same results or u-boot refuses because i'm trying to overwrite reserved memory (i have no idea what memory ranges are reserved or
<jordemort>
appropriate for what uses on the device)
<jordemort>
i am flailing about trying to figure it out but any hints that might lead me to a better understanding of what i'm doing would be greatly appreciated
<jordemort>
i've also tried a 14M image (reduced initrd) and an 8.4M image (just the bare kernel) and still get the overwrite so whatever the threshold is it's below 8.4M or there's something i'm doing systematically wrong and no image would ever work
<jordemort>
aha, i've found a loadaddr that works
smartin has quit [Ping timeout: 240 seconds]
alpernebbi has quit [Quit: alpernebbi]
agust has quit [Ping timeout: 272 seconds]
akaWolf has quit [Ping timeout: 252 seconds]
<Tartarus>
xypron: Oh, do you have any comment on dropping grub for riscv32?
<Tartarus>
jordemort: OK, so, part of the problem is that you're loading the FIT image at the place in memory that you then want to move the kernel image to
<Tartarus>
That then blows up
<Tartarus>
jordemort: Try loading your FIT image in to memory a bit higher than where the kernel is going to be moved to.
<jordemort>
Tartarus: yep that worked, i bumped loadaddr up to 0x90800000 (from 0x80800000) and now it starts the kernel, but the kernel doesn't seem find/realize it has an initramfs
<Tartarus>
jordemort: boot log including kernel please :)
<jordemort>
you'll see in that log my environment, and that i hacked an env variable there to see if that was my problem, but it breaks the same w/o the hack
<Tartarus>
[ 0.556543] Trying to unpack rootfs image as initramfs...
<jordemort>
was just looking at that, wondering what it means
<Tartarus>
Well, looking up a bit more in the log, you pass in: bootargs=console=ttymxc0,115200 ubi.mtd=rootfs root=ubi0:rootfs rootfstype=ubifs mtdparts=gpmi-nand:8m(boot),2m(uboot_env),1m(sc_default),16m(nandtee),-(rootfs)
<Tartarus>
Which is seen and passed to the kernel
<Tartarus>
So, with the kernel log I also pasted, it sees your initrd, but doesn't see anything to do with it
<Tartarus>
and continues on
jwillikers has quit [Remote host closed the connection]
<jordemort>
should root be /dev/ram instead?
<jordemort>
i thought if there was an initramfs preset it ran it
<jordemort>
regardless of boot args; i'm wrong about that?
<Tartarus>
I don't know the contents of your initramfs either :)
<Tartarus>
I know if it's a cpio, and has /init, that /init will get run
<Tartarus>
If you want to use an initrd, not an initramfs, then yes root=/dev/ram is likely what you want
<jordemort>
it's a cpio and it should have /init
<jordemort>
looks like it's trying?
<jordemort>
[ 6.235496] Run /init as init process
<jordemort>
[ 6.243401] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
<Tartarus>
should or does? You can cat | cpio -id to extract a cpio in to your currrent dir
<Tartarus>
That later message about Run /init is from the UBI you told it to configure
<Tartarus>
And then it didn't find anything it liked in it
<jordemort>
Yes it has an /init
<jordemort>
just extracted the cpio the fit was allegedly built from to be sure, don't know how to take apart the fit; i'm using yocto
<jordemort>
fwiw my current initramfs recipe is extremely similar to another one which does work on the same machine, but i don't load that as fit, it's a "legacy format" separate zImage and cpio.gz.u-boot
<Tartarus>
but it's the same cpio in essence, so it should be working
<Tartarus>
and I assume Yocto is generating the FIT and not you by hand?
<jordemort>
correct
<jordemort>
hmm
<jordemort>
it's a cpio.gz right now
<jordemort>
should it just be a .cpio maybe?
<Tartarus>
No, it should be fine...
<Tartarus>
Can you do some debugging with your cpio /init to see if its' running or not?
<Tartarus>
like toggle a LED manually for a few seconds, or something?
<Tartarus>
getting console msgs out of initramfs is stupid hard I find anyhow
akaWolf has joined #u-boot
<jordemort>
my cpio /init should jump right into a shell
<jordemort>
although crap i'm not passing -i
<jordemort>
i bet that's it
<jordemort>
if it was running though it should have at least echoed something
<jordemort>
i'll stick set -x on it to be sure, it's just a shell script
jwillikers has joined #u-boot
<Tartarus>
set -x without a /dev/console can be funky
<Tartarus>
It's why I suggested LED toggling :)
<Tartarus>
I personally end up spending more time than I like every time I have to dig in to "why is this initramfs not doing what I want? is it even running?"
<jordemort>
yeah it's definitely not running it
<jordemort>
i put a couple sleeps in there and it ends with a reboot
<jordemort>
and none of that is happening
<jordemort>
out of time for today, but at least getting the kernel loaded is progress, thanks for your help Tartarus
jwillikers has quit [Remote host closed the connection]