[9fans] Small bits of progress on SIMpad, couple of ARM questions

[9fans] Small bits of progress on SIMpad, couple of ARM questions

[Devon H. O'Dell]

[-- Attachment #1: Type: text/plain, Size: 2441 bytes --]

Hey,

I'm hoping there's someone here who knows a bit more about ARM
than I do. I've grabbed the ARM specification and the docs on the
SA-1110 from Intel, and these are a real big help with learning
how the code works.

I've got the decompressor to inflate the kernel, but I'm having
trouble getting it to jump to the kernel afterwards. From what
I can tell is happening:

 o After compiling, the image I send looks like:
   +---------+  
	 | inflate | } 20KB, text of _start at 0xc0200010
	 +---------+  
	 |         | )
	 | kernel  | > ~420KB, text of _start at 0xc0008010
	 |         | )
	 +---------+

 o I generate a boot header and put it in flash, telling the
   loader to load this to 0xc0008000 and enter at 0xc0008010.

 o Since inflate is in front of the kernel, and it has the
   kernel magic, the bootloader sees that at 0xc0008010 and
	 jumps into it.

 o inflate knows it's at the wrong place, so it relocates
   itself to 0xc0200000 and jumps to the relocated address which
	 calls the main() in imain.c

 o this gunzips the kernel from 0xc0200000 + 20*1024 to
   0xc0008000.

 o Kernel's _start is at 0xc0008010 (I'm assuming the extra 16
   bytes are the a.out header for all these things?). This is
	 assigned to ``f''

 o cache is drained, (*f)() is called.

I've placed various debugging prints around, and it turns out
that I _cannot_ get the thing to jump there. Reading the docs on
the processor, there shouldn't be any differences between bitsy
and my SIMpad at this point. When the jump should occur, the
unit powers off after a short delay, and I have verified with
prints that it never actually reaches _start in 
/sys/src/9/bitsy/l.s

So I'm curious what's happening. Perhaps the MMU is turned on
somehow and I'm accessing an illegal offset, which causes a
memory fault to be generated, but since there's no handler, the
unit powers itself down? This is all I can think of at the
moment.

I've been reading the Linux source, and Walter Schweizer from
Siemens has been quite helpful at pointing me to to relevant
sections of Linux (which are surprisingly similar, when I'm able
to identify matching code). Are there any bitsy / ARM gurus who
might be able to give me some tips on what might be going wrong
at this early stage? If I can get past this, it should be 
comparatively trivial to get it running further :)

Kind regards,

Devon H. O'Dell

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]

Re: [9fans] Small bits of progress on SIMpad, couple of ARM questions

[Michael Zappe]

Well, I just did the same thing for OpenBSD on IXP (XScale core), and 
here are some of the issues you may want to look at. 

It seems there's an errata with the XScale core that causes 
self-modifying code (including linkers and loaders) not to work if write 
coalescing is disabled in CP15.  Check to make sure that it is enabled 
in register 0. 

Also, make sure that the cache flush you are calling invalidates the 
I-cache after flushing the D-cache. 

One other thing to try to make sure that it's a cache issue (what it 
sounds like), is to try running it with caches disabled on startup.

If you need any more help, feel free to contact me!

    Mike

Devon H. O'Dell wrote:

>Hey,
>
>I'm hoping there's someone here who knows a bit more about ARM
>than I do. I've grabbed the ARM specification and the docs on the
>SA-1110 from Intel, and these are a real big help with learning
>how the code works.
>
>I've got the decompressor to inflate the kernel, but I'm having
>trouble getting it to jump to the kernel afterwards. From what
>I can tell is happening:
>
> o After compiling, the image I send looks like:
>   +---------+  
>	 | inflate | } 20KB, text of _start at 0xc0200010
>	 +---------+  
>	 |         | )
>	 | kernel  | > ~420KB, text of _start at 0xc0008010
>	 |         | )
>	 +---------+
>
> o I generate a boot header and put it in flash, telling the
>   loader to load this to 0xc0008000 and enter at 0xc0008010.
>
> o Since inflate is in front of the kernel, and it has the
>   kernel magic, the bootloader sees that at 0xc0008010 and
>	 jumps into it.
>
> o inflate knows it's at the wrong place, so it relocates
>   itself to 0xc0200000 and jumps to the relocated address which
>	 calls the main() in imain.c
>
> o this gunzips the kernel from 0xc0200000 + 20*1024 to
>   0xc0008000.
>
> o Kernel's _start is at 0xc0008010 (I'm assuming the extra 16
>   bytes are the a.out header for all these things?). This is
>	 assigned to ``f''
>
> o cache is drained, (*f)() is called.
>
>I've placed various debugging prints around, and it turns out
>that I _cannot_ get the thing to jump there. Reading the docs on
>the processor, there shouldn't be any differences between bitsy
>and my SIMpad at this point. When the jump should occur, the
>unit powers off after a short delay, and I have verified with
>prints that it never actually reaches _start in 
>/sys/src/9/bitsy/l.s
>
>So I'm curious what's happening. Perhaps the MMU is turned on
>somehow and I'm accessing an illegal offset, which causes a
>memory fault to be generated, but since there's no handler, the
>unit powers itself down? This is all I can think of at the
>moment.
>
>I've been reading the Linux source, and Walter Schweizer from
>Siemens has been quite helpful at pointing me to to relevant
>sections of Linux (which are surprisingly similar, when I'm able
>to identify matching code). Are there any bitsy / ARM gurus who
>might be able to give me some tips on what might be going wrong
>at this early stage? If I can get past this, it should be 
>comparatively trivial to get it running further :)
>
>Kind regards,
>
>Devon H. O'Dell
>  
>

Re: [9fans] Small bits of progress on SIMpad, couple of ARM questions

[Devon H. O'Dell]

[-- Attachment #1: Type: text/plain, Size: 1140 bytes --]

On Sun, Apr 10, 2005 at 11:36:03AM -0600, Michael Zappe wrote:
> Well, I just did the same thing for OpenBSD on IXP (XScale core), and 
> here are some of the issues you may want to look at. 
> 
> It seems there's an errata with the XScale core that causes 
> self-modifying code (including linkers and loaders) not to work if write 
> coalescing is disabled in CP15.  Check to make sure that it is enabled 
> in register 0. 
> 
> Also, make sure that the cache flush you are calling invalidates the 
> I-cache after flushing the D-cache. 
> 
> One other thing to try to make sure that it's a cache issue (what it 
> sounds like), is to try running it with caches disabled on startup.
> 
> If you need any more help, feel free to contact me!
> 
>    Mike

Thanks for the offer, certainly will do. I'll open up that ARM
spec and the SA-1110 datasheet again tomorrow and see if I can't
apply some of your tips. Charles and Bruce Ellis also responded
off-list with tips of their own.

I'll see if these tips combined get me any further, otherwise
I'll just accept the offers and bug you guys some more ;).

--Devon

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]