On 13 Aug 1999, Dave Daniels wrote:

> In the absence of anybody else saying anything, I have been
> looking at the NetBSD boot problem to see what has to be done to
> fix it. However my experience of programming at this low a level
> is zero and I do not fully understand what is going on nor do I
> have all the information needed. In particular BtRiscBSD uses a
> number of constants in the code that no longer works without
> explaining what they are for. Could anybody shed any light on
> them?
I'll try ...

> The ones that I am interested in are:
> In the code that plugs addresses directly into the page tables
> is the statement:
>  
>         WriteWord(0x02c00000 + (logical >> 10) & 0xfffffffc,
>           0x00000ffe | (physical & 0xfffff000));
>    
> What does the constant 0x00000ffe signify? I am wondering if this
> code can be replaced by calls to OS_Memory to find the physical
> page numbers that correspond the the addresses being inserted (the
> variable 'physical' in the above statement) and then the page
> tables updated with a call to OS_SetMemMapEntries. Does anyone
> have any comments?
Ok this is filling in an entry in a L2 page table. ARM data sheets
describe the layout of the page tables.
the 0xffe means  SVC mode read/write & USER mode read/write access
permissions on all sub pages in the mapping, bufferable, cacheable and it
maps a 4K page.

sys/arch/arm32/include/pte.h has definitions for all the page tables bits
if you want another reference.

> In a similar vein, a couple of lines later there is the comment
> 'Map the IO up high so we can get at it' followed by the lines:
>   
>     WriteWord(0x02c0c000 + (0xf6000000 >> 18) & 0xfffffffc,
>       0x00000412 | (0x03200000 & 0xfffff000));
>     WriteWord(0x02c0c000 + (0xf6100000 >> 18) & 0xfffffffc,
>       0x00000412 | (0x03400000 & 0xfffff000));
>  
> Again this is updating the page table, but could anyone explain
> all the magic numbers used here? What is the significance of
> shifting what I assume is the logical address the I/O will be
> mapped to (0xf6000000) by 18? I guess that this maps the address
> on to a megabyte boundary instead of a 4K byte page one. The
> base address of the area being overwritten (0x2c0c000) is different
> too. What is this? What does the flag value 0x00000412 mean?
Ok there are ading entries in the L1 page table.

The 0x412 is SVC mode read/write and a L1 section mapping (maps 1MB)
This maps the physical memory for VIDC and IOMD to 0xf600000 & 0xf6100000

> I doubt if 'OS_SetMemMapEntries' can be used here.

What is really needed is a way on directly manipulating the page tables.
When I originally did the code the only way way was to directly access
them.

> I guess that the lack of 'me too!' messages on here could signify
> either that nobody uses NetBSD/arm32 on a RiscPC any more or that
> I am on the bleeding edge and am the only person who has tried
> NetBSD with RISCOS 4. Which is it?
Given that apparently only a few RO4 have been distributed and I believe
there is a shipping delay on others I guess very few people have RO4.
Personally I don't need RO4 for my RiscPC as it will not give me any
benefits so I will not upgrading (I may have considered it if it was a
reasonable price). The down side for users is that it means
I will not be able to fix the bootloader for RO4 myself.

CHeers,
				Mark