[PATCH 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(+)
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.
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 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].
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
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
participants (5)
-
Andy Shevchenko -
Andy Shevchenko -
Heinrich Schuchardt -
Pali Rohár -
Tom Rini