[PATCH v1] doc: README.distro: Special case with Windows formatted disk
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
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