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

Attachment: signature.asc
Description: PGP signature

Reply via email to