[OpenWrt-Devel] RFC: minor fixes for dockstar (kirkwood platform)
Hi mailinglist,
Please find attached a simple patchset which solved some of the issues,
I introduced in a forum thread:
https://forum.openwrt.org/viewtopic.php?id=27043
SeagateDockstar - kirkwood derivative
- squashfs and overlay support (u-boot config)
- pad jffs2-128k to 128k (as the name implies)
- create proper squashfs image
I'm new here. Please let me know, how to speed up the process to commit
these patches in mainline (and where they break your guidelines).
Is svn diff ok, or do you prefere git format-patch?
btw: mv_cesa should rely on crypto_aes like kmod-crypto-hw-padlock:
https://dev.openwrt.org/ticket/7643
Regards,
Ossy
this patch adds squashfs support to the feature list of the dockstar profile
Signed-off-by: marcus.osd...@googlemail.com
---
Index: target/linux/kirkwood/Makefile
===
--- target/linux/kirkwood/Makefile (Revision 23697)
+++ target/linux/kirkwood/Makefile (Arbeitskopie)
@@ -9,7 +9,7 @@
ARCH:=arm
BOARD:=kirkwood
BOARDNAME:=Marvell Kirkwood
-FEATURES:=targz usb jffs2
+FEATURES:=targz usb jffs2 squashfs
MAINTAINER:=Imre Kaloz
LINUX_VERSION:=2.6.35.7
pad the kernel to 128k,
pad jffs2-128k really to 128k as the name implies,
create a plain padded squashfs (without uImage in front)
this does not break history, since the image WITH uImage
in front is still created in parallel
Signed-off-by: marcus.osd...@googlemail.com
---
Index: target/linux/kirkwood/image/Makefile
===
--- target/linux/kirkwood/image/Makefile(Revision 23697)
+++ target/linux/kirkwood/image/Makefile(Arbeitskopie)
@@ -15,7 +15,7 @@
define Image/BuildKernel
# do mach-id fixup here, if needed
- cp $(KDIR)/uImage $(BIN_DIR)/$(IMG_PREFIX)-uImage
+ dd if=$(KDIR)/uImage of=$(BIN_DIR)/$(IMG_PREFIX)-uImage bs=128k
conv=sync
endef
define Image/Build
@@ -27,15 +27,17 @@
define Image/Build/jffs2-128k
dd if=$(KDIR)/root.$(1) of=$(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-$(1).img
\
- bs=2048 conv=sync
+ bs=128k conv=sync
endef
define Image/Build/squashfs
$(call prepare_generic_squashfs,$(KDIR)/root.squashfs)
+ dd if=$(KDIR)/root.$(1) bs=128k conv=sync \
+ of=$(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-$(1).img
( \
dd if=$(KDIR)/uImage bs=4096k conv=sync; \
dd if=$(KDIR)/root.$(1) bs=128k conv=sync; \
- ) > $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-$(1).img
+ ) > $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-uImage-$(1).img
endef
$(eval $(call BuildImage))
squashfs added as alternative to rootfstype, must be in order squashfs,jffs2
tested on dockstar with both jffs2 and squashfs - openwrt was started in both
cases
without updating the bootparameters,
rename data to rootfs_data since squashfs-version needs to have some overlay;
unfortunatly, the jffs2 version creates an overlay, too...
maybe this is not desired, but the situtation is not worse than before, since
one has to update the bootparmeters for using squashfs and overlay on two
places, now only one
Signed-off-by: marcus.osd...@googlemail.com
---
Index: package/uboot-kirkwood/files/include/configs/dockstar.h
===
--- package/uboot-kirkwood/files/include/configs/dockstar.h (Revision 23697)
+++ package/uboot-kirkwood/files/include/configs/dockstar.h (Arbeitskopie)
@@ -133,15 +133,18 @@
"setenv bootargs ${x_bootargs} ${x_bootargs_root}; "\
"${x_bootcmd_usb}; bootm 0x640;"
-#define CONFIG_MTDPARTS"orion_nand:1M(u-boot),"\
+#define CONFIG_MTDPARTS\
+ "orion_nand:1M(u-boot)," \
"1...@1m(second_stage_u-boot)," \
- "3...@2m(kernel),3...@5m(rootfs),2...@37m(data) rw\0"
+ "3...@2m(kernel)," \
+ "3...@5m(rootfs)," \
+ "2...@37m(rootfs_data)\0"
#define CONFIG_EXTRA_ENV_SETTINGS "x_bootargs=console"\
"=ttyS0,115200 mtdparts="CONFIG_MTDPARTS\
"x_bootcmd_kernel=nand read 0x640 0x20 0x30\0" \
"x_bootcmd_usb=usb start\0" \
- "x_bootargs_root=root=/dev/mtdblock3 rw rootfstype=jffs2\0"
+ "x_bootargs_root=root=/dev/mtdblock3 ro rootfstype=squashfs,jffs2\0"
/*
* Size of malloc() pool
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [kirkwood-dockstar] minor fixes
Hi again,
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?
So please find attached a simple patchset which solves some of the
issues, I introduced in a forum thread:
https://forum.openwrt.org/viewtopic.php?id=27043
SeagateDockstar - kirkwood derivative
- squashfs and overlay support (u-boot config)
- pad jffs2-128k to 128k (as the name implies)
- create proper squashfs image
I'm new here. Please let me know, how to speed up the process to commit
these patches in mainline (and where they break your guidelines).
Is svn diff ok, or do you prefere git format-patch?
btw: mv_cesa should rely on crypto_aes like kmod-crypto-hw-padlock:
https://dev.openwrt.org/ticket/7643
Regards,
Ossy
this patch adds squashfs support to the feature list of the dockstar profile
Signed-off-by: marcus.osd...@googlemail.com
---
Index: target/linux/kirkwood/Makefile
===
--- target/linux/kirkwood/Makefile (Revision 23697)
+++ target/linux/kirkwood/Makefile (Arbeitskopie)
@@ -9,7 +9,7 @@
ARCH:=arm
BOARD:=kirkwood
BOARDNAME:=Marvell Kirkwood
-FEATURES:=targz usb jffs2
+FEATURES:=targz usb jffs2 squashfs
MAINTAINER:=Imre Kaloz
LINUX_VERSION:=2.6.35.7
pad the kernel to 128k,
pad jffs2-128k really to 128k as the name implies,
create a plain padded squashfs (without uImage in front)
this does not break history, since the image WITH uImage
in front is still created in parallel
Signed-off-by: marcus.osd...@googlemail.com
---
Index: target/linux/kirkwood/image/Makefile
===
--- target/linux/kirkwood/image/Makefile(Revision 23697)
+++ target/linux/kirkwood/image/Makefile(Arbeitskopie)
@@ -15,7 +15,7 @@
define Image/BuildKernel
# do mach-id fixup here, if needed
- cp $(KDIR)/uImage $(BIN_DIR)/$(IMG_PREFIX)-uImage
+ dd if=$(KDIR)/uImage of=$(BIN_DIR)/$(IMG_PREFIX)-uImage bs=128k
conv=sync
endef
define Image/Build
@@ -27,15 +27,17 @@
define Image/Build/jffs2-128k
dd if=$(KDIR)/root.$(1) of=$(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-$(1).img
\
- bs=2048 conv=sync
+ bs=128k conv=sync
endef
define Image/Build/squashfs
$(call prepare_generic_squashfs,$(KDIR)/root.squashfs)
+ dd if=$(KDIR)/root.$(1) bs=128k conv=sync \
+ of=$(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-$(1).img
( \
dd if=$(KDIR)/uImage bs=4096k conv=sync; \
dd if=$(KDIR)/root.$(1) bs=128k conv=sync; \
- ) > $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-$(1).img
+ ) > $(BIN_DIR)/$(IMG_PREFIX)-$(PROFILE)-uImage-$(1).img
endef
$(eval $(call BuildImage))
squashfs added as alternative to rootfstype, must be in order squashfs,jffs2
tested on dockstar with both jffs2 and squashfs - openwrt was started in both
cases
without updating the bootparameters,
rename data to rootfs_data since squashfs-version needs to have some overlay;
unfortunatly, the jffs2 version creates an overlay, too...
maybe this is not desired, but the situtation is not worse than before, since
one has to update the bootparmeters for using squashfs and overlay on two
places, now only one
Signed-off-by: marcus.osd...@googlemail.com
---
Index: package/uboot-kirkwood/files/include/configs/dockstar.h
===
--- package/uboot-kirkwood/files/include/configs/dockstar.h (Revision 23697)
+++ package/uboot-kirkwood/files/include/configs/dockstar.h (Arbeitskopie)
@@ -133,15 +133,18 @@
"setenv bootargs ${x_bootargs} ${x_bootargs_root}; "\
"${x_bootcmd_usb}; bootm 0x640;"
-#define CONFIG_MTDPARTS"orion_nand:1M(u-boot),"\
+#define CONFIG_MTDPARTS\
+ "orion_nand:1M(u-boot)," \
"1...@1m(second_stage_u-boot)," \
- "3...@2m(kernel),3...@5m(rootfs),2...@37m(data) rw\0"
+ "3...@2m(kernel)," \
+ "3...@5m(rootfs)," \
+ "2...@37m(rootfs_data)\0"
#define CONFIG_EXTRA_ENV_SETTINGS "x_bootargs=console"\
"=ttyS0,115200 mtdparts="CONFIG_MTDPARTS\
"x_bootcmd_kernel=nand read 0x640 0x20 0x30\0" \
"x_bootcmd_usb=usb start\0" \
- "x_bootargs_root=root=/dev/mtdblock3 rw rootfstype=jffs2\0"
+ "x_bootargs_root=root=/dev/mtdblock3 ro rootfstype=squashfs,jffs2\0"
/*
* Size of malloc() pool
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] removing uclibc versions
Hi, Just curious about https://dev.openwrt.org/browser/trunk?rev=23779 Assuming 0.9.30_2 means higher patchlevel than 0.9.30_1 shouldn't it be _1 and _2 who should be removed and preserve the highest patchlevel 0.9.30_3 ? Please enlight me. Regards, Ossy ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] removing uclibc versions
Am 02.11.2010 19:55, schrieb Felix Fietkau: On 2010-11-02 7:39 PM, Marcus Osdoba wrote: Just curious about https://dev.openwrt.org/browser/trunk?rev=23779 Assuming 0.9.30_2 means higher patchlevel than 0.9.30_1 shouldn't it be _1 and _2 who should be removed and preserve the highest patchlevel 0.9.30_3 ? 0.9.30.1 is what's being used now. 0.9.31 is what's going to be used next. Hi, Thanks for answering. I know, that 0.9.31 should be used. I was even woundering, why OpenWrt does not default to it earlier. BUT, the question was: why keeping a lower patchlevel and removing higher ones. 0.9.30_1 <- still in trunk https://dev.openwrt.org/changeset/23779 0.9.30_2 <- removed 0.9.30_3 <- removed If I would switch to 0.9.31 and keep some 0.9.30 version as backup, I would choose the highest patchlevel (which is 0.9.30_3 and not 0.9.30_1) Maybe there is some very rational reason for this... Regards ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [kirkwood-dockstar] minor fixes
Am 02.11.2010 08:37, schrieb Imre Kaloz: Hi, On Mon, 01 Nov 2010 22:17:11 +0100, Marcus Osdoba 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 DEPENDS:=+kmod-crypto-aes. Tested with current trunk and confirmed. If mv-cesa is built without aes the module is not loadable. Regards, Ossy ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] toolchain: introducing gcc 4.4.5 with Linaro enhancements
Hi mailinglist, Currently I'm working on improved dockstar support for OpenWrt. The current toolchain 4.3.3+cs is not that up to date and linaro 4.5 branch is already included. Unfortunatly, this version does not support Marvell Feroceon (mtune=marvell-f). The Linaro version 4.4.5 does. So I added support for 4.4.5+l in OpenWrt, which can be found here: http://gitorious.org/dockstar/openwrt-trunk/commit/2fcb44e0f16a41ef409aaa9d424e473bf86eb34c http://gitorious.org/dockstar/openwrt-trunk/commit/2fcb44e0f16a41ef409aaa9d424e473bf86eb34c.patch I compiled the recent trunk with it and flashed it onto my dockstar device. Works perfectly. Feel free to demand an evidence if needed. Please consider the integration of version 4.4.5 LINARO into OpenWrt (similar to 4.5.1+l). Once done, the kirkwood platforms may point to it by default: http://gitorious.org/dockstar/openwrt-trunk/commit/b8d23a89c920f3caf8ac7b050b4dab568108f05b http://gitorious.org/dockstar/openwrt-trunk/commit/b8d23a89c920f3caf8ac7b050b4dab568108f05b.patch Kind regards, Ossy ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] toolchain: introducing gcc 4.4.5 with Linaro enhancements
Am 22.11.2010 13:24, schrieb Imre Kaloz: Hi, On Sun, 21 Nov 2010 12:37:37 +0100, Marcus Osdoba wrote: Currently I'm working on improved dockstar support for OpenWrt. The current toolchain 4.3.3+cs is not that up to date and linaro 4.5 branch is already included. Unfortunatly, this version does not support Marvell Feroceon (mtune=marvell-f). The Linaro version 4.4.5 does. So I added support for 4.4.5+l in OpenWrt, which can be found here: http://gitorious.org/dockstar/openwrt-trunk/commit/2fcb44e0f16a41ef409aaa9d424e473bf86eb34c.patch Once done, the kirkwood platforms may point to it by default: http://gitorious.org/dockstar/openwrt-trunk/commit/b8d23a89c920f3caf8ac7b050b4dab568108f05b.patch Talked to Linaro. The feroceon optimization has been removed from the Linaro and CS toolchains because it will never make it upstream, as Marvell didn't assign it to the FSF. I don't want to have yet another gcc version, so if you really want this optimization, please submit a patch to add only that - or we can go back to -mtune=xscale for feroceon as well. Thanks for clarifying that. Sorry, I wasn't aware of Marvell's "policy". I think the Feroceon Line started before Marvell bought Intel's Xscale. So the current Feroceon Cores are a combination of original Marvell Feroceon and Xscale features. Using only Xscale might cause some feature loss. The current trunk points to -mtune=marvell-f. If switching to Linaro gcc 4.5.1 this has to be altered anyway. I will have a look into the patches for marvell-f support. But furthermore, I think switching to Xscale as fallback might be more realistic. By the way, the kernel probes the mtune=marvell-f ability: http://kerneltrap.org/mailarchive/git-commits-head/2008/12/31/4552164 Maybe, something similar is possible in OpenWrt, too? Regards, Marcus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [kirkwood] Kernel 2.6.35.9 does not boot for dockstar
Hi mailinglist, I updated to the current trunk and rebuilt openwrt including the kernel. I was wondering, why the uImage does not boot upcorrectly and I tried every arcNumber and mainlineLinux=yes combination in u-boot (factory default and 2nd stage openwrt one). Kernel 2.6.35.9 does not boot! " Starting kernel ... Uncompressing Linux... done, booting the kernel. mtdparts parameter> " I reverted the kernel version in target/kirkwood/Makefile to 2.6.35.7 and rebuilt all. The newly built kernel boots perfectly as it did before 2.6.35.9. I will now try to create all with version 2.6.35.8 - so the list of changes in the kernel log is a bit shorter to identify the commit which introduced the problem. Meanwhile, everyone who is experimetning with dockstar support should be aware of that. If you are running 2.6.35.9 on you Dockstar - please let me know eventually I missed a detail somewhere. Regards, Marcus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [kirkwood] Kernel 2.6.35.9 does not boot for dockstar
Am 27.11.2010 21:45, schrieb Marcus Osdoba: Kernel 2.6.35.9 does not boot! I reverted the kernel version in target/kirkwood/Makefile to 2.6.35.7 and rebuilt all. The newly built kernel boots perfectly as it did before 2.6.35.9. I will now try to create all with version 2.6.35.8 - so the list of changes in the kernel log is a bit shorter to identify the commit which introduced the problem. Kernel 2.6.35.8 shows the same behaviour like 2.6.35.9. It does not boot. So the "error" may be introduced after 2.6.35.7. Meanwhile, everyone who is experimetning with dockstar support should be aware of that. If you are running 2.6.35.9 on you Dockstar - please let me know eventually I missed a detail somewhere. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [kirkwood] Kernel 2.6.35.9 does not boot for dockstar
Am 28.11.2010 16:27, schrieb Marcus Osdoba: Am 27.11.2010 21:45, schrieb Marcus Osdoba: Kernel 2.6.35.9 does not boot! I reverted the kernel version in target/kirkwood/Makefile to 2.6.35.7 and rebuilt all. The newly built kernel boots perfectly as it did before 2.6.35.9. I will now try to create all with version 2.6.35.8 - so the list of changes in the kernel log is a bit shorter to identify the commit which introduced the problem. Kernel 2.6.35.8 shows the same behaviour like 2.6.35.9. It does not boot. So the "error" may be introduced after 2.6.35.7. False alarm. GCC 4.4.5 with Linaro extensions was the problem. Summary here: https://forum.openwrt.org/viewtopic.php?id=27539 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] preinit-problem with current trunk
Hello mailinglist, I'm compiling kirkwood images for my dockstar out of the current trunk (r24217). Everything seems to work fine. Jffs2 is expanding and the system tries to enter init process. Unfortunatly I get the following error message and the system hangs: [..] Freeing init memory: 100K /etc/preinit: line 1: can't open : no such file Kernel panic - not syncing: Attempted to kill init! [..] I had a look into the tar.gz and didn't see anything suspicious. The preinit skript looked like the one on several positive tries before. bin/sh is present, the export should work, too diag.sh is present so is functions.sh. sbin/init points to busybox... Do you have any hint where I may find the cause? Thanks in advance. Regards, Marcus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] preinit-problem with current trunk
Am 08.12.2010 11:21, schrieb Alexey Loukianov: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 05.12.2010 17:36, Marcus Osdoba wrote: Unfortunatly I get the following error message and the system hangs: [..] Freeing init memory: 100K /etc/preinit: line 1: can't open : no such file Kernel panic - not syncing: Attempted to kill init! [..] Check if your image contain correct symlink from /bin/sh to busybox or to any other POSIX-complaint shell (ash/bash/whatever-you-use-in-your-build). That was my first action. And yes, ash and sh are pointing correct to the busybox executable. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] NAND Flash questions and Dockstar
Am 06.01.2011 16:38, schrieb Mauricio Tavares: I think I am experiencing the issues mentioned in http://www.dslreports.com/forum/r24833189-Other-Seagate-DockStar-U-Boot-NAND-flash-considerations. Namely, I installed the os in the flash memory; after a while it will degrade enough (probably due to writing/reading to it) that the dockstar will stop working and cannot successfully boot. Writing the root partition back to the nand solves the problem for a few more weeks. Hi, I always used the overlay strategy: A ReadOnly squashfs on the 32MiB mtd parititon and the overlay (jffs2) on the 219MiB mtd parititon. You need to modify the mtdparts names (rootfs and rootfs_data) in the bootloader to let OpenWrt automatically create an overlay. The overlay patition must be empty before intialisation. Maybe the 219MiB gives you a bigger buffer before the "suspicious lock condition" is reached Regards, Marcus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
