OpenWRT Kamikaze 7.09

From NAS-Central MRT Wiki
Jump to: navigation, search

Important note: a new release of OpenWRT Kamikaze for GigaNAS is available here.

Here it is first port of | OpenWRT Kamikaze 7.09 for the GigaNAS (and no other NAS else you'll brick it)! It's still an alpha release because of many things to fix. So, please dont use it if you dont exactly understand what you are doing. I suggest you to not upgrade your firmware if you dont have a serial console connected to your NAS to restore it using its bootloader if something wont go fine.

Contents

OpenWRT vs original MRT firmware

  • OpenWRT only need flash partitions to run. No more hard-coded partitions on your hard-disks.
  • No more ugly scripts+code but only standard linux scripts + utils
  • More available memory and CPU power available (do a 'cat /dev/meminfo' to see how much)
  • Additional easily installable packages (only a small set already available: see the list here)

Build instructions

Read here.

Installation instructions

Automatic installation (still not working)

Warning: this need to be tuned and actually dont work. You need to have a working original (or original-based) firmware to do this, and an hard-disk configured on it to allow the upgrade system using its swap partition. Without an hard disk the upgrade procedure will cause the process being killed because it needs more RAM than available (only 2Mb available at startup!).

  • Download firmware image running "wget http://www.arsenio.net/openwrt/gemini/openwrt-gemini-0.1.tgz "
  • Gunzip the tar from that package running "tar -xzf openwrt-gemini-0.1.tgz"
  • Upload output tar to your actual Sausalito-based firmware using the webgui update page
  • Wait for flash programming completition (about 25 minutes)
  • Now you should have OpenWRT already running on your NAS (default IP is 192.168.1.1)

Manual installation

You need to have bootloader access to do this. You can achieve this connecting a serial console to the NAS JP2 connector.

  • Install a tftp server (i use tftpd32 on windows)
  • Download firmware image from here.
  • Extract files from that package and put into the tftp server directory
  • Press Y on the bootloader menu, then press 2, enter your tftp server IP, press enter, enter 'zImage' and press enter
  • Press R on the bootloader menu, then press 2, enter your tftp server IP, press enter, enter 'rd.gz' and press enter
  • Press 1 on the bootloader menu or manually shutdown/restart the NAS
  • Now you should have OpenWRT booting on your NAS (default IP is 192.168.1.1)
  • Connect to the serial console pressing ENTER
  • Change the root password with using 'passwd'

Post installation

Remember that default IP/Gateway/DNS are 192.168.1.1. After installed, you can log ONLY using the serial console. SSH is enabled but you cannot login because of no root password is set (OpenWRT security policy). the first time you connect).

So, you can manually change the default password, or using the web interface running these commands:

ipkg update
ipkg install webif

Then connect to the NAS IP using your preferred browser and enjoy OpenWRT !

Original firmware restore instructions

You can always use your bootloader menu to restore single firmware partitions. Else you have to do that while your NAS is running linux, but it's more complicated. I'll write a script to do these steps automatically:

  • Mount a new temporary rootfs in RAM
  • Write new firmware partitions into the flash
  • Reboot the NAS

Porting details

  • Kernel: 2.6.15
  • Rootfs: jffs2 (12Mb available)
  • GCC version: 4.2.0
  • Endianess: Little endian

Flash partitions

I've decided not to change the original Gemini platform flash partitioning scheme to avoid problems with StorLink bootloader hardcoded partition sizes and menu functions. So, i use as root filesystem for OpenWRT a jffs2 image put into both Ramdisk+Application partitions. That partitions scheme is hardcoded in the kernel. Doing this you wont need to overwrite the bootloader and you can always restore your original firmware easily (from linux or bootloader serial console). Said this, the firmware builder outputs an apparently standard MRT compatible firmware containing zImage, rd.gz and hddapp.tgz. But last two are simply the jffs2 root filesystem splitted in two renamed files!

Kernel

I've used MRT 2.6.15-based kernel with some little modifications into the MTD stuff to handle the flash/ide shared pin be locked while working with our mtd device. That didnt worked before 'cause StorLink programmers only handled it if the device were used using the mtdchar api.

Pending issues

Division by zero in kernel

This happens when a JFFS2 filesystem is mount, no matter if on a real MTD device or fake MTD device (blk2mtd o block2mtd). But it seems not to broken anything.

jffs2_scan_eraseblock(): End of filesystem marker found at 0x160000
Division by zero in kernel.
jffs2_build_filesystem(): unlocking the mtd device... done.
jffs2_build_filesystem(): erasing all blocks after the end marker... done.

This has to be investigated.

Missing USB 1.1 support

When you insert a 1.1 USB device it wont works and these messages appear on console:

usb 1-1.2: new full speed USB device using ehci-hcd-FOTG2XX and address 3
usb 1-1.2: device descriptor read/64, error -71
usb 1-1.2: device descriptor read/64, error -71
usb 1-1.2: new full speed USB device using ehci-hcd-FOTG2XX and address 4
usb 1-1.2: device descriptor read/64, error -71
usb 1-1.2: device descriptor read/64, error -71
hub_port_reset status 0
usb 1-1.2: new full speed USB device using ehci-hcd-FOTG2XX and address 5
usb 1-1.2: device not accepting address 5, error -71
hub_port_reset status 0
usb 1-1.2: new full speed USB device using ehci-hcd-FOTG2XX and address 6
usb 1-1.2: device not accepting address 6, error -71
connect_change 1
clear_bit
return set_bit
connect_change 1
clear_bit
debounce: port 4: total 100ms stable 100ms status 0x101
hub_port_reset status 0
usb 1-1.4: new full speed USB device using ehci-hcd-FOTG2XX and address 7
usb 1-1.4: device descriptor read/64, error -71
usb 1-1.4: device descriptor read/64, error -71
hub_port_reset status 0
usb 1-1.4: new full speed USB device using ehci-hcd-FOTG2XX and address 8
usb 1-1.4: device descriptor read/64, error -71
usb 1-1.4: device descriptor read/64, error -71
hub_port_reset status 0
usb 1-1.4: new full speed USB device using ehci-hcd-FOTG2XX and address 9
usb 1-1.4: device not accepting address 9, error -71
hub_port_reset status 0
usb 1-1.4: new full speed USB device using ehci-hcd-FOTG2XX and address 10
usb 1-1.4: device not accepting address 10, error -71
usb 1-1.2: new full speed USB device using ehci-hcd-FOTG2XX and address 3
usb 1-1.2: device descriptor read/64, error -71

Inserting a USB 2.0 hub i got this strange message:

hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
***qtd_list NULL

What does it mean?

Anyway, follow this thread if you are interested in the topic above.

Power event is not catched

When you press the power button, nothing happens but this message on the console:

Power event by Button...

That's because there's no userspace utility listening for that event. We have to write a simple utility that polls /dev/sl_pwr device and make a shutdown when the button is pressed. Is there a more elegant method to do that?

- I do not think so. for the linkstations lb_worm coded avr_evtd for the ppc based boards from freescale and micro_evtd for the marvell orion based boards. possibly you could take some code from this GPL`d apps and use it for these boxes? Mindbender

- My idea is to generate a ctrl+alt+del event to init, to let user configure a custom behaviour. Like running stop scripts and shutting down the system. That's how Debian works with NSLU2. Lordscaffard

- not bad idea indeed. the nslu2 has only 2 buttons (front button and reset button on the back for getting it into upgrade mode). are there other buttons as well? maybe you can live without a daemon. i thought about it and the only reason why we needed a daemon was that all boards had a watchdog timer which reseted the board if the watchdog was not feed with some packages . Mindbender

To do next

  • Fix pending issues (!)
  • Creating a flash restore utility (hopefully using webif)
  • Switch to squashfs+rootfs overlay filesystem (using mini_fo)
  • Make better/faster MTD/IDE sharing flag than mtd_lock()/mtd_unlock()
  • Build all openwrt packages (apply this patch that avoid building all stuff)
  • Add all optware packages
  • Add others packages already available for Tinky (dctcs+ctorrent, twonkymedia server, etc...)