[OpenWrt-Devel] [PATCH] kirkwood: include kernel images and DTB in rootfs

[Nathan Hintz]

> Date: Sat, 24 Jan 2015 12:25:41 +0100
> From: daniel at makrotopia.org
> To: openwrt-devel at lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH] kirkwood: include kernel images and DTB in rootfs
> 
> Hi Nathan,
> 
> I don't believe that files inside UBIFS rootfs is the right approach for
> kernel and dtb. Given that the bootloader already supports UBI, why not
> use use a UBI volume instead?
> While U-Boot does support reading files from UBIFS, squashfs inside UBI
> volumes are not supported (squashfs inside read-only UBI volume is
> desirable if you like having the features depending on ROM+overlay such as
> failsafe and factory restore similar to other hardware targets).
> 
> The Kirkwood target is part of OpenWrt for a long while already, longer
> than proper UBI support is around and long before wasting any thoughts
> about rootfs_overlay on NAND.
> Our current "state of the art" is to have squashfs read-only rootfs, just
> like on NOR devices, using UBIFS as rootfs_overlay (instead of JFFS2 on
> NOR). For bootloaders supporting UBI it makes sense to store kernel (and
> DTB) in a UBI volume and load them from there.
> Take a look at SysupgradeNAND and UbinizeImage targets in image.mk for
> examples.
> 
> 
> Cheers
> 
> 
> Daniel
> 
> 
Hi Daniel,

What I've been working on lately is to get OpenWrt running on a GuruPlug Server Plus I have 
that has been mostly gathering dust up until now.  I've updated to the latest uboot, patched for
Guruplug in a similar fashion to the Dockstar/IConnect/PogoPlug patches that can be found in
"package/boot/uboot-kirkwood/patches" (but w/o "second_stage_uboot").  All of those devices
have been patched to load the kernel image and DTB from the rootfs (based on the default
environment variables set up in the OpenWrt uboot), and I basically followed that model.  What
I don't understand is how any of those would work out of the box unless you were to specify to
include the kernal image and DTB in the rootfs (which none of them do).  I'm obviously missing
something.  Any ideas?

The change you are suggesting would probably best be addressed by the target maintainer;
but I may experiment with it a bit too.

Thanks for the pointers!

Nathan

> 
> On Fri, Jan 23, 2015 at 08:57:57PM -0800, Nathan Hintz wrote:
> > For SheevaPlug and GuruPlug devices.
> > 
> > Signed-off-by: Nathan Hintz <nlhintz at hotmail.com>
> > ---
> >  target/linux/kirkwood/profiles/120-plug.mk | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/target/linux/kirkwood/profiles/120-plug.mk b/target/linux/kirkwood/profiles/120-plug.mk
> > index dcbda71..473955d 100644
> > --- a/target/linux/kirkwood/profiles/120-plug.mk
> > +++ b/target/linux/kirkwood/profiles/120-plug.mk
> > @@ -7,6 +7,7 @@
> >  
> >  define Profile/SHEEVAPLUG
> >    NAME:=Globalscale Technologies SheevaPlug
> > +  DEPENDS:=+ at TARGET_ROOTFS_INCLUDE_KERNEL + at TARGET_ROOTFS_INCLUDE_ZIMAGE + at TARGET_ROOTFS_INCLUDE_DTB
> >    PACKAGES:= \
> >  	kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \
> >  	kmod-of-i2c kmod-i2c-core kmod-i2c-mv64xxx \
> > @@ -24,6 +25,7 @@ $(eval $(call Profile,SHEEVAPLUG))
> >  
> >  define Profile/SHEEVAPLUGSATA
> >    NAME:=Globalscale Technologies eSATA SheevaPlug
> > +  DEPENDS:=+ at TARGET_ROOTFS_INCLUDE_KERNEL + at TARGET_ROOTFS_INCLUDE_ZIMAGE + at TARGET_ROOTFS_INCLUDE_DTB
> >    PACKAGES:= \
> >  	kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \
> >  	kmod-of-i2c kmod-i2c-core kmod-i2c-mv64xxx \
> > @@ -42,6 +44,7 @@ $(eval $(call Profile,SHEEVAPLUGSATA))
> >  
> >  define Profile/Guruplug-Server-Plus
> >    NAME:=Globalscale Technologies Guruplug Server Plus
> > +  DEPENDS:=+ at TARGET_ROOTFS_INCLUDE_KERNEL + at TARGET_ROOTFS_INCLUDE_ZIMAGE + at TARGET_ROOTFS_INCLUDE_DTB
> >    PACKAGES:= \
> >  	kmod-mmc kmod-mvsdio kmod-usb2 kmod-usb-storage \
> >  	kmod-of-i2c kmod-i2c-core kmod-i2c-mv64xxx \
> > -- 
> > 1.9.3
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel at lists.openwrt.org
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150124/40fe07ee/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel