RE: [PATCH 2/2] arch: arm64: configs: Enable UBI and UBIFS

[Lee, Kah Jing]

> -----Original Message-----
> From: Krzysztof Kozlowski <krzysztof.kozlowski@xxxxxxxxxx>
> Sent: Saturday, 24 June, 2023 3:30 PM
> To: Lee, Kah Jing <kah.jing.lee@xxxxxxxxx>; Dinh Nguyen
> <dinguyen@xxxxxxxxxx>; Rob Herring <robh+dt@xxxxxxxxxx>; Krzysztof
> Kozlowski <krzysztof.kozlowski+dt@xxxxxxxxxx>; Conor Dooley
> <conor+dt@xxxxxxxxxx>; Catalin Marinas <catalin.marinas@xxxxxxx>; Will
> Deacon <will@xxxxxxxxxx>
> Cc: linux-kernel@xxxxxxxxxxxxxxx
> Subject: Re: [PATCH 2/2] arch: arm64: configs: Enable UBI and UBIFS
> 
> On 24/06/2023 05:42, Lee, Kah Jing wrote:
> >>>> So you miss init ramdisk.
> >>> Currently we are using the bootargs to mount the rootfs from QSPI
> >>> NOR
> >> flash:
> >>> [    0.000000] Kernel command line: earlycon panic=-1 ubi.mtd=1
> >> root=ubi0:rootfs rootfstype=ubifs rw rootwait
> >>> Is it possible to mount the ubifs rootfs with the ubifs=m config during
> boot?
> >>
> >> I think yes. rootfs devices are for example modules, so filesystem
> >> can be as well.
> > Was going through mtd ubifs page -
> > http://www.linux-mtd.infradead.org/faq/ubifs.html
> > Quoted: 'In order to mount UBIFS as the root file system, you have to
> > compile UBIFS into the kernel (instead of compiling it as a kernel
> > module) and specify proper kernel boot arguments and make the kernel
> mount UBIFS on boot.'
> 
> Why? Module loaded by initramfs would also understand cmdline arguments,
> right?
The suggestion is to use initramfs for rootfs -> remount UBIFS as chroot?
The concern is additional initrd image and steps to store in the
limited NOR flash (256MB, Boot data + Uboot - ~66MB, UBIFS image - ~88MB, 
kernel.itb - ~10MB = 164MB).
With the mounting Rootfs from UBIFS volume, we can skip the initrd step, and
save some space for the user operations. 
Let me know if I understands that correctly.
> 
> Best regards,
> Krzysztof

Thanks. 

Regards, 
Lee, Kah Jing