G'day<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> > > +# or set your networking parameters here<br>
> > > +#eth0.ipaddr=192.168.1.80<br>
> > > +#eth0.netmask=255.255.255.0<br>
> > > +#eth0.gateway=a.b.c.d<br>
> > > +eth0.serverip=192.168.1.23<br>
> > > +eth0.ethaddr=00:50:c2:8c:e6:0e<br>
> ><br>
> > *never* *ever* add MAC addresses to the default environment.<br>
><br>
><br>
> Ok. In my case, the MAC address is actually stored inside a secured at24<br>
> EEPROM buffer. Unfortunately, at24 via I2C does not seem to be available in<br>
> barebox. I reckon I have to port it from the kernel or uboot :).<br>
<br>
</div>Or just leave the field blank. In this case a random (local-) MAC<br>
address is generated.</blockquote><div><br></div><div>Oh, I didn't know that, brilliant.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> I have included some more debugging and also workarounds for the mx25. This<br>
> is the current debug output, where it clearly indicates that for some<br>
> reason the mx25 esdhc related registers never show a transfer complete for<br>
> a multiblock write:<br>
<br>
</div>The kernel has this:<br>
<br>
if (is_imx25_esdhc(imx_data) || is_imx35_esdhc(imx_data))<br>
/* Fix errata ENGcm07207 present on i.MX25 and i.MX35 */<br>
host->quirks |= SDHCI_QUIRK_NO_MULTIBLOCK<br>
| SDHCI_QUIRK_BROKEN_ADMA;<br></blockquote><div><br></div><div>:) 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!</div>
<div><br></div><div>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:</div>
<div><br></div><div>"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.</div>
<div>
<p class="p1">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."</p>
<p class="p1">So the solution is as follows:</p><p class="p1">
</p><p class="p1">To abort data transfers on the AHB, software can reset the eSDHC by writing 1 to SYSCTL[24] (RSTA).</p><p class="p1">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.</p>
<p class="p1">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.</p>
<p class="p1">I happily stand corrected ;).</p><p class="p1">Best regards</p><p class="p1">Roberto</p><p></p></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Which means that the kernel won't do multiblock on i.MX25 and i.MX35.<br>
<div class="HOEnZb"><div class="h5"><br>
Sascha<br>
<br>
--<br>
Pengutronix e.K. | |<br>
Industrial Linux Solutions | <a href="http://www.pengutronix.de/" target="_blank">http://www.pengutronix.de/</a> |<br>
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: <a href="tel:%2B49-5121-206917-0" value="+4951212069170">+49-5121-206917-0</a> |<br>
Amtsgericht Hildesheim, HRA 2686 | Fax: <a href="tel:%2B49-5121-206917-5555" value="+4951212069175555">+49-5121-206917-5555</a> |<br>
</div></div></blockquote></div><br>