Topic: ar71xx eeprom area on TL-WR1043ND vs. kexec

Hi everyone,

I'm trying to run kexec'ed kernel on TL-WR1043ND (https://forum.openwrt.org/viewtopic.php?id=23901). It makes it possible to perform full upgrades of the software without any reflashing. And it works pretty well except for network related stuff wink

Here's some info to present situation:

root@OpenWrt:/# dmesg |grep ath
ath: Bad EEPROM checksum 0x0 or revision 0x0000
ath: Unable to initialize hardware; initialization status: -22
ath9k ath9k: failed to initialize device
ath9k: probe of ath9k failed with error -22
root@OpenWrt:/# ifconfig
br-lan    Link encap:Ethernet  HWaddr 00:00:00:01:00:00
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:402 (402.0 B)

eth0      Link encap:Ethernet  HWaddr 00:00:00:01:00:00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1134 (1.1 KiB)  TX bytes:2678 (2.6 KiB)
          Interrupt:4

eth0.1    Link encap:Ethernet  HWaddr 00:00:00:01:00:00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:406 (406.0 B)

eth0.2    Link encap:Ethernet  HWaddr 00:00:00:01:00:00
          inet addr:192.168.1.229  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:814 (814.0 B)  TX bytes:1229 (1.2 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@OpenWrt:/#

As you can see the ath9k module doesn't create PHY device because eeprom's checksum is 0 while during normal operation it's FF. Also MACs got zeroed.

I've found following board specific initialization code in mach-tl-wr1043nd.c

static void __init tl_wr1043nd_setup(void)
{
        u8 *mac = (u8 *) KSEG1ADDR(0x1f01fc00);
        u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff1000);

It looks that the data is lost once the kexec kernel takes over the operation
Question is what loads eeprom and mac data to the memory? Kernel? U-boot? Is it possible to reinitialize it?
Any hints or suggestions what to try to bring back eeprom data? Things to try?

Re: ar71xx eeprom area on TL-WR1043ND vs. kexec

bump - want to do the same thing with the same hardware ... anyone?

2x TP-Link wr1043nd (1x64MB RAM, 1x32MB RAM) - booting from usb sticks (kexec'd kernel)
1x Seagate DockStar booting  from 500GB 2,5" HDD (firststage u-boot with usb boot support)
1x la fonera 2.0 (stock @ backfire)

Re: ar71xx eeprom area on TL-WR1043ND vs. kexec

When the kernel starts, the flash chip is memory-mapped, that's why copying from these addresses works during the early kernel init. Once the SPI flash driver is initialized, this memory mapping is turned off.

4 (edited by Memphis 2010-07-29 12:08:32)

Re: ar71xx eeprom area on TL-WR1043ND vs. kexec

That sounds tricky. So in theory the flash init from uboot bootloader (which memorymaps the flash) has to be rerun in early kexec - kernel boot (activated by kernel cmdline for example). Would this do the trick?

2x TP-Link wr1043nd (1x64MB RAM, 1x32MB RAM) - booting from usb sticks (kexec'd kernel)
1x Seagate DockStar booting  from 500GB 2,5" HDD (firststage u-boot with usb boot support)
1x la fonera 2.0 (stock @ backfire)

Re: ar71xx eeprom area on TL-WR1043ND vs. kexec

@ nbd

ist it possible to first load the spi flash driver and after that accessing the needed flash parts via the spi flash driver instead of using:

u8 *mac = (u8 *) KSEG1ADDR(0x1f01fc00);
u8 *eeprom = (u8 *) KSEG1ADDR(0x1fff1000);

I'm sure this is very naiv thinking though wink - this would then work on the host kernel and on the kexec kernel aswell.

2x TP-Link wr1043nd (1x64MB RAM, 1x32MB RAM) - booting from usb sticks (kexec'd kernel)
1x Seagate DockStar booting  from 500GB 2,5" HDD (firststage u-boot with usb boot support)
1x la fonera 2.0 (stock @ backfire)

Re: ar71xx eeprom area on TL-WR1043ND vs. kexec

I don't think that's a good idea, that would mess with the device initialization order.
It's better to just restore the memory mapping when doing kexec. the AR71xx SPI driver contains code to switch from memory mapping to direct access and to switch back. Maybe it could work if you unbind or deinit the SPI driver before the kexec happens.

Re: ar71xx eeprom area on TL-WR1043ND vs. kexec

mhh i would try this when i'm at home ... maybe i just could unbind the spi driver via sysfs before issueing kexec (which i have copied to ramdisk before of course) ... but i'm not sure if unbinding the driver is such a good idea ... this could do funny things with running processes which hold file handles i think ...

2x TP-Link wr1043nd (1x64MB RAM, 1x32MB RAM) - booting from usb sticks (kexec'd kernel)
1x Seagate DockStar booting  from 500GB 2,5" HDD (firststage u-boot with usb boot support)
1x la fonera 2.0 (stock @ backfire)

Re: ar71xx eeprom area on TL-WR1043ND vs. kexec

mhh... that didn't work for me... I hardcoded this values into the kexec-kernel (dumped using u-boot, converted to c-code and included into mach-tl-wr1043nd.c).
Not very nice but it works for me.

If you've got it to work without such ugly hacks, please tell us how this could be done wink

Re: ar71xx eeprom area on TL-WR1043ND vs. kexec

What is the actual benefit of kexec?

If you do not like extroot, because the booted kernel remains on the flash, maybe you could teach u-boot to boot from USB.

Jeef doozan patched the dockstar-uboot to do that. Vanilla uboot can also handle a couple of filesystems. But I guess tp-link never bothered to port their stuff back into vanilla and I also guess that the to-link-uboot cannot boot from usb.

Re: ar71xx eeprom area on TL-WR1043ND vs. kexec

The actual benefit of kexec is to be able to boot a kernel from USB without having to touch u-boot.

I still haven't got my EJTAG hardware and without any possibility to debug u-boot or at least recover
from a bad flash without de- and resoldering the flash chip this seems too dangerous to me...

I like extroot. I use iton many devices and it works without problems... But one of my WR1043NDs has some
serious issues with flashing. If I try to flash anything, I have to do that about 4 or 5 times till it really is in flash
without errors. I think booting the kernel from USB is a better alternative for this special device.

Re: ar71xx eeprom area on TL-WR1043ND vs. kexec

hugo1789 wrote:

The actual benefit of kexec is to be able to boot a kernel from USB without having to touch u-boot.

I see. So you got to decide what is simpler, chainloading 2 uboots one after the other, so you can tinkner around with the second one, or using kexec.

I think the first method would be simpler.

For reasons I do not understand, the dockstar: http://wiki.openwrt.org/toh/seagate/dockstar#flash.layout  is doing that. I use one-stage with debian, and it's doing fine.