frieder has quit [Remote host closed the connection]
apteryx has joined #u-boot
guillaume_g has quit [Ping timeout: 264 seconds]
GNUtoo_ has quit [Ping timeout: 255 seconds]
underpantsgnome[ has quit [Quit: You have been kicked for being idle]
GuySoft has joined #u-boot
ikarso has quit [Quit: Connection closed for inactivity]
<GuySoft>
marc1, they did and say they don't fully support Debian, they just provide it as a reference. I am considering adding a PR to https://github.com/varigit/debian-var/blob/debian_bullseye_var01/var_make_debian.sh#L728 and adding the uboot-initial-env target, but I am doing this as part of work and I am not sure they will let me because of IP contracts
<georgem>
cambrian_invader: awesome, thanks for the info!
Leopold has quit [Remote host closed the connection]
frieder has quit [Remote host closed the connection]
Leopold has joined #u-boot
cottsay has quit [Quit: TTFN]
cottsay has joined #u-boot
guillaume_g has quit [Quit: Konversation terminated!]
vagrantc has joined #u-boot
torez has joined #u-boot
PhoenixMage has quit [Ping timeout: 260 seconds]
PhoenixMage has joined #u-boot
monstr has quit [Remote host closed the connection]
mmu_man has quit [Ping timeout: 252 seconds]
<paulbarker>
Just to check my understanding of the filesystem & block layers in u-boot: Am I right that a filesystem can only run on top of a device which implements the blk API?
<paulbarker>
i.e has a `struct blk_desc`
<paulbarker>
I want to put a squashfs image onto SPI flash and then load the kernel from within the squashfs filesystem, but it looks like it may not be possible as the SPI flash driver doesn't appear to implement the blk API
mmu_man has joined #u-boot
<cambrian_invader>
paulbarker: try ubi
<cambrian_invader>
you could also implement a block class
mmu_man has quit [Quit: Lost terminal]
<paulbarker>
cambrian_invader: ubifs could be an option, though I would prefer squashfs for the better compression support
<cambrian_invader>
no, I meant just ubi
<cambrian_invader>
and stick your squashfs on a partition
<paulbarker>
cambrian_invader: I don't think the ubi driver in u-boot implements the blk API either
<cambrian_invader>
it does
<cambrian_invader>
you boot up and run `ubi part 5` (or whatever) and it creates a block device called ubi
<cambrian_invader>
not really the most orthogonal system, but...
<paulbarker>
cambrian_invader: I can't see any use of `blk_desc` in `drivers/mtd/ubi` or `cmd/ubi.c` so unsure how filesystem mounting would work
mmu_man has joined #u-boot
<cambrian_invader>
huh, I guess it doesn't create a generic block device (although it could)
<cambrian_invader>
ugh, the whole ubi stuff is a mess
<paulbarker>
cambrian_invader: Yes, I think some extension would be required in either case
<paulbarker>
I will add it to my list of ideas, though there's already many in the backlog
<paulbarker>
For now I will stick with separate SPI flash partitions for the kernel, dtb and rootfs so that u-boot does not have to read the kernel & dtb from within the rootfs
<paulbarker>
That does require static partitioning of space for those files which has overhead, but it does work
<marex>
cambrian_invader: yes :)
<cambrian_invader>
paulbarker: you can always use a fit...
<cambrian_invader>
although you still have to have an upper bound
<paulbarker>
fit is an option, it kind of inverts things so the fit contains the rootfs. Could be worth a look
vfazio__ has quit [Read error: Connection reset by peer]
<marex>
you can always send patches to implement block device on top of MTD device ...
vfazio__ has joined #u-boot
<paulbarker>
marex: I'd like to. It's now on my list, but not top priority right now
<paulbarker>
cambrian_invader: fit does imply an initramfs instead of squashfs if I understand correctly. But the rootfs will be small when it's on SPI flash anyway (several MB at most) so loading it all at once into memory is fine
<cambrian_invader>
last I mucked about with this was for the k210 and for that I just punted and used an mmc rootfs
sbach has quit [Read error: Connection reset by peer]