[U-Boot] [PATCH] M28: Added guarding for reserved bits in GPIO driver

[Marek Vasut]

> Hi Marek,
> 
> > Hey, this looks reasonable. Did you send similar patch to Linux too ?
> 
> No, I'm not at that yet. I'm just starting to explore the New U-Boot: It's
> been since version 1.1.2 that I have actually contributed something.
> 
> My current project requires a mechanism to manipulate GPIO pins, to aid the
> bring-up of a new board in a couple of weeks. Until last weeks I've been
> using the ancient FreeScale supplied U-Boot. When I took that in, your
> work didn't appear in the repository yet, so finding that was a big and
> pleasant surprise. Especially because the FreeScale version had a couple
> of bugs in it. Not to start about the bugs in the supplied bootlets...
> 
> So taking in U-Boot with your work is killing at least 3 birds with one
> stone.
> 
> I will do some work on the Kernel later. For now we're using the FreeScale
> supplied Kernel. I have tried 3.1rc4 before and it ran our application
> perfectly, so that's looking good already. But changing Kernel 2 weeks
> before board bring-up is a bit too exciting for me. For that reason I will
> probably hold on to the FreeScale bootlets and U-Boot version too.
> 
> But now I've got your attention anyway: Is there a reason why U-Boot
> expects the bootstream at sector 1024 of the SD-Card?

To make things simple for users, there's standard layout. It's actually at 
sector 2048 btw.

> The internal bootrom
> doesn't know this limitation. It is clever enough to interpret the
> partition table, and start loading SRAM from the first sector of the first
> partition of type 53.

That's what happens internally, it's just that some pieces (like sector offset 
of the partition!) need to be filled into the bootstream header by the mxsboot 
utility -- see mxsboot -h for how to change that.

The 2048 sector offset was chosen because that's standard in Linux now for first 
partiiton.

> Now I figure that the internal bootrom can only load
> the first part of U-Boot, because of SRAM limits, and that this first part
> has to power-up all power rails, initialize SD-RAM and load the remainder
> of U-Boot, but I don't see why it couldn't be as clever as the internal
> bootrom.

What do you mean?

> The reason I'm asking is because our project intends to boot from
> MMC all the time. We don't think unmanaged NAND is reliable enough for our
> appliction. We would like to have the oppertunity to boot from an SD-Card,
> that also usable on Windows. And since that poor OS doesn't know the
> difference between a disk, a partition and a file system it gets confused
> if the first partition on an SD-Card isn't FAT formatted.

You can adjust that, see above.

> 
> Cheers,
> 
>         Robert.