Re: [9fans] Plan9 on QNAP TS-212 NAS (kw)

Re: [9fans] Plan9 on QNAP TS-212 NAS (kw)

[erik quanstrom]

as a wag, i would start by tweaking ether1116.c (sic) to leave the
second port alone.  remember that one disadvantage of
socs is that there isn't a lot of discoverability.  you just
need to know what hardware you're running on.  and
touching stuff that's not there is often fatal.  so, for
instance, you may need to tweak the memory setup if
you don't have exactly the same configuration of memory
as the openrd.

- erik

Re: [9fans] Plan9 on QNAP TS-212 NAS (kw)

[Jared Jennings]

On 7/9/11, erik quanstrom <quanstro@quanstro.net> wrote:
> as a wag, i would start by tweaking ether1116.c (sic) to leave the
> second port alone.

Wagged. It appears from the code in devether.c that the MaxEther enum
in devether.h is what controls how many ethernet cards are frobbed. I
changed MaxEther from 2 to 1. It said the same thing except without
the #l1 line.

Because I saw the "#u/u" right before the message, I tried turning off
the USB entirely by commenting it out in the plug file. The "#u/u" at
the beginning of the line went away, but the "spurious irqbridge
interrupt: 00000010" messages continue.

Still investigating.

Re: [9fans] Plan9 on QNAP TS-212 NAS (kw)

[erik quanstrom]

> Because I saw the "#u/u" right before the message, I tried turning off
> the USB entirely by commenting it out in the plug file. The "#u/u" at
> the beginning of the line went away, but the "spurious irqbridge
> interrupt: 00000010" messages continue.

that's an invalid access error.  unfortunately there's
not too much information on what the invalid
access was.  i think you'll just have to do a binary
search with prints.

- erik

Re: [9fans] Plan9 on QNAP TS-212 NAS (kw)

[Jared Jennings]

I figured out I can't iprint my way out of the problem, because iprint
doesn't work until after trapinit is over.

I added a special case to intrs so that if ibits is 0x00000010 and the
sort is Irqbridge, we just turn off that bit in the irq mask, and
uncommented several debuggy iprints.

I found the sheevamem structure and changed its 512*MB to 256*MB
because my TS-212 only has 256 MB of RAM, according to the u-boot
startup message. (I think TS-219s have 512 MB.)

Now my message looks like so:


Marvell>> go 0x800000
## Starting application at 0x00800000 ...

Plan 9 from Bell Labs

l1 D: 16384 bytes, 4 ways 128 sets 32 bytes/line; write-through only
l1 I: 16384 bytes, 4 ways 128 sets 32 bytes/line; write-back type `reg
7 ops, format C' (016) possible
l2 cache: 256K or 512K: 4 ways, 32-byte lines, write-back, sdram only
cpu0: 1200MHz ARM Marvell 88F6281 A1; arm926ej-s arch v5te rev 2.1 part 131
enabling intr 0 vec 11 for ether0
#l0: 88e1116: 100Mbps port 0xf1072000 irq 11: 00089bc1d539
enabling intr 1 vec 1 for eia0
duplicate irq: eia0 (0x60859aac)
248intrs: quashing bridge irq 00000010
enabling intr 0 vec 29 for twsi
M memory: 27M kernel data, 221M user, 961M swap


(The "intrs:" message is mine.)

Then it just hangs there. It does not automatically reboot after 10
seconds. Has the kernel finished starting up? Do I now need to figure
out the next step in the boot process?

On 7/9/11, Jared Jennings <jjenning@gmail.com> wrote:
> On 7/9/11, erik quanstrom <quanstro@quanstro.net> wrote:
>> as a wag, i would start by tweaking ether1116.c (sic) to leave the
>> second port alone.
>
> Wagged. It appears from the code in devether.c that the MaxEther enum
> in devether.h is what controls how many ethernet cards are frobbed. I
> changed MaxEther from 2 to 1. It said the same thing except without
> the #l1 line.
>
> Because I saw the "#u/u" right before the message, I tried turning off
> the USB entirely by commenting it out in the plug file. The "#u/u" at
> the beginning of the line went away, but the "spurious irqbridge
> interrupt: 00000010" messages continue.
>
> Still investigating.
>

Re: [9fans] Plan9 on QNAP TS-212 NAS (kw)

[erik quanstrom]

> I figured out I can't iprint my way out of the problem, because iprint
> doesn't work until after trapinit is over.

you can wave() your way out.

> I added a special case to intrs so that if ibits is 0x00000010 and the
> sort is Irqbridge, we just turn off that bit in the irq mask, and
> uncommented several debuggy iprints.
>
> I found the sheevamem structure and changed its 512*MB to 256*MB
> because my TS-212 only has 256 MB of RAM, according to the u-boot
> startup message. (I think TS-219s have 512 MB.)

there are assumptions about the memory size in many devices,
including the ethernet.  make sure that you reprogram all the
windows that are active.  maybe that's not it, but it's the most
obvious change.  it could be that the new hw just tickles an
old problem.  those are the worst bugs to hunt.

- erik

Re: [9fans] Plan9 on QNAP TS-212 NAS (kw)

[Jared Jennings]

Oops, when it was "hanging there" it was sending out DHCP queries. So
it appears I'm on my way.

But what is this interrupt? Should I be catching it? How can I make a
change that is an improvement instead of a hack?

Re: [9fans] Plan9 on QNAP TS-212 NAS (kw)

[erik quanstrom]

> But what is this interrupt? Should I be catching it? How can I make a
> change that is an improvement instead of a hack?
>

it's an access violation.  check the docs.

- erik

Re: [9fans] Plan9 on QNAP TS-212 NAS (kw)

[Ethan Grammatikidis]

On Sat, 9 Jul 2011 18:40:49 -0400
erik quanstrom <quanstro@quanstro.net> wrote:

> there are assumptions about the memory size in many devices,

Ouch. Couldn't the kernel probe the memory size at boot time and use that? Or at least have it set in a constant for a single point of change?

Re: [9fans] Plan9 on QNAP TS-212 NAS (kw)

[erik quanstrom]

On Tue Jul 12 06:57:22 EDT 2011, eekee57@fastmail.fm wrote:
> On Sat, 9 Jul 2011 18:40:49 -0400 erik quanstrom
> <quanstro@quanstro.net> wrote:
>
> > there are assumptions about the memory size in many devices,
> >
> Ouch.  Couldn't the kernel probe the memory size at boot time and use
> that?  Or at least have it set in a constant for a single point of
> change?

sadly no.  often, probling is not possible.  and assumptions about
memory sizes and layouts are typically not possible.

while you can view this as an advantage, i think this tilts toward
disavantage in little systems that have a ddr2/3 slot.  you can't
probe it, and you can't boot unless you have exactly the correct
memory module.

- erik

Re: [9fans] Plan9 on QNAP TS-212 NAS (kw)

[Ethan Grammatikidis]

On Tue, 12 Jul 2011 11:32:03 -0400
erik quanstrom <quanstro@labs.coraid.com> wrote:

> On Tue Jul 12 06:57:22 EDT 2011, eekee57@fastmail.fm wrote:
> > On Sat, 9 Jul 2011 18:40:49 -0400 erik quanstrom
> > <quanstro@quanstro.net> wrote:
> >
> > > there are assumptions about the memory size in many devices,
> > >
> > Ouch.  Couldn't the kernel probe the memory size at boot time and use
> > that?  Or at least have it set in a constant for a single point of
> > change?
>
> sadly no.  often, probling is not possible.  and assumptions about
> memory sizes and layouts are typically not possible.
>
> while you can view this as an advantage, i think this tilts toward
> disavantage in little systems that have a ddr2/3 slot.  you can't
> probe it, and you can't boot unless you have exactly the correct
> memory module.

Ouch. :( At least with the 640K split you knew where the split was.

Re: [9fans] Plan9 on QNAP TS-212 NAS (kw)

[ron minnich]

well, to elaborate on this.

Long ago, you probed by just reading memory until you read back
nothing but ffffffffffffffffff. That was a memory hole. Then somebody
at one chipset vendor got clever and broke this test. Oops, you have
to figure out if maybe your test is failing because somebody got
clever.

You can in fact figure out memory size on many systems by reading
registers in configuration space. On K8/K10/whatever, you can write
code to probe the famous "1f" configuration space and read out memory
bank info. Core 0 can read it for ALL cpus. I've written this and then
lost it :-) but it's pretty easy.

Of course, many vendors view such info as "crown jewels" so this is
hardly a universal solution.

You can, if you want to get really weird, use the I2C bus to probe all
installed DDR and figure it out. Silly that the OS has to do this when
the BIOS does it but hey ... it's a PC ... of course it's gross.
Reference code for MANY chipsets is available in coreboot.

But I agree with Erik: frequently memory slots are more of a headache
than a bonus.

ron

Re: [9fans] Plan9 on QNAP TS-212 NAS (kw)

[erik quanstrom]

> Long ago, you probed by just reading memory until you read back
> nothing but ffffffffffffffffff. That was a memory hole. Then somebody
> at one chipset vendor got clever and broke this test. Oops, you have
> to figure out if maybe your test is failing because somebody got
> clever.

yes, this worked great on x86 until memory got large enough that it
might run right up to something you shouldn't hammer like pci space.
now this probing.

unfortunately socs like the kw require the kernel to program windows
that include chip select bits, and touching memory that's not there is
a fatal bus exception.

- erik

[9fans] Plan9 on QNAP TS-212 NAS (kw)

[Jared Jennings]

Hello everyone, I got a QNAP TS-212 filer, because it purports to have
the same processor as the SheevaPlug, but has space in its case for
two SATA hard drives, and a separate power supply, and a cooling fan,
thus neatly avoiding all the problems I foresaw in using a SheevaPlug
as a file server.

Anyway, upon booting 9plug according to the instructions in
booting(8), I got this sort of thing:

Marvell>> tftp 0x1000 kw-example
[...]
Marvell>> tftp 0x800000 9plug
[...]
Marvell>> go 0x800000
## Starting application at 0x00800000 ...

Plan 9 from Bell Labs

l1 D: 16384 bytes, 4 ways 128 sets 32 bytes/line; write-through only
l1 I: 16384 bytes, 4 ways 128 sets 32 bytes/line; write-back type `reg
7 ops, format C' (016) possible
l2 cache: 256K or 512K: 4 ways, 32-byte lines, write-back, sdram only
cpu0: 1200MHz ARM Marvell 88F6281 A1; arm926ej-s arch v5te rev 2.1 part 131
#l0: 88e1116: 100Mbps port 0xf1072000 irq 11: [mac address]
#l1: ether1116: init mii failure
#u/uspurious irqbridge interrupt: 00000010
spurious irqbridge interrupt: 00000010
spurious irqbridge interrupt: 00000010
spurious irqbridge interrupt: 00000010
spurious irqbridge interrupt: 00000010
[repeats for about 15 seconds at more than 100 messages per second,
then the system reboots]

Judging from the place where that message is printed, in
/sys/src/9/kw/trap.c (search for irq%s), the 'bridge' sort of
interrupt is flagged in the CPU status register; the documentation
from Marvell shows what each bit in the low and high interrupt
registers means, but that's not the sort of interrupt I'm getting
spuriously here.

I don't think it's far from working, but I don't know how to advance
from here. Any ideas?