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 <[email protected]> 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
