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 <p...@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! -- Tom
signature.asc
Description: PGP signature
