Date: Sun, 26 Oct 2008 13:37:32 +0000 From: Bruce M Simpson <bms@incunabulum.net> To: freebsd-embedded@freebsd.org Subject: Breaking into the Emprex NAS-100 firmware Message-ID: <4904729C.9080108@incunabulum.net>
next in thread | raw e-mail | index | archive | help
Hi, I just had a chance to look at this. So, Emprex are shipping a box (the NAS100) in violation of the GPL w/o releasing all relevant source code. After I contacted Cavium about the GPL issues with their acquisition of Star Semiconductor, they sent me links to the binaries which Linksys were required to release for the WAP4400N. I downloaded the WAP4400N materials and cross-compiled mtd-utils using Star's provided toolchain binaries (Gentoo crossdev is often broken for me). I then used mtd_debug to extract an image of the mtd0 partition, using a USB2 flash disk for data exchange. I quickly noticed that the ARMboot image targetted for the WAP4400N, built from Linksys provided sources, doesn't match the ARMboot image inside the NAS100. As far as I can tell this is down to two things: 1. The environment region for ARMboot is inside ARMboot's flash partition, at the very end (0x1E000 to 0x20000, 4096 bytes including the 4-byte CRC32 at the start of the region). [The image for the WAP4400N assumes it's at 0x20000 and is 8192 bytes long.. so don't use that image.] 2. The PHY drivers are slightly different. So I looked at the STR9100 board support, and after noting the binary differences in the flash layout, skimmed some of the code to do with environment variable processing. On a whim, I decided to deliberately corrupt the contents of the environment in the flash by modifying it with a hex editor and rewriting it w/mtd_debug, and rebooted. There is a CRC-32 at the start and it wasn't 100% clear which region was being used for it. Having done this, I noticed that ARMboot drops into its prompt (after attempting to execute its 'firstboot' routine and hitting CTRL-C). I was able to run Emprex's shipped kernel using "go 0x10020000", which seems to point to them not using the U-Boot image facility in ARMboot. The majority of Star's patches to ARMboot are to add support for some of the onboard peripherals (Ethernet MAC, timers, UART etc). BY THE WAY... There is a funny bug in ARMboot which I've seen on little endian ARM such as these, and that is, you need to configure an alias of the *reverse* of the IP address of the default gateway in order for it to boot from the network successfully. It seems to need a default gateway in order to use its bootp code, even when the server is on a directly attached network. Simply flipping the octets in the BOOTP/DHCP option given out to the box doesn't work, an actual alias on the gateway is needed. As far as I know this bug hasn't been fixed. So I guess now the way ahead is lit for folk to get U-Boot or similar onto this platform, as well as hopefully porting FreeBSD in future. If anyone is interested in following this up please contact me, I might not have free time to look at this in any detail. thanks BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4904729C.9080108>