1. 23 Jan, 2020 1 commit
  2. 02 Dec, 2019 1 commit
  3. 31 Oct, 2019 1 commit
    • Heinrich Schuchardt's avatar
      disk: part_dos: correctly detect DOS PBR · 34856b0f
      Heinrich Schuchardt authored
      The signature 0x55 0xAA in bytes 510 and 511 of the first sector can either
      indicate a DOS partition table of the first sector of a FAT file system.
      
      The current code tries to check if the partition table is valid by looking
      at the boot indicator of the partition entries. But first of all it does
      not count from 0 to 3 but only from 0 to 2. And second it misses to
      increment the pointer for the partition entry.
      
      If it is a FAT file system can be discovered by looking for the text 'FAT'
      at offset 0x36 or 'FAT32' at offset 0x52. In a DOS PBR there are no
      partition entries, so those bytes are undefined. Don't require the byte at
      offset 0x1BE to differ from 0x00 and 0x80.
      
      With the patch the logic is changed as follows:
      
      If the partition table has either an invalid boot flag for any partition or
      has no partition at all, check if the first sector is a DOS PBR by looking
      at the FAT* signature.
      Signed-off-by: Heinrich Schuchardt's avatarHeinrich Schuchardt <xypron.glpk@gmx.de>
      34856b0f
  4. 19 Sep, 2019 1 commit
  5. 23 Aug, 2019 2 commits
  6. 11 Aug, 2019 1 commit
  7. 24 Jul, 2019 1 commit
  8. 18 Jul, 2019 1 commit
  9. 16 Jul, 2019 1 commit
    • Heinrich Schuchardt's avatar
      disk: efi: avoid unaligned pointer error · 06e921b1
      Heinrich Schuchardt authored
      When building with GCC 9.1 an error occurs:
      
      disk/part_efi.c: In function ‘gpt_verify_partitions’:
      disk/part_efi.c:737:49: error: taking address of packed member of
      ‘struct _gpt_entry’ may result in an unaligned pointer value
      [-Werror=address-of-packed-member]
        737 |   gpt_convert_efi_name_to_char(efi_str, gpt_e[i].partition_name,
            |                                         ~~~~~~~~^~~~~~~~~~~~~~~
      cc1: all warnings being treated as errors
      make[1]: *** [scripts/Makefile.build:279: disk/part_efi.o] Error 1
      make: *** [Makefile:1594: disk] Error 2
      
      Adjust gpt_convert_efi_name_to_char() to accept unaligned strings.
      Reported-by: default avatarRamon Fried <rfried.dev@gmail.com>
      Signed-off-by: Heinrich Schuchardt's avatarHeinrich Schuchardt <xypron.glpk@gmx.de>
      06e921b1
  10. 06 Jul, 2019 1 commit
  11. 21 Jun, 2019 1 commit
    • Robert Hancock's avatar
      disk: part: Don't skip partition init · 4edfabd9
      Robert Hancock authored
      blk_get_device_by_str was skipping part_init when hw partition 0 was
      selected because it is the default. However, this caused issues when
      switching to a non-zero partition and then back to partition zero, as
      stale data from the wrong partition was returned.
      
      Remove this optimization and call part_init regardless of the selected
      partition.
      Signed-off-by: default avatarRobert Hancock <hancock@sedsystems.ca>
      4edfabd9
  12. 14 Jun, 2019 1 commit
  13. 02 May, 2019 2 commits
    • Eugeniu Rosca's avatar
      disk: efi: Fix memory leak on 'gpt verify' · 716f919d
      Eugeniu Rosca authored
      Below is what happens on R-Car H3ULCB-KF using clean U-Boot
      v2019.04-00810-g6aebc0d1 and r8a7795_ulcb_defconfig:
      
       => ### interrupt autoboot
       => gpt verify mmc 1
       No partition list provided - only basic check
       Verify GPT: success!
       => ### keep calling 'gpt verify mmc 1'
       => ### on 58th call, we are out of memory:
       => gpt verify mmc 1
       alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
       GPT: Failed to allocate memory for PTE
       gpt_verify_headers: *** ERROR: Invalid Backup GPT ***
       Verify GPT: error!
      
      This is caused by calling is_gpt_valid() twice (hence allocating pte
      also twice via alloc_read_gpt_entries()) while freeing pte only _once_
      in the caller of gpt_verify_headers(). Fix that by freeing the pte
      allocated and populated for primary GPT _before_ allocating and
      populating the pte for backup GPT. The latter will be freed by the
      caller of gpt_verify_headers().
      
      With the fix applied, the reproduction scenario [1-2] has been run
      hundreds of times in a loop w/o running into OOM.
      
      [1] gpt verify mmc 1
      [2] gpt verify mmc 1 $partitions
      
      Fixes: cef68bf9 ("gpt: part: Definition and declaration of GPT verification functions")
      Signed-off-by: default avatarEugeniu Rosca <erosca@de.adit-jv.com>
      Reviewed-by: Heinrich Schuchardt's avatarHeinrich Schuchardt <xypron.glpk@gmx.de>
      716f919d
    • Eugeniu Rosca's avatar
      disk: efi: Fix memory leak on 'gpt guid' · 1cfe9694
      Eugeniu Rosca authored
      Below is what happens on R-Car H3ULCB-KF using clean U-Boot
      v2019.04-00810-g6aebc0d1 and r8a7795_ulcb_defconfig:
      
       => ### interrupt autoboot
       => gpt guid mmc 1
       21200400-0804-0146-9dcc-a8c51255994f
       success!
       => ### keep calling 'gpt guid mmc 1'
       => ### on 59th call, we are out of memory:
       => gpt guid mmc 1
       alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
       GPT: Failed to allocate memory for PTE
       get_disk_guid: *** ERROR: Invalid GPT ***
       alloc_read_gpt_entries: ERROR: Can't allocate 0X4000 bytes for GPT Entries
       GPT: Failed to allocate memory for PTE
       get_disk_guid: *** ERROR: Invalid Backup GPT ***
       error!
      
      After some inspection, it looks like get_disk_guid(), added via v2017.09
      commit 73d6d18b ("GPT: add accessor function for disk GUID"),
      unlike other callers of is_gpt_valid(), doesn't free the memory pointed
      out by 'gpt_entry *gpt_pte'. The latter is allocated by is_gpt_valid()
      via alloc_read_gpt_entries().
      
      With the fix applied, the reproduction scenario has been run hundreds
      of times ('while true; do gpt guid mmc 1; done') w/o running into OOM.
      
      Fixes: 73d6d18b ("GPT: add accessor function for disk GUID")
      Signed-off-by: default avatarEugeniu Rosca <erosca@de.adit-jv.com>
      Reviewed-by: Heinrich Schuchardt's avatarHeinrich Schuchardt <xypron.glpk@gmx.de>
      1cfe9694
  14. 26 Apr, 2019 1 commit
  15. 18 Jan, 2019 1 commit
  16. 14 Nov, 2018 1 commit
  17. 09 Oct, 2018 1 commit
  18. 11 Sep, 2018 1 commit
  19. 10 Aug, 2018 1 commit
  20. 14 Jun, 2018 1 commit
    • Heinrich Schuchardt's avatar
      efi_loader: avoid initializer element is not constant · 44ab2d32
      Heinrich Schuchardt authored
      When building with -pedantic the current definition of EFI_GUID() causes
      an error 'initializer element is not constant'.
      
      Currently EFI_GUID() is used both as an anonymous constant and as an
      intializer. A conversion to efi_guid_t is not allowable when using
      EFI_GUID() as an initializer. But it is needed when using it as an
      anonymous constant.
      
      We should not use EFI_GUID() for anything but an initializer. So let's
      introduce a variable where needed and remove the conversion.
      Signed-off-by: Heinrich Schuchardt's avatarHeinrich Schuchardt <xypron.glpk@gmx.de>
      Signed-off-by: Alexander Graf's avatarAlexander Graf <agraf@suse.de>
      44ab2d32
  21. 05 Jun, 2018 1 commit
    • Sam Protsenko's avatar
      disk: efi: Correct backing up the MBR boot code · 955575c8
      Sam Protsenko authored
      In commit e163a931 ("cmd: gpt: backup boot code before writing MBR")
      there was added the procedure for storing old boot code when doing "gpt
      write". But instead of storing just backup code, the whole MBR was
      stored, and only specific fields were replaced further, keeping
      everything else intact. That's obviously not what we want.
      
      Fix the code to actually store only old boot code and zero out
      everything else. This fixes next testing case:
      
          => mmc write $loadaddr 0x0 0x7b
          => gpt write mmc 1 $partitions
      
      In case when $loadaddr address and further memory contains 0xff, the
      board was bricked (ROM-code probably didn't like partition entries that
      were clobbered with 0xff). With this patch applied, commands above don't
      brick the board.
      Signed-off-by: default avatarSam Protsenko <semen.protsenko@linaro.org>
      Cc: Alejandro Hernandez <ajhernandez@ti.com>
      Tested-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      955575c8
  22. 07 May, 2018 1 commit
    • Tom Rini's avatar
      SPDX: Convert all of our single license tags to Linux Kernel style · 83d290c5
      Tom Rini authored
      When U-Boot started using SPDX tags we were among the early adopters and
      there weren't a lot of other examples to borrow from.  So we picked the
      area of the file that usually had a full license text and replaced it
      with an appropriate SPDX-License-Identifier: entry.  Since then, the
      Linux Kernel has adopted SPDX tags and they place it as the very first
      line in a file (except where shebangs are used, then it's second line)
      and with slightly different comment styles than us.
      
      In part due to community overlap, in part due to better tag visibility
      and in part for other minor reasons, switch over to that style.
      
      This commit changes all instances where we have a single declared
      license in the tag as both the before and after are identical in tag
      contents.  There's also a few places where I found we did not have a tag
      and have introduced one.
      Signed-off-by: Tom Rini's avatarTom Rini <trini@konsulko.com>
      83d290c5
  23. 28 Apr, 2018 1 commit
    • Alex Kiernan's avatar
      spl: disk: usb: Add dependencies to sprintf/strto* · ab9e12f6
      Alex Kiernan authored
      If SPL serial support is disabled nothing brings in sprintf, snprintf
      or simple_strtoul:
      
        env/built-in.o: In function `regex_callback':
        env/attr.c:128: undefined reference to `sprintf'
        disk/built-in.o: In function `blk_get_device_by_str':
        disk/part.c:386: undefined reference to `simple_strtoul'
        disk/part.c:395: undefined reference to `simple_strtoul'
        disk/built-in.o: In function `blk_get_device_part_str':
        disk/part.c:522: undefined reference to `simple_strtoul'
        disk/built-in.o: In function `part_set_generic_name':
        disk/part.c:704: undefined reference to `sprintf'
        drivers/built-in.o: In function `init_peripheral_ep':
        drivers/usb/musb-new/musb_gadget.c:1826: undefined reference to `sprintf'
        drivers/built-in.o: In function `musb_core_init':
        drivers/usb/musb-new/musb_core.c:1451: undefined reference to `snprintf'
      
      Add those dependencies here.
      Signed-off-by: default avatarAlex Kiernan <alex.kiernan@gmail.com>
      ab9e12f6
  24. 27 Apr, 2018 1 commit
  25. 16 Apr, 2018 1 commit
    • Alexander Graf's avatar
      part: Disable CONFIG_SPL_ISO_PARTITION by default · 4f67b93f
      Alexander Graf authored
      We enabled CONFIG_ISO_PARTITION by default for distro boot, so that U-Boot
      could load distro images that usually get shipped as iso images. These images
      usually come with a board agnostic boot environment.
      
      However, there is very little point in having ISO support enabled (for anyone
      really) in SPL, as the whole idea of SPL is to load U-Boot proper which again
      is board specific. So the fact that we enable ISO support in U-Boot proper does
      not mean at all that we want ISO support in U-Boot SPL.
      
      Hence, let's remove the Kconfig dependency. Along the way, let's also clean up
      all those default configs that disabled SPL ISO support.
      Signed-off-by: Alexander Graf's avatarAlexander Graf <agraf@suse.de>
      4f67b93f
  26. 14 Mar, 2018 2 commits
  27. 09 Feb, 2018 2 commits
  28. 08 Feb, 2018 1 commit
    • Alexey Brodkin's avatar
      part: Allocate only one legacy_mbr buffer · 8639e34d
      Alexey Brodkin authored
      Commit ff98cb90 ("part: extract MBR signature from partitions")
      blindly switched allocated by ALLOC_CACHE_ALIGN_BUFFER buffer type from
      "unsigned char" to "legacy_mbr" which caused allocation of size =
      (typeof(legacy_mbr) * dev_desc->blksize) instead of just space enough
      for "legacy_mbr" structure.
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Alexander Graf <agraf@suse.de>
      Cc: Tom Rini <trini@konsulko.com>
      8639e34d
  29. 07 Dec, 2017 2 commits
  30. 30 Nov, 2017 1 commit
  31. 06 Nov, 2017 2 commits
    • Shawn Guo's avatar
      disk: part_dos: fix part_get_info_extended() function · 8f7102cf
      Shawn Guo authored
      The check in part_get_info_extended() for a successful partition
      searching misses a condition for extended partition. In case of
      (ext_part_sector == 0), we should anyway mark the partition as found,
      even if it's an extended partition, i.e. (is_extended(pt->sys_ind) == 0).
      Otherwise, the extended partition (type 0x0f) will never be identified,
      and the following recursive call to part_get_info_extended() will get a
      wrong 'part_num' and 'which_part' parameter.  In the end, all those
      partitions in extended table will not be identified.
      
      Let's add the missing OR condition of (ext_part_sector == 0) for
      is_extended() check to fix the problem.
      
      The issue is discovered by running fastboot flash to an extended
      partition on eMMC.
      
        $ fastboot flash mmcsda5 cache.img
        target reported max download size of 536870912 bytes
        sending 'mmcsda5' (18796 KB)...
        OKAY [  2.144s]
        writing 'mmcsda5'...
        FAILED (remote: cannot find partition)
        finished. total time: 2.261s
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      8f7102cf
    • Lukasz Majewski's avatar
      gpt: Use cache aligned buffers for gpt_h and gpt_e · bb021013
      Lukasz Majewski authored
      Before this patch one could receive following errors when executing
      "gpt write" command on machine with cache enabled:
      
      display5 factory > gpt write mmc ${mmcdev} ${partitions}
      Writing GPT:
      CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0]
      CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8]
      CACHE: Misaligned operation at range [4ef8f9f8, 4ef939f8]
      CACHE: Misaligned operation at range [4ef8f7f0, 4ef8f9f0]
      success!
      
      To alleviate this problem - the calloc()s have been replaced with
      malloc_cache_aligned() and memset().
      
      After those changes the buffers are properly aligned (with both start
      address and size) to SoC cache line.
      Signed-off-by: Lukasz Majewski's avatarLukasz Majewski <lukma@denx.de>
      bb021013
  32. 23 Oct, 2017 1 commit
    • Patrick Delaunay's avatar
      disk: efi: correct the overlap check on GPT header and PTE · ae0e0228
      Patrick Delaunay authored
      the partition starting at 0x4400 is refused with overlap error:
        $> gpt write mmc 0 "name=test,start=0x4400,size=0"
        Writing GPT: Partition overlap
        error!
      
      even if the 0x4400 is the first available offset for LBA35 with default
      value:
      - MBR=LBA1
      - GPT header=LBA2
      - PTE= 32 LBAs (128 entry), 3 to 34
      
      And the command to have one partition for all the disk failed also :
        $> gpt write mmc 0 "name=test,size=0"
      
      After the patch :
      
        $> gpt write mmc 0 "name=test,size=0"
        Writing GPT: success!
        $> part list mmc 0
      
        Partition Map for MMC device 0  --   Partition Type: EFI
      
        Part	Start LBA	End LBA		Name
      	Attributes
      	Type GUID
      	Partition GUID
        1	0x00000022	0x01ce9fde	"test"
      	attrs:	0x0000000000000000
      	type:	ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
      	type:	data
      	guid:	b4b84b8a-04e3-4000-0036-aff5c9c495b1
      
      And 0x22 = 34 LBA => offset = 0x4400 is accepted as expected
      Reviewed-by: Lukasz Majewski's avatarŁukasz Majewski <lukma@denx.de>
      Tested-by: Stephen Warren's avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: Patrick Delaunay's avatarPatrick Delaunay <patrick.delaunay@st.com>
      ae0e0228
  33. 16 Oct, 2017 2 commits