> Date: Sat, 24 Jan 2015 12:25:41 +0100
> From: [email protected]
> To: [email protected]
> 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 <[email protected]>
> > ---
> >  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:=+@TARGET_ROOTFS_INCLUDE_KERNEL +@TARGET_ROOTFS_INCLUDE_ZIMAGE 
> > +@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:=+@TARGET_ROOTFS_INCLUDE_KERNEL +@TARGET_ROOTFS_INCLUDE_ZIMAGE 
> > +@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:=+@TARGET_ROOTFS_INCLUDE_KERNEL +@TARGET_ROOTFS_INCLUDE_ZIMAGE 
> > +@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
> > [email protected]
> > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> _______________________________________________
> openwrt-devel mailing list
> [email protected]
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

                                          
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to