07 Jul, 2019

1 commit


21 Jun, 2019

1 commit

  • 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: Robert Hancock

    Robert Hancock
     

15 Jun, 2019

1 commit


03 May, 2019

2 commits

  • Below is what happens on R-Car H3ULCB-KF using clean U-Boot
    v2019.04-00810-g6aebc0d11a10 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: cef68bf9042dda ("gpt: part: Definition and declaration of GPT verification functions")
    Signed-off-by: Eugeniu Rosca
    Reviewed-by: Heinrich Schuchardt

    Eugeniu Rosca
     
  • Below is what happens on R-Car H3ULCB-KF using clean U-Boot
    v2019.04-00810-g6aebc0d11a10 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 73d6d18b7147c9 ("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: 73d6d18b7147c9 ("GPT: add accessor function for disk GUID")
    Signed-off-by: Eugeniu Rosca
    Reviewed-by: Heinrich Schuchardt

    Eugeniu Rosca
     

27 Apr, 2019

1 commit


18 Jan, 2019

1 commit


15 Nov, 2018

1 commit


09 Oct, 2018

1 commit


11 Sep, 2018

1 commit

  • In int-ll64.h, we always use the following typedefs:

    typedef unsigned int u32;
    typedef unsigned long uintptr_t;
    typedef unsigned long long u64;

    This does not need to match to the compiler's .
    Do not include it.

    The use of PRI* makes the code super-ugly. You can simply use
    "l" for printing uintptr_t, "ll" for u64, and no modifier for u32.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

11 Aug, 2018

1 commit

  • Underlying API should already print some meaningful error message, so
    this one is just brings more noise. E.g. we can see log like this:

    MMC: no card present
    ** Bad device mmc 0 **

    Obviously, second error message is unwanted. Let's only print it in case
    when DEBUG is defined to keep log short and clear.

    Signed-off-by: Sam Protsenko

    Sam Protsenko
     

14 Jun, 2018

1 commit

  • 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
    Signed-off-by: Alexander Graf

    Heinrich Schuchardt
     

05 Jun, 2018

1 commit

  • In commit e163a931af34 ("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: Sam Protsenko
    Cc: Alejandro Hernandez
    Tested-by: Andy Shevchenko

    Sam Protsenko
     

07 May, 2018

1 commit

  • 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

    Tom Rini
     

29 Apr, 2018

1 commit

  • 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: Alex Kiernan

    Alex Kiernan
     

28 Apr, 2018

1 commit


17 Apr, 2018

1 commit

  • 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

    Alexander Graf
     

14 Mar, 2018

2 commits


09 Feb, 2018

2 commits

  • config_fallbacks.h has some logic that sets HAVE_BLOCK_DEVICE
    based on a list of enabled options. Moving HAVE_BLOCK_DEVICE to
    Kconfig allows us to drastically shrink the logic in
    config_fallbacks.h

    Signed-off-by: Adam Ford
    [trini: Rename HAVE_BLOCK_DEVICE to CONFIG_BLOCK_DEVICE]
    Signed-off-by: Tom Rini

    Adam Ford
     
  • config_fallback.h has some logic that checks a variety of options
    and selects LIB_UUID if it hasn't already been selected. This
    will all LIB_UUID in Kconfig and select this option for the list
    of options to allow us to remove the logic from fallbacks

    Signed-off-by: Adam Ford

    Adam Ford
     

08 Feb, 2018

1 commit

  • Commit ff98cb90514d ("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: Alexey Brodkin
    Cc: Rob Clark
    Cc: Peter Jones
    Cc: Alexander Graf
    Cc: Tom Rini

    Alexey Brodkin
     

19 Dec, 2017

1 commit


07 Dec, 2017

2 commits


30 Nov, 2017

1 commit


06 Nov, 2017

2 commits

  • 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: Shawn Guo

    Shawn Guo
     
  • 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

    Lukasz Majewski
     

24 Oct, 2017

1 commit

  • 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: Łukasz Majewski
    Tested-by: Stephen Warren
    Signed-off-by: Patrick Delaunay

    Patrick Delaunay
     

16 Oct, 2017

2 commits

  • The test and info callbacks into the partition callback struct are
    used by the "part list" command on the command line. That command
    is used by the distro script.

    With verb=1 set, "part list" thus throws a lot of warnings about
    partitions it can't find when an upper layer searches for partitions.

    So let's reduce verbosity to bring it to the same level of noise
    as the other partition targets.

    Signed-off-by: Alexander Graf

    Alexander Graf
     
  • While this goes somewhat against normal coding style we should ensure
    that dev_desc is not NULL before we dereference it in allocation of
    legacy_mbr.

    Reported-by: Coverity (CID: 167292)
    Signed-off-by: Tom Rini

    Tom Rini
     

06 Oct, 2017

1 commit


05 Oct, 2017

1 commit

  • Since commit ff98cb90514d ("part: extract MBR signature from partitions")
    SPL boot on i.MX6 starts to fail:

    U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
    Trying to boot from MMC1
    (keep in loop)

    Use the original allocation scheme for the SPL case, so that MX6 boards
    can boot again.

    This is a temporary solution to avoid the boot regression.

    Signed-off-by: Fabio Estevam
    Acked-by: Rob Clark
    Tested-by: Peter Robinson

    Fabio Estevam
     

04 Oct, 2017

1 commit

  • U-Boot widely uses error() as a bit noisier variant of printf().

    This macro causes name conflict with the following line in
    include/linux/compiler-gcc.h:

    # define __compiletime_error(message) __attribute__((error(message)))

    This prevents us from using __compiletime_error(), and makes it
    difficult to fully sync BUILD_BUG macros with Linux. (Notice
    Linux's BUILD_BUG_ON_MSG is implemented by using compiletime_assert().)

    Let's convert error() into now treewide-available pr_err().

    Done with the help of Coccinelle, excluing tools/ directory.

    The semantic patch I used is as follows:

    //
    @@@@
    -error
    +pr_err
    (...)
    //

    Signed-off-by: Masahiro Yamada
    Reviewed-by: Simon Glass
    [trini: Re-run Coccinelle]
    Signed-off-by: Tom Rini

    Masahiro Yamada
     

20 Sep, 2017

1 commit

  • EFI client programs need the signature information from the partition
    table to determine the disk a partition is on, so we need to fill that
    in here.

    Signed-off-by: Peter Jones
    [separated from efi_loader part, and fixed build-errors for non-
    CONFIG_EFI_PARTITION case]
    Signed-off-by: Rob Clark
    Signed-off-by: Alexander Graf

    Peter Jones
     

19 Sep, 2017

1 commit

  • The UEFI spec allows an EFI system partition (ESP, with the bootloader or
    kernel EFI apps on it) to reside on a disk using a "legacy" MBR
    partitioning scheme.
    But in contrast to actual legacy disks the ESP is not marked as
    "bootable" using bit 7 in byte 0 of the legacy partition entry, but is
    instead using partition *type* 0xef (in contrast to 0x0b or 0x0c for a
    normal FAT partition). The EFI spec isn't 100% clear on this, but it even
    seems to discourage the use of the bootable flag for ESPs.
    Also it seems that some EFI implementations (EDK2?) even seem to ignore
    partitions marked as bootable (probably since they believe they contain
    legacy boot code).
    The Debian installer [1] (*not* mini.iso), for instance, contains such an
    MBR, where none of the two partitions are marked bootable, but the ESP
    has clearly type 0xef.
    Now U-Boot cannot find the ESP on such a disk (USB flash drive) and
    fails to load the EFI grub and thus the installer.

    Since it all boils down to the distro bootcmds eventually calling
    "part list -bootable" to find potential boot partitions, it seems logical
    to just add this "partition type is 0xef" condition to the is_bootable()
    implementation.

    This allows the bog standard arm64 Debian-testing installer to boot from
    an USB pen drive on Allwinner A64 boards (Pine64, BananaPi-M64).
    (Ubuntu and other distribution installers don't have a legacy MBR, so
    U-Boot falls back to El Torito there).

    [1] https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/
    Signed-off-by: Andre Przywara
    Reviewed-by: Alexander Graf
    Signed-off-by: Alexander Graf

    Andre Przywara
     

15 Sep, 2017

1 commit

  • Needed to support efi file protocol. The fallback.efi loader wants
    to be able to read the contents of the /EFI directory to find an OS
    to boot.

    Modelled after POSIX opendir()/readdir()/closedir(). Unlike the other
    fs APIs, this is stateful (ie. state is held in the FS_DIR "directory
    stream"), to avoid re-traversing of the directory structure at each
    step. The directory stream must be released with closedir() when it
    is no longer needed.

    Signed-off-by: Rob Clark
    Reviewed-by: Łukasz Majewski
    Reviewed-by: Simon Glass

    Rob Clark
     

07 Sep, 2017

1 commit


04 Sep, 2017

1 commit


03 Sep, 2017

1 commit

  • The current code checks that no partitions overlap with the GPT partition
    table using the offset of the first LBA usable for that partition.

    This works fine, unless you have a partition entry that is further away
    than it usually is and you want to create partitions in the gap between the
    GPT header and the GPT partition entries, for example to reflash a
    bootloader that needs to be set there.

    Rework the test to something a bit smarter that checks whether a partition
    would overlap with either the GPT header or the partition entries, no
    matter where it is on the disk.

    Partitions that do not have a start LBA specified will still start at the
    first LBA usable set in the GPT header, to avoid weird behaviours.

    Signed-off-by: Maxime Ripard
    Reviewed-by: Tom Rini

    Maxime Ripard