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

If someone wants to use shared (by installed OS) eMMC partition to
the Windows to boot from, it's not possible due to U-Boot limitations.

Describe this case and possible workaround.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 doc/README.distro | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

On Friday 17 January 2020 12:44:51 Andy Shevchenko wrote:
> If someone wants to use shared (by installed OS) eMMC partition to
> the Windows to boot from, it's not possible due to U-Boot limitations.
> 
> Describe this case and possible workaround.
> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
>  doc/README.distro | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/doc/README.distro b/doc/README.distro
> index ab6e6f4e74..807a82c910 100644
> --- a/doc/README.distro
> +++ b/doc/README.distro
> @@ -405,3 +405,23 @@ of the boot environment and are not guaranteed to exist or work in the same
>  way in future u-boot versions.  In particular the <device type>_boot
>  variables (e.g. mmc_boot, usb_boot) are a strictly internal implementation
>  detail and must not be used as a public interface.
> +
> +Using a eMMC partition that has been formatted as a disk by Windows 10
> +======================================================================
> +
> +Let's assume we have an (embedded) board with U-Boot and Linux OS
> +installed on eMMC. Linux OS shares one of the eMMC partitions as
> +a disk via USB Mass Storage protocol.
> +
> +It may be useful to utilize that disk to copy bootable files from
> +Windows machine to the board in case someone doesn't want to erase
> +stock installation on it.
> +
> +Unfortunately, Windows 10 doesn't provide knobs and always formats
> +that disk as a whole, meaning that it creates a partition table on it
> +with requested (FAT) partition. As a result U-Boot may not see any
> +files on it due to nesting partition tables.
> +
> +The workaround may be in formatting the partition under Linux OS,
> +setting up a network connection between Linux OS and Windows 10 and
> +use it to copy files to the partition.

There is a better way how to do it. You can format partition to FAT with
fake MBR table which reference to itself. Windows can correctly
recognize such disk because it has MBR table and do not care that
partition in MBR table starts at same offset as MBR table itself. And
FAT filesystem can be put on such partition because first sector (where
is stored MBR) is not used by FAT itself. So non-FAT data can be stored
there. Also Linux does not have any issue to access such partition
because filesystem starts at offset zero (where it should be).

FAT fs can be formatted with this fake MBR table by "mformat" tool which
should work also on Windows systems. "mformat" supports this feature for
a longer time but I do not remember how to activate it. Passing correct
arguments to "mformat" always took me lot of time.

Or alternatively it can be formatted by "mkfs.fat" tool with option
--mbr=y but support for this option is not in any released version of
"mkfs.fat" yet.

On Sunday, December 27, 2020, Pali Rohár <pali@kernel.org> wrote:

> On Friday 17 January 2020 12:44:51 Andy Shevchenko wrote:
> > If someone wants to use shared (by installed OS) eMMC partition to
> > the Windows to boot from, it's not possible due to U-Boot limitations.
> >
> > Describe this case and possible workaround.
> >
> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > ---
> >  doc/README.distro | 20 ++++++++++++++++++++
> >  1 file changed, 20 insertions(+)
> >
> > diff --git a/doc/README.distro b/doc/README.distro
> > index ab6e6f4e74..807a82c910 100644
> > --- a/doc/README.distro
> > +++ b/doc/README.distro
> > @@ -405,3 +405,23 @@ of the boot environment and are not guaranteed to
> exist or work in the same
> >  way in future u-boot versions.  In particular the <device type>_boot
> >  variables (e.g. mmc_boot, usb_boot) are a strictly internal
> implementation
> >  detail and must not be used as a public interface.
> > +
> > +Using a eMMC partition that has been formatted as a disk by Windows 10
> > +======================================================================
> > +
> > +Let's assume we have an (embedded) board with U-Boot and Linux OS
> > +installed on eMMC. Linux OS shares one of the eMMC partitions as
> > +a disk via USB Mass Storage protocol.
> > +
> > +It may be useful to utilize that disk to copy bootable files from
> > +Windows machine to the board in case someone doesn't want to erase
> > +stock installation on it.
> > +
> > +Unfortunately, Windows 10 doesn't provide knobs and always formats
> > +that disk as a whole, meaning that it creates a partition table on it
> > +with requested (FAT) partition. As a result U-Boot may not see any
> > +files on it due to nesting partition tables.
> > +
> > +The workaround may be in formatting the partition under Linux OS,
> > +setting up a network connection between Linux OS and Windows 10 and
> > +use it to copy files to the partition.
>
> There is a better way how to do it. You can format partition to FAT with
> fake MBR table which reference to itself. Windows can correctly
> recognize such disk because it has MBR table and do not care that
> partition in MBR table starts at same offset as MBR table itself. And
> FAT filesystem can be put on such partition because first sector (where
> is stored MBR) is not used by FAT itself. So non-FAT data can be stored
> there. Also Linux does not have any issue to access such partition
> because filesystem starts at offset zero (where it should be).
>
> FAT fs can be formatted with this fake MBR table by "mformat" tool which
> should work also on Windows systems. "mformat" supports this feature for
> a longer time but I do not remember how to activate it. Passing correct
> arguments to "mformat" always took me lot of time.
>
> Or alternatively it can be formatted by "mkfs.fat" tool with option
> --mbr=y but support for this option is not in any released version of
> "mkfs.fat"
>



While it’s a good idea, it’s not user friendly. The best option is to fix
U-Boot to recognize nested fat disks. But yeah, we may describe this in
U-Boot documentation at least.

On Sunday 27 December 2020 11:08:05 Andy Shevchenko wrote:
> On Sunday, December 27, 2020, Pali Rohár <pali@kernel.org> wrote:
> 
> > On Friday 17 January 2020 12:44:51 Andy Shevchenko wrote:
> > > If someone wants to use shared (by installed OS) eMMC partition to
> > > the Windows to boot from, it's not possible due to U-Boot limitations.
> > >
> > > Describe this case and possible workaround.
> > >
> > > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > > ---
> > >  doc/README.distro | 20 ++++++++++++++++++++
> > >  1 file changed, 20 insertions(+)
> > >
> > > diff --git a/doc/README.distro b/doc/README.distro
> > > index ab6e6f4e74..807a82c910 100644
> > > --- a/doc/README.distro
> > > +++ b/doc/README.distro
> > > @@ -405,3 +405,23 @@ of the boot environment and are not guaranteed to
> > exist or work in the same
> > >  way in future u-boot versions.  In particular the <device type>_boot
> > >  variables (e.g. mmc_boot, usb_boot) are a strictly internal
> > implementation
> > >  detail and must not be used as a public interface.
> > > +
> > > +Using a eMMC partition that has been formatted as a disk by Windows 10
> > > +======================================================================
> > > +
> > > +Let's assume we have an (embedded) board with U-Boot and Linux OS
> > > +installed on eMMC. Linux OS shares one of the eMMC partitions as
> > > +a disk via USB Mass Storage protocol.
> > > +
> > > +It may be useful to utilize that disk to copy bootable files from
> > > +Windows machine to the board in case someone doesn't want to erase
> > > +stock installation on it.
> > > +
> > > +Unfortunately, Windows 10 doesn't provide knobs and always formats
> > > +that disk as a whole, meaning that it creates a partition table on it
> > > +with requested (FAT) partition. As a result U-Boot may not see any
> > > +files on it due to nesting partition tables.
> > > +
> > > +The workaround may be in formatting the partition under Linux OS,
> > > +setting up a network connection between Linux OS and Windows 10 and
> > > +use it to copy files to the partition.
> >
> > There is a better way how to do it. You can format partition to FAT with
> > fake MBR table which reference to itself. Windows can correctly
> > recognize such disk because it has MBR table and do not care that
> > partition in MBR table starts at same offset as MBR table itself. And
> > FAT filesystem can be put on such partition because first sector (where
> > is stored MBR) is not used by FAT itself. So non-FAT data can be stored
> > there. Also Linux does not have any issue to access such partition
> > because filesystem starts at offset zero (where it should be).
> >
> > FAT fs can be formatted with this fake MBR table by "mformat" tool which
> > should work also on Windows systems. "mformat" supports this feature for
> > a longer time but I do not remember how to activate it. Passing correct
> > arguments to "mformat" always took me lot of time.
> >
> > Or alternatively it can be formatted by "mkfs.fat" tool with option
> > --mbr=y but support for this option is not in any released version of
> > "mkfs.fat"
> >
> 
> 
> 
> While it’s a good idea, it’s not user friendly. The best option is to fix
> U-Boot to recognize nested fat disks. But yeah, we may describe this in
> U-Boot documentation at least.

I do not think that it is a good idea to recognize disks with nested MBR
tables in u-boot. Neither linux support it. On linux you can hack it via
device mapper kpartx or maybe also partx. But it is not something which
is used by default or which is user friendly, as you need to do it every
time when going to access such disk.

My "solution" (or workaround or hack) is just to use non-standard /
different arguments at the time when formatting disk and after this
one-time operation, disk is accessible on all common systems without any
future hacks. I think this is more user friendly.

On Mon, Dec 28, 2020 at 06:50:39PM +0100, Pali Rohár wrote:
> On Sunday 27 December 2020 11:08:05 Andy Shevchenko wrote:
> > On Sunday, December 27, 2020, Pali Rohár <pali@kernel.org> wrote:
> > > On Friday 17 January 2020 12:44:51 Andy Shevchenko wrote:

...

> > > > +Using a eMMC partition that has been formatted as a disk by Windows 10
> > > > +======================================================================
> > > > +
> > > > +Let's assume we have an (embedded) board with U-Boot and Linux OS
> > > > +installed on eMMC. Linux OS shares one of the eMMC partitions as
> > > > +a disk via USB Mass Storage protocol.
> > > > +
> > > > +It may be useful to utilize that disk to copy bootable files from
> > > > +Windows machine to the board in case someone doesn't want to erase
> > > > +stock installation on it.
> > > > +
> > > > +Unfortunately, Windows 10 doesn't provide knobs and always formats
> > > > +that disk as a whole, meaning that it creates a partition table on it
> > > > +with requested (FAT) partition. As a result U-Boot may not see any
> > > > +files on it due to nesting partition tables.
> > > > +
> > > > +The workaround may be in formatting the partition under Linux OS,
> > > > +setting up a network connection between Linux OS and Windows 10 and
> > > > +use it to copy files to the partition.
> > >
> > > There is a better way how to do it. You can format partition to FAT with
> > > fake MBR table which reference to itself. Windows can correctly
> > > recognize such disk because it has MBR table and do not care that
> > > partition in MBR table starts at same offset as MBR table itself. And
> > > FAT filesystem can be put on such partition because first sector (where
> > > is stored MBR) is not used by FAT itself. So non-FAT data can be stored
> > > there. Also Linux does not have any issue to access such partition
> > > because filesystem starts at offset zero (where it should be).
> > >
> > > FAT fs can be formatted with this fake MBR table by "mformat" tool which
> > > should work also on Windows systems. "mformat" supports this feature for
> > > a longer time but I do not remember how to activate it. Passing correct
> > > arguments to "mformat" always took me lot of time.
> > >
> > > Or alternatively it can be formatted by "mkfs.fat" tool with option
> > > --mbr=y but support for this option is not in any released version of
> > > "mkfs.fat"


> > While it’s a good idea, it’s not user friendly. The best option is to fix
> > U-Boot to recognize nested fat disks. But yeah, we may describe this in
> > U-Boot documentation at least.
> 
> I do not think that it is a good idea to recognize disks with nested MBR
> tables in u-boot. Neither linux support it. On linux you can hack it via
> device mapper kpartx or maybe also partx.

On Linux you can use loop and offset, there is no hack needed.

> But it is not something which
> is used by default or which is user friendly, as you need to do it every
> time when going to access such disk.

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.

> My "solution" (or workaround or hack) is just to use non-standard /
> different arguments at the time when formatting disk and after this
> one-time operation, disk is accessible on all common systems without any
> future hacks. I think this is more user friendly.

As a compromise, but see above.

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:
> > On Sunday 27 December 2020 11:08:05 Andy Shevchenko wrote:
> > > On Sunday, December 27, 2020, Pali Rohár <pali@kernel.org> wrote:
> > > > On Friday 17 January 2020 12:44:51 Andy Shevchenko wrote:
> 
> ...
> 
> > > > > +Using a eMMC partition that has been formatted as a disk by Windows 10
> > > > > +======================================================================
> > > > > +
> > > > > +Let's assume we have an (embedded) board with U-Boot and Linux OS
> > > > > +installed on eMMC. Linux OS shares one of the eMMC partitions as
> > > > > +a disk via USB Mass Storage protocol.
> > > > > +
> > > > > +It may be useful to utilize that disk to copy bootable files from
> > > > > +Windows machine to the board in case someone doesn't want to erase
> > > > > +stock installation on it.
> > > > > +
> > > > > +Unfortunately, Windows 10 doesn't provide knobs and always formats
> > > > > +that disk as a whole, meaning that it creates a partition table on it
> > > > > +with requested (FAT) partition. As a result U-Boot may not see any
> > > > > +files on it due to nesting partition tables.
> > > > > +
> > > > > +The workaround may be in formatting the partition under Linux OS,
> > > > > +setting up a network connection between Linux OS and Windows 10 and
> > > > > +use it to copy files to the partition.
> > > >
> > > > There is a better way how to do it. You can format partition to FAT with
> > > > fake MBR table which reference to itself. Windows can correctly
> > > > recognize such disk because it has MBR table and do not care that
> > > > partition in MBR table starts at same offset as MBR table itself. And
> > > > FAT filesystem can be put on such partition because first sector (where
> > > > is stored MBR) is not used by FAT itself. So non-FAT data can be stored
> > > > there. Also Linux does not have any issue to access such partition
> > > > because filesystem starts at offset zero (where it should be).
> > > >
> > > > FAT fs can be formatted with this fake MBR table by "mformat" tool which
> > > > should work also on Windows systems. "mformat" supports this feature for
> > > > a longer time but I do not remember how to activate it. Passing correct
> > > > arguments to "mformat" always took me lot of time.
> > > >
> > > > Or alternatively it can be formatted by "mkfs.fat" tool with option
> > > > --mbr=y but support for this option is not in any released version of
> > > > "mkfs.fat"
> 
> 
> > > While it’s a good idea, it’s not user friendly. The best option is to fix
> > > U-Boot to recognize nested fat disks. But yeah, we may describe this in
> > > U-Boot documentation at least.
> > 
> > I do not think that it is a good idea to recognize disks with nested MBR
> > tables in u-boot. Neither linux support it. On linux you can hack it via
> > device mapper kpartx or maybe also partx.
> 
> On Linux you can use loop and offset, there is no hack needed.
> 
> > But it is not something which
> > is used by default or which is user friendly, as you need to do it every
> > time when going to access such disk.
> 
> 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!

On Fri, Jan 29, 2021 at 9:28 PM Tom Rini <trini@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.

On 1/29/21 10:05 PM, Andy Shevchenko wrote:
> On Fri, Jan 29, 2021 at 9:28 PM Tom Rini <trini@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

On Fri, Jan 29, 2021 at 11:39 PM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
> On 1/29/21 10:05 PM, Andy Shevchenko wrote:
> > On Fri, Jan 29, 2021 at 9:28 PM Tom Rini <trini@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

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@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

On 1/29/21 11:09 PM, Andy Shevchenko wrote:
> On Fri, Jan 29, 2021 at 11:39 PM Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>> On 1/29/21 10:05 PM, Andy Shevchenko wrote:
>>> On Fri, Jan 29, 2021 at 9:28 PM Tom Rini <trini@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