Booting mx25 based device from SD and NOR

[Roberto Nibali]

G'day

> > > +# or set your networking parameters here
> > > > +#eth0.ipaddr=192.168.1.80
> > > > +#eth0.netmask=255.255.255.0
> > > > +#eth0.gateway=a.b.c.d
> > > > +eth0.serverip=192.168.1.23
> > > > +eth0.ethaddr=00:50:c2:8c:e6:0e
> > >
> > > *never* *ever* add MAC addresses to the default environment.
> >
> >
> >  Ok. In my case, the MAC address is actually stored inside a secured at24
> > EEPROM buffer. Unfortunately, at24 via I2C does not seem to be available
> in
> > barebox. I reckon I have to port it from the kernel or uboot :).
>
> Or just leave the field blank. In this case a random (local-) MAC
> address is generated.


Oh, I didn't know that, brilliant.

> I have included some more debugging and also workarounds for the mx25.
> This
> > is the current debug output, where it clearly indicates that for some
> > reason the mx25 esdhc related registers never show a transfer complete
> for
> > a multiblock write:
>
> The kernel has this:
>
>  if (is_imx25_esdhc(imx_data) || is_imx35_esdhc(imx_data))
>                /* Fix errata ENGcm07207 present on i.MX25 and i.MX35 */
>                host->quirks |= SDHCI_QUIRK_NO_MULTIBLOCK
>                        | SDHCI_QUIRK_BROKEN_ADMA;
>

:) Yes, the kernel has lots of quirks for the mx25 based esdhc
implementation, and I have stumbled across these lines a dozen times
already over the past few weeks trying to figure out why SD write transfer
is doooooog slow on my device. I have been sending a lot of in-depth
analysis and traces, including timing charts showing completely impossible
CMD timeouts, and no one seems to be able to figure out what causes this.
Hardware failure is almost not possible, and that's why I focused on the
Software part. Since the eSDHC stack in the kernel is composed of a lot of
intermediary drivers down to block layer, I opted for the simplest possible
test case where I didn't have to write an SD driver from scratch: barebox!

That's how we ended up here. I am well aware that for others this problem
does not seem to exist, but I simply don't know where to look for anymore.
With regard to ENGcm07207, IMHO the introduced quirk does not really fix
this specific erratum. The problem description in the READ case is as
follows:

"If a CMD12 command is sent during a WRITE MULTIPLE BLOCK transfer, the AHB
bus keeps writing to the internal buffers. This is undesirable behavior.
During this situation, the AHB bus does not stop until all the blocks are
written to the internal buffer, and an AutoCMD12 command is sent.

A typical scenario is as follows: After Sending a non-ending block, the
card replies with a CRC error. The software detects the CRC error and
manually sends a CMD12 command to the card to stop the transmission.
Internally, the AHB bus keeps writing to the internal buffer even though
the software stopped the transfer."

So the solution is as follows:

To abort data transfers on the AHB, software can reset the eSDHC by writing
1 to SYSCTL[24] (RSTA).

I haven't tried this, but I can assure you that setting block count to 1
does not resolve the issue at all, or the other way around: having multiple
block write/read support for the i.MX25 does not seem to be the cause of
any reproducible problem. So, unless someone proves me otherwise, I believe
the kernel driver implementation is wrong. On top of that, there is
erratum ENGcm01112 which then directly comes into action, something I also
didn't see addressed in the kernel sources.

I'll keep looking for other answers, however you might want to consider the
minimally invasive WML changes I did in the patch sent before, which at the
same time introduce a similar quirk "framework" to the esdhc driver in
barebox like the kernel has. I will also compare to the uboot driver. I
understand that there is very little concern for this in the barebox
driver, since most of what the users need is to copy from the SD card, and
so far nobody has complained.

I happily stand corrected ;).

Best regards

Roberto



> Which means that the kernel won't do multiblock on i.MX25 and i.MX35.
>
> Sascha
>
> --
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/barebox/attachments/20120601/6341c55b/attachment.html>