Village Telco » Uncategorized

Booting Linux on the Mesh Potato

drowe — Mon, 08 Jun 2009 08:19:09 +0000

The good news is we have Linux booting on the Mesh Potato:

+Ethernet eth0: MAC address 00:22:b0:42:03:e4 IP: 192.168.1.1/255.255.255.0, Gateway: 192.168.1.22 Default server: 192.168.1.2

RedBoot(tm) bootstrap and debug environment [ROMRAM] Non-certified release, version v1.3.0 - built 16:59:11, Jun 8 2009

Board: ap61 RAM: 0x80000000-0x81000000, [0x8003dd50-0x80fe1000] available FLASH: 0xa8000000 - 0xa87e0000, 128 blocks of 0x00010000 bytes each. == Executing boot script in 5.000 seconds - enter ^C to abort RedBoot> load openwrt-atheros-vmlinux.elf Using default protocol (TFTP) Entry point: 0x801f8850, address range: 0x80041000-0x80262086 RedBoot> go Linux version 2.6.26.3 (david@bunny) (gcc version 4.1.2) #3 Mon Jun 8 15:07:39 9memcfg: 0x141168 memsize: 0x1000000 SDRAM_DATA_WIDTH: 0x0 SDRAM_COL_WIDTH: 0x8 SDRAM_ROW_WIDTH: 0xb CPU revision is: 00019064 (MIPS 4KEc) Determined physical RAM map: memory: 01000000 @ 00000000 (usable) Initrd not found or empty - disabling initrd Zone PFN ranges: Normal 0 -> 4096 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 4096 Built 1 zonelists in Zone order, mobility grouping off. Total pages: 4064 Kernel command line: console=ttyS0,9600 rootfstype=squashfs,jffs2 init=/etc/pretPrimary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes. Primary data cache 16kB, 4-way, VIPT, no aliases, linesize 16 bytes PID hash table entries: 64 (order: 6, 256 bytes) console [ttyS0] enabled Dentry cache hash table entries: 2048 (order: 1, 8192 bytes) Inode-cache hash table entries: 1024 (order: 0, 4096 bytes) Memory: 13692k/16384k available (1773k kernel code, 2692k reserved, 289k data, )SLUB: Genslabs=6, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Mount-cache hash table entries: 512 net_namespace: 644 bytes NET: Registered protocol family 16 WARNING: broken board data detected Radio config found at offset 0xf8(0x1f8) NET: Registered protocol family 2 IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 512 (order: 0, 4096 bytes) TCP bind hash table entries: 512 (order: -1, 2048 bytes) TCP: Hash tables configured (established 512 bind 512) TCP reno registered NET: Registered protocol family 1 ar531x: Registering GPIODEV device squashfs: version 3.0 (2006/03/15) Phillip Lougher Registering mini_fo version $Id$ JFFS2 version 2.2. (NAND) (SUMMARY) .. 2001-2006 Red Hat, Inc. msgmni has been set to 26 io scheduler noop registered io scheduler deadline registered (default) gpiodev: gpio device registered with major 254 gpiodev: gpio platform device registered with access mask FFFFFFFF Serial: 8250/16550 driver $Revision: 1.90 $ 1 ports, IRQ sharing disabled serial8250: ttyS0 at MMIO 0xb1100003 (irq = 37) is a 16550A eth0: Atheros AR231x: 00:22:b0:42:03:e4, irq 4 ar2313_eth_mii: probed eth0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=0:01) cmdlinepart partition parsing not available Searching for RedBoot partition table in spiflash at offset 0x7d0000 6 RedBoot partitions found on MTD device spiflash Creating 6 MTD partitions on "spiflash": 0x00000000-0x00030000 : "RedBoot" 0x00030000-0x000e0000 : "vmlinux.bin.l7" 0x000e0000-0x007d0000 : "rootfs" mtd: partition "rootfs" set to be root filesystem mtd: partition "rootfs_data" created automatically, ofs=330000, len=4A0000 0x00330000-0x007d0000 : "rootfs_data" 0x007d0000-0x007df000 : "FIS directory" 0x007df000-0x007e0000 : "RedBoot config" 0x007e0000-0x00800000 : "boardconfig" Registered led device: gpio1 Registered led device: gpio2 Registered led device: gpio3 Registered led device: gpio4 Registered led device: wlan TCP vegas registered NET: Registered protocol family 17 802.1Q VLAN Support v1.8 Ben Greear All bugs added by David S. Miller VFS: Mounted root (squashfs filesystem) readonly. Freeing unused kernel memory: 120k freed Please be patient, while OpenWrt loads ... eth0: Configuring MAC for full duplex Algorithmics/MIPS FPU Emulator v1.5 - preinit - Press CTRL-C for failsafe jffs2 not ready yet; using ramdisk mini_fo: using base directory: / mini_fo: using storage directory: /tmp/root - init -

Please press Enter to activate this console. device eth0 entered promiscuous moebr-lan: port 1(eth0) entering learning state br-lan: topology change detected, propagating br-lan: port 1(eth0) entering forwarding state PPP generic driver version 2.4.2 tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky ip_tables: (C) 2000-2006 Netfilter Core Team nf_conntrack version 0.5.0 (1024 buckets, 4096 max) ipt_time loading wlan: trunk ath_hal: module license 'Proprietary' taints kernel. ath_hal: 2008-10-02 (AR5212, AR5312, RF5111, RF5112, RF2316, RF2317, REGOPS_FUN)ath_rate_minstrel: Minstrel automatic rate control algorithm 1.2 (trunk) ath_rate_minstrel: look around rate set to 10% ath_rate_minstrel: EWMA rolloff level set to 75% ath_rate_minstrel: max segment size in the mrr set to 6000 us wlan: mac acl policy registered ath_ahb: trunk Atheros HAL provided by OpenWrt, DD-WRT and MakSat Technologies wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 3swifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps wifi0: H/W encryption support: WEP AES AES_CCM TKIP ath_ahb: wifi0: Atheros 2317 WiSoC REV1: mem=0xb0000000, irq=3 jffs2_scan_eraseblock(): End of filesystem marker found at 0x0 jffs2_build_filesystem(): unlocking the mtd device... done. jffs2_build_filesystem(): erasing all blocks after the end marker... done. mini_fo: using base directory: / mini_fo: using storage directory: /jffs

BusyBox v1.11.2 (2009-05-18 13:36:36 CST) built-in shell (ash) Enter 'help' for a list of built-in commands.

_______ ________ __ | |.-----.-----.-----.| | | |.----.| |_ | - || _ | -__| || | | || _|| _| |_______|| __|_____|__|__||________||__| |____| |__| W I R E L E S S F R E E D O M KAMIKAZE (bleeding edge, r91) ------------------- * 10 oz Vodka Shake well with ice and strain * 10 oz Triple sec mixture into 10 shot glasses. * 10 oz lime juice Salute! --------------------------------------------------- root@OpenWrt:/# df -h Filesystem Size Used Available Use% Mounted on rootfs 2.3M 2.3M 0 100% / /dev/root 2.3M 2.3M 0 100% /rom tmpfs 6.7M 60.0k 6.7M 1% /tmp tmpfs 512.0k 0 512.0k 0% /dev mini_fo:/tmp/root 2.3M 2.3M 0 100% /tmp/root /dev/mtdblock3 4.6M 268.0k 4.4M 6% /jffs mini_fo:/jffs 2.3M 2.3M 0 100% / root@OpenWrt:/#

A bee's view flying over the Potato landscape

It even picks up the 8M flash, Ethernet works, and the Wifi drivers come up. In the last installment Linux was choking due to an inaccurate estimate of available memory (32M rather than the actual 16M). I spent an afternoon tracking down the cause – Linux on the AR2317 detects the amount of memory by examining a register that the boot loader sets up before Linux starts. Here is the Linux source (arch/mips/atheros/ar5315/board.c):


memcfg = sysRegRead(AR5315_MEM_CFG);
memsize   = 1 + ((memcfg & SDRAM_DATA_WIDTH_M) >> SDRAM_DATA_WIDTH_S);
memsize <<= 1 + ((memcfg & SDRAM_COL_WIDTH_M) >> SDRAM_COL_WIDTH_S);
memsize <<= 1 + ((memcfg & SDRAM_ROW_WIDTH_M) >> SDRAM_ROW_WIDTH_S);
memsize <<= 3;
add_memory_region(0, memsize, BOOT_MEM_RAM);

Hmmmm, just after I thought I was free of boot loader issues! Anyway a bit of Googling found another guy in the OpenWRT community who had found and solved exactly the same problem 6 months ago . Thanks Yoonix!

The fix involved changing the SDRAM #defines in the boot loader source and reflashing the boot loader. As soon as we re-flashed the boot loader Linux came up straight away. Joel, a local Linux hacker came around to help out. He wrote a little Python script to model the register configuration changes and make sure I didn't type anything too silly while reflashing the boot loader (my record is not good ).

I also found a neat trick for testing Linux kernel images in RedBoot without reflashing:
RedBoot> load openwrt-atheros-vmlinux.elf RedBoot> go
This can be automated using fconfig -d to make the two steps above the boot script. That way you can compile a new Linux kernel image, then power cycle the Atheros device to test it without flashing anything.

OK, now time to look at bringing up Wifi, or maybe the FXS port. Or maybe I'll just order some pizza!

Breathing Life into the Mesh Potato – Day 1

drowe — Tue, 02 Jun 2009 07:53:55 +0000

The first Mesh Potato

Yesterday (Monday June 1) the courier arrived with the very first Mesh Potato (MP) prototype, which had been hand assembled by the good people at Atcom. This is always an exciting and risky time in the life of any hardware project, as you don’t really know if it’s going to work. In fact, there is a hell of a lot that could go wrong. Like one solder ball under the Atheros BGA chip not soldered, or a nasty PCB or schematic design error that means another re-spin of the PCB and 1 month delay. Or smoke might come out of the Atheros chip when you first apply power. I have seen all of these on past projects…..

Fortunately Alen at Atcom had done some initial tests, like checking for the 3V3 and 1V8 power rails, and making sure the 40 MHz clock was present. So we had some encouraging early signs of life.

My initial goal was to get the boot loader to run – this would prove that most of the AR2317 circuit is OK (CPU, RAM, flash etc). I chose the boot loader image (ap61.rom) that we have been using on the DIR-300 router as this router uses the same Atheros AR2317 chip. So I connected the JTAG cable. The CPU was detected (excellent!) and the jtagspi software started flashing the boot loader. This is a slow process (2.5 hours) using my home-brew JTAG cable, so I headed out for a nice Chinese lunch and a walk with my wife! Alright, so we also went to the bakery and bought a custard filled cake. You need energy to hack.

Two hours later I returned and tentatively connected the RS232 cable and power up the MP. This is what I saw:

No board config data found!+flash_hwr_init: Unsupported flash device - id=22FLASH: driver init failed: Driver does not support deviceSorry, FLASH config exceeds available space in FIS directoryCouldn't find valid MAC address for enet0. Using default!Invalid PHY ID1 for enet0 port0.  Expected 0x0243, read 0xffff/ar2317-prj/LSDK5.0.2.46/src/redboot_cobra/ecos/packages/devs/eth/mips/ar531x/ccEthernet eth0: MAC address 00:03:7f:e0:02:bfIP: 0.0.0.0/255.255.255.0, Gateway: 0.0.0.0Default server: 0.0.0.0RedBoot(tm) bootstrap and debug environment [ROMRAM]Non-certified release, version UNKNOWN - built 00:32:22, Aug  7 2007Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.Board: ap61RAM: 0x80000000-0x80800000, [0x80040760-0x807f1000] availableFLASH: 0x00000000 - 0x00000001, 0 blocks of 0x00000000 bytes each.RedBoot>

This is actually pretty good – the boot loader is running – with a few complaints about the 8M flash and Ethernet PHY. However a running boot loader means much of the hardware must be OK. Nice.

I have some RedBoot hacking to do (to accommodate the 8M flash and Ethernet PHY) so the next step was to get the Ethernet up. That way I can tftp new boot loader images rather than put up with 2 hour JTAG flash sessions. Actually in hind sight I should have bought a commercial JTAG cable that can flash in 5 seconds. However the Ethernet was dead (no link lights, ping didn’t work), and I didn’t like the look of those complaints about the PHY chip.

So I perused the DP83848I PHY chip data sheet. I decided to probe a few pins on the PHY chip with my oscilloscope to see if it looked alive. One pin I tested was the CLK_OUT pin 25, which should have a 25 MHz signal on it. However it was silent. Hmmmm, not good.

So I contacted Alen via IM and he confirmed that on other designs using that chip p25 definetely had a 25 MHz signal on it. So I checked the second MP01 I had been sent. No CLK_OUT signal either.

When both my MP01′s didn’t have the CLK_OUT signal I suspected it was a wiring/design error. Well, it was just a guess really. Telling these bug hunt stories in review it looks like the outcome was pre-ordained. However at the time you are never really sure. You usually go down many blind alleys, which results in frustration and lack of sleep shutting brain cells down!

Anyway clocks should usually come straight up without any software initialization. So I just checked the reset/interrupt lines (in case the chip was being held in the reset state), then I checked the various power supply lines to the chip. A-HA! One power supply line (pin 22 AVDD33) was not connected! Via IM Alen then double checked his other designs and confirmed that yes, it was a bug.

When I added a wire to supply 3V3 to pin 22 CLK_OUT came up and the network link light started working. Yayyyyyyy!

There is also a golden rule in hardware (and indeed software) development. Anything you change will have bugs. That PHY was changed from the reference design so it’s a natural source of bugs. A bug “emitter” if you like.

Then it was time for some network tests. Ping, and even tftp worked. Very cool. The default state of the PHY chip seems to be just enough to get basic network connectivity. This means I can download new RedBoot images quickly as I modify for thew new flash and PHY.

It was getting late by this stage so I decided to call it a night. So I emailed Elektra about where we were at and went to watch Top Gear which my three year old. However our story does not end there. Elektra was working hard while I was resting and sleeping. When I woke up this morning she sent me several emails detailing how to set up the RedBoot development environment. This is great – saves me a mornings work. Amazing how working 12 hours apart (Berlin and Adelaide, Australia) can be helpful!

Right. Time for some a fresh cup of coffee and some RedBoot hacking.

Village Telco Profiled in ICTUpdate

steve — Fri, 24 Oct 2008 13:35:54 +0000

The Village Telco and the Mesh Potato are profiled in the latest edition of ICTUpdate, a bimonthly printed bulletin, a web magazine, and an accompanying email newsletter published by the Technical Centre for Agricultural and Rural Cooperation (CTA) ACP–EU. I’d love to say those were my own words, as the article does such a good job of explaining the village telco, but the article was written by Jim Dempsey of Contactivity.com.