[U-Boot] Cannot access a FAT filesystem in an El-Torito partition
The U-Boot FAT driver appears to manually check for the existence of an MS-DOS partition table, even when CONFIG_DOS_PARTITION is present and working.
As a result, it is not possible to use the FAT driver on an ISO9660 El-Torito boot volume, because it does not have a DOS MBR and does not pass the magic number check.
It looks like the code in the FAT driver to check DOS MBRs is just legacy code from before libpart existed, and I would like to remove it, except several board configs seem to set CONFIG_CMD_FAT but do not set CONFIG_DOS_PARTITION: include/configs/dbau1x00.h include/configs/mv88f6281gtw_ge.h include/configs/hymod.h include/configs/LANTEC.h include/configs/gth2.h include/configs/dreamplug.h include/configs/lacie_kw.h include/configs/dockstar.h include/configs/omap3_evm_common.h include/configs/guruplug.h include/configs/rd6281a.h include/configs/ep8260.h include/configs/sheevaplug.h
Can I just modify those board configs to set CONFIG_DOS_PARTITION and remove the duplicated FAT-specific partition-table probing code or is there something else I should do?
Cheers, Kyle Moffett
-- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/
On Dec 19, 2011, at 15:21, Kyle Moffett wrote:
The U-Boot FAT driver appears to manually check for the existence of an MS-DOS partition table, even when CONFIG_DOS_PARTITION is present and working.
As a result, it is not possible to use the FAT driver on an ISO9660 El-Torito boot volume, because it does not have a DOS MBR and does not pass the magic number check.
It looks like the code in the FAT driver to check DOS MBRs is just legacy code from before libpart existed, and I would like to remove it, except several board configs seem to set CONFIG_CMD_FAT but do not set CONFIG_DOS_PARTITION: include/configs/dbau1x00.h include/configs/mv88f6281gtw_ge.h include/configs/hymod.h include/configs/LANTEC.h include/configs/gth2.h include/configs/dreamplug.h include/configs/lacie_kw.h include/configs/dockstar.h include/configs/omap3_evm_common.h include/configs/guruplug.h include/configs/rd6281a.h include/configs/ep8260.h include/configs/sheevaplug.h
Nevermind, I just checked all of these and they do indirectly set CONFIG_DOS_PARTITION where necessary.
Can I just modify those board configs to set CONFIG_DOS_PARTITION and remove the duplicated FAT-specific partition-table probing code or is there something else I should do?
I will be submitting a patch shortly.
Cheers, Kyle Moffett
-- Curious about my work on the Debian powerpcspe port? I'm keeping a blog here: http://pureperl.blogspot.com/
Dear Kyle,
In message 4EDC0B2F-3D26-48A6-9CD9-0B40D6A01EA4@boeing.com you wrote:
The U-Boot FAT driver appears to manually check for the existence of an MS-DOS partition table, even when CONFIG_DOS_PARTITION is present and working.
As a result, it is not possible to use the FAT driver on an ISO9660 El-Torito boot volume, because it does not have a DOS MBR and does not pass the magic number check.
It looks like the code in the FAT driver to check DOS MBRs is just legacy code from before libpart existed, and I would like to remove it, except several board configs seem to set CONFIG_CMD_FAT but do not set CONFIG_DOS_PARTITION: include/configs/dbau1x00.h include/configs/mv88f6281gtw_ge.h include/configs/hymod.h include/configs/LANTEC.h include/configs/gth2.h include/configs/dreamplug.h include/configs/lacie_kw.h include/configs/dockstar.h include/configs/omap3_evm_common.h include/configs/guruplug.h include/configs/rd6281a.h include/configs/ep8260.h include/configs/sheevaplug.h
Some of these devices are well maintained, others are more or less dead and have long reached their (commercial, at least) EOL. It will probably be impossible to test on all of them.
Can I just modify those board configs to set CONFIG_DOS_PARTITION and remove the duplicated FAT-specific partition-table probing code or is there something else I should do?
The best you can do is probbaly 1) provide an easy to reproduce test case for the problem (for example including an image that can be put on a USB stick or an SDCard), and 2) submit a patch that implements your fix. Then at least the boards that are still alive can be tested.
Best regards,
Wolfgang Denk
participants (2)
-
Moffett, Kyle D -
Wolfgang Denk