According to the UEFI Spec (Table 16, section 5.2.3 of the version 2.4 Errata B), the protective MBR partition record size must be set to the size of the disk minus one, in LBAs. However, the current code was setting the size as the total number of LBAs on the disk, resulting in an off-by-one error. This confused the AM335x ROM code, and will probably confuse other tools as well. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Implement a feature to allow fastboot to write the downloaded image to the space reserved for the Protective MBR and the Primary GUID Partition Table. Additionally, prepare and write the Backup GUID Partition Table. Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2]
Signed-off-by: Steve Rae <srae@broadcom.com> Tested-by: Lukasz Majewski <l.majewski@samsung.com> [Test HW: Exynos4412 - Trats2]
Now that we have inttypes.h, use it in a few more places to avoid compiler warnings on sandbox when building on 64-bit machines. Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Jeroen Hofstee <jeroen@myspectrum.nl>
Cleanup disk/part.c Signed-off-by: Pavel Machek <pavel@denx.de>
Whitespace cleanups. Signed-off-by: Pavel Machek <pavel@denx.de>
Commit 95fac6ab4589 "sandbox: Use os functions to read host device tree" removed the ability for get_device_and_partition() to handle the "host" device type, and redirect accesses to it to the host filesystem. This broke some unit tests that use this feature. So, revert that change. The code added back by this patch is slightly different to pacify checkpatch. However, we're then left with "host" being both: - A pseudo device that accesses the hosts real filesystem. - An emulated block device, which accesses "sectors" inside a file stored on the host. In order to resolve this discrepancy, rename the pseudo device from host to hostfs, and adjust the unit-tests for this change. The "help sb" output is modified to reflect this rename, and state where the host and hostfs devices should be used. Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Josh Wu <josh.wu@atmel.com> Acked-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
Currently, get_device()/get_dev_hwpart() for MMC devices does not select an explicit HW partition unless the user explicitly requests one, i.e. by requesting device "mmc 0.0" rather than just "mmc 0". I think it makes more sense if the default is to select HW partition 0 (main data area) if the user didn't request a specific partition. Otherwise, the following happens, which feels wrong: Select HW partition 1 (boot0): mmc dev 0 1 Attempts to access SW partition 1 on HW partition 1 (boot0), rather than SW partition 1 on HW partition 0 (main data area): ls mmc 0:1 / With this patch, the second command above re-selects the main data area. Many device types don't support HW partitions at all, so if HW partition 0 is selected (either explicitly or as the default) and there's no select_hwpart function, we simply skip attempting to select a HW partition. Some MMC devices (i.e. SD cards) don't support HW partitions. However, this patch still works, since mmc_start_init() sets the current partition number to 0, and mmc_select_hwpart() succeeds if the requested partition is already selected. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Bug: SDCard with a messed up partition but still has a FAT signature intact is readable in Linux but unreadable in uboot with 'fatls'. Fix: When partition info checking fails, there is no checking for a FAT signature (DOS_PBR) which will fail 'fatls'. FAT signature checking is done when no valid partition is found in partition table. If FAT signature is found, the disk will be read as PBR and continue processing. Signed-off-by: Darwin Dingel <darwin.dingel@alliedtelesis.co.nz>