Re: RouterBoard 133 support

David Young wrote:
> I have heard of this problem before.  Maybe you mentioned it to me?
>
nop, last time I powered the board I ended up in the "TLB out of the
universe" at extio? attachment and didn't look further.

> IIRC, there are six VLANs, one for each of the 5 MII ports, and a
> sixth for a "virtual" port that connects to the CPU.
>
ok, I better understand the layout now, I had some difficulties to
represent it before :-)

> I suggest that if the bootloader has assigned one port to each VLAN,
> then you derive the port numbers from the VLAN matrix:
>
> MII0 MII1 MII2 MII3 MII4 CPU VLAN0      x                   x VLAN1
> x              x VLAN2                x         x VLAN3
> x    x VLAN4 x                        x VLAN5
> x
>
If I trust the Vlan_GI and Vlan_GII, I have the following mapping:
          MII0 MII1 MII2 MII3 MII4 MII5 CPU
    VLAN0 x                             x
    VLAN1      x                        x
    VLAN2           x                   x
    VLAN3                x              x
    VLAN4                     x         x
    VLAN5                          x    x

Looks like one of the MII is a GMII.

> In this case, the 0th MII port is admsw4, and MII ports 1 through 4
> are ports admsw0 through admsw3.
>
is it really good to have such an interface mapping ? Wouldn't be better
to have only one interface attaching to a switch device and a userland
tool to control the switch feature. I am under the impression that the
switch code is mixed with the interface code currently. I don't really
see a way to use bridge(4) and vlan(4) with this.

Btw, the current interface mapping will attach 6 interfaces which does
not fit with the hardware (only 3 ethernet plug on the board)

>> ps: is there a way to enforce arch endianness and fails if a wrong
>> one is used? evbmips has no default MACHINE_ARCH, but the
>> bootloader will fails with big endian kernel (the SoC endiannes is
>> wired in hardware anyway).
>
> I'm not sure what you're asking.  I build with build.sh -m
> evbmips-el.
>
I was more thinking of something like:
<config file>
options LITTLE_ENDIAN_BOARD

and somewhere in the code

#if BYTE_ORDER == BIG_ENDIAN && defined(LITTLE_ENDIAN_BOARD)
#error Board is little endian and the toolchain is big endian
#endif

so you don't finish the compilation, try to boot the kernel, to finally
die on wrong format error.

> IIRC, that was a NOR Flash driver.  It looked to me like either the
> license was inappropriate for NetBSD, or an appropriate license had
> been misapplied to some vendor/GPL source code by an honest mistake,
> so I left it out.
>
ok, is there any doc on the NAND controller of the adm5120 to access the
NAND.