[PATCH 2/3] ARM: at91: mmc-xload: allow overriding card capacity

[Alexander Dahl]

Hello,

thanks for the surprisingly detailed explanation.

Am Thu, Jun 03, 2021 at 08:28:48AM +0200 schrieb Ahmad Fatoum:
> Hei hei Alex,
> 
> On 03.06.21 07:34, Alexander Dahl wrote:
> > Am Wed, Jun 02, 2021 at 12:25:23PM +0200 schrieb Ahmad Fatoum:
> >> The PBL MMC driver works with the assumption that the BootROM has left
> >> the SD-Card in transfer mode. There seems to be no definitive way
> >> to find out whether a running card is high capacity (> 2G) or not,
> >> but we need this info when reading, because default capacities accept
> >> their read offset in bytes while high capacity deal in 512 byte blocks.
> > 
> > I'm a little surprised there's not.  Once like ten years ago I had to
> > write a SD card driver for a small microcontroller.  In the firmware I
> > switched to high capacity mode just based on the Card Capacity Status
> > (CCS) bit in the Operation Conditions Register (OCR) of the SD card.
> > Got that after sending advanced command 41 (send op cond) to the card.
> 
> barebox proper does that in sd_send_op_cond() as well.
> 
> > Not sure if it's that easy, or if that command was only sent under
> > certain conditions, but I can not remember just guessing high capacity
> > based on some heuristics nor hard code it. 
> 
> When you build at91_multi_defconfig, multiple images are generated, currently:
> 
> barebox-at91sam9x5ek.img
> barebox-at91sam9263ek.img
> barebox-microchip-ksz9477-evb.img
> barebox-microchip-ksz9477-evb-xload-mmc.img
> barebox-sama5d27-som1-ek.img
> barebox-sama5d27-som1-ek-xload-mmc.img
> barebox-groboards-sama5d27-giantboard.img
> barebox-groboards-sama5d27-giantboard-xload-mmc.img
> barebox-skov-arm9cpu.img
> 
> This patch here is for the xload-mmc.img's, which result from the barebox
> prebootloader. The PBL sets up SDRAM and chainloads barebox proper from the
> same boot medium that itself came from. Because of this limited scope, it can
> reuse here the SD-card setup done by the BootROM. The BootROM leaves the
> SD-Card in transfer mode, allowing the PBL to directly read blocks off the
> SD-Card without a full MMC/SD-Card driver.

I see.

> > We certainly used low
> > capacity (like 32 MB for example) and high capacity cards (4G or more)
> > with that system.
> > 
> > You probably already looked for a reliable way to detect this.  I was
> > just curious why this needs to be hardcoded.
> 
> It's been a while since I wrote the sama5d27 PBL support (which the
> sama5d3 support I am patching here is based on), but I recall that
> the send op cond did not work in transfer mode, the card must be sent
> into idle first, i.e. reset. I'd be happy if there happens to be indeed
> a way to deduce high capacity mode without resetting and having to repeat
> the SD-Card setup in the first boot stage.

Makes sense.  And yes, IIRC correctly, that register read happens
while setting up the card.  If you can not or don't want to reset the
card again, it's probably tricky.

> There are of course alternatives to this:
>   - build barebox twice with different configs for first and second stage:
>     There is already code for this (chainload code that uses barebox proper
>     driver that fully re-initializes card). The first stage config needs to
>     be small to fit into SRAM, so we can no longer generate both stages from
>     the same multi-image config as we already do.
> 
>   - provide full MMC support in PBL:
>     The objective so far was to keep PBL code to the bare minimum. Doing
>     full MMC setup there violates that.
> 
> 
> AFAIK, all barebox platforms, except for i.MX, went for the first alternative
> of having multiple configs. barebox on i.MX doesn't have this issue, because
> it reads barebox from offset 0 of the SD/MMC, which works equally well whether
> booting off default or high capacity cards.
> 
> I like how the i.MX defconfig generates more than a hundred images in one go and
> wanted AT91 to have something similar, but the fact that FAT needs to seek around
> (offsets != 0) complicates this.
> The trade off I took then was assuming high capacity cards and postpone the decision
> on how to deal with default capacity cards in PBL into the future.

I just had the idea of just trying to read from different small
offsets and compare it with the block you get from offset 0.  For
example reading 500 bytes from offset 10 and reading 510 bytes from
offset 0 in byte mode should match the last 500 bytes, but probably in
block mode that wouldn't match.  But that's obviously highly dependent
on the card content and more an ugly hack, right?

Greets
Alex