[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <PH0PR11MB567351DA47A104A8D7CEED22CB29A@PH0PR11MB5673.namprd11.prod.outlook.com>
Date: Mon, 3 Jul 2023 04:06:20 +0000
From: "Lee, Kah Jing" <kah.jing.lee@...el.com>
To: Dinh Nguyen <dinguyen@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
"Conor Dooley" <conor+dt@...nel.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
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.
> >>
> >> arm64 defconfig creates huge development config for all platforms, so
> >> why would you ever use it in resource-constrained system? It would
> barely fit.
> >> defconfig modules take 50 MB alone and you don't need most of them.
> >>
> >> I think you misunderstood the purpose of this defconfig and now try
> >> to apply some arguments for different use cases.
> > Understood the point. In this case, I would drop this defconfig patch,
> > and document it for customers to enable through menuconfig.
> >
> > Will proceed to send the v3 for only dts changes.
> > Thanks for the time.
> >>
>
> You can still have the defconfig build them as modules. Then you can include
> them in your initramfs.
Understood, but we can maintain it as the wiki steps since previously for JFFS2
is part of the rocketboard page for users to follow to enable from menuconfig.
Thanks.
>
> Dinh
Regards,
Lee, Kah Jing
Powered by blists - more mailing lists