[OpenWrt-Devel] [PATCH] [kirkwood-dockstar] minor fixes

Marcus Osdoba marcus.osdoba at googlemail.com
Thu Nov 11 21:10:26 CET 2010

Am 02.11.2010 08:37, schrieb Imre Kaloz:
> Hi,
> 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 
arcNumbers, etc.).

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:
>> https://dev.openwrt.org/ticket/7643
> 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 mailing list