[raspi-internals] Re: [ANN] piface 0.1
- From: Herman Hermitage <hermanhermitage@xxxxxxxxxxx>
- To: "raspi-internals@xxxxxxxxxxxxx" <raspi-internals@xxxxxxxxxxxxx>
- Date: Thu, 13 Jun 2013 19:34:46 +1200
Like the cache? :-)
eg. look at SH4 where the L1 DCache (operand cache as they call it) can be
split so its half direct mapped SRAM and half cache. Ok on the SH4 CCR:ORA
defaults to off on reset so you always see boot code setting it, if it needs
storage in preboot.
Just random thoughts...
For sure a dedicated sram buffer would be useful for a tiny non intrusive
monitor...
Yeah, the Tile Buffer is probably a bad choice. But I'm sure they managed to
find a block of usable ram somewhere and (if necessary) wire it's power domain
to be active during boot.
____________
Scott Mansell
From: phiren@xxxxxxxxx
Date: Mon, 10 Jun 2013 01:30:20 +1200
Subject: [raspi-internals] Re: [ANN] piface 0.1
To: raspi-internals@xxxxxxxxxxxxx
There is also some ram at 0x60008000 which bootrom uses for it's stack and
bootcode.bin uses as a temporary place to copy and run code which touches
various registers that configure the L1 and L2 caches.
I can't remember how big this block of ram is, but the bootrom is probably
abusing a block of sram which has a specialised purpose inside the Videocore,
like the 3d pipeline's Tile Buffer (notice how it has two way access with the
main bus
https://github.com/hermanhermitage/videocoreiv/wiki/VideoCore-IV---BCM2835-Overview#gpu-and-3d-pipeline).
We will eventually see this address again.
About the memory map, it helps to think of the "physical" address bus inside
the BCM2835 as a 30 bit bus (1GB) with the top two bits reserved for
controlling cache access modes. So everything including the rom and the
registers gets mirrored 4 times.
From memory, linux uses the 0x3e000000 - 0x3fffffff mirror for accessing the
registers, which suggests the upper 512 megabytes of each mirror (or just the
registers) are unaffected by the caches.
This is also why there will never be a version of the rpi with more than 512MB
of ram.
____________
Scott Mansell
On Sat, Jun 8, 2013 at 2:02 PM, Herman Hermitage <hermanhermitage@xxxxxxxxxxx>
wrote:
> This is the simple boot monitor which I've mentioned previously. It's
> currently in a pretty basic state, but it'll let you examine memory,
> modify memory, do XMODEM downloads, run things, etc.
>
> https://cowlark.com/piface
Looking good!
> Do we have a memory map yet? I gather the 128kB of SRAM is at 80000000,
> the boot ROM is at 60000000 (how big is this? I've downloaded over two
> megabytes from there without reaching the end of the mapped memory
> region; and apart from the code at the top, it's all zeros, so it
> doesn't look like it's repeating). I know the peripherals are at
> 7e000000. And there's *something* mapped at 0, which I suspect is the
> uninitialised SDRAM.
Nothing concrete, but its pretty reasonable:
https://github.com/hermanhermitage/videocoreiv/tree/master/dumpbootenv
"According to the BCM2835 ARM Peripherals manual, address ranges are:
00000000 - 3fffffff ; L1 and L2 cached
40000000 - 7fffffff ; L2 cache coherent (non allocating)
80000000 - bfffffff ; L2 cached only
c0000000 - ffffffff ; Direct uncached"
I think the responders are:
0x00000000 - 0x1FFFFFFF, SDRAM
0x20000000 - 0x20007FFF, Boot (OTP or) ROM.
0x7E000000 - 0x7EFFFFFF, IO
There might be more at:
https://github.com/hermanhermitage/videocoreiv/tree/master/dumpbootrom
And at:
https://github.com/hermanhermitage/videocoreiv/wiki
I think the full range of IO is only active when all power domains are enabled
(figure 2 at
https://github.com/hermanhermitage/videocoreiv/wiki/VideoCore-IV---BCM2835-Overview).
>
> Also, a rather embarrassed request for assistance: I don't have XMODEM
> upload support yet, because I can't figure out how XMODEM upload is
> supposed to work. The protocol is driven by the receiver. When doing a
> download, it's fine, because I tell the Pi to start sending, at which
> point it listens for a receiver; I then tell my terminal emulator to
> start receiving, and it all works. But to do an upload, I tell my
> emulator to start sending... and then I can't tell the Pi to start
> receiving because the terminal emulator is busy trying to send. Um, help?
It's been too long for me to recall accurately, but isnt xmodem bidirectional?
Either side can start a packet with SOH to transfer a CP/M block?
dwelch67 has an example bootloader/xmodem receiver for videocore at:
https://github.com/dwelch67/rpigpu/blob/master/vbcc/bootloader01.c
So on the pi side you poll or have an interrupt to detect incoming characters,
when its SOH its time to receive a packet.
Other related posts:
