[PATCH v1] doc: README.distro: Special case with Windows formatted disk

Pali Rohár pali at kernel.org
Fri Jan 29 23:53:16 CET 2021


On Friday 29 January 2021 22:39:01 Heinrich Schuchardt wrote:
> On 1/29/21 10:05 PM, Andy Shevchenko wrote:
> > On Fri, Jan 29, 2021 at 9:28 PM Tom Rini <trini at konsulko.com> wrote:
> > > On Mon, Dec 28, 2020 at 08:27:49PM +0200, Andy Shevchenko wrote:
> > > > On Mon, Dec 28, 2020 at 06:50:39PM +0100, Pali Rohár wrote:
> > 
> > ...
> > 
> > > > The case I got into has been achieved by very standard procedures. Hence it's
> > > > kinda default behaviour in some cases and should be handled accordingly. The
> > > > patch proposed here is to cover this in the U-Boot, because real fix has been
> > > > rejected by maintainer (probably I failed to explain that). But this is still
> > > > bug in U-Boot for such cases. And again, Linux has an offset option. I'm fine
> > > > if this can be added to the fat* commands in the U-Boot.
> > > 
> > > Sorry, what is the real fix that was rejected again?  Thanks!
> > 
> > I probably misspelled the state of the affairs. The direction (*) of
> > how to fix this had been rejected.
> > 
> > *) the idea is to fix fat support code to consider nested MBRs.
> > 
> 
> Hello Andy,
> 
> could you, please, provide an image created by Windows but not
> recognized by U-Boot. According to the thread the first 1 MiB should be
> enough to reproduce the problem. Maybe place it on gist.github.io.
> 
> This should give us the test case for correcting disk/part_dos.c.
> 
> Best regards
> 
> Heinrich

Hello again! Just a question, is not better to just properly (*) format
disk so it would be automatically supported by U-Boot, Windows and Linux
without need to patch any of these systems and without need to manually
specify mount offsets and other hacks?

(*) via mkfs.fat 4.2 or mformat


More information about the U-Boot mailing list