Ok, so for implementing access to a SD Card from boot loader what all we need to implement? Here goes:
- SD Card block read, identification routines
- Routines to identify, validate and read the partition information from MBR
- Routines to perform the FAT (VFAT) data from card.
If you check out the sources code in U-boot, these functionalities has been divide in to the following modules:
- pxa_mmc.c (/drivers/mmc/)
- part.c (/disk/)
- part_dos.c (/disk)
- fat.c (fs/fat)
- file.c (fs/fat)
If you directly take the relevant headers and these source files and compile it along E-Boot, of course, you will end up in lot of error, mostly related to
- data types
- use of __attribute__
- structure and macros which are present in Linux headers
Once the errors have been resolved (of course, I am going to leave it up to you), I first enabled and invoked the SD CARD detection routines, I was able to detect the SD CARD, but seemed to failing in reading the MBR, on dumping it, I observed that some bits are not the same as the actual data on SDCARD. So I posted the same on to U-boot mailing list.
Then I figured out that the GPIO configuration was getting overridden in another place in code. Corrected it and there it was working like a charm.
Now I enabled, the FAT access module, here again I was stumped with another problem, the compilation was happening properly, but the Flash Image (Eboot.Nb0), was not generating properly. I.e., I observed that there was no change in behavior if I flash the image, with new functionality, also the time stamp on the file was not updating for NB0 file after compilation.
If I disable the new code added, the Image generation was happening properly. So there I was stuck again with another strange problem. So I went through the code again. After some pain staking and careful analysis, I noticed on thing, there were some array declarations like the following, through out the code:
__u8 get_vfatname_block[MAX_CLUSTSIZE];
The macro MAX_CLUSTSIZE, was having the value 65536 . So it is creating an array of very huge size.
So why didn't it create a problem in BIN file creation, instead the problem is showing up NB0 file creation? Answer is very simple:
BIN files are something similar to a loader, i.e. they will have a predefined record format, and will a piece of loader code to unpack the same. On the other hand, NB0 or ROM Image files are like how the Program will be present in memory, when it is loaded.
What happened was that, when trying to create spaces for all the arrays that had been declared in code, the NB0 file creation was failing (Although it was not shown as a warning or error while building). The size of Rom Image for boot loader is restricted to 256KBytes in Eboot.bib.
Now to work around this problem, I used the free memory in RAM and changed these arrays to pointers and initialized them to some addresses in RAM. Now, I had the module working , with reading of any content in an SD Card.
Now moving on to USB Client Upgrade implementation, I will explain the things later on in the next post