diff mbox series

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

Message ID 20200117104451.62417-1-andriy.shevchenko@linux.intel.com
State New
Delegated to: Tom Rini
Headers show
Series [v1] doc: README.distro: Special case with Windows formatted disk | expand

Commit Message

Andy Shevchenko Jan. 17, 2020, 10:44 a.m. UTC
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(+)

Comments

Pali Rohár Dec. 27, 2020, 12:27 a.m. UTC | #1
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.
Andy Shevchenko Dec. 27, 2020, 9:08 a.m. UTC | #2
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.
Pali Rohár Dec. 28, 2020, 5:50 p.m. UTC | #3
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.
Andy Shevchenko Dec. 28, 2020, 6:27 p.m. UTC | #4
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.
diff mbox series

Patch

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.