Recently I bought a Freecom FSG device (http://openfsg.com).

As it doesn't have much software, I thought of installing OpenWRT on it.

It has 64 MB RAM, 266 MHz ARM CPU, builtin HDD, 4 USB ports, 4 ethernet ports, 1 SATA port, so it's powerful enough to replace some small servers.

As I can see, it uses big-endian binaries.

This is the /proc/cpuinfo output:

Processor       : XScale-IXP4xx/IXC11xx rev 1 (v5b)
BogoMIPS        : 266.24
Features        : swp half thumb fastmult edsp

Hardware        : Intel IXP425 Freecom Platform
Revision        : 0000
Serial          : 0000000000000000

As I checked on the Intel website, this processor supports little- and big-endian modes - so perhaps installing OpenWRT on it would be possible?
I guess the most problematic part would be to change the endianness, to start with.

The endianness is not a problem, the XScale port I did uses big-endian as well. Question is what changes are needed to support the device. You can try to get Kamikaze working, and in the meantime I try to finish the ethernet driver library for the port.

It looks like no big changes would be needed.

It seems to me that even the kernel is placed on the main partition on HDD, so perhaps to install a different distro there would be to just copy a proper "base filesystem" there?

Right now I'm trying to get there debian-armeb, as it's already compiled for big-endian ARM.

The XScale port is compiled for big-endian arm as well. The real question is how stuff stored on that router, and what kind of workarounds does it need, if it needs at all. Also note that my XScale port is based on 2.6.16, so maybe You need to port some drivers over from 2.4 (I'm quite sure the factory firmware is based on that).

Yes, it has 2.4.27 kernel.

I can see it uses ixp400 and ixp425_eth modules.

They are proprietary Intel modules as described in Documentation/arm/IXP4XX

BTW, it seems XScale port compiles 2.4.32 kernel?

Nope, it just builds the toolchain with that kernel. For the target is uses 2.6.16.x (7 IIRC).

Some more info on this device.

It uses RedBoot bootloader, and has a JTAG.

Here's dmesg of it when it starts:

http://www.openfsg.com/forum/viewtopic. … ight=kern1

# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00020000 "RedBoot"
mtd1: 00180000 00020000 "kern1"
mtd2: 00180000 00020000 "kern2"
mtd3: 00020000 00020000 "RedBoot config"
mtd4: 00020000 00020000 "FIS directory"

(Last edited by mangoo on 26 May 2006, 10:54)

Somehow, I can't boot a kernel prepared with OpenWRT:

RedBoot> exec -c "console=ttyS0,115200 root=/dev/hda1 mem=64M@0x00000000"
Using base address 0x00700000 and length 0x00180000

And that's all.

Normally, I should see something like "Uncompressing Linux........................................................................................... done, booting the kernel."

Well, you have to port the board-specific stuff over ftom the fsg sources to our 2.6 tree, or you won't see anything for sure

Freecom kernel is compiled for Montejade with added patches to support onboard IDE. You might have more luck compiling buildroot-ng version of XScale 2.6 kernel. Make sure you enable debug messages. I don't know what machine id FSG3 uses. For example Billion router I played with had Coyote id on Redboot, but it fails with Coyote kernel. Compiling kernel for IXPD425 dev platform and patching machine id table on kernel so Coyote is treated as IXPD425 fixed it. Before that it hanged on booting kernel message. Enabling debug messages on kernel config will show you bit more information and clearly state if problem is due machine id conflict. Select only one machine type on kernel config. Enabling multiple ones is sure way to hang it on boot.

I have Freecom too (added it to OpenWrt wiki today) but haven't tried with custom firmware yet.

If I make the kernel using Snapgear toolchain + source [1], on which FSG-3 is based, the kernel boots fine.

Other thing is, it doesn't detect USB nor HDD then although I'm sure I compiled all required things in the kernel.

I wish there was a standard for those devices, like we have for PCs

BTW - you still want photos of this board?

[1] http://openfsg.com/index.php/Downloads

The cleanest and best would be creating a new machtype for the fsg and forget using other devices' confige. And I'm almost sure jr is right, and the RedBoot on it sets some stupid mac id.

And it seems that IDE is not supported in 2.6 kernels (the patch is for 2.4 kernel).

How do you check the "machine id" in RedBoot? I couldn't find such an option.

When I accidentally compiled the kernel for little-endian, it showed at least some garbage

There's "sata_via.c" in 2.6.17 that supports VIA VT6420 and VT6421. FSG-3 has VT6421 so it might work. You might need some PCI device enabling bits from Freecom 2.4.27, but that's beyond my knowledge and skills.

I don't know how to check machine id from Redboot. You could try building kernel with "Kernel low-level debugging functions" enabled under "Kernel hacking". Then kernel tries to print sensible error message after "booting kernel" message instead of just hanging. Also remember that sometimes it seems to take up to 10 seconds before any output after booting message.

If you want to run little-endian environment you can probably get needed patches from NSLU2 kernel for LE ARM Debian. Simply changing option when compiling kernel is not enough. Of course you need to get working kernel before you attempt to re-use NSLU2 userspace binaries.

Yes, the "sata_via.c" appeared in 2.6.11 kernel (or somewhere around).

It's a SATA driver, and if you look at the beginning of it, you will see:

*  To-do list:
*  - VT6421 PATA support

The VT6421A chipset in FSG-3 has supports one PATA and 2 SATA drives, but PATA is not supported in "sata_via.c" in 2.6 kernels.

I tried to build 2.6 kernel using Snapgear sources, and even if I compile sata_via in the kernel, it doesn't detect the drive.

There is a patch from VIA [1], which applies cleanly on 2.6 kernel (in Snapgear sources; it won't apply to 2.6.17.1). But even with that applied, the kernel doesn't detect any HDD.

Interestingly, I couldn't make USB work with a 2.6 kernel (I was hoping to boot from USB for a start), but the kernel doesn't detect it, either (I added bootdelay=10 to kernel boot options, and I think I compiled everything what's needed to detect USB devices).

So right now, it's only possible to boot with the default Freecom 2.4.27 kernel, but with it, some applications just segfault for some reason.

[1] VIA SATA patch for VT6421/L (it's a tar.gz package despite the name): http://www.viaarena.com/default.aspx?Pa … bCatID=117

NSLU2 uses big endian mode (although recently they made it support LE, too), and you can use NSLU2's binaries, if you install it in a chroot jail on your FSG-3.
However, many apps will segafault (like dpkg -l).

(Last edited by mangoo on 28 Jun 2006, 19:25)

I think NSLU2 is much more useful in little-endian mode than bigendian because LE ARM Debian is at least somewhat maintained and up-to-date compared to BE ARM Debian. Assuming you want complete Linux environment and not just uClibc.

For USB and SATA/PATA support I think you need to fix at least PCI setup first. Compare clean snapgear source and FSG source. There's not that many changes althought I don't know how much those area differ between 2.4.27 and 2.6.17.

Just compiled vanilla 2.6.17 configured for Montajade using OpenWrt buildroot-ng gcc. Results below. As you see machine ID for FSG3 is 0x122 (290 dec). That's actually ADI Coyote ID while hardware is more like Montajade. Same problem as those Billion routers have. Of course FSG3 also has broken Redboot that crashes on most commands.

RedBoot> fis load kern2
RedBoot> exec -c "console=ttyS0,115200 root=/dev/hda2 mem=64M@0x00000000"
Using base address 0x00700000 and length 0x00180000
Uncompressing Linux..................................................... done, booting the kernel.

Error: unrecognized/unsupported machine ID (r1 = 0x00000122).

Available machine support:

ID (hex)        NAME
0000025c        Intel IXDPG425

Please check your kernel config and/or bootloader.

Second attempt with patched arch/arm/tools/mach-types worked bit better.

edBoot> fis load kern2
RedBoot> exec -c "console=ttyS0,115200 root=/dev/hda2 mem=64M@0x00000000"
Using base address 0x00700000 and length 0x00180000
Uncompressing Linux............................................................ done, booting the kernel.
[42949372.960000] Linux version 2.6.17 (root@Freeride.adtest.net) (gcc version 3.4.6 (OpenWrt-2.0)) #5 Th
u Jun 29 01:38:51 EEST 2006
[42949372.960000] CPU: XScale-IXP42x Family [690541f1] revision 1 (ARMv5TE)
[42949372.960000] Machine: Intel IXDPG425
[42949372.960000] Memory policy: ECC disabled, Data cache writeback
[42949372.960000] CPU0: D VIVT undefined 5 cache
[42949372.960000] CPU0: I cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
[42949372.960000] CPU0: D cache: 32768 bytes, associativity 32, 32 byte lines, 32 sets
[42949372.960000] Built 1 zonelists
[42949372.960000] Kernel command line: console=ttyS0,115200 root=/dev/hda2 mem=64M@0x00000000
[42949372.960000] PID hash table entries: 512 (order: 9, 2048 bytes)
[42949372.960000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[42949372.960000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[42949372.960000] Memory: 64MB = 64MB total
[42949372.960000] Memory: 63012KB available (1640K code, 137K data, 72K init)
[42949373.200000] Mount-cache hash table entries: 512
[42949373.200000] CPU: Testing write buffer coherency: ok
[42949373.200000] NET: Registered protocol family 16
[42949373.200000] IXP4xx: Using 16MiB expansion bus window size
[42949373.200000] PCI: IXP4xx is host
[42949373.200000] PCI: IXP4xx Using direct access for memory space
[42949373.200000] PCI: bus0: Fast back to back transfers disabled
[42949373.200000] dmabounce: registered device 0000:00:0c.0 on pci bus
[42949373.200000] dmabounce: registered device 0000:00:0e.0 on pci bus
[42949373.210000] dmabounce: registered device 0000:00:0e.1 on pci bus
[42949373.210000] dmabounce: registered device 0000:00:0e.2 on pci bus
[42949373.210000] SCSI subsystem initialized
[42949373.210000] usbcore: registered new driver usbfs
[42949373.210000] usbcore: registered new driver hub
[42949373.210000] NET: Registered protocol family 2
[42949373.310000] IP route cache hash table entries: 512 (order: -1, 2048 bytes)
[42949373.310000] TCP established hash table entries: 2048 (order: 1, 8192 bytes)
[42949373.310000] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[42949373.310000] TCP: Hash tables configured (established 2048 bind 1024)
[42949373.310000] TCP reno registered
[42949373.310000] NetWinder Floating Point Emulator V0.97 (double precision)
[42949373.310000] JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc.
[42949373.320000] io scheduler noop registered
[42949373.320000] io scheduler deadline registered (default)
[42949373.710000] IXP4xx Watchdog Timer: heartbeat 60 sec
[42949373.710000] Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
[42949373.720000] serial8250.0: ttyS0 at MMIO 0xc8000000 (irq = 15) is a XScale
[42949373.970000] loop: loaded (max 8 devices)
[42949373.970000] PCI: enabling device 0000:00:0c.0 (0000 -> 0001)
[42949373.980000] sata_via 0000:00:0c.0: routed to hard irq line 8
[42949373.990000] ata1: SATA max UDMA/133 cmd 0x1420 ctl 0x142A bmdma 0x1400 irq 24
[42949373.990000] ata2: SATA max UDMA/133 cmd 0x1430 ctl 0x143A bmdma 0x1408 irq 24
[42949374.210000] ata1: SATA link down (SStatus 0)
[42949374.210000] scsi0 : sata_via
[42949374.420000] ata2: SATA link down (SStatus 0)
[42949374.420000] scsi1 : sata_via
[42949374.430000] IXP4XX-Flash.0: Found 1 x16 devices at 0x0 in 16-bit bank
[42949374.430000]  Intel/Sharp Extended Query Table at 0x0031
[42949374.440000] Using buffer write method
[42949374.440000] cfi_cmdset_0001: Erase suspend on write enabled
[42949374.450000] Searching for RedBoot partition table in IXP4XX-Flash.0 at offset 0x3e0000
[42949374.580000] 7 RedBoot partitions found on MTD device IXP4XX-Flash.0
[42949374.590000] Creating 7 MTD partitions on "IXP4XX-Flash.0":
[42949374.590000] 0x00000000-0x00040000 : "RedBoot"
[42949374.600000] 0x00040000-0x00080000 : "unallocated"
[42949374.610000] 0x00080000-0x00200000 : "kern1"
[42949374.610000] 0x00200000-0x00380000 : "kern2"
[42949374.620000] 0x00380000-0x003c0000 : "unallocated"
[42949374.620000] 0x003c0000-0x003e0000 : "RedBoot config"
[42949374.630000] 0x003e0000-0x00400000 : "FIS directory"
[42949374.640000] PCI: enabling device 0000:00:0e.2 (0140 -> 0142)
[42949374.640000] ehci_hcd 0000:00:0e.2: EHCI Host Controller
[42949374.650000] ehci_hcd 0000:00:0e.2: new USB bus registered, assigned bus number 1
[42949374.690000] ehci_hcd 0000:00:0e.2: irq 23, io mem 0x48002000
[42949374.690000] ehci_hcd 0000:00:0e.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[42949374.700000] usb usb1: configuration #1 chosen from 1 choice
[42949374.710000] hub 1-0:1.0: USB hub found
[42949374.710000] hub 1-0:1.0: 5 ports detected
[42949374.820000] Initializing USB Mass Storage driver...
[42949374.820000] usbcore: registered new driver usb-storage
[42949374.830000] USB Mass Storage support registered.
[42949374.830000] TCP bic registered
[42949374.840000] NET: Registered protocol family 1
[42949374.840000] 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
[42949374.850000] All bugs added by David S. Miller <davem@redhat.com>
[42949374.860000] VFS: Cannot open root device "hda2" or unknown-block(0,0)
[42949374.860000] Please append a correct "root=" boot option
[42949374.870000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[42949374.880000]

Results with VIA PATA patch. Had to drop VT8251 support as it didn't compile. Don't know if I broke something by removing those parts. It does detect disk at some level as capacity is correct.

[42949373.970000] PCI: enabling device 0000:00:0c.0 (0000 -> 0001)
[42949373.980000] sata_via 0000:00:0c.0: routed to hard irq line 8
[42949373.980000] ata1: PATA max UDMA/133 cmd 0x1420 ctl 0x142A bmdma 0x1400 irq 24
[42949373.990000] ata2: PATA max UDMA/133 cmd 0x1430 ctl 0x143A bmdma 0x1408 irq 24
[42949374.000000] ata3: PATA max UDMA/133 cmd 0x1440 ctl 0x144A bmdma 0x1410 irq 24
[42949374.180000] ata1: disabling port
[42949374.180000] scsi0 : sata_via
[42949374.350000] ata2: disabling port
[42949374.350000] scsi1 : sata_via
[42949374.530000] ata3: dev 0 ATA-7, max UDMA/100, 488397168 sectors: LBA48
[42949404.530000] ata3: qc timeout (cmd 0xef)
[42949404.530000] ata3: failed to set xfermode (err_mask=0x4)
[42949404.530000] scsi2 : sata_via

Also plugged in USB memstick and HDD that are detected on boot.

[42949404.750000] PCI: enabling device 0000:00:0e.2 (0140 -> 0142)
[42949404.760000] ehci_hcd 0000:00:0e.2: EHCI Host Controller
[42949404.770000] ehci_hcd 0000:00:0e.2: new USB bus registered, assigned bus number 1
[42949404.800000] ehci_hcd 0000:00:0e.2: irq 23, io mem 0x48002000
[42949404.800000] ehci_hcd 0000:00:0e.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[42949404.810000] usb usb1: configuration #1 chosen from 1 choice
[42949404.820000] hub 1-0:1.0: USB hub found
[42949404.820000] hub 1-0:1.0: 5 ports detected
[42949404.930000] Initializing USB Mass Storage driver...
[42949405.210000] usb 1-4: new high speed USB device using ehci_hcd and address 2
[42949405.360000] usb 1-4: configuration #1 chosen from 1 choice
[42949405.640000] usb 1-5: new high speed USB device using ehci_hcd and address 3
[42949405.800000] usb 1-5: configuration #1 chosen from 1 choice
[42949405.810000] scsi3 : SCSI emulation for USB Mass Storage devices
[42949405.820000] scsi4 : SCSI emulation for USB Mass Storage devices
[42949405.820000] usbcore: registered new driver usb-storage
[42949405.830000] USB Mass Storage support registered.

Hmm, nice. So you got farther than I did.

If it sees the disk, it should boot, shouldn't it? Perhaps it's somewhere else than on /dev/hda if it doesn't boot.

Did you try to boot from USB stick, and see if you can really see the disk?

Yes, true, armeb is not even blessed as official.

To do that on FSG, we would have to install LE RedBoot, (or do some other things), as described here:

http://www.nslu2-linux.org/wiki/Info/EndianNess

It doesn't look easy to me.

But first, perhaps it's a better idea to try to run anything other than Freecom firmware on a custom kernel

Yes it sees disk but I think it doesn't work correctly. There's long delay after it detects capacity and before driver prints "ata3: qc timeout (cmd 0xef)". I also agree device is probably called something else than hda, formatted as reiserfs etc. so I don't even expect it to boot with that kernel. I haven't tried using usb storage as root either.

Another issue with FSG-3 is cooling. There's that tiny fan that's spinning at insane speeds (9500+ rpm) and case is hot to touch. What good does that fan when there's no air inlets on case? Seems like design error to me. Only few small holes like that one for kensington lock. I tried to left front cover slightly open and within few minutes temps were down to normal levels and fan slowed down.

(Last edited by jr on 29 Jun 2006, 10:36)

Could you post your .config file for the 2.6 kernel compiled with OpenWRT?

Did you use a "regular" svn snapshot?

There is a "fand" daemon in FSG firmware, and the fan can operate in a couple of modes (fast, slow, off, and perhaps "auto"), it can be regulated via a web interface.
You can read the warnings in the web interface (turning off the fan will shorten the life of your FSG system).

And there are some more holes: USB, ethernet, SATA ports

Here's quite old guide how to run LE Debian on NSLU2 http://peter.korsgaard.com/articles/deb … tle-endian . It doesn't require Redboot changes at all. I even booted that image on Billion router with BE Redboot.

I know there's fan control, but it only makes device hotter. Doesn't fix actual problem with inadequate cooling. If you look closely there's plenty of space for fan to push air out, but lot less holes to get air in. Trying to suck air thru small gaps around ports isn't working.