On 1/29/21 11:09 PM, Andy Shevchenko wrote:
On Fri, Jan 29, 2021 at 11:39 PM Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
On 1/29/21 10:05 PM, Andy Shevchenko wrote:
On Fri, Jan 29, 2021 at 9:28 PM Tom Rini <tr...@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.
I already shared this, it's still there [1].
[1]: https://gist.github.com/andy-shev/469aef8dfcd8f5605cb8992cf5958769
The gist contains 4 files:
image-file.gz
mac-nvme-0x2001-disk-image.bin
mmc-fat-part.gz
'Test FAT32 Image'
Which one exposes the problem?
I had no problem reading the directory of the images provided in the
gist using U-Boot:
=> host bind 0 /tmp/mmc-fat-part
=> ls host 0:0
0 file(s), 0 dir(s)
=> host bind 1 /tmp/image-file
=> ls host 0:1
System Volume Information/
23 New Text Document.txt
$RECYCLE.BIN/
1 file(s), 2 dir(s)
=> host bind 2 /tmp/mac-nvme-0x2001-disk-image.bin
=> ls host 2:1
9585536 vmlinuz.efi
2769508 initrd
boot/
EFI/
78 startup.nsh
3 file(s), 2 dir(s)
=>
$ sudo mount mmc-fat-part /mnt
$ find /mnt
/mnt
$
So Linux and U-Boot both don't see a file.
Looking at mmc-fat-part with a hexeditor shows that there is an *empty*
FAT16 partition starting at sector 0 and there once was a FAT32
partition starting at sector 2048.
If you create a new example image, please wipe the image with 0x00
beforehand. Please, provide an accompanying text describing what is in
the image.
$ fdisk image-file
Device Boot Start End Sectors Size Id Type
image-file1 2048 1574912 1572865 768M c W95 FAT32 (LBA)
$ sudo mount image-file /mnt -o offset=$((2048*512))
$ ls /mnt
It is strange that Linux can't see the files that U-Boot sees and which
seem to be present:
00510000 45 44 49 53 4F 4E 20 20 20 20 20 08 00 00 00 00 EDISON
.....
00510010 00 00 00 00 00 00 D8 B4 2D 50 00 00 00 00 00 00
........-P......
00510020 42 20 00 49 00 6E 00 66 00 6F 00 0F 00 72 72 00 B
.I.n.f.o...rr.
00510030 6D 00 61 00 74 00 69 00 6F 00 00 00 6E 00 00 00
m.a.t.i.o...n...
00510040 01 53 00 79 00 73 00 74 00 65 00 0F 00 72 6D 00
.S.y.s.t.e...rm.
00510050 20 00 56 00 6F 00 6C 00 75 00 00 00 6D 00 65 00
.V.o.l.u...m.e.
00510060 53 59 53 54 45 4D 7E 31 20 20 20 16 00 C0 D7 B4 SYSTEM~1
.....
00510070 2D 50 2D 50 00 00 D8 B4 2D 50 03 00 00 00 00 00
-P-P....-P......
00510080 42 6D 00 65 00 6E 00 74 00 2E 00 0F 00 9F 74 00
Bm.e.n.t......t.
00510090 78 00 74 00 00 00 FF FF FF FF 00 00 FF FF FF FF
x.t.............
005100A0 01 4E 00 65 00 77 00 20 00 54 00 0F 00 9F 65 00 .N.e.w.
.T....e.
005100B0 78 00 74 00 20 00 44 00 6F 00 00 00 63 00 75 00 x.t.
.D.o...c.u.
005100C0 4E 45 57 54 45 58 7E 31 54 58 54 20 00 AC E4 B4
NEWTEX~1TXT ....
005100D0 2D 50 2D 50 00 00 EF B4 2D 50 08 00 17 00 00 00
-P-P....-P......
005100E0 24 52 45 43 59 43 4C 45 42 49 4E 16 00 BF E4 B4
$RECYCLEBIN.....
005100F0 2D 50 2D 50 00 00 E5 B4 2D 50 06 00 00 00 00 00
-P-P....-P.....
Best regards
Heinrich
