[U-Boot-Users] FAT mbr on MMC or SD cards

[U-Boot-Users] FAT mbr on MMC or SD cards

[Heiko Schocher]

Hello Joey,

"Joey Oravec" <joravec@drewtech.com> wrote:
> >> 1. This code assumes that sector 0 contains a VBR. Instead I think it 
> >> should
> >> decide if 0 is an MBR or VBR, or even better utilize the dev:part command
> >> line. Can I make this determination that from the first three bytes, or 
> >> is
> >> there a better way?
> >
> > We have a patch in the queue to fix this, but it  did  not  pass  our
> > internal  review  and unfortunately the engineer is on vacation right
> > now so he cannot clean it up. Please be patiend for a week or two.
> 
> I wanted to share that with the list in case anybody else gets stuck.
> 
> Since my original email, I noticed code in fat_register_device() which 
> determines a part_offset for 1.1.5 and 1.1.6. For now I've hacked this code 
> to check the first three bytes EB:xx:90 or E9:xx:xx to make the mbr/pbr 
> decision instead of the ascii string. Also I have it reading the valid 
> partition offset instead of assuming 32. And finally I added a packed 
> attribute to all structs.

I am not sure if we can use EB:xx:90 or E9:xx:xx (Am I right, this is
the "Jump instruction to boot code" on a PBR?) for deciding between
a MBR and a VBR, because the First 446 Bytes from a MBR are only
"Bootcode", whatever this means, and maybe there is a MBR with
EB:xx:90 or E9:xx:xx in the First 3 Bytes ...

> >> 2. The decision of fat12, fat16, and fat32 is made upon fat_length and an
> >> ascii field. The Microsoft document claims that the determination shall 
> >> be
> >> made only by the count of clusters. Any disputes on that fix?
> >
> > I have no idea...
> 
> I was reading a document "FAT: General Overfiew of On-Disk Format" v1.02 May 
> 5, 1999 by Microsoft Corporation. The correct way is to calculate 
> CountofClusters. Less than 4085 is FAT12, less than 65525 is FAT16, anything 
> else is FAT32. I'll watch, and after he gets back from vacation we can do 
> something about it.

This sounds good to me.

Do you have a patch for me, so I can test it?

thanks
Heiko
-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany

[U-Boot-Users] FAT mbr on MMC or SD cards

[Joey Oravec]

"Heiko Schocher" <hs@denx.de> wrote in message 
news:1182164674.15090.54.camel at Apollo...
> I am not sure if we can use EB:xx:90 or E9:xx:xx (Am I right, this is
> the "Jump instruction to boot code" on a PBR?) for deciding between
> a MBR and a VBR, because the First 446 Bytes from a MBR are only
> "Bootcode", whatever this means, and maybe there is a MBR with
> EB:xx:90 or E9:xx:xx in the First 3 Bytes ...

Correct, the Microsoft document says the beginning of a VBR will always be 
"a 3-byte intel x86 unconditional branch (jump) instruction that jumps to 
the start of the operating system bootstrap code". It says either form is 
acceptable but 0xEB is used more frequently.

None of the common MBRs start with a jump 
(http://mirror.href.com/thestarman/asm/mbr/), so it seems like a pretty 
decent heuristic.

Linux-2.6.20 in fs/partitions/msdos.c has a function msdos_partition() that 
checks for the 0xAA55 signature and a 0x80 active or 0x00 inactive boot 
indicator for each partition in the table. I'm not sure if that technique is 
any better or worse.

-joey 

[U-Boot-Users] FAT mbr on MMC or SD cards

[Joey Oravec]

Hi all,

I've been testing a wide variety of MMC/SD cards straight out of the 
package. Some cards have a MBR at sector 0 (like a hard drive) while others 
are unpartitioned with a volume boot sector at sector 0 (like a floppy). And 
it might change if you reformat the card.

I'm still on 1.1.5, but I didn't see any major changes in 1.1.6. Within 
fs/fat/fat.c one of the first functions file_fat_detectfs() calls 
read_bootsectandvi(). I think I need to make, and then submit patches for, a 
few changes:

1. This code assumes that sector 0 contains a VBR. Instead I think it should 
decide if 0 is an MBR or VBR, or even better utilize the dev:part command 
line. Can I make this determination that from the first three bytes, or is 
there a better way?

2. The decision of fat12, fat16, and fat32 is made upon fat_length and an 
ascii field. The Microsoft document claims that the determination shall be 
made only by the count of clusters. Any disputes on that fix?

3. Structure boot_sector may need a packed attribute. As far as I can tell 
there are no makefile flags so gcc is free to add padding to align members 
inside structures. This would be a problem for the memcpy from block to 
boot_sector within read_bootsectandvi(). What is the coding standard for 
specifying 1-byte packing where necessary? Just add the gcc attribute?

Thanks!

-joey 

[U-Boot-Users] FAT mbr on MMC or SD cards

[Wolfgang Denk]

In message <f4p407$8qj$1@sea.gmane.org> you wrote:
> 
> I've been testing a wide variety of MMC/SD cards straight out of the 
> package. Some cards have a MBR at sector 0 (like a hard drive) while others 
> are unpartitioned with a volume boot sector at sector 0 (like a floppy). And 
> it might change if you reformat the card.
> 
> I'm still on 1.1.5, but I didn't see any major changes in 1.1.6. Within 

Comparing to ancient versions probably shows little difference in that
area. indeed.

> fs/fat/fat.c one of the first functions file_fat_detectfs() calls 
> read_bootsectandvi(). I think I need to make, and then submit patches for, a 
> few changes:
> 
> 1. This code assumes that sector 0 contains a VBR. Instead I think it should 
> decide if 0 is an MBR or VBR, or even better utilize the dev:part command 
> line. Can I make this determination that from the first three bytes, or is 
> there a better way?

We have a patch in the queue to fix this, but it  did  not  pass  our
internal  review  and unfortunately the engineer is on vacation right
now so he cannot clean it up. Please be patiend for a week or two.

> 2. The decision of fat12, fat16, and fat32 is made upon fat_length and an 
> ascii field. The Microsoft document claims that the determination shall be 
> made only by the count of clusters. Any disputes on that fix?

I have no idea...

> 3. Structure boot_sector may need a packed attribute. As far as I can tell 
> there are no makefile flags so gcc is free to add padding to align members 
> inside structures. This would be a problem for the memcpy from block to 
> boot_sector within read_bootsectandvi(). What is the coding standard for 
> specifying 1-byte packing where necessary? Just add the gcc attribute?

Just add "__attribute__ ((packed))".

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
If I can have honesty, it's easier to overlook mistakes.
	-- Kirk, "Space Seed", stardate 3141.9

[U-Boot-Users] FAT mbr on MMC or SD cards

[Joey Oravec]

"Wolfgang Denk" <wd@denx.de> wrote in message 
news:20070613184133.A9478352681 at atlas.denx.de...
>> 1. This code assumes that sector 0 contains a VBR. Instead I think it 
>> should
>> decide if 0 is an MBR or VBR, or even better utilize the dev:part command
>> line. Can I make this determination that from the first three bytes, or 
>> is
>> there a better way?
>
> We have a patch in the queue to fix this, but it  did  not  pass  our
> internal  review  and unfortunately the engineer is on vacation right
> now so he cannot clean it up. Please be patiend for a week or two.

I wanted to share that with the list in case anybody else gets stuck.

Since my original email, I noticed code in fat_register_device() which 
determines a part_offset for 1.1.5 and 1.1.6. For now I've hacked this code 
to check the first three bytes EB:xx:90 or E9:xx:xx to make the mbr/pbr 
decision instead of the ascii string. Also I have it reading the valid 
partition offset instead of assuming 32. And finally I added a packed 
attribute to all structs.

>> 2. The decision of fat12, fat16, and fat32 is made upon fat_length and an
>> ascii field. The Microsoft document claims that the determination shall 
>> be
>> made only by the count of clusters. Any disputes on that fix?
>
> I have no idea...

I was reading a document "FAT: General Overfiew of On-Disk Format" v1.02 May 
5, 1999 by Microsoft Corporation. The correct way is to calculate 
CountofClusters. Less than 4085 is FAT12, less than 65525 is FAT16, anything 
else is FAT32. I'll watch, and after he gets back from vacation we can do 
something about it.

-joey 






From "abiyani at unix dot telasic dot com" at unix.telasic.com  Wed Jun 13 23:01:29 2007
From: "abiyani at unix dot telasic dot com" at unix.telasic.com (Arun Biyani)
Date: Wed, 13 Jun 2007 14:01:29 -0700
Subject: [U-Boot-Users] U-Boot 1.2 - Cannot run hello_world - Coldfire
Message-ID: <200706132101.OAA10296@unix.telasic.com>

I have a target board with a Coldfire CPU. I am unable to run the 
example program
hello_world which comes with the distribution. Transcript of session is 
below. What
am I missing? The cross compile tools were run on Linux (FC 7), 
downloaded from
snapgear.org uClinux directory. I tried this with v1.1.6 also. I'll be 
glad to provide
any additional data. I have just started with U-Boot so please be 
explicit. On the host,
I was running Tera Term and used "send file" from the "File" menu to 
send the srec file.
I ran the program with parameters as well with the same result.

U-Boot 1.2.0 (Jun 13 2007 - 07:36:11)

CPU:   Freescale MCF5272 (Mask:1)
Board: Telasic RLB 2.0
DRAM:  16 MB
FLASH: 32 MB
In:    serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
->
-> ds
Unknown command 'ds' - try 'help'
-> loads
## Ready for S-Record download ...

## First Load Addr = 0x00020000
## Last  Load Addr = 0x000222F7
## Total Size      = 0x000022F8 = 8952 Bytes
## Start Addr      = 0x00020000
-> go 0x00020004
## Starting application at 0x00020004 ...


*** Unexpected exception ***
Vector Number: 4  Format: 04  Fault Status: 0

PC: 00ff94fc    SR: 00002004    SP: 00f6db0c
D0: 00000000    D1: 0000048c    D2: 00000000    D3: 00ff8fac
D4: 000000f3    D5: 00000000    D6: 00000000    D7: 00f7df90
A0: 00fed912    A1: 00ff94fc    A2: 00020004    A3: 00f6ded8
A4: 00000002    A5: 00ff7300    A6: 00f6db8c

*** Please Reset Board! ***