[U-Boot-Users] [PATCH] CFI driver AMD Command Set Top boot geometry reversal, etc. [Updated]

Tolunay Orkun listmember at orkun.us
Sun Nov 12 23:04:08 CET 2006

Stefan Roese wrote:

>>> -               flash_write_cmd(info, 0, 0, FLASH_CMD_READ_ID);
>>> +               flash_write_cmd(info, 0, AMD_ADDR_START,
>> I think this change is what was missing which I overlooked. Intel does
>> not need a specific address to write the command nor unlock sequence.
> And that's the reason I don't like those Intel devices. I got some devices 
> accidentally screwed in a project once.

I hear you. I was not talking about merits.

> So FLASH ID's are now read back correctly.

Great. Your flash device should validate CFI = 1.0 code path for geometry 
reversal detection as well.

>> I will update the patch tonight and resend it yet again.
> Not necessary. I'll forward this patch with the fix to Wolfgang. Thanks again.

I did it anyway [DNX#2006111242000019]. Plus a few more minor changes: I've 
added my copyright line. Added a few more comments and removed some other 
change history comments included with previous copyright lines. Copyrights 
are still there as it should be.

I prefer if you can use this patch if it is not too late.

> And when it's included we can continue to extend the code with additional 
> features, like fixing this ST FLASH geometry reversal (or others) by 
> identifying it's device ID.

It looks the sector addresses you included (below) is now that of top boot. 
Is it not working for you? When I enabled DEBUG the flash driver would have 
trouble with writes even for Intel  (possibily clearing the status register 
prematurely). Make sure you test with DEBUG disabled for cp command.

> Sector Start Addresses:
> FFE00000        FFE10000        FFE20000 E      FFE30000 E      FFE40000 E
> FFE50000 E      FFE60000 E      FFE70000 E      FFE80000 E      FFE90000 E
> FFEA0000 E      FFEB0000 E      FFEC0000 E      FFED0000 E      FFEE0000 E
> FFEF0000 E      FFF00000 E      FFF10000 E      FFF20000 E      FFF30000 E
> FFF40000 E      FFF50000 E      FFF60000 E      FFF70000 E      FFF80000 E
> FFF90000 E      FFFA0000   RO   FFFB0000   RO   FFFC0000   RO   FFFD0000   RO
> FFFE0000   RO   FFFF0000   RO   FFFF8000 E      FFFFA000 E      FFFFC000

I think should probably re-org the code sometime to be more table driven. We 
can avoid testing for vendor everywhere and make code much easier to read 
and extend. If a vendor is sticking to AMD style chips we could also have 
option to exclude the Intel support (or vice versa) completely to save some 
space that way.

Best regards,

More information about the U-Boot mailing list