OS_Memory 13 on Raspberry Pi

Does OS_Memory 13 work correctly on the Raspberry Pi?

I mapped 512 bytes starting at &7E200000. The first few words should be the addresses of the GPIO function select registers. But the values I’m reading from them have bit 30 set, which couldn’t possibly be true; and the values as a whole look like nonsense. They more resemble ASCII values.

The code is:

REM Map the GPIO function select stuff in
map_code% = 13 + (1 << 17)
SYS "OS_Memory", map_code%, &7E200000, 512 TO r0%, r1%, r2%, gpiofsel%
PRINT "R0 = " + STR$~r0%
PRINT "R1 = " + STR$~r1%
PRINT "R2 = " + STR$~r2%
PRINT "GPIOFSEL0 = " + STR$~gpiofsel%
FOR ofs% = 0 TO 20 STEP 4
 fsel0% = gpiofsel%!ofs%
 PRINT "Content = " + STR$~fsel0%
 IF fsel0% AND &C0000000 THEN PRINT "Illegal top bits!"
 gpio_fn0% = fsel0% AND &7
 gpio_fn1% = (fsel0% >> 3) AND 7
 PRINT "GPIO0 function = " + FNgpio_fn(gpio_fn0%)
 PRINT "GPIO1 function = " + FNgpio_fn(gpio_fn1%)
 PRINT ""
NEXT ofs%
END

DEF FNgpio_fn(fn%)
LOCAL o$
fn% = fn% AND 7
o$ = "(" + STR$fn% + ") "
CASE fn% OF
 WHEN 0: o$ += "GPIO in"
 WHEN 1: o$ += "GPIO out"
 WHEN 2: o$ += "Alt f5"
 WHEN 3: o$ += "Alt f4"
 WHEN 4: o$ += "Alt f0"
 WHEN 5: o$ += "Alt f1"
 WHEN 6: o$ += "Alt f2"
 WHEN 7: o$ += "Alt f3"
ENDCASE
= o$

(I know only GPIO0 and GPIO1 are correctly numbered; I added the loop as a quick hack to see if the next few registers looked as wrong. They do.)

I don’t know OS_Module 13, but I know OS_Module 6 isn’t implemented because it gets passed through to HAL_PhysInfo which isn’t implemented. The memory size stuff doesn’t work at the moment because we’re waiting for the VCHIQ interface code to be supported by the GPU, then we can read out memory size etc in a clean way rather than being hard coded. I wouldn’t be surprised if reason code 13 is falling down for similar reasons. Think its kernel.s.MemInfo2 and HAL.s.Top that has the code

OS_Memory 13 is working fine on the Pi. What you’re having trouble with is that instead of there being two address spaces (logical and physical), the Pi actually has three address spaces – the ARM logical address, the ARM physical address, and the bus physical address. This is because all RAM and I/O accesses go through both the ARM’s MMU and the VideoCore’s MMU before it actually hits the target device.

The BCM2835 TRM usually lists bus addresses for everything rather than ARM physical addresses. If you look at the diagram on page 5, you’ll see that the I/O block at bus address &7exxxxxx is mapped to ARM physical address &20xxxxxx. So you’ll have to pass an address of &20200000 to OS_Memory 13 if you want to access the GPIO registers.

Much more sensible results now. Thanks, Jeffrey.

Yes, it took me a while to find this out while changing the GPIO module.
Finally found this by looking in the HAL source for the Pi….

If you’re working in the HAL (to match the GPIO support for the beagleboard) then you don’t need to map it in again, as the HAL initialisation code hap mapped it in already. The variable PeriBase contains the logical address at which ARM physical address &20000000 and the following 16 MB have been mapped in (although obviously this is only available within the HAL). As an aside, you will notice from the HAL sources that the the VideoCore MMU mapping has changed at least once in the past.

Don’t forget to insert data memory barriers at the top and bottom of each of your entries, and (if applicable, though probably not in your case) within your code wherever you switch peripherals, as described at the top of Broadcom’s datasheet.

Ben, the only interaction with the HAL is to obtain the GPIO machine info added by Jeffrey from OS_Hardware 4. I then determine which table of data is used to access various registers and GPIO pins to enact control, so I need to map in the memory for myself. (At present the Pi is not in the list, so my module uses the Pi tables as the default).
The PeriBase variable would not be accessible to me.
The GPIO SWI’s do return my logical addresses to the caller though.

I can report that IIC is showing the first signs of life: an attempt to address a non-existent EEPROM chip. Classic IIC waveforms on the storage scope.

Time to add a chip to my header board now!

attempt to address a non-existent EEPROM chip

Heh, that’ll be it thinking it’s running on a Risc PC and probing the I2C bus for an old Phiips combined RTC/CMOS chip. I just fixed that in Hdr:Machine.Machine :-)

Sorry to be boring, but that’s me checking that I get IIC waveforms that I trust before I solder in an EEPROM chip!

… which I have now done, and I can see the next stage of it working. I’m still doing this as an application in BASIC so I can ensure I understand how the BCM2835 has to be driven before I start writing proper code.

Does anyone know how deep the IIC FIFOs are? I can’t see a figure anywhere in the data sheet. I can feel an experiment coming on.

In partial reply to my own question: the Tx FIFO is 16 deep. It’s rather harder to measure the Rx FIFO’s depth, but it’s very likely to be the same as the Tx.

More progress: last night I successfully wrote “Hello, Raspberry Pi!” to a page (not the base page) in an EEPROM, and successfully read it back again.

I found, rather by accident, that the read FIFO is also 16 deep.