mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Ahmad Fatoum <>
To: Sam Ravnborg <>
Subject: Re: [PATCH v1 8/8] ARM: at91: Add xload support to skov-arm9cpu
Date: Mon, 16 May 2022 17:35:06 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hello Sam,

On 16.05.22 17:28, Sam Ravnborg wrote:
> Hi Ahmad,
> On Mon, May 16, 2022 at 01:15:42PM +0200, Ahmad Fatoum wrote:
>> Hello Sam,
> Thanks for your feedback - very appreciated!


>> Is your SD-Card perhaps 2G or smaller? The AT91 PBL MCI functions
>> assume high capacity (> 2G). It's a quite ugly thing, but
>> finding out whether a card is High-Capacity or not happens
>> during init phase and as we don't redo init in PBL...
> From the at91sam9263 datasheet:
> "Boot ROM does not support high capacity SDCards."
> Sounds like a very plausible explanation - and gives me something to go
> after.

Try toggling priv->highcapacity_card = 1; in atmel_mci_pbl.c

The original in atmel-sdhci-pbl.c had a comment:

 // FIXME can we determine this without leaving SD transfer mode? 
 priv->highcapacity_card = 1;                                  

>> High Capacity cards reference start block offset in sectors, while
>> older cards use bytes. On i.MX, barebox just reads at offset 0
>> and all is good, but on AT91, we need to do random access, so
>> we need to decide whether to use sectors or bytes. Currently,
>> the driver hardcodes the sector assumption. I found this to be
>> the lesser evil to the alternative: having a full MMC stack in PBL. 
>> If that's indeed your issue, there's a heuristic possible:
>> Try to mount for High-Capacity, if that fails, assume non-high
>> capacity and try again. It's not 100%, but it's better than status quo.
> I will try to find a nice way to tell that we shall go for a non-high
> capacity in the first place.
> And then I will dig into the sector versus byte thing afterwards.

It's probably best we move this setting into the _bio_init functions,
so callers are aware of the limitation and can e.g. for the 9263
always hardcode it as false. Heuristic would be nice to have,
but apparently it's not required for your use case.

>> Unrelated to your patch, but you might know the answer: Why is there a max PBL memory size here?
>> AFAIK, you use at91bootstrap to chainload barebox into DRAM, why do you need
>> a PBL size limit then?
> The limit is from the old days where we tried to squeeze barebox into
> the SRAM, so it could be used as the only bootloader - dropping the need
> for at91bootstrap.
> The new approach where we do a PBL barebox and then a full barebox is
> much easier when you have first understood the concept.
> I will drop the size restriction in my next patch stack.
> We see other at91sam boards with the same restrictions due to the same
> history. I think we can safely assume there is no use for barebox as
> at91bootstrap and we can drop the size restrictions.
> But then I am not happy to edit old boards that I cannot tests.
> I have an at91sam9263-ek board and will update the board support
> when I have skov-arm9cpu done. Focus is on the skov board first, as I
> have more HW to play with here.

Ye, doing the change for your board only is fine by me. I just
wondered when I looked at the code. Thanks for clearing this up.


> 	Sam

Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       |  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

barebox mailing list

  reply	other threads:[~2022-05-16 15:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-15 19:37 [RFC PATCH v1 0/8] ARM: at91: Add pbl " Sam Ravnborg
2022-05-15 19:38 ` [PATCH v1 1/8] pwm: atmel: Fix build and update Sam Ravnborg
2022-05-15 19:38 ` [PATCH v1 2/8] ARM: at91: Provide at91_mux_pio_pin for use in lowlevel Sam Ravnborg
2022-05-15 19:38 ` [PATCH v1 3/8] ARM: at91: Add at91sam9 xload_mmc for PBL use Sam Ravnborg
2022-05-15 19:38 ` [PATCH v1 4/8] ARM: at91: Add extra register definitions Sam Ravnborg
2022-05-15 19:38 ` [PATCH v1 5/8] ARM: at91: Add lowlevel helpers for at91sam9263 Sam Ravnborg
2022-05-15 19:38 ` [PATCH v1 6/8] ARM: at91: Make sdramc.h useable in multi image builds Sam Ravnborg
2022-05-15 19:38 ` [PATCH v1 7/8] ARM: at91: Add initialize function to sdramc Sam Ravnborg
2022-05-16 10:47   ` Ahmad Fatoum
2022-05-16 15:13     ` Sam Ravnborg
2022-05-15 19:38 ` [PATCH v1 8/8] ARM: at91: Add xload support to skov-arm9cpu Sam Ravnborg
2022-05-16 11:15   ` Ahmad Fatoum
2022-05-16 15:28     ` Sam Ravnborg
2022-05-16 15:35       ` Ahmad Fatoum [this message]
2022-05-16 15:47         ` Ahmad Fatoum
2022-05-30  7:20 ` [RFC PATCH v1 0/8] ARM: at91: Add pbl " Sam Ravnborg
2022-06-28 19:23 ` Sam Ravnborg
2022-06-28 21:12   ` Ahmad Fatoum
2022-06-28 21:18     ` Sam Ravnborg
2022-06-28 21:20       ` Ahmad Fatoum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox