Problems loading netbsd-current on TS7250

Hello,

I have built the TS7200 kernels but am having problems netbooting them on 
my TS7250, on which I have successfully run NetBSD 3.0 before.

I have been trying to boot the netbsd-epe0 kernel and netbsd-epe0.bin raw 
image, to no avail. Directly from tip(1):

Loading the raw image, everything looks correct:

--8<--
RedBoot> load -r -b 0x200000 -h 192.168.1.6 netbsd-epe0.bin
Using default protocol (TFTP)
Raw file loaded 0x00200000-0x004f8143, assumed entry at 0x00200000
RedBoot> exec 0x200000
Using base address 0x00200000 and length 0x002f8144
--8<--
<hangs here with no further output>

Loading the ELF image never got far:

--8<--
RedBoot> load netbsd-epe0
Using default protocol (TFTP)
Can't load ELF file - program headers out of order
RedBoot>
--8<--

As a random attempt to try something else, I tried loading the raw image 
to 0xc0200000 instead since this is the actual virtual address of the 

Re: Problems loading netbsd-current on TS7250

*Sigh* replying to my own post.. anyway, never mind -- I already figured 
out I should be using the RedBoot "go" command instead of the "exec" 
command.

/ali

panic trying to add missing SDRAM to tsarm kernel.

As mentioned in my previous post, I am trying to make my TS7250 board 
utilise all its 64MB SDRAM. The current NetBSD code has a physical memory 
size of 32MB hardcoded in.

I've successfully booted NetBSD 4.99.16 (TS7200) on it and now I am trying 
to change its opinion on the amount of available SDRAM.

The first 32MB show up at PA 0x0, 0x16MB, 0x64MB and 0x80MB. The banks I 
am trying to add are located on the EP9302 nSDCE2 starting at PA 
0xE0000000, with the same bank layout.

I made the following changes:

- Added additional banks to the bootconfig.dram[] array at 
<sys/arch/evbarm/tsarm/tsarm_machdep.c:454>, changing dramblocks to 8 and 
adding the additional ranges.

- Updated the size of the tsarm_dma_ranges[] array from 4 to 8 at 
<sys/arch/evbarm/tsarm/tsarm_machdep.c:181>.

- Added uvm_page_physload() calls for the additional banks at 
<sys/arch/evbarm/tsarm/tsarm_machdep.c:777>, and updated physmem 
accordingly.

This looked like it should be pretty much it; it's just some more RAM, 
after all. Rebuild kernel and reboot. It looks promising, the kernel 
boots, finding 64MB:

  :
  :

common irq handler code

Hi,

I was looking into fixing acorn32 to actually build, and found that its
IRQ handler is dated by NetBSD/arm standards (it's still in asm, it
lacks IPL_ levels etc)  I was about to update it but realised that I'd
just be making yet another copy of the same code with a couple of tweaks.

So instead I've taken the footbridge irqhandler code, and made it a
common file. (The footbridge version was based on Jason's work for
xscale platforms)

To use it, you provide two functions (via machine/intr_hardware.h):
arm_hardware_set_irq_mask - sets the interrupt mask in the hardware
arm_hardware_irq_status - retrieves the current hardware interrupts.

These should be pretty simple functions for most arm hardware, on
footbridge it totals about 10 lines of code.  Iomd is probably a bit
more to allow for different iomds with 16 and 32bit registers.

With this the platform intr_init, intr_claim and intr_disestablish code
will then wrapper arm_intr_init, arm_intr_claim and
arm_intr_disestablish, with any appropriate tweaks.

The common code is in arm/arm32/arm_irqhandler.c and arm/include/arm_intr.h

Limitations:
* Only works if you use 32 or less interrupts
* Need to update platforms to use it (I can do iomd and footbridge, but
lack hardware for everything else)
* soft interrupts are handled by a separate uint32, rather than using

Sony Clie PEG-NX70V

Re: common irq handler code

Chris Gilbert says;

[ ... proposal to add "common irq code path" ... ]

> So instead I've taken the footbridge irqhandler code, and made it a
> common file. (The footbridge version was based on Jason's work for
> xscale platforms)

I agree with that providing "the common" is an better idea, but it should
be emphasised that it has limitations which might be inadequate for some
cases.

There are two different kinds of "common code"; one to ease future
growth and another to spoil the growth.  As Chris points there is the
number of IRQ designs in ARM implementation.  Having separate intr*.c
code is the way to ease the new HW adaptation; just to copy the most
similar intr*.c as a template and hack the copy at well until it works.  Then,
the "common" should be regarded "not-generic-but-useful-for-simple-case"
code, not to impose the adaptation for the possible new (increasingly
getting complicated) ARM HW.

Toru Nishimura/ALKYL Technology

Re: panic trying to add missing SDRAM to tsarm kernel.

In message: <Pine.GSO.4.60.0704091602120.4637 <at> igloo.df.lth.se>
            Anders Lindgren <ali <at> df.lth.se> writes:
: This is insane; I now reliably get the same Mutex error booting an 
: *unmodified* kernel. The unmodified kernel worked before I started playing 
: with the startup code, but now I consistently get a "locking against 
: myself" panic, despite having reverted all my changes and rebuilt the 
: kernel from scratch.

I'm unsure what you are doing at the lowest level, but I've seen weird
behavior like this before.  Have you tried resetting the board by
turning it off for at least a minute?  I've had bad kernels cause
corruption in memory that somehow keeps things bad until a power
cycle.

I've more typically seen this in boot blocks where the SRAM in the
part I was working on persisted after reset.

It is a long shot...

Warner

Re: panic trying to add missing SDRAM to tsarm kernel.

Some more tidbits of information.

This is insane; I now reliably get the same Mutex error booting an 
*unmodified* kernel. The unmodified kernel worked before I started playing 
with the startup code, but now I consistently get a "locking against 
myself" panic, despite having reverted all my changes and rebuilt the 
kernel from scratch.

Before reverting my changes, I had some weird results; In an attempt to 
verify that the SDRAM behaves as expected, I tried to add a second mapping 
for the first nSDCE2 bank in tsarm_start.S; VA 0xc0800000..c0ffffff => PA 
0xe0000000..0xe07fffff, by entering it into the bootstrap page table just 
after the lowest 8MB gets mapped.

I then did some printfs right after consinit() in initarm to verify I 
could read and write to the memory, which succeeded. To make sure I wasn't 
just seeing D$ data, I moved my test to right after set_cpufuncs and did a 
cpu_dcache_wbinv_range on the address after the write, to make sure it was 
cleaned out, and after that I get 0xe59fe59f back instead of the pattern I 
wrote (one unsigned long).

Anyone else tried -current on TS72xx boards?

Fumbling pretty much in blind here, so any help is appreciated.

Best regards,
ali:)

On Sat, 7 Apr 2007, Anders Lindgren wrote:

> As mentioned in my previous post, I am trying to make my TS7250 board utilise 
> all its 64MB SDRAM. The current NetBSD code has a physical memory size of 
> 32MB hardcoded in.
>
> I've successfully booted NetBSD 4.99.16 (TS7200) on it and now I am trying to 
> change its opinion on the amount of available SDRAM.
>
> The first 32MB show up at PA 0x0, 0x16MB, 0x64MB and 0x80MB. The banks I am 
> trying to add are located on the EP9302 nSDCE2 starting at PA 0xE0000000, 
> with the same bank layout.
>
> I made the following changes:
>
> - Added additional banks to the bootconfig.dram[] array at 
> <sys/arch/evbarm/tsarm/tsarm_machdep.c:454>, changing dramblocks to 8 and 
> adding the additional ranges.
>
> - Updated the size of the tsarm_dma_ranges[] array from 4 to 8 at 
> <sys/arch/evbarm/tsarm/tsarm_machdep.c:181>.
>
> - Added uvm_page_physload() calls for the additional banks at 
> <sys/arch/evbarm/tsarm/tsarm_machdep.c:777>, and updated physmem accordingly.
>
> This looked like it should be pretty much it; it's just some more RAM, after 
> all. Rebuild kernel and reboot. It looks promising, the kernel boots, finding 
> 64MB:
>
> :
> :
> total memory = 65536 KB
> avail memory = 60156 KB
> :
> :
>
> ..but shortly after mounting the NFS root filesystem, I get a "locking 
> against myself" kernel panic from a pipe_read syscall. Obviously I'm missing 
> something, since the default kernel works fine, but this is my first venture 
> into NetBSD kernel programming so I am pretty much fumbling in the dark here. 
> Any ideas?
>
> This is the backtrace I get from ddb:
>
> ----8<----8<----
> root on 192.168.1.6:/export/tsarm
> Sat Apr  7 15:52:51 CEST 2007
> Mutex error: mutex_vector_enter: locking against myself
>
> lock address : 0x00000000c051ee0c
> current cpu  :                  0
> current lwp  : 0x00000000c2511c80
> owner field  : 0x0000000000010c00 wait/spin:                0/1
>
> panic: lock error
> Stopped in pid 13.1 (sh) at     netbsd:cpu_Debugger+0x4:        mov r15, r14
>
> db> bt
> netbsd:panic+0x14
>        scp=0xc03674c0 rlv=0xc0362134 (netbsd:lockdebug_abort+0x5c)
>        rsp=0xc2d87d5c rfp=0xc2d87d7c
> netbsd:lockdebug_abort+0x10
>        scp=0xc03620e8 rlv=0xc0346960 (netbsd:mutex_abort+0x3c)
>        rsp=0xc2d87d80 rfp=0xc2d87d90
>        r5=0xc051ee0c r4=0xffffffff
> netbsd:mutex_abort+0x10
>        scp=0xc0346934 rlv=0xc0346ad8 (netbsd:mutex_vector_enter+0x110)
>        rsp=0xc2d87d94 rfp=0xc2d87db4
> netbsd:mutex_vector_enter+0x10
>        scp=0xc03469d8 rlv=0xc035a3a8 (netbsd:turnstile_lookup+0x28)
>        rsp=0xc2d87db8 rfp=0xc2d87dcc
>        r8=0xc2511c80 r7=0xc2da2f00
>        r6=0xc2da2f08 r5=0xc2da2f00 r4=0xc051f840
> netbsd:turnstile_lookup+0x10
>        scp=0xc035a390 rlv=0xc0346c2c (netbsd:mutex_vector_exit+0x8c)
>        rsp=0xc2d87dd0 rfp=0xc2d87de4
>        r5=0x00000000 r4=0xc2da2f00
> netbsd:mutex_vector_exit+0x10
>        scp=0xc0346bb0 rlv=0xc0337950 (netbsd:cv_wait_sig+0xa0)
>        rsp=0xc2d87de8 rfp=0xc2d87e14
>        r5=0x00000000 r4=0xc051e8f0
> netbsd:cv_wait_sig+0x10
>        scp=0xc03378c0 rlv=0xc036e780 (netbsd:pipe_read+0x348)
>        rsp=0xc2d87e18 rfp=0xc2d87e48
>        r8=0xc2d87e54 r7=0xc2da2f18
>        r6=0xc2da2f00 r5=0xc2da2f08 r4=0xc2519f00
> netbsd:pipe_read+0x10
>        scp=0xc036e448 rlv=0xc036b678 (netbsd:dofileread+0xb0)
>        rsp=0xc2d87e4c rfp=0xc2d87eac
>        r10=0xc2511c80 r9=0x00000003
>        r8=0x00000000 r7=0x00000080 r6=0xc251089c r5=0xbfffeaa8
>        r4=0xc2519f00
> netbsd:dofileread+0x10
>        scp=0xc036b5d8 rlv=0xc036b7dc (netbsd:sys_read+0x84)
>        rsp=0xc2d87eb0 rfp=0xc2d87edc
>        r10=0x0002fd28 r9=0x00000004
>        r8=0xc2511c80 r7=0xc2d87f30 r6=0xc2511c80 r5=0x00000003
>        r4=0xc2d87fb8
> netbsd:sys_read+0x10
>        scp=0xc036b768 rlv=0xc03ba244 (netbsd:syscall_plain+0x118)
>        rsp=0xc2d87ee0 rfp=0xc2d87f60
>        r7=0xc0463b38 r6=0xc2d87fb4
>        r5=0x00000003 r4=0xefa00003
> netbsd:syscall_plain+0x10
>        scp=0xc03ba13c rlv=0xc03ba710 (netbsd:swi_handler+0xa4)
>        rsp=0xc2d87f64 rfp=0xc2d87fb0
>        r10=0x0002fd28 r9=0x0002fdfe
>        r8=0x00000000 r7=0xc251089c r6=0xefa00003 r5=0xc2d87fb4
>        r4=0xc2511c80
> netbsd:swi_handler+0x10
>        scp=0xc03ba67c rlv=0xc03bd744 (netbsd:swi_entry+0x64)
>        rsp=0xc2d87fb4 rfp=0xbfffeb70
>        r7=0x0002fe20 r6=0x00000000
>        r5=0xffffffff r4=0x0002f76c
> ----8<----8<----
>
> Best regards,
> ali:)
>

4.99.16 panics on TS7250 (was: Re: panic trying to add missing SDRAM to tsarm kernel.)

On Mon, 9 Apr 2007, M. Warner Losh wrote:

> In message: <Pine.GSO.4.60.0704091602120.4637 <at> igloo.df.lth.se>
>            Anders Lindgren <ali <at> df.lth.se> writes:
> : This is insane; I now reliably get the same Mutex error booting an
> : *unmodified* kernel. The unmodified kernel worked before I started playing
> : with the startup code, but now I consistently get a "locking against
> : myself" panic, despite having reverted all my changes and rebuilt the
> : kernel from scratch.
>
> I'm unsure what you are doing at the lowest level, but I've seen weird

In this case I was only adding some more entries to the L1 page table set 
up in the startup-code, by copying & modifying the existing code that sets 
up the section mappings for the first 8MB of SDRAM.

> behavior like this before.  Have you tried resetting the board by
> turning it off for at least a minute?  I've had bad kernels cause
> corruption in memory that somehow keeps things bad until a power
> cycle.
>
> I've more typically seen this in boot blocks where the SRAM in the
> part I was working on persisted after reset.
>
> It is a long shot...

Yep, tried that too just for the heck of it. As expected, it didn't make a 
difference.

Hrrm.. I just tried changing rc.conf back to its original state -- and 
voilà: If I say rc_configured=NO, I successfully drop into single user and 
can type "/bin/ksh" for shell and poke around, running vi, setting date 
via ntpdate etc.

When I reboot with rc_configured changed to YES, I get the lock error 
again... presumably I just missed that the first time and started poking 
around the startup code immediately after the first successful boot 
(although I could swear I tried rebooting too  )...

This all suggests that 4.99.16 is simply broken -- at least on TS7250.
The kernel I am booting (via RedBoot TFTP) is the netbsd-epe0.bin one.

Best regards,
/ali:)

Re: common irq handler code

On Monday 09 April 2007 08:01, Toru Nishimura wrote:
> Chris Gilbert says;
>
> [ ... proposal to add "common irq code path" ... ]
>
> > So instead I've taken the footbridge irqhandler code, and made it a
> > common file. (The footbridge version was based on Jason's work for
> > xscale platforms)
>
> I agree with that providing "the common" is an better idea, but it
> should be emphasised that it has limitations which might be inadequate
> for some cases.

I'll echo that. While the common code may be useful during early bring-up 
of a new port, there is no substitute for an implementation targetted 
directly at the flavour of interrupt controller. This code is critical 
to good performance. In particular, the spl(9) implementation must be as 
small as possible. I have a few comments...

1. Consider the proposed arm_intr_splx() implementation. Right at the 
start there are a whole bunch of 'extern foo' declarations. Each one of 
those variables will generate, on ARM, a PC-relative load just to find 
the address of the variable. This is all inlined code, so even small 
functions like this contrived example:

{
 extern volatile int x;
 int s = splbio();
 x = 0;
 splx(s);
}

when compiled will be very much larger than you'd expect. Consider moving 
some state into cpu_info.

2. As you noted, the 'mask' approach whereby pending interrupts are 
recorded in a mask which mirrors the hardware's mask registers does not 
scale well with more than 32 individual interrupt sources. It also 
becomes extremely unwieldy in splx(9) where you'd have to logically AND 
multiple 32-bit values to determine if an interrupt is pending. Instead, 
on CPUs with an ffs(2)-like instruction ("clz" for example) you can use 
a single 32-bit variable to record pending interrupts per IPL_*. Then 
splx(9) can simply use "clz" to determine if it needs to invoke the 
'dispatch pending' heavy lifter. You also greatly reduce the number of 
external variable references in splx(9).

Using the above two suggestions in tandem, the spl(9) implementation will 
be much smaller, the code will scale to multiple hardware masks much 
more easily, and you may find some more opportunities to factor out 
common/shared code.

Cheers, Steve