public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] FAT mbr on MMC or SD cards
Date: Mon, 18 Jun 2007 13:04:34 +0200	[thread overview]
Message-ID: <1182164674.15090.54.camel@Apollo> (raw)
In-Reply-To: <20070613212533.EA32A353B6D@atlas.denx.de>

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

       reply	other threads:[~2007-06-18 11:04 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20070613212533.EA32A353B6D@atlas.denx.de>
2007-06-18 11:04 ` Heiko Schocher [this message]
2007-06-18 13:51   ` [U-Boot-Users] FAT mbr on MMC or SD cards Joey Oravec
2007-06-13 15:54 Joey Oravec
2007-06-13 18:41 ` Wolfgang Denk
2007-06-13 20:59   ` Joey Oravec

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1182164674.15090.54.camel@Apollo \
    --to=hs@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox