On Wednesday 14 September 2005 11:27 am, Hubert Feyrer wrote:
> If you find anything, post it here so others can work from that.

The Sentry5 SoCs have two 16550 serial ports, one at 0x18000300 (0xb8000300 in 
Linux dmesg) the second at 0x18000400 (0xb8000400 in the Linux dmesg). The 
WRT54G uses the lower-addressed port, the WGT634U the higher for their 
firmware consoles. I ran this program to test the serial ports:
{{{
        .file   1 "program.c"
        .section .mdebug.abi32
        .previous
        .abicalls
        .text
        .align  2
        .globl  _start
        .ent    _start
_start:
$L2:
        li      $2,64                   # 0x40
        #.set   volatile
        sb      $2,-1207958784
        #.set   novolatile
        li      $2,64                   # 0x40
        #.set   volatile
        sb      $2,-1207958528
        #.set   novolatile
        b       $L2
        .end    _start
        .size   _start, .-_start
        .ident  "GCC: (GNU) 3.3.3 (NetBSD nb3 20040520)"
}}}
This program, linked to enter at 0x80500000 (the address Linux is linked to 
start at in the stock WGT634U firmware) using our MIPS stand.ldscript, will 
load on the WGT634U, with its "CFE version 1.0.34 for BCM95365R 
(32bit,SP,LE)". On the WRT54Gv3 CFE 3.61.13.0 seems to have an exception 
while loading it. Unlike sbmips, there is no memory at 0x20000000 to load 
things to.

The flash is located at 0x1C000000, usually 4MiB or 8MiB. It is somehow mapped 
into partitions. Does NetBSD presently provide a way to map something like 
this into a block device?

PCI device listings from Linux (with added comments concerting function):

WRT54G v3, BCM4712
    Class 0200: PCI device 14e4:4713 (rev 1). Ethernet
    Class 0280: PCI device 14e4:4320 (rev 1). WLAN
    Class 0500: PCI device 14e4:080f (rev 1). RAM ctlr
    Class 0501: PCI device 14e4:0800 (rev 1). IO ctlr
    Class 0b30: PCI device 14e4:0816 (rev 1). CPU
    Class 0c03: PCI device 14e4:4716 (rev 1). USB Host
    Class 0c03: PCI device 14e4:4717 (rev 1). USB device

WGT634U, BCM5365P, the EHCI and WLAN are behind a bridge
    Class 0501: PCI device 14e4:0800 (rev 1). IO
    Class 0200: PCI device 14e4:4713 (rev 1). Ethernet
    Class 1000: PCI device 14e4:4718 (rev 1). Crypto
    Class 0c03: PCI device 14e4:4715 (rev 1). USB
    Class 0604: PCI device 14e4:0804 (rev 1). PCI bridge
    Class 0b30: PCI device 14e4:0816 (rev 1). CPU
    Class 0500: PCI device 14e4:080f (rev 1). RAM
    Class 0600: PCI device 14e4:5365 (rev 0). PCI-SB bridge
    Class 0200: PCI device 168c:0013 (rev 1). Atheros WLAN
    Class 0c03: PCI device 1033:0035 (rev 67). USB EHCI
    Class 0c03: PCI device 1033:0035 (rev 67). USB EHCI
    Class 0c03: PCI device 1033:00e0 (rev 4). USB EHCI

Memory map according to Linux:

WRT54Gv3
Determined physical RAM map:
 memory: 01000000 @ 00000000 (usable)

WGT634U
Determined physical RAM map:
 memory: 02000000 @ 00000000 (usable)

On the WGT634U the firmware configures the vlan tagging managed ethernet 
switch (which seems to be controlled via MII registers; a GPLed frobber 
called 'robocfg' exists) in a way the WAN port remains untagged and the LAN 
ports are tagged to vlan #1. I am unsure as to how the WRT54G's firmware 
configures things. Not all WRT54G(S)es use a Broadcom switch. The ethernet 
controller appears to be compatible with the BCM4401, as the 2.6 kernel that 
OpenWrt uses on the WGT634U drives it with a module called 'b44'. 
Unfortunately our bce(4) driver doesn't grok 802.1q yet (according to the 
manpage). I know of no readily available documentation on these components.

The WLAN story is much sadder. The BCM4712 in the WRT54G v3 uses a 
BCM4320-compatible controller. This is the same infamous controller natively 
unsupported by all free Unixes, the only real hope to use it would be to have 
hooks into the Broadcom-proprietary Linux-driver object files. A project 
exists to reverse engineer documentation from these object files (of course 
any resulting driver will be of questionable legality with the FCC). 
Fortunately the WGT634U uses a Atheros AR5213 on a miniPCI card, a HAL exists 
in our source tree. Has anyone tested the ath(4) driver on MIPS-el?

Would the experts care to comment on if there should be another bootloader to 
load the kernel, or to load the kernel directly from CFE?

I have attempted to run a relinked sbmips boot loader with no success. I 
believe the exception is happening after it starts executing. Unfortunately 
to do much more I will have to learn more about the kernel and it's loader; 
probably even this platform in general.

	Jonathan Kollasch