Document GPIO boot mode on its own page

[ghost]

Currently, there is no specific page which documents GPIO boot mode. This PR proposes to add one. This will clarify that this is a specific boot mode, enabled by a specific GPIO. It will also document exactly which GPIO activates which type of boot (SD, MSD, Ethernet etc) - the current docs are not ideal in this regard.

[ghost]

This is a follow on from #1126

[lurch]

GPIO activates which type of boot (SD, MSD, Ethernet etc)

Nitpick: the GPIOs allow you to select to enable "SD1, SD2, NAND, SPI, USB" and USB covers both MSD and Ethernet, so you can't use GPIO to select between them 😜

And since SD2, NAND and SPI boot aren't supported, I guess it effectively only allows you to select between SD and USB boot.

[ghost]

I would have discovered that when I read Gordon's existing docs. Which I will do tomorrow.

[ghollingworth]

Depends if you have control over the OTG_ID pin on the Pi compute module, if you do then you can choose between host and device mode.

[ghost]

@ghollingworth Do you mean OTG_ID is exposed on the compute module's edge connector?

[ghollingworth]

Yes it is... For device mode it should be left open circuit, for host mode it should be pulled / driven low. On the CMIO board there is a resistor R12 which pulls this low permanently, I would suggest removing this and then using a jumper on the GPIO connector (the USB_ID pin comes out on pin 168 on the edge connector which is J6 pin 55 on the CMIO3 board)

[lurch]

@ghollingworth Out of curiosity: if OTG_ID is permanently pulled low on the CMIO board, how does the usbboot flashing mode work? Doesn't that require the CM to be in device mode?

[ghost]

Thanks for the extra information @ghollingworth - I will add that to the new page. I pinged you on a couple of other documentation PRs - don't know if you saw those 😉

[ghost]

@ghollingworth Can you confirm 3 things:

1. What is the current state of SPI and NAND boot?

2. Currently bootflow.md says this: "The primary SD card boot mode is, as standard, set to be GPIOs 49-53". Does this mean that by default the primary SD card interface is on GPIOs 49-53?

3. Which SD card interface block is SD1, and which is SD2?

[lurch]

https://elinux.org/RPi_BCM2835_GPIOs

I suspect 'SD1' being discussed in bootflow.md is 'SD0' in that GPIOs table, and 'SD2' in bootflow.md is 'SD1' in that table.

[ghost]

https://elinux.org/RPi_BCM2835_GPIOs

I suspect 'SD1' being discussed in bootflow.md is 'SD0' in that GPIOs table, and 'SD2' in bootflow.md is 'SD1' in that table.

That still doesn't explain which hardware block they are.

[lurch]

That still doesn't explain which hardware block they are.

I'm not sure what you mean?

[ghost]

That still doesn't explain which hardware block they are.

I'm not sure what you mean?

There are two different implementations of an SD card interface present in the chip, and they come from two different vendors. It would be useful to know which one is SD1 and which is SD2. (Also, they should probably be called SD0 and SD1 if that's how the rest of the docs refer to them).

[lurch]

There are two different implementations of an SD card interface present in the chip, and they come from two different vendors.

Hmmm, I wasn't aware of that! I did a bit of googling and eventually found raspberrypi/linux#1536 where @pelwell says "The alt3 function on pins 22-27 is SD1 a.k.a. MMC. You want SD0 a.k.a. SDHOST which is alt0"

[pelwell]

SD0 is the Broadcom in-house SD/MMC interface - known as SDHOST - which is now used by default on current images to drive the SD card or (on the Compute Module) eMMC. SD1 is the standard Arasan MMC block, but without ADMA/bus mastering support. This block is SDIO-capable, which is why it is used to connect the WiFi module. (SDHOST can almost do SDIO, but some over-aggressive clock gating prevents it from working.)

[ghost]

@pelwell @ghollingworth This PR just needs confirmation of the GPIO assignments, and which Pis have different GPIO enables as it seems from what has been said that newer Pis have more of them.

[lurch]

@andrum99 The documentation you've got now seems to imply that it's possible to boot from either SD0 or SD1, but from what I understand it's only possible to boot from SD0? Gordon earlier said "currently the only enableable modes are SDHOST boot, USB device, USB mass storage and USB ethernet".

[ghost]

@andrum99 The documentation you've got now seems to imply that it's possible to boot from either SD0 or SD1, but from what I understand it's only possible to boot from SD0? Gordon earlier said "currently the only enableable modes are SDHOST boot, USB device, USB mass storage and USB ethernet".

As does the existing documentation. It's not entirely clear in what way these modes are "enabled" and the ones which aren't available are "disabled". It could be that the boot ROM will try all of the modes listed (or else, why bother documenting them?), but that there is currently no support in Linux.

[lurch]

@andrum99 I don't think it adds anything that you've not already covered, but I've just noticed there's some documentation about SD0 and SD1 in section 9.1.4 of https://www.raspberrypi.org/documentation/hardware/computemodule/datasheets/rpi_DATA_CM3plus_1p0.pdf

[lurch]

I guess this would also fix #793

[ghost]

I guess this would also fix #793

I guess it would to. Pinging @JamesH65 as this one is ready to go, but I hadn't pinged him before to tell him - my bad 😮

[JamesH65]

Pushed to copy edit.

[ghost]

Just to clarify - I've changed GPIO pins TO lines, since the GPIO pins are not necessarily in the same order as the GPIO lines on the chip. The GPIO lines on the chip are tested in numerical order to select the desired boot modes. This order is not necessarily the same as the order of those GPIOs on the connector.

[pelwell]

Can we get this merged ASAP?

[JamesH65]

Cannot wait for CE, so merging.

[ghost]

Note that this PR on its own does not create ANY links to the new page documenting GPIO boot mode. I have created a new PR, #1194, to add a suitable link from the main bootmodes documentation page. Pinging @JamesH65.