[OpenWrt-Devel] [PATCH] [kirkwood-dockstar] minor fixes
marcus.osdoba at googlemail.com
Thu Nov 11 21:10:26 CET 2010
Am 02.11.2010 08:37, schrieb Imre Kaloz:
> On Mon, 01 Nov 2010 22:17:11 +0100, Marcus Osdoba
> <marcus.osdoba at googlemail.com> wrote:
>> The patches for the dockstar won't break history and they do not
>> introduce new features, so they are quite harmless. Is there any chance
>> to commit them to the current trunk?
> I'm surprised squashfs works for you, as it lacks nand support. For
> real, kirkwood should be moved to ubifs or (for a combined layout)
> squashfs+ubifs (over ubi). The whole jffs2 thing is stupid. For the
> bootloader part, things have to be changed a lot. Command line
> partition parsing is lame, the second stage bootloader (if it's really
> needed) should do what it's purpose, load a kernel, and the kernel
> should take care about partitioning.
Hi, thanks for have a look into this. I'm a bit confused, squashfs is a
quite common replacement for cramfs and works excellently with a lot of
routers. It can be written without problems on an nand device. The
problem is, that it won't work around broken blocks (no wear leveling).
I worked with the original buildroot before and built some experimental
support for the dockstar device. Buildroot already supports ubifs as
target image. If I would work on KIRKWOOD: USE_UBIFS=true, would you
have a look at a patchset?
Anyways, I like the overlay part very much!
Bootloader part: I strongly prefer the 2nd stage u-boot. Simple reason:
OpenWrt project could configure everything on its own, without touching
the original. A dockstar owner should be able to remove OpenWrt easily
and try other software, too. I think, the 2nd stage loader is the best
approach to separate OpenWrt from the rest of the world (differetn
Partitioning via commandline: Since OpenWrt patches the kernel, it could
define the mtd parts earlier - so basically agreed here. But again you
are a bit more flexible in using the commandline options. Maybe someone
prefers a completly different layout (two parallel openwrt versions,
other software in the last 32MiB, ...), it is more convenient to change
the u-Boot parameters than patching around in OpenWrt sources/patches.
I like to proceed with working on Dockstar support for OpenWrt. What
chance do I have to see patches integrated into mainline?
>> btw: mv_cesa should rely on crypto_aes like kmod-crypto-hw-padlock:
> I'll take a look at that later.
Change applied there was: https://dev.openwrt.org/changeset/22321
Module define KernelPackage/crypto-mv-cesa should additonally depend
Tested with current trunk and confirmed. If mv-cesa is built without aes
the module is not loadable.
More information about the openwrt-devel