Hi again,

this is a bit of a follow-up to my post in the general forum, maybe it's better suited here.

I've been thinking about putting kamikaze on my ASUS WL-HDD (rebadged by Yakumo),
however, without JTAG or even a serial port, this looks a bit risky for now.

But according to http://wiki.openwrt.org/OpenWrtDocs/Cus … dware/UART , some
BCM4702KPB-based boards contain a 20-pin jumper block that can be used to connect an
external UART, and I've found a very similar array of solder pads right behind the IDE connector
(see also here http://wiki.openwrt.org/OpenWrtDocs/Har … rnalImages ).

According to what it says here http://forum.openwrt.org/viewtopic.php?id=4159 , the pinout could be
the same as on the WL-500g, where someone here http://wl500g.info/showthread.php?t=587&pp=15
already managed to add a serial port.

Has anybody already tried this? If not, I guess I will do that maybe next weekend. Does the CFE have
to be modified in any way to enable the serial port?

Yours, Florian

Hello Florian

I was thinking about exactly the same thing but was to lazy to build UART board. I hope you will succeed

I hope that too :-) Do you know if the CFE has to be modified in any way to enable the serial port
(always presumed that adding one works)?

Florian

The pinout looks similar indeed - GND and VCC look alright, D0 - D7 seem to connect to the appropriate pins on the flash-rom so the rest will hopefully be in the right place as well.

Yes - on my WL-500g.

I think wtzm can answer this question

Nope. On the WL-500g you simply connect your UART board and the power supply and you will see the bootloader messages (CTRL+C gets you a prompt). By the way - the WL-HDD uses PMON, not CFE.

Are you sure? Because the wiki entry claims it's using CFE - but I'm more inclined to believe you :-)

BTW: what quartz crystal did you use? 12.75 MHz?

Florian

Yes - 12.75 MHz.

Not at all. So promise not to throw heavy things at me if I'm wrong.
After looking through a WL-HDD nvram dump I'm fairly confident that it is PMON indeed. You can also try to find the prompt string in your bootloader partition

grep 'PMON>' /dev/mtdblock/0
grep 'CFE>' /dev/mtdblock/0

Just make sure the '>' is escaped.

It works:

Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0xbf800008 (irq = 2) is a 16550A

Details will follow tomorrow (I just switched it on briefly to check for black smoke and sparks )

Florian

(Last edited by floe on 6 Sep 2006, 22:34)

Okay, now for a bit more detail..

I first spent an awful amount of time soldering a pin header to the SMD pads on the WL-HDD board,
but I finally managed to get them decently fixed without frying the traces.

After that, having wasted almost an entire saturday , I was a bit less careful when constructing the
ciruit on a piece of perfboard, so it looks a bit messy - but it works.

At the first try (see above), the UART was detected at 0xbf800008, as I had simply replicated the
circuit from the AsusForum post. However, it only worked in Linux that way, not in the bootloader,
so I just removed the connection between pin 12 (A3) on the WL-HDD and pin 13 on the UART and
connected the latter to VCC. Now Linux detects the UART twice (to be expected, I should have added
an inverter instead, but I was too lazy ), but the bootloader does, too, and that's the important part.

BTW: it's really PMON, not CFE. And about the quartz: I used a 6.55 MHz crystal, because a) that one
was easy to get and b) the UART's datasheet said it had a maximum rating of 8 MHz.
6.55 is okay because 57600 x 16 x 7 = 6451200, that's quite a bit outside the specified 5% error, but
my USB-RS232 converter accepted it anyway (thanks to the FIFO, it doesn't matter that it's not running
at 115200).

And just in case anybody is interested, you can look at the entire output from one fresh boot here.

One thing that's still missing IMHO is a better schematic than the one from the AsusForum.. I've started
to draw one in Eagle, but it's not finished yet, so stay tuned

Florian

Congratulations!
Sorry, I forgot to mention the address decoding issue. BTW: For simplicity's sake I used the same solution.

No problem, I've read this part in the AsusForum post. About the schematic: I've noticed that, unfortunately,
it doesn't get any more readable just because it's drawn in Eagle.. I'll post a link to the Eagle files in the
evening, so maybe somebody with a bit more skill than me can give it a try.

A question I have left is about the way this interface works, because I was thinking about attaching a display
there (USB would be a more portable option, but it's a bit unreliable and slow for a larger display).

If I now write (read) a byte somewhere between 0xbf800000 and 0xbf80000f, the following things will happen:
a) the byte shows up on pins D0..D7
b) the low nibble of the address shows up on pins A0..A3
c) /CS is set low
c) a strobe on /WR (/RD) is generated

Is that about correct? And if I strobe the INT line, which interrupt is triggered?

P.S. Just as a reference, here's the pinout from the other post again:

----------
> D0  D1 |
| D2  D3 |
| D4  D5 |
| D6  D7 |
| A0  A1 |
| A2  A3 |
|+5V /CS |
|/RD /WR |
|INT GND |
| NC  NC |
----------

I don't know the exact timings for reading/writing from/to the EXTIF, so use common sense (or the datasheet of your UART) and it will probably work.
By the way, on the WL-500g /CS is the "real" /CS OR A4 (Printer Port selected with A4=1).

INT connects to one of the GPIO ports, which can trigger the interrupt of the SB_EXTIF core. The relevant code is in sbmips.c (invoked by setup.c) in your kernels arch/mips/bcm947xx directory.

How did you do this? I tried via /dev/port but i could not see any change on any pins...

Uh, this was meant hypothetically, I didn't actually implement anything like that. In practice, I probably would have tried using a small kernel driver for this..

I now connected my oscilloscope to /CS-line and plugged in power supply to my router. I can't see any high to low transition on this line! Shouldn't the router test for a external UART chip here? I looked at sbmips and found that it should write some byte to 0xbf80000x and try to read back. So /CS should go low for about 32 times.

Is there a documentation about all the sb stuff, so i can get a clue how to gain access?

I also had a look at gpio.c and found that the functions sb_gpioin from sbutils.c have a switch for SB_EXITIF "case SB_EXTIF:" so is it possible to use the gpio module to get access... and if yes, how?

Thanks for your help...

As far as I can tell, /CS will probably stay low all the time - the strobes would rather happen on /WR or /RD.

Florian

It's high all the time...

As far as i know of busconcetps /CS should go low from any address in range from 0xbf800000 to 0xbf80000F because on external address lines only the low nibble appears and to differ for e.g. 0x0020000A from 0xBF80000A you need some additional information... the /CS line.

Any further help is welcome

Tobias

After some days of source-reading i found the solution for my problem on howo accessing the external interface. I even managed to connect a standard LCD display and write some text onto it.

For all interested i started sharing my experience with this here: http://tobiscorner.floery.net/ (under category "jukebox" )

Congratulations, this is really useful! But are you still having problems with the /CS line?

Florian

Now that I can write to many addresses I can have a closer look at the /CS line.

Tobias

Hi
i notice that you try to use kamikaze on wl-hdd.
i have a wl-hdd from yakumo, and kamikaze r5058 is running on it.
wireless config is default
network config: (note that dmesg finds also eth0, but only the eth1-port exists on the Board)
#### LAN configuration
config interface lan
        option ifname   "eth1"
        option proto    static
        option ipaddr   192.168.1.220
        option netmask  255.255.255.0

config interface wlan0
        option ifname   "wl0"
        option proto    static
        option ipaddr   192.168.10.1
        option netmask  255.255.255.0

i think with a standard kamikaze build wl-hdd will not initialize the netconfig accurate,
because the /etc/init.d/S05netconfig can´t handle a wl-hdd at the moment,
so it will never build a usefull /etc/config/network config.

i use a r5058 image from a wl500g, modified the netconfig on the wl500g, make a backup image and load it on wl-hdd. it works.
it is not nice, but for testing its ok.

hope it helps

Did that and found out that my, now dead, oscilloscope was too slow.. The /CS line goes low whenever an address between 0xBF800000 and 0xBF80000F is read or written. But controlling the Display using the /CS line will be somehow more complicated... read here: http://tobiscorner.floery.net/?p=63

If you have some slower hardware connected to the external interface you can adjust the wait states of the bus. I have not figured out all the values. But with some more time on it I think I can find the last one.

-> http://tobiscorner.floery.net/