On Fri, Jul 10, 2020 at 11:13:50AM +0200, Thomas Petazzoni wrote: > On Fri, 10 Jul 2020 10:54:24 +0200 > Rasmus Villemoes <rasmus.villem...@prevas.dk> wrote: > > > > It's very much like the FAT filesystem case: if you have U-Boot proper > > > and your Linux kernel image in a FAT filesystem, > > > > No, this is very much _not_ like the above. In this paragraph, you > > combine "U-Boot proper and your Linux kernel", imposing an implicit > > assumption that they are stored in the same way. Sure, _if_ both these > > items are stored in squashfs images (possibly the same, possibly > > distinct), then the thing that loads the respective images obviously > > needs squashfs (or FAT, or whatnot) support. > > > > My point is that it's possible that, say, U-Boot proper is stored in a > > FAT file system, and the kernel is stored in a UBI volume. So SPL needs > > FAT support. Why should I be forced to compile FAT support into U-Boot > > proper if U-Boot proper never needs to access a FAT filesystem? And the > > same for squashfs. Or any of the drivers or DM_ frameworks that do that > > "depends on" or "select". > > Ah, I absolutely agree that it should be possible to have Squashfs in > both SPL and U-Boot proper, or only in SPL or only in U-Boot proper. > > It was not clear in your initial e-mail that this was the issue you > were pointing.
Note that on this point the question is, do we have a use case for falcon mode and loading linux from squashfs? I assume the answer is yes, and that's why we would want to have squashfs be enabled in SPL. -- Tom
signature.asc
Description: PGP signature