November 2018 - U-Boot

[U-Boot] [PATCH v2] fw_setenv: avoid writing environment when nothing has changed
by Rasmus Villemoes 20 Nov '19

20 Nov '19

In the case where one deletes an already-non-existing variable, or sets a variable to the value it already has, there is no point in writing the environment back, thus reducing wear on the underlying storage device. In the case of redundant environments, if the two environments differ (e.g. because one is corrupt), make sure that any call of fw_setenv causes the two to become synchronized, even if the fw_setenv call does not change anything in the good copy. Signed-off-by: Rasmus Villemoes <rasmus.villemoes(a)prevas.dk> --- Add logic to ensure a corrupt copy gets replaced, even if fw_setenv wouldn't change anything in the good copy. tools/env/fw_env.c | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index a5d75958e1..66372dad55 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -110,6 +110,7 @@ struct environment { unsigned char *flags; char *data; enum flag_scheme flag_scheme; + int dirty; }; static struct environment environment = { @@ -508,6 +509,9 @@ int fw_env_flush(struct env_opts *opts) if (!opts) opts = &default_opts; + if (!environment.dirty) + return 0; + /* * Update CRC */ @@ -553,7 +557,8 @@ int fw_env_write(char *name, char *value) deleting = (oldval && !(value && strlen(value))); creating = (!oldval && (value && strlen(value))); - overwriting = (oldval && (value && strlen(value))); + overwriting = (oldval && (value && strlen(value) && + strcmp(oldval, value))); /* check for permission */ if (deleting) { @@ -593,6 +598,7 @@ int fw_env_write(char *name, char *value) /* Nothing to do */ return 0; + environment.dirty = 1; if (deleting || overwriting) { if (*++nxt == '\0') { *env = '\0'; @@ -1441,6 +1447,7 @@ int fw_env_open(struct env_opts *opts) "Warning: Bad CRC, using default environment\n"); memcpy(environment.data, default_environment, sizeof(default_environment)); + environment.dirty = 1; } } else { flag0 = *environment.flags; @@ -1494,6 +1501,16 @@ int fw_env_open(struct env_opts *opts) crc1_ok = (crc1 == redundant->crc); flag1 = redundant->flags; + /* + * environment.data still points to ((struct + * env_image_redundant *)addr0)->data. If the two + * environments differ, or one has bad crc, force a + * write-out by marking the environment dirty. + */ + if (memcmp(environment.data, redundant->data, ENV_SIZE) || + !crc0_ok || !crc1_ok) + environment.dirty = 1; + if (crc0_ok && !crc1_ok) { dev_current = 0; } else if (!crc0_ok && crc1_ok) { @@ -1503,6 +1520,7 @@ int fw_env_open(struct env_opts *opts) "Warning: Bad CRC, using default environment\n"); memcpy(environment.data, default_environment, sizeof(default_environment)); + environment.dirty = 1; dev_current = 0; } else { switch (environment.flag_scheme) { -- 2.16.4

2 2

[U-Boot] [PATCH 0/1] board: arm: Add support for Broadcom BCM7445D0
by Thomas Fitzsimmons 28 Sep '19

28 Sep '19

Hi, This patch adds support for loading U-Boot on the Broadcom 7445D0 SoC, as a third stage bootloader loaded by Broadcom's BOLT bootloader. While this is only a partial port, it does enable some of U-Boot's flexibility on this SoC, functionality beyond what BOLT provides. Specifically, it brings: - ext4 file system traversal - support for loading FIT images - advanced scripting - support for FIT-provided DTBs instead of relying on the BOLT-provided DTB My team at Cisco is using a customized version of this port in production. The same approach may work on other BCM7xxx boards, with some configuration adjustments and memory layout experimentation. Stefan Roese reviewed (off-list) some early revisions of these changes. This patch is my attempt to rebase on the current U-Boot master branch. I'm submitting it in case there is interest in including this port in upstream U-Boot. Thomas Thomas Fitzsimmons (1): board: arm: Add support for Broadcom BCM7445D0 arch/arm/Kconfig | 12 + arch/arm/cpu/armv7/Makefile | 1 + arch/arm/cpu/armv7/bcm7445d0/Makefile | 11 + arch/arm/cpu/armv7/bcm7445d0/lowlevel_init.S | 24 ++ arch/arm/lib/crt0.S | 2 + arch/arm/mach-bcm7445d0/include/mach/gpio.h | 12 + arch/arm/mach-bcm7445d0/include/mach/hardware.h | 12 + arch/arm/mach-bcm7445d0/include/mach/sdhci.h | 15 + board/broadcom/bcm7445d0/Kconfig | 132 ++++++++ board/broadcom/bcm7445d0/Makefile | 11 + board/broadcom/bcm7445d0/bcm7445d0.c | 147 ++++++++ common/fdt_support.c | 9 +- common/image-fit.c | 2 + configs/bcm7445d0_defconfig | 21 ++ drivers/mmc/Makefile | 1 + drivers/mmc/bcmstb_sdhci.c | 59 ++++ drivers/spi/Kconfig | 7 + drivers/spi/Makefile | 1 + drivers/spi/bcmstb_spi.c | 428 ++++++++++++++++++++++++ dts/Kconfig | 6 + include/configs/bcm7445d0.h | 227 +++++++++++++ include/configs/bcmstb.h | 57 ++++ lib/fdtdec.c | 8 + 23 files changed, 1204 insertions(+), 1 deletion(-) create mode 100644 arch/arm/cpu/armv7/bcm7445d0/Makefile create mode 100644 arch/arm/cpu/armv7/bcm7445d0/lowlevel_init.S create mode 100644 arch/arm/mach-bcm7445d0/include/mach/gpio.h create mode 100644 arch/arm/mach-bcm7445d0/include/mach/hardware.h create mode 100644 arch/arm/mach-bcm7445d0/include/mach/sdhci.h create mode 100644 board/broadcom/bcm7445d0/Kconfig create mode 100644 board/broadcom/bcm7445d0/Makefile create mode 100644 board/broadcom/bcm7445d0/bcm7445d0.c create mode 100644 configs/bcm7445d0_defconfig create mode 100644 drivers/mmc/bcmstb_sdhci.c create mode 100644 drivers/spi/bcmstb_spi.c create mode 100644 include/configs/bcm7445d0.h create mode 100644 include/configs/bcmstb.h -- 1.8.3.1

6 36

[U-Boot] [usb dwc3] xHCI driver -- a hint needed.
by Yuri Frolov 11 Sep '19

11 Sep '19

Hi, I've been trying to bring up a dwc3 usb controller included in 32-bit MIPS chip. Usb is the one port usb2.0 host module, compliant with xHCI Revision 1.0, UTMI+ Low Pin interface (ULPI) Revision 1.1 and AMBA AXI Protocol specification. g_snpsid register reports 0x5533290a revision. It's verified, that linux kernel support is ok, usb is fully functional. axi { <...> usb@1F04D050 { compatible = "be,baikal-dwc3"; reg = <0x1f04d050 0x4>; interrupts = <0x0 0x45 0x4>; #address-cells = <0x1>; #size-cells = <0x1>; clocks = <0xf 0x0>; clock-names = "usb"; ranges; status = "okay"; dwc3@1F100000 { compatible = "snps,dwc3", "synopsys,dwc3", "generic-xhci"; reg = <0x1f100000 0x10000>; interrupts = <0x0 0x44 0x4>; dr_mode = "host"; tx-fifo-resize; maximum-speed = "high-speed"; }; }; }; whereas in u-boot 'usb start' fails on hub initialization (as I can see): Any ideas why this could happen?.. Any direction where to look at? Any suggestions will be greatly appreciated. # usb start (Re)start USB... USB0: dwc3_reg->g_snpsid: 0x5533290a Register 1000140 NbrPorts 1 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... New Device 0 set address 1 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x9 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x1F get_conf_no 0 Result 25, wLength 31 if 0, ep 0 ##EP epmaxpacketin[1] = 8 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=1, Product=2, SerialNumber=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF USB device number 1 default language ID 0x409 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409 length 0xFF Manufacturer U-Boot Product XHCI Host Controller SerialNumber USB hub found usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length 0xC 1 ports detected ganged power switching standalone hub individual port over-current protection TT requires at most 8 FS bit times (666 ns) power on to power good time: 20ms hub controller current requirement: 0mA port 1 is removable usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 get_hub_status returned status 1, change 801 local power source is lost (inactive) no over-current condition exists enabling power on all ports usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 port 1 returns 0 devnum=1 poweron: query_delay=100 connect_timeout=1100 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 Port 1 Status 101 Change 1 devnum=1 port=1: USB dev found usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 101, change 1, 12 Mb/s usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x1 length 0x0 usb_hub_port_reset: resetting port 1... usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 111, change 0, 12 Mb/s STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 portstatus 503, change 10, 480 Mb/s STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x0 New Device 1 XHCI timeout on event type 33... cannot recover. BUG: failure at drivers/usb/host/xhci-ring.c:474/xhci_wait_for_event()! BUG! Reset CPU by CPC Here is the drivers/usb/host/xhci-baikal.c: #include <common.h> #include <usb.h> #include <linux/errno.h> #include <linux/compat.h> #include <linux/usb/dwc3.h> #include <linux/usb/xhci-omap.h> #include "xhci.h" /* Declare global data pointer */ DECLARE_GLOBAL_DATA_PTR; struct baikal_xhci { struct xhci_hccr *hcd; struct dwc3 *dwc3_reg; }; static struct baikal_xhci baikal; int __attribute__((weak)) board_usb_init(int index, enum usb_init_type init); static int baikal_xhci_core_init(struct baikal_xhci *baikal) { int ret = 0; ret = dwc3_core_init(baikal->dwc3_reg); if (ret) { debug("%s:failed to initialize core\n", __func__); return ret; } /* We are hard-coding DWC3 core to Host Mode */ dwc3_set_mode(baikal->dwc3_reg, DWC3_GCTL_PRTCAP_HOST); return ret; } static void baikal_xhci_core_exit(struct baikal_xhci *baikal) { } int xhci_hcd_init(int index, struct xhci_hccr **hccr, struct xhci_hcor **hcor) { struct baikal_xhci *ctx = &baikal; int ret = 0; ctx->hcd = (struct xhci_hccr *)CONFIG_USB_XHCI_BAIKAL_BASE; ctx->dwc3_reg = (struct dwc3 *)((char *)(ctx->hcd) + DWC3_REG_OFFSET); ret = board_usb_init(index, USB_INIT_HOST); if (ret != 0) { puts("Failed to initialize board for USB\n"); return ret; } ret = baikal_xhci_core_init(ctx); if (ret < 0) { puts("Failed to initialize xhci\n"); return ret; } *hccr = (struct xhci_hccr *)(CONFIG_USB_XHCI_BAIKAL_BASE); *hcor = (struct xhci_hcor *)((uint32_t) *hccr + HC_LENGTH(xhci_readl(&(*hccr)->cr_capbase))); debug("baikal-xhci: init hccr %x and hcor %x hc_length %d\n", (uint32_t)*hccr, (uint32_t)*hcor, (uint32_t)HC_LENGTH(xhci_readl(&(*hccr)->cr_capbase))); return ret; } void xhci_hcd_stop(int index) { } TIA, Yuri

4 6

[U-Boot] [PATCH 2/2] efi_loader: set the dhcp ack received flag
by Patrick Wildt 06 Aug '19

06 Aug '19

The PXE object contains a flag that specifies whether or not a DHCP ACK has been received. This can be used by EFI Applications to find out whether or not it is worth to read the DHCP information from our object. Signed-off-by: Patrick Wildt <patrick(a)blueri.se> --- lib/efi_loader/efi_net.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/efi_loader/efi_net.c b/lib/efi_loader/efi_net.c index 8c5d5b492c..0b9c7b9345 100644 --- a/lib/efi_loader/efi_net.c +++ b/lib/efi_loader/efi_net.c @@ -332,8 +332,10 @@ int efi_net_register(void) netobj->net_mode.max_packet_size = PKTSIZE; netobj->pxe.mode = &netobj->pxe_mode; - if (dhcp_ack) + if (dhcp_ack) { netobj->pxe_mode.dhcp_ack = *dhcp_ack; + netobj->pxe_mode.dhcp_ack_received = 1; + } /* * Create WaitForPacket event. -- 2.14.3 (Apple Git-98)

5 19

[U-Boot] [PATCH 0/10] x86: Add generic VESA video driver
by Simon Glass 01 Aug '19

01 Aug '19

This series introduces a generic VESA video driver and adjusts the generic PCI ROM support to support it. It also fixes up some problems which prevent this from working on PowerPC at present. It is now possible to use VESA graphics: - On PowerPC, using the x86 emulator - On x86, using either the x86 emulator or native code execution As it turns out, on the only platform I have tested (link), the x86 emulator is only slightly slower that native code execution (200ms difference). Still, we may as well leave this feature in there. VGA ROMs are a very old technology but they are still used by modern platforms, including at least link and some Atom designs. Simon Glass (10): bios_emulator: Fix an #ifdef typo in the header file x86: Correct endianness isues in pci_rom x86: Support ROMs on other archs bios_emulator: Don't display error when emulator terminates bios_emulator: Add some VESA interface debugging x86: pci: Don't stop when we get a vendor/device mismatch x86: Add a VESA video driver x86: Drop the x86_fb driver x86: Access the VGA ROM when needed RFC: Test code for glacier PCI video support arch/x86/include/asm/u-boot-x86.h | 2 + drivers/bios_emulator/atibios.c | 161 +++++++++++++++++++++++---- drivers/bios_emulator/include/x86emu/debug.h | 2 +- drivers/bios_emulator/x86emu/ops.c | 2 +- drivers/pci/pci_auto.c | 28 ++++- drivers/pci/pci_rom.c | 40 ++++--- drivers/video/Makefile | 2 +- drivers/video/vesa_fb.c | 64 +++++++++++ drivers/video/x86_fb.c | 38 ------- include/configs/canyonlands.h | 31 ++++++ include/configs/chromebook_link.h | 2 +- include/pci.h | 9 ++ include/pci_rom.h | 1 - include/vbe.h | 9 +- 14 files changed, 312 insertions(+), 79 deletions(-) create mode 100644 drivers/video/vesa_fb.c delete mode 100644 drivers/video/x86_fb.c -- 2.2.0.rc0.207.ga3a616c

3 42

[U-Boot] [RFC] Reserve ATF memory on Marvell Armdada 3700/7K/8K
by Mark Kettenis 13 Jun '19

13 Jun '19

Currently U-Boot doesn't make any effort to reserve the memory used by ARM Trusted Firmware on these platforms. The result is that the memory is listed as available in the EFI memory map. And as soon as a loaded kernel tries to use this memory things explode. I've seen this with the OpenBSD kernel. But I totally expect a Linux kernel to suffer the same fate. I'm currently using the diff below, but it is not entirely clear to me if arch_early_init_r() is the appropriate place to do this. I'm also wondering whether the block should also be marked as reserved in the FDT using fdt_add_mem_rsv(). If the latter is required this probably needs to be done by ft_board_setup() or ft_system_setup(). The address and size of the region have been taken from Marvell's ATF fork at https://github.com/MarvellEmbeddedProcessors/atf-marvell The memory layout is defined in plat/marvell/a8k/common/include/platform_def.h where there are lots of defines and a diagram that attempt to describe the memory. It is not entirely obvious to me what part needs to be reserved. But 0x0400000-0x04200000 works. diff --git a/arch/arm/mach-mvebu/arm64-common.c b/arch/arm/mach-mvebu/arm64-common.c index 3c84043a2c..895cd2852f 100644 --- a/arch/arm/mach-mvebu/arm64-common.c +++ b/arch/arm/mach-mvebu/arm64-common.c @@ -95,5 +95,11 @@ int arch_early_init_r(void) pci_init(); #endif +#ifdef CONFIG_EFI_LOADER + /* Reserve trusted SRAM section */ + efi_add_memory_map(0x04000000, 0x00200000 >> EFI_PAGE_SHIFT, + EFI_RESERVED_MEMORY_TYPE, false); +#endif + return 0; }

7 11

[U-Boot] [PATCH v2 00/10] Various fixes and improvements
by Simon Glass 22 May '19

22 May '19

This series collects together a large number of small patches that I have been fiddling with for a while. At lot of them relate to SPL and TPL and updating Chromium OS verified boot to work on U-Boot. Unfortunately one patch (RTC) in the original series had a subtle failure which requires a bit of fiddling to fix. This v2 series includes this. Changes in v2: - Rebase to master - Correct definition of log() when logging is disabled - Leave the misc uclass alone since it stops sandbox_spl working - Drop patches previously applied - Add new patches to support the RTC change Simon Glass (10): malloc_simple: Add logging of allocations spl: misc: Allow misc drivers in SPL and TPL power: pmic: Correct debug/error output test: Add a 'make qcheck' target for quicker testing dm: core: Export uclass_find_device_by_phandle() dm: core: Add a few more specific child-finding functions dm: core: Put UCLASS_SIMPLE_BUS in order dm: sandbox: i2c: Add a new 'emulation parent' uclass dm: sandbox: i2c: Use new emulator parent uclass rtc: Allow child drivers Makefile | 6 ++- arch/sandbox/dts/sandbox.dts | 25 ++++++--- arch/sandbox/dts/sandbox_pmic.dtsi | 71 ++++++++++++------------- arch/sandbox/dts/test.dts | 30 +++++++---- common/malloc_simple.c | 58 +++++++++++++-------- drivers/core/device.c | 34 ++++++++++++ drivers/core/uclass.c | 6 +-- drivers/i2c/i2c-emul-uclass.c | 77 ++++++++++++++++++++++++++++ drivers/i2c/sandbox_i2c.c | 20 +------- drivers/misc/Kconfig | 72 ++++++++++++++++++++++++++ drivers/misc/Makefile | 8 +-- drivers/power/pmic/act8846.c | 2 +- drivers/power/pmic/as3722.c | 14 ++--- drivers/power/pmic/as3722_gpio.c | 11 ++-- drivers/power/pmic/i2c_pmic_emul.c | 2 +- drivers/power/pmic/lp873x.c | 6 +-- drivers/power/pmic/lp87565.c | 6 +-- drivers/power/pmic/max77686.c | 8 +-- drivers/power/pmic/max8997.c | 4 +- drivers/power/pmic/max8998.c | 4 +- drivers/power/pmic/mc34708.c | 4 +- drivers/power/pmic/palmas.c | 8 +-- drivers/power/pmic/pfuze100.c | 6 +-- drivers/power/pmic/rk8xx.c | 6 +-- drivers/power/pmic/rn5t567.c | 4 +- drivers/power/pmic/s2mps11.c | 8 +-- drivers/power/pmic/s5m8767.c | 6 +-- drivers/power/pmic/sandbox.c | 4 +- drivers/power/pmic/stpmu1.c | 2 +- drivers/power/pmic/tps65090.c | 8 +-- drivers/rtc/rtc-uclass.c | 1 + include/dm/device.h | 25 +++++++++ include/dm/uclass-id.h | 3 +- include/dm/uclass-internal.h | 17 ++++++ include/i2c.h | 21 ++++++++ include/log.h | 2 +- include/malloc.h | 1 + test/README | 6 ++- test/dm/i2c.c | 2 +- test/dm/rtc.c | 9 ++-- test/dm/test-fdt.c | 47 +++++++++++++++++ test/py/tests/test_fs/test_basic.py | 1 + test/py/tests/test_fs/test_ext.py | 1 + test/py/tests/test_fs/test_mkdir.py | 1 + test/py/tests/test_fs/test_unlink.py | 1 + test/run | 10 +++- 46 files changed, 502 insertions(+), 166 deletions(-) -- 2.19.1.1215.g8438c0b245-goog

4 24

[U-Boot] [PATCH V3 01/10] disk: support host devices in dev_print()
by Stephen Warren 18 May '19

18 May '19

Add a case statement for IF_TYPE_HOST in dev_print() so that it prints the device type rather than the "device type unknown" message. Signed-off-by: Stephen Warren <swarren(a)wwwdotorg.org> --- disk/part.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/disk/part.c b/disk/part.c index 43485c9148b0..4e72257434b6 100644 --- a/disk/part.c +++ b/disk/part.c @@ -179,6 +179,9 @@ void dev_print (block_dev_desc_t *dev_desc) case IF_TYPE_DOC: puts("device type DOC\n"); return; + case IF_TYPE_HOST: + puts("host device\n"); + break; case IF_TYPE_UNKNOWN: puts("device type unknown\n"); return; -- 1.9.1

2 13

[U-Boot] [PATCH 1/2] mtd: fix mtd_oobavail() incoherent returned value
by Miquel Raynal 12 Apr '19

12 Apr '19

mtd_oobavail() returns either mtd->oovabail or mtd->oobsize. Both values are unsigned 32-bit entities, so there is no reason to pretend returning a signed one. Signed-off-by: Miquel Raynal <miquel.raynal(a)bootlin.com> --- include/linux/mtd/mtd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/linux/mtd/mtd.h b/include/linux/mtd/mtd.h index 68e5915324..0525cfd27c 100644 --- a/include/linux/mtd/mtd.h +++ b/include/linux/mtd/mtd.h @@ -390,7 +390,7 @@ static inline void mtd_set_ooblayout(struct mtd_info *mtd, mtd->ooblayout = ooblayout; } -static inline int mtd_oobavail(struct mtd_info *mtd, struct mtd_oob_ops *ops) +static inline u32 mtd_oobavail(struct mtd_info *mtd, struct mtd_oob_ops *ops) { return ops->mode == MTD_OPS_AUTO_OOB ? mtd->oobavail : mtd->oobsize; } -- 2.17.1

3 6

[U-Boot] [PATCH] fs: fat: fix reading non-cluster-aligned root directory
by Anssi Hannula 10 Apr '19

10 Apr '19

FAT16 root directory might not start at a cluster boundary (though it always ends on one). However, next_dent() always starts reading the directory at the beginning of the cluster, causing no files to be found (at least if the beginning of the cluster contains zeroes). Fix that by skipping to the actual start of the root directory in such a case. This is a relatively common case as at least the filesystem formatter on Win7 seems to create such filesystems by default on 2GB USB sticks (cluster size 64 sectors, rootdir size 32 sectors). dosfstools mkfs.vfat does not seem to create such filesystems. Signed-off-by: Anssi Hannula <anssi.hannula(a)bitwise.fi> --- fs/fat/fat.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/fs/fat/fat.c b/fs/fat/fat.c index b08949d370..4a0d4bb8bc 100644 --- a/fs/fat/fat.c +++ b/fs/fat/fat.c @@ -782,6 +782,20 @@ static dir_entry *next_dent(fat_itr *itr) itr->remaining = nbytes / sizeof(dir_entry) - 1; itr->dent = dent; + + if (itr->fsdata->fatsize != 32 && + itr->clust == itr->fsdata->root_cluster) { + /* rootdir might not start at cluster boundary */ + u32 sect_offset = itr->fsdata->rootdir_sect - + clust_to_sect(itr->fsdata, + itr->fsdata->root_cluster); + u32 dirent_offset = itr->fsdata->sect_size / + sizeof(dir_entry) * sect_offset; + + itr->remaining -= dirent_offset; + itr->dent += dirent_offset; + } + } else { itr->remaining--; itr->dent++; -- 2.17.1

3 4