Raspberry pi-3 bcm2837 soc documents

[PramodK]

Hi,

I am working on raspberry pi-3.

I am looking for BCM2837 SOC hardware documentation for address map of peripherals.

I could not find it in below link:
https://www.raspberrypi.org/documentati ... spberrypi/

Also, I couldn't find after googling as well.

Kindly let me know if someone already has it.

-pK

[rpdom]

I am looking for BCM2837 SOC hardware documentation for address map of peripherals.

Use the BCM2836 peripherals documentation. The addresses are the same for the two chips.

For the actual details, the BCM2835 peripherals document has all the details, it is just the base address has been changed to allow addressing 1GB of RAM.

[PramodK]

What about the SD host controller added in bcm2837 for WiFi? I don't think SD host controller is present in 2836 or 2835 right.

[rpdom]

What about the SD host controller added in bcm2837 for WiFi? I don't think SD host controller is present in 2836 or 2835 right.

Both SD host controllers are present in all versions of the BCM283x chips. The interfaces were switched over on the Pi 3.

[PramodK]

Thanks a lot for your quick responses. I will check it and get back to you for any more info.

-pK

[PramodK]

Hi rpdom,

I was looking into sdio host controller driver added in linux/drivers/mmc/host/bcm2835-sdhost.c.

I see that below are the register offsets used to send commands/responses to/from card:
#define SDCMD 0x00 /* Command to SD card - 16 R/W */
#define SDARG 0x04 /* Argument to SD card - 32 R/W */
#define SDTOUT 0x08 /* Start value for timeout counter - 32 R/W */
#define SDCDIV 0x0c /* Start value for clock divider - 11 R/W */
#define SDRSP0 0x10 /* SD card response (31:0) - 32 R */
#define SDRSP1 0x14 /* SD card response (63:32) - 32 R */
#define SDRSP2 0x18 /* SD card response (95:64) - 32 R */
#define SDRSP3 0x1c /* SD card response (127:96) - 32 R */
#define SDHSTS 0x20 /* SD host status - 11 R */
#define SDVDD 0x30 /* SD card power control - 1 R/W */
#define SDEDM 0x34 /* Emergency Debug Mode - 13 R/W */
#define SDHCFG 0x38 /* Host configuration - 2 R/W */
#define SDHBCT 0x3c /* Host byte count (debug) - 32 R/W */
#define SDDATA 0x40 /* Data to/from SD card - 32 R/W */
#define SDHBLC 0x50 /* Host block count (SDIO/SDHC) - 9 R/W */

I don't find explanation about the above registers at datasheets located at below link:
https://www.raspberrypi.org/documentati ... spberrypi/

Also, I don't find explanation at rpi-registers_master_rpi-registers.pdf.

It would be of great help if you can share SDIO host controller datasheet(or reference user-guide) which help in programming in any platfrom.

-pK

[nastybuttler322]

I'm just starting to learn programming and learning about operating systems. I am not sure what you are wanting to know, because first you want the memory addresses, and then you show a list and say that you can not find an explanation about the registers. That looks like it could be a list of references to pages and offsets to me. Example: 0x50 could be pageXoffset, or page at offset. I don't know if that is what it is, but I am pretty sure that is not a list of registers.

Also, the explanation of each item is within each line that you posted.

SDHBLC is Host block count, SD part of SDHBLC is the type of hardware for the memory, like an sd card.

SDIO/SDHC may mean SD input and output divided by SD Host Count of blocks.

(SDIO/SDHC) - 9 R/W */ This is probably saying to perform SDIO/SDHC, then subtract 9 values that result from write divided by read
I can not figure out what */ that is there for unless that is the way that the end of a statement is formed for what you have posted.

The addresses are different from the registers, and the registers are different from the references. I am pretty sure that addresses are the binary code of the bus line at the unit of memory, unless a tape, laser disk, and other things probably. A register occupies addresses in different ways depending upon how the operating system manages its memory for the most part. Also depending on the processor architecture for the registers that it contains. Registers hold references to addresses. Those addresses may or may not lead to the absolute address of a unit of memory. I doubt that you would find those addresses within any documents for the operating systems because the operating system sets that stuff up using memory management algorithms. Also, all of the hardware is proprietary and bought from different manufacturers to put together the pi computers. There is no reason for a person to know these things unless he or she is the one designing this. Or ripping it off, which would make less sense than designing a similar one from scratch for improvements.

The only reason that I could think of that you would believe that you want to know the absolute memory addresses would be to upgrade the RAM on the board. To do that, you still would not need to know those addresses. You would want the lowest and the highest address, probably. But that's it. Even then, you need some equipment that I have no idea of what that would be. You would need a lot of things, especially a lot of knowledge gained from a lot of expensive textbooks. If you were to have all of that, I don't think you would be asking what you are asking. If the only reason I could think of is what you were desiring to do. Honestly, an easier task would be to upgrade the device to USB 3.0 by reprogramming the SoC and installing a separate USB controller outside of the SoC, and setting one of the USB drives up to be virtual memory that the new or modified operating system kernel would know to mount it as that. I don't know how to do any of that, I just know some concepts of things from school. But I'm thinking you would save a lot of time and money by just buying a different board like the HiKey, or the Raspberry Pi 3 developer board and compute modules. The absolute addresses that you are wanting is pretty high level knowledge stuff for engineers I think. The people making the different linux/GNU distros for it probably don't know that stuff either.

[rpdom]

The only reason that I could think of that you would believe that you want to know the absolute memory addresses would be to upgrade the RAM on the board. To do that, you still would not need to know those addresses. You would want the lowest and the highest address, probably. But that's it. Even then, you need some equipment that I have no idea of what that would be. You would need a lot of things, especially a lot of knowledge gained from a lot of expensive textbooks. If you were to have all of that, I don't think you would be asking what you are asking. If the only reason I could think of is what you were desiring to do. Honestly, an easier task would be to upgrade the device to USB 3.0 by reprogramming the SoC and installing a separate USB controller outside of the SoC, and setting one of the USB drives up to be virtual memory that the new or modified operating system kernel would know to mount it as that. I don't know how to do any of that, I just know some concepts of things from school. But I'm thinking you would save a lot of time and money by just buying a different board like the HiKey, or the Raspberry Pi 3 developer board and compute modules. The absolute addresses that you are wanting is pretty high level knowledge stuff for engineers I think. The people making the different linux/GNU distros for it probably don't know that stuff either.

This is the Bare Metal forum. Here we poke around memory using absolute addresses. We don't use operating systems, we make our own. Actually, on the Pi it is not unheard of to access the GPIO via direct memory access in C and other languages.

[LdB]

It would be of great help if you can share SDIO host controller datasheet(or reference user-guide) which help in programming in any platfrom.

The addresses are pretty much what you have

Code: Select all

// EMMC registers
#define EMMC_ARG2			((uint32_t* volatile)(RPi_IO_Base_Addr + 0x300000))
#define EMMC_BLKSIZECNT		((uint32_t* volatile)(RPi_IO_Base_Addr + 0x300004))
#define EMMC_ARG1			((uint32_t* volatile)(RPi_IO_Base_Addr + 0x300008))
#define EMMC_CMDTM			((uint32_t* volatile)(RPi_IO_Base_Addr + 0x30000c))
#define EMMC_RESP0			((uint32_t* volatile)(RPi_IO_Base_Addr + 0x300010))
#define EMMC_RESP1			((uint32_t* volatile)(RPi_IO_Base_Addr + 0x300014))
#define EMMC_RESP2			((uint32_t* volatile)(RPi_IO_Base_Addr + 0x300018))
#define EMMC_RESP3			((uint32_t* volatile)(RPi_IO_Base_Addr + 0x30001c))
#define EMMC_DATA			((uint32_t* volatile)(RPi_IO_Base_Addr + 0x300020))
#define EMMC_STATUS			((uint32_t* volatile)(RPi_IO_Base_Addr + 0x300024))
#define EMMC_CONTROL0		((uint32_t* volatile)(RPi_IO_Base_Addr + 0x300028))
#define EMMC_CONTROL1		((uint32_t* volatile)(RPi_IO_Base_Addr + 0x30002c))
#define EMMC_INTERRUPT		((uint32_t* volatile)(RPi_IO_Base_Addr + 0x300030))
#define EMMC_IRPT_MASK		((uint32_t* volatile)(RPi_IO_Base_Addr + 0x300034))
#define EMMC_IRPT_EN		((uint32_t* volatile)(RPi_IO_Base_Addr + 0x300038))
#define EMMC_CONTROL2		((uint32_t* volatile)(RPi_IO_Base_Addr + 0x30003c))
#define EMMC_SLOTISR_VER	((uint32_t* volatile)(RPi_IO_Base_Addr + 0x3000fc))

RPi_IO_Base_Addr is 0x20000000 for Pi1 and 0x3F000000 for Pi2/3
There are a few weird things with the PI SD card controller things like the CRC register result is missing so they can compact one of the registers down to 32 bits. It's not to hard to work thru just requires a bit of poking around.

If you want a baremetal example of using it and reading the FAT16/32 on the SD card I did an article which has the assembler code.
https://www.codeproject.com/Articles/11 ... he-Pi-part

If you want C-code a modified version of hldswrth code is available for the Pi1 from the moizumi repo just change the addresses at the top for the Pi2/3
https://github.com/moizumi99/RPiHaribot ... e/sdcard.c

A discussion of the code is on the forum (link below).... hldswrth code is second post down but as commented there were a couple of problems. The Pi SD card clock is 41.66667Mhz it used to be different be careful when reading posts on it. The Pi SD controller is strictly 3.3V it can't do 1.8V stepdown for ultraspeed.
viewtopic.php?f=72&t=94133

So everything you need is out there in the public domain .. let us know if you have any specific questions.

[elicorrales]

https://ultibo.org/wiki/Unit_BCM2837

[dhmquang]

I was looking into sdio host controller driver added in linux/drivers/mmc/host/bcm2835-sdhost.c.
...

I don't find explanation about the above registers at datasheets located at below link:
https://www.raspberrypi.org/documentati ... spberrypi/

I think that Arasan's EMMC is the SDIO host controller that you mentioned, and explanation of registers is described as following,

Please have a check:
https://www.raspberrypi.org/documentati ... herals.pdf
Section 5 - EMMC - page 65

-----
PS:
Maybe this thread is too old, sorry because of pulling it up
Recently, I need to check how would performance change when we use eMMC instead of Micro-SD, so I searched around forum and find this thread.

Br,
QD