<kallisti5>
cambrian_invader: no worries. I don't submit many u-boot patches, so wanted to make sure I wasn't missing something :-)
torez has quit [Quit: torez]
alan_o has quit [Ping timeout: 258 seconds]
alan_o has joined #u-boot
vagrantc has quit [Quit: leaving]
LeSpocky_ has joined #u-boot
LeSpocky has quit [Ping timeout: 240 seconds]
Gravis has quit [Read error: Connection reset by peer]
Gravis has joined #u-boot
mmu_man has quit [Ping timeout: 248 seconds]
jwillikers has quit [Remote host closed the connection]
Jaanes has quit [Ping timeout: 248 seconds]
Wizzup has quit [Ping timeout: 272 seconds]
Wizzup has joined #u-boot
indy has quit [Ping timeout: 268 seconds]
indy has joined #u-boot
monstr has joined #u-boot
Jaanes has joined #u-boot
LeSpocky_ is now known as LeSpocky
agust has joined #u-boot
indy has quit [Ping timeout: 240 seconds]
indy has joined #u-boot
frieder has joined #u-boot
fdanis_away is now known as fdanis
sbach has quit [Read error: Connection reset by peer]
sbach has joined #u-boot
fdanis is now known as fdanis_away
milkylainen has joined #u-boot
fdanis_away is now known as fdanis
sszy has joined #u-boot
<marex>
kallisti5: why do you need to start usb in preboot ?
tre has joined #u-boot
alpernebbi has joined #u-boot
rtjure has joined #u-boot
<LeSpocky>
does any board in u-boot already use raw nand partitions defined in dts? I saw some dts files with partitions defined, but are those actually parsed and used?
<rtjure>
Is it appropriate to ask for help with older U-boot here? I would like to fix an older Buffalo Linkstation that I managed to tftp boot from, but fail to boot from harddrive with.
<LeSpocky>
I think asking is appropriate, you might get no answer though
<marex>
LeSpocky: u-boot usually defines those partitions and passes them to linux
<marex>
rtjure: problem with old downstream forks is that they are usually modified to the point where any hint you get here might not even apply
<marex>
so ask, but keep in mind the answer might not work
<LeSpocky>
marex: in the past I used MTDPARTS_DEFAULT and the kernel cmdline for defining mtdparts
<LeSpocky>
but I read in different places, that the plan for the future is to have those partitions defined in dts
<LeSpocky>
and for a new board, I just tried to find out if that should already work
<LeSpocky>
difficult ;-)
<LeSpocky>
marex: btw, I think I solved the boot hanging problem with the sama5d27 sip d5m, I'll post a follow up to the mailing list once I'm confidend it works reliably
<rtjure>
LeSpocky: thanks! Replies on IRC are always a balance and channel dependent. It looked a bit like a dev oriented channel so I was not sure if there is a better place maybe..
<rtjure>
I will post boot messages, help output and printenv to pastebin to give a better idea what I am talking about.
<LeSpocky>
rtjure: judging from the log, the ethernet adapter has no link, thus no data is transfered over tftp
<rtjure>
LeSpocky: Correct, I want it to boot from disk. I booted from tftp earlier and installed Debian with the tftp on said disk. Tftp work fine. It's the booting from HDD part that does not.
<rtjure>
Yes, it is ancient.. retrocomputing, one might say
<LeSpocky>
"Wrong Image Type for bootm command"
<rtjure>
I saw it, yes. not sure what that means, ie what bootm expects.. Also I am unsure why I see a ** Bad partition 1 ** on ide0. My suspicion is that the bootargs_root or the bootcmd_sata are set incorrectly. Are you suggesting I have the wrong image installed?
<LeSpocky>
did you compare the images on the hard disk with those from tftp?
<rtjure>
I booted from tftp and installed that way(debian exposes the installer via ssh and serial), so unless it downloaded a different version during install, it should be the same one.
<rtjure>
I also thought that I might have messed up the partitioning. But at that point these are too many failure points that are hard to verify through testing, so I came here.
<rtjure>
bootcmd_sata=ide reset; ext2load ide 0:1 0x01100000 /uInitrd; ext2load ide 1:1 0x00800000 /uImage looks particularly suspicious to me as it seems to look for the initrd on ide 0:1 and for the kernel/uimage on ide 1:1 .
jwillikers has joined #u-boot
jwillikers has quit [Remote host closed the connection]
<marex>
urja: so where is the compressed initramfs unpacked if not loop device ?
<milkylainen_>
1. initramfs || initrd?
<milkylainen_>
2. compressed and supported compression?
<milkylainen_>
3. init at /init?
<ad__>
milkylainen_, i have /init
<urja>
marex: to the kernels first ever filesystem, the unmountable always existing rootfs (that's a tmpfs or a ramfs depending on what you have enabled)
<ad__>
now i set CONFIG_BLK_DEV_LOOP as y
<ad__>
trying
<urja>
the cpio is just unpacked/written file by file into the tmpfs, essentially
<milkylainen_>
ad__: And is executable? like kernel interface not older than what C-library expects?
<marex>
urja: maybe that would require CONFIG_BLK_DEV_RAM or TMPFS enabled ?
<milkylainen_>
cmdline not containing something funky?
<urja>
marex: nah, neither
<milkylainen_>
tmpfs must be enabled for initramfs.
<marex>
well there we have two contradicting opinions right there
<urja>
BLK_DEV_RAM is the old initrd stuff, TMPFS is just fancy ramfs
<milkylainen_>
otherwise I think it ends up in a block ramdisk.
<marex>
ad__: so , bottom like is, enable them all and then figure out which one was missing ?
<marex>
*ine
<marex>
*line
<urja>
milkylainen_: show me the code for that :P
<milkylainen_>
urja: for what?
<urja>
"otherwise I think it ends up in a block ramdisk."
<urja>
it first unpacks the embedded cpio to the rootfs, then tries to unpack the externally provided memory area... if it fails, it tries it as an initrd
<milkylainen_>
ok. Did we solve ad__s problems? :)
<milkylainen_>
marex: Btw. Finally fond a working bootloader solution. And it wasn't this one. :P
<urja>
*shrug*, but atleast the point was ... dabbling with those options will not help (if they're doing what they say they're doing...)
<milkylainen_>
found, even.
<milkylainen_>
ad__: Arch = ARM I assume? (since you're trying to embed the dtb).
<milkylainen_>
ad__: kernel cmdline?
<milkylainen_>
Or log.
<marex>
milkylainen_: enjoy your vendor lock-in, broken on crap code etc
<marex>
*old
<milkylainen_>
marex: hmm? you mean the EFI eMMC BLOCK_IO presentation?
fdanis is now known as fdanis_away
<milkylainen_>
I'd happily go native. But one step at a time.
frieder has joined #u-boot
frieder has quit [Remote host closed the connection]
FO2 has joined #u-boot
FO3 has joined #u-boot
FO2 has quit [Quit: Leaving]
sszy has quit [Ping timeout: 240 seconds]
<marex>
ad__: you got it booting ?
<ad__>
marex, thanks a lot. i think i found the issue, cpio was not properly created, will try in short
jwillikers has quit [Remote host closed the connection]
jwillikers has joined #u-boot
<ad__>
marex, urja milkylainen_ thanks solved. mainly cpio was wrong, was missing /init
<milkylainen_>
ad__: placed in /sbin/init instead?
<ad__>
no was just missing /init
<ad__>
that seems mandatory to run initramfs without rdinit=
<marex>
I would expect the kernel to complain about the missing init rather than about unknown block
<marex>
hum
redbrain has quit [Ping timeout: 248 seconds]
<urja>
no /init is not distinguishable from no initramfs for the kernel, so it tries to mount a rootfs on top of it the old way
<urja>
(like for the code atleast... there always exists an empty(ish?) internal initramfs...)
<milkylainen_>
marex: I run into that. The thing seems that the kernel _always_ has an builtin initrd.
<milkylainen_>
marex: It's empty though. So a missing initramfs is normal.
<milkylainen_>
Which catches ppl out. Because their initramfs is broken.
<milkylainen_>
It does not differ between broken initramfs and no initramfs.