Compiling OpenWrt for Kirkwood

This is the working thread for effort to compiling OPenWrt for Kirkwood boxes.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 4 time(s). Last edit at 07/18/2016 01:34AM by bodhi.

a quick followup:

I'm currently compiling a few kirkwood test builds from Openwrt-trunk (current sources in git), but there is also an easy-to-use makefile-based assembler system called ImageBuilder that assembles a bunch of flashable images from pre-compiled packages in a whitelist. https://downloads.openwrt.org/snapshots/trunk/kirkwood/generic/

The trick is that the only way to decide what packages you want in your image is use the "compile from source" make menuconfig CLI-graphical menu (thanks Obama), so while I was at it, I thought why not compile the damn thing anyway?

Atm the plan is making a generalized openwrt rootfs that will boot on all boards, placing the Openwrt zImage, the folder with all dtb files and the rest of the openwrt system inside a ubifs (and the u-boot will be selecting the right dtb, just as normal).
Ubifs allows easier management, and u-boot can read from it without having to resort to writing things in flash (this is convenient for the /dts folder for example). Don't know if u-boot can read from squashfs, but I did not find any data about that.

ubifs does offer less compression than squashfs, but it does not matter that much for openwrt on a NAS with 128+ MB of NAND.

Also generating ubifs images/filesystems requires nand flash settings like say erase blocks and page size and similar, but that can be easily automated with a script that reads a table of values and makes the images using the same base rootfs.

Will probably have to sort out leds and buttons, but that's for later.

I made a test image with openwrt's rootfs+zImage+dtsfolder following the (good) info here http://free-electrons.com/blog/creating-flashing-ubi-ubifs-images/

and I was ready to install it in the flash of my guinea... I mean nsa310 box.

Point is, I think my mtd setup is a bit wrong, even if I can fw_print/setenv.

root@nsa310debian:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 08000000 00020000 "orion_nand"

its old mtd variable in stock uboot was

mtdparts=nand_mtd:0x100000(uboot),0x80000(uboot_env),0x80000(key_store),0x80000(info),0xA00000(etc),0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(kernel_2),0x2FC0000(rootfs2)

At the moment, it's running with your u-boot and its envs are not in stock place anymore, plus I don't know what all those things above are and if they are useful or not.

So, I came here to ask if you could tell me a "generic kirkwood mtd setup" where your u-boot and its envs are safe and the rest of the space is usable by openwrt? (also asking for devices that have ssd/network/whatever-hardware firmwares or somesuch)

Also. what is the best firmware size to fit in most/all kirkwoods you support?

And do you have the stats of all flash chips used in the devices you support? even just model names.

EDIT: feel free to answer "no" to any/all question heh, I'm just asking if you have something already done you can share, not to do work for me. :)



Edited 4 time(s). Last edit at 03/22/2016 01:04PM by bobafetthotmail.

bobafetthotmail,

> I'm currently compiling a few kirkwood test builds
> from Openwrt-trunk (current sources in git), but
> there is also an easy-to-use makefile-based
> assembler system called ImageBuilder that
> assembles a bunch of flashable images from
> pre-compiled packages in a whitelist.
> https://downloads.openwrt.org/snapshots/trunk/kirk
> wood/generic/
>
> The trick is that the only way to decide what
> packages you want in your image is use the
> "compile from source" make menuconfig
> CLI-graphical menu (thanks Obama), so while I was
> at it, I thought why not compile the damn thing
> anyway?

Thanks for the hints! I have not have much time looking into it. With this ImageBuilder available, my impression about the OpenWrt build process previously was wrong :) I should attempt the build again sometime.

> Atm the plan is making a generalized openwrt image
> that will boot on all boards, placing the Openwrt
> zImage, the folder with all dtb files and the rest
> of the openwrt system inside a ubifs (and the
> u-boot will be selecting the right dtb, just as
> normal).
> Ubifs allows easier management, and u-boot can
> read from it without having to resort to writing
> things in flash (this is convenient for the /dts
> folder for example). Don't know if u-boot can read
> from squashfs, but I did not find any data about
> that.
>

Usually, ubifs will be big for kirkwood plugs. Lots of them has ony 128MB. This is why Arch approach was to go all the way and use the whole NAND (except 1st 1MB) for rescue system. Using ubifs make the new rescue system just a little bit more useful than stock OS (no enough space to install packages). With OpenWrt, it should be a full blown system, so it is more interesting, but they still use squashfs because normal routers NAND are much smaller. With squashfs, the installation is more difficult, but it stretch the available space.

> ubifs does offer less compression than squashfs,
> but it does not matter that much for openwrt on a
> NAS with 128+ MB of NAND.
>
> Will probably have to sort out leds and buttons,
> but that's for later.
>
> I made a test image with openwrt's
> rootfs+zImage+dtsfolder following the (good) info
> here
> http://free-electrons.com/blog/creating-flashing-u
> bi-ubifs-images/
>
> and I was ready to install it in the flash of my
> guinea... I mean nsa310 box.
>
> Point is, I think my mtd setup is a bit wrong,
> even if I can fw_print/setenv.
>
>

> root@nsa310debian:~# cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 08000000 00020000 "orion_nand"
>

>
> its old mtd variable in stock uboot was
>
>

> mtdparts=nand_mtd:0x100000(uboot),0x80000(uboot_en
> v),0x80000(key_store),0x80000(info),0xA00000(etc),
> 0xA00000(kernel_1),0x2FC0000(rootfs1),0xA00000(ker
> nel_2),0x2FC0000(rootfs2)
>

>
> At the moment, it's running with your u-boot and
> its envs are not in stock place anymore, plus I
> don't know what all those things above are and if
> they are useful or not.

When installing OpenWrt, the stock MTD is not useful, they will be wiped out.

>
> So, before wasting time figuring out myself that
> stuff, I came here to ask if you could tell me a
> "generic kirkwood mtd setup" where your u-boot and
> its envs are safe and the rest of the space is
> usable by openwrt? (also asking for devices that
> have ssd/network/whatever-hardware firmwares or
> somesuch)
>

The only MTD that matters to kirkwood u-boot and its envs is mtd0 (1MB). You can use the rest for anything.

> Also. what is the best firmware size to fit in
> most/all kirkwoods you support?

That depends on the size of OpenWrt images after you compile them. That's the best size, because you are going to use up the remaining 124-126MB.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

> Usually, ubifs will be big for kirkwood plugs. Lots of them has ony 128MB.

I'm optimistic, 128 MB is a lot for a OpenWrt system. I mean... really a lot.

This is the package list of stuff for the UBIFS image for my nsa310 (not yet tested, so I may still be terribly wrong).
All filesystems supported, a bunch of basic router things, wireless drivers for usb keys, samba, nfs, full webinterface for a bunch of things like samba, ddns or traffic shaping, filesystem making/fixing tools (for ext2-3-4) and for fat, hard drive SMART check programs, nut and its drivers (controlling a UPS), media streaming services, tinyproxy, nano and mc.

base-files busybox ca-certificates dnsmasq dnsmasq-dhcpv6 dnsmasq-full dnsmasq_full_dhcpv6 dnsmasq_full_dnssec dnsmasq_full_auth dnsmasq_full_ipset dropbear firewall fstools jsonfilter libc libgcc libpthread librt libstdcpp mtd netifd opkg procd resolveip rpcd sqm-scripts swconfig ubox ubus ubusd uci usign wireless-tools ath9k-htc-firmware mt7601u-firmware mwl8k-firmware kmod-ata-core kmod-ata-marvell-sata kmod-dm kmod-scsi-core kmod-crypto-aead kmod-crypto-crc32c kmod-crypto-des kmod-crypto-ecb kmod-crypto-hash kmod-crypto-hmac kmod-crypto-manager kmod-crypto-md4 kmod-crypto-md5 kmod-crypto-michael-mic kmod-crypto-pcompress kmod-crypto-sha256 kmod-fs-autofs4 kmod-fs-btrfs kmod-fs-cifs kmod-fs-exportfs kmod-fs-ext4 kmod-fs-f2fs kmod-fs-isofs kmod-fs-jfs kmod-fs-msdos kmod-fs-nfs kmod-fs-nfs-common kmod-fs-nfsd kmod-fs-ntfs kmod-fs-vfat kmod-fs-xfs kmod-fuse kmod-hwmon-core kmod-i2c-core kmod-i2c-mv64xxx kmod-input-core kmod-leds-gpio kmod-leds-pca963x kmod-ledtrig-default-on kmod-ledtrig-gpio kmod-ledtrig-heartbeat kmod-ledtrig-morse kmod-ledtrig-netdev kmod-ledtrig-netfilter kmod-ledtrig-oneshot kmod-ledtrig-timer kmod-ledtrig-transient kmod-ledtrig-usbdev kmod-lib-crc-ccitt kmod-lib-crc-itu-t kmod-lib-crc16 kmod-lib-crc32c kmod-lib-lzo kmod-lib-raid6 kmod-lib-xor kmod-lib-zlib kmod-nls-base kmod-ip6tables kmod-ipt-conntrack kmod-ipt-conntrack-extra kmod-ipt-core kmod-ipt-ipopt kmod-ipt-ipset kmod-ipt-nat kmod-nf-conntrack kmod-nf-conntrack6 kmod-nf-ipt kmod-nf-ipt6 kmod-nf-nat kmod-nfnetlink kmod-ifb kmod-dnsresolver kmod-ppp kmod-pppoe kmod-pppox kmod-sched kmod-sched-core kmod-slhc kmod-tun kmod-eeprom-93cx6 kmod-mmc kmod-mvsdio kmod-rtc-marvell kmod-thermal kmod-thermal-kirkwood kmod-sound-core kmod-usb-core kmod-usb-storage kmod-usb-storage-extras kmod-usb2 kmod-usb3 kmod-ath kmod-ath9k kmod-ath9k-common kmod-ath9k-htc kmod-cfg80211 kmod-mac80211 kmod-mt7601u kmod-mwl8k kmod-p54-common kmod-p54-usb kmod-rt2500-usb kmod-rt2x00-lib kmod-rt2x00-usb kmod-rt73-usb kmod-rtl8187 libiwinfo-lua lua perl perlbase-base perlbase-bytes perlbase-class perlbase-config perlbase-cwd perlbase-errno perlbase-essential perlbase-fcntl perlbase-file perlbase-filehandle perlbase-i18n perlbase-integer perlbase-io perlbase-list perlbase-locale perlbase-params perlbase-posix perlbase-re perlbase-scalar perlbase-selectsaver perlbase-socket perlbase-symbol perlbase-tie perlbase-utf8 perlbase-xsloader libbz2 libacl libattr libext2fs libfuse libsysfs libip4tc libip6tc libxtables libgnutls libopenssl libpolarssl alsa-lib bind-libs glib2 libao libavahi-client libavahi-compat-libdnssd libavahi-dbus-support libblkid libblobmsg-json libcurl libdaemon libdevmapper libdbus libevent2 libexpat libffi libgcrypt libgd libgmp libgpg-error libf2fs libhttp-parser libiwinfo libjpeg libjson-c libltdl liblua liblzo libmount libncurses libnetsnmp libnettle libnl-tiny libpam libpcap libpcre libpng libpopt libprotobuf-c libreadline librpc librrd1 libsensors libsmartcols libubox libubus libubus-lua libuci libuci-lua libuclient libusb-1.0 libusb-compat libustream-polarssl libuuid libwrap libxml2 terminfo uclibcxx zlib luci luci-ssl luci-base luci-mod-admin-full luci-app-commands luci-app-ddns luci-app-firewall luci-app-hd-idle luci-app-ntpc luci-app-ocserv luci-app-openvpn luci-app-radicale luci-app-samba luci-app-shairplay luci-app-shairport luci-app-sqm luci-app-statistics luci-app-tinyproxy luci-app-transmission luci-app-udpxy luci-app-uhttpd luci-app-upnp luci-app-vnstat luci-app-wol luci-app-wshaper luci-theme-bootstrap luci-proto-ipv6 luci-proto-openconnect luci-proto-ppp luci-proto-relay luci-proto-vpnc luci-lib-ip luci-lib-jsonc luci-lib-nixio transmission-daemon aria2 curl rsync rsyncd wget nfs-kernel-server nfs-kernel-server-utils sshfs ip6tables iptables iptables-mod-conntrack-extra iptables-mod-ipopt miniupnpd avahi-dbus-daemon bind-client ddns-scripts ddns-scripts_cloudflare ddns-scripts_no-ip_com ddns-scripts_nsupdate nmap nmap-ssl relayd tc openssh-client openssh-client-utils openssh-keygen openssh-moduli openssh-server openssh-server-pam openssh-sftp-avahi-service openssh-sftp-client openssh-sftp-server sshtunnel ntpclient ocserv openconnect vpnc vpnc-scripts tinyproxy uhttpd uhttpd-mod-ubus cifsmount etherwake hostapd-common iw nut nut-avahi-service nut-driver-al175 nut-driver-apcsmart nut-driver-apcsmart-old nut-driver-apcupsd-ups nut-driver-bcmxcp nut-driver-bcmxcp_usb nut-driver-belkin nut-driver-belkinunv nut-driver-bestfcom nut-driver-bestfortress nut-driver-bestuferrups nut-driver-bestups nut-driver-blazer_ser nut-driver-blazer_usb nut-driver-clone nut-driver-etapro nut-driver-everups nut-driver-gamatronic nut-driver-genericups nut-driver-isbmex nut-driver-ivtscd nut-driver-liebert nut-driver-liebert-esp2 nut-driver-masterguard nut-driver-metasys nut-driver-mge-shut nut-driver-mge-utalk nut-driver-microdowell nut-driver-nutdrv_atcl_usb nut-driver-nutdrv_qx nut-driver-oldmge-shut nut-driver-oneac nut-driver-optiups nut-driver-powercom nut-driver-powerpanel nut-driver-rhino nut-driver-richcomm_usb nut-driver-riello_ser nut-driver-riello_usb nut-driver-safenet nut-driver-snmp-ups nut-driver-solis nut-driver-tripplite nut-driver-tripplite_usb nut-driver-tripplitesu nut-driver-upscode2 nut-driver-usbhid-ups nut-driver-victronups nut-web-cgi odhcp6c portmap ppp ppp-mod-pppoe samba36-server uclient-fetch udpxy vnstat vnstati wpad-mini wshaper shairplay shairport bzip2 unrar unzip zip nano acl attr badblocks btrfs-progs dosfsck dosfslabel dumpe2fs e2freefrag e2fsprogs f2fs-tools filefrag fuse-utils lsattr mkdosfs ncdu nfs-utils resize2fs sysfsutils tune2fs certtool blkid fdisk hd-idle hdparm lsblk lvm2 swap-utils wipefs collectd collectd-mod-interface collectd-mod-iwinfo collectd-mod-load collectd-mod-network collectd-mod-rrdtool cryptsetup cryptsetup-openssl dbus dmesg gnupg hwclock iwinfo jshn libjson-script lm-sensors lm-sensors-detect mc mdadm mmc-utils mount-utils mountd procd-nand px5g rrdtool1 smartd smartmontools tar ubi-utils uboot-envtools

the rootfs folder itself + zImage + dts folder is around 75 MB (no compression), the UBIFS image is 45 MB (UBIFS does compress the data, not as good as squashfs tho), squashfs images are around 25 MB (zImage excluded).

If I need to fit in 125 MB of space... I might very well run out of (sensible) things to throw in.

>The only MTD that matters to kirkwood u-boot and its envs is mtd0 (1MB). You can use the rest for anything.

Good, will alter that accordingly.

>That depends on the size of OpenWrt images after you compile them.

I decide the size depending on what packages I embed, a working openwrt system can live with 4 MB, 8MB is decent, beyond 16MB is woooooooooo!!!!! (with squashfs)



Edited 1 time(s). Last edit at 03/22/2016 02:23PM by bobafetthotmail.

Quick update, it's ALIVEEEE. (forgot to include realtek driver tho so ethernet isn't working, but from serial I see it's working)

Will post some u-boot tips and configs tomorrow.

I was thinking about opening a thread in openwrt forums for the actual tutorial, since this is not the right place for openwrt discussion.

@bobbafetthotmqil

I have an HP T5325 i would be more than happy to smash this onto - If you need anyone to test, obviuosly i will need instructions on how to load this onto the HDD area.....

an openwrt router with 512ram and 512 HDD..... thats device i would LOVE to play with.

pls post a link here to your OPENWRT discussion.

This is easier, so I can tell it now, for the tutorial about flashing in nand I need moar time.

Since the t5325 should have a marvell eth, you should not need to recompile anything
Also since the t5325 has a "SSD" (actually a crappy USB flash drive on a sata port), you cannot use ubifs but must use normal filesystems as the controller generates a FTL (flash translation layer, or somesuch) abstracting the raw NAND under it. It's the first thing that will die horribly when I have time, as I consider it unworthy of the Sata port it occupies.

go here (this is trunk, bleeding edge of Openwrt, there are also stable versions, released in october 2015) https://downloads.openwrt.org/snapshots/trunk/kirkwood/generic/

download the rootfs.tar.gz file and the zimage (or uimage, should work too), rename the zimage/uimage so it does not start with "openwrt-something"

take the dtb bodhi made for the t5325

then you need to format the internal SSD as ext2-4, give it the label "rootfs" and extract the rootfs.tar.gz there (must use the debian rootfs to do it, probably)

make a folder called /boot in the root of the SSD, and place the dts and zimage/uimage there.

Then adjust the uboot envs for sata boot (if you flashed the standard envs in your uboot and use the uImage you shouldn't need to alter the uboot, as the kernel, dtb and rootfs is there.)

Make sure that the env called "devices=usb ide" is like this, this way it will look in usb FIRST, then try Sata, this allows you to boot debian too.

Then it's the standard openwrt setup. I don't think you have webinterface though, so use telnet to 192.168.1.1.

If you can't get anywhere without webinterface, use the imagebuilder (same link above) (this one is the documentation on how to use it) https://wiki.openwrt.org/doc/howto/obtain.firmware.generate and the list of packages I posted above to bodhi as "included packages".

It will download things and assemble the rootfs.tar.gz and zimage/uimage for you.

EDIT: this obviously works for usb drives too.

EDIT2: while that thin client is probably the worst candidate for a router (only low-speed interfaces, eth100mb and usb2.0) openwrt has a feature called extroot that allows it to boot from a tiny 4-8MB flash firmware, but then remount the root into a bigger storage device (usually over USB in routers). So if a supported router has a usb port, you can fit whatever on it. I got a tiny nexx 3020 router that is now permanently married to a huawei 3g/4g usb dongle because in the dongle there is a 32GB microSD card I use to expand the router's root.



Edited 3 time(s). Last edit at 03/23/2016 08:03AM by bobafetthotmail.

@bobafetthotmail

Thanks for the above info - i will be going the web-interface route, i do like to waggle the mouse around

mh, if you go webinterface route, first thing to do after you log in is disable its DHCP server, set a static IP that does not conflict with your router, then go in DNS settings and write the address of your router (the gateway) in its "custom DNS" field. This way it can reach the internet.



Edited 1 time(s). Last edit at 03/23/2016 05:31PM by bobafetthotmail.

Jumping on the bandwagon while I'm online...
I wrote a guide for installing OpenWRT on flash on the Dockstar. I used the JFFS2 image, but I have no idea how these instructions translate when using ubifs. Any pointers?
The last jffs2 image I got to work was 12.09, nothing after that gets past "Starting Linux" and I have no idea what to do with ubifs. I'm running bodhi's latest u-boot.

The guide I wrote is here: https://wiki.openwrt.org/doc/howto/dockstar_sandbox

the dockstar's page is what helped me setup the uboot envs, as there is a tutorial about installing openwrt CC in the dockstar https://wiki.openwrt.org/toh/seagate/dockstar?

and above I posted the info I used to actually build the ubifs image from plain files in a folder using my own device's nand information to set it up correctly.

For more through info, it's better if you wait for my tutorial in openwrt forums, I'll post a link here, just keep this thread in your "watched" list.

posted the guide in the openwrt forum https://forum.openwrt.org/viewtopic.php?pid=316900#p316900

If you want to try it out at your own risk, be my guest.

I'd rather like to know megal0maniac's opinion of it (as he does have some experience as he made another guide).



Edited 1 time(s). Last edit at 03/26/2016 06:12PM by bobafetthotmail.

bobafetthotmail,

I've read your tutorial. It's packed with well explained steps and looks like mostly it's going to work fine. Note: I've not looked closely at step 5 yet.

1. You mentioned 1.5MB reserved for u-boot and envs. This is not going to work with our u-boot in which the envs are defined at 0xc0000, which is 768K location.

2. To accomodate bad blocks, you should make sure that you use a little more than needed. So perhaps 2MB for u-boot and envs is better. And then 124MB for kernel and rootfs.

General comment: I think people will be a little bit intimidated by the explanation. I know that from my instructions for u-boot and kernel threads. I kept revising them, because by the questions I got, I've realized that the less explanation the better :) It's hard to write instruction that applicable to all devices. OTOH, if you can list the steps so that it's possible to copy/paste then a lot more less experienced people will try, and chance is that some will brick their boxes. That's why a runable script is always preferrable. I still can't decide whether I will upgrade Jeff's script or write a whole bunch of new ones (like Arch Linux ARM approach).

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 05/08/2016 03:27PM by bodhi.

>1. You mentioned 1.5MB reserved for u-boot and envs.

I made that with the stock uboot in mind, and the stock uboot+envs says that. I'm probably going to refine that a little into "just install bodhi's uboot first" because I'm sure that it works reliably anyway.

>2. To accomodate bad blocks, you should make sure that you use a little more than needed. So perhaps 2MB for u-boot and envs is better. And then 124MB for kernel and rootfs.

noted.

>I think people will be a little bit intimidated by the explanation.

I know, it's mostly for hackers. Once I get the data about the NAND specifications (about my devices since none is answering there anyway, not that I was expecting something else from openWRT), I'm just integrating it in the automated image build process.

Then it's just a "download here, connect a serial, do things with uboot"

>I still can't decide whether I will upgrade Jeff's script or write a whole bunch of new ones (like Arch Linux ARM approach).

I did try to make an automated install script for Zyxel NASes, but I canceled it as it's unstable and dangerous. Even ALARM's misfires relatively often (like on mine).

If you do one you must pack with it ALL tools you use, as the ones in the firmware are either ancient, non-existing or configured in weird ways, causing the script to fail or misfire and you'll have to waste ages making 100 checks and giving the same command in 5 different ways.

If you make a sane "autoflashing toolkit" (youhave flashing tools already, but I must have "blkid", a busybox with Gawk sed grep and company, and a commandline partition tool), I can help out with the script itself.

bobafetthotmail,

Sorry about not responding to this post! Somehow I missed this completely. It must have been while using my phone to read forum posts, and fat-fingered this post as already read :)

Update:

Ok. I've read it. And yes, thanks for the offer to volunteer, let me see if we could fork Jeff script and modify it.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 07/15/2016 06:32AM by bodhi.

uhh... what was this all about again?

...

ah yes. The automated installer. :)

So let's make sure we are still on the same page:

I'm now going to make a script (most of this is already written for that discontinued project, if i can still find it anyway) that
-checks the name of your flashable uboot binary and uses that to determine what box it is working on
-checks that there are no bad blocks in uboot, quits otherwise (logging an error)
-goes and partitions properly (ext4 if possible otherwise ext2, would be cool to have a make ext4 static binary) either another USB drive OR a sata drive (the usb device containing the installer toolkit is of course ignored because reasons)
-extracts the debian rootfs in there
-makes sure it went well
-proceeds with flashing the new uboot
-flashes the env image (plz make a good env image as it's not always possible to change your uboot envs from stock firmware)
-powers off the box


The general plan afterwards would be to ask the user to prepare a standard FAT usb with downloaded files and script, get root terminal access to the box (serial or not), mount the usb manually, execute the script.

And my nsa310 is going to play guinea pig again.

P.s. It's entirely possible to have the script react smartly to bad blocks in uboot sectors and install correctly anyway, but for now I'll focus on making something that works at all.