Eric Lee / smarc-uboot

18 May, 2020

1 commit

  • ed915f7d4   MA-14916-4 support dual bootloader for imx8m/imx8q ... Browse Code »

    This commit enables dual bootloader feature for imx8m/imx8q, but
    as commit 'a2018ab' already brings in some dual bootloader codes
    when enabling fastboot support, so this commit won't be a complete
    and standalone patch to introduce the dual bootloader feature.

    This commit will do the following:
    1. clean up dual bootloader flow and add missing implementation.
    2. Merge the dual bootloader entry for fit and container to one
    function 'mmc_load_image_raw_sector_dual_uboot'.

    Change-Id: Ic9410a48092cc05de599dd897fc912177e2a1fe1
    Signed-off-by: Ji Luo

    Ji Luo
     

27 Apr, 2020

1 commit

  • a2018ab0d   MLK-18591-3 android: Add FSL android fastboot support ... Browse Code »
    12

    Porting the FSL android fastboot features from imx u-boot v2018.03 to
    support all SoCs: imx6/imx7/imx7ulp/imx8/imx8m.

    The UUU commands like UCmd and ACmd are also added. Users need set
    CONFIG_FASTBOOT_UUU_SUPPORT=y to enable the feature.

    Signed-off-by: Frank Li
    Signed-off-by: Ye Li
    (cherry picked from commit 65120b06a7f750b9b1a6e0db3d2082cc7088d5a8)
    (cherry picked from commit 9b149c2a28829fe7017f83981d634157bc31cc94)

    Ye Li
     

03 Dec, 2019

1 commit

23 Aug, 2019

2 commits

17 Jul, 2019

1 commit

  • 06e921b18   disk: efi: avoid unaligned pointer error ... Browse Code »

    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: Ramon Fried
    Signed-off-by: Heinrich Schuchardt

    Heinrich Schuchardt
     

07 Jul, 2019

1 commit

03 May, 2019

2 commits

  • 716f919d2   disk: efi: Fix memory leak on 'gpt verify' ... Browse Code »

    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
     
  • 1cfe96947   disk: efi: Fix memory leak on 'gpt guid' ... Browse Code »

    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
     

18 Jan, 2019

1 commit

09 Oct, 2018

1 commit

11 Sep, 2018

1 commit

  • dee37fc99   Remove <inttypes.h> includes and PRI* usages in printf() entirely ... Browse Code »
    14

    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
     

14 Jun, 2018

1 commit

  • 44ab2d325   efi_loader: avoid initializer element is not constant ... Browse Code »

    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

  • 955575c8d   disk: efi: Correct backing up the MBR boot code ... Browse Code »

    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

  • 83d290c56   SPDX: Convert all of our single license tags to Linux Kernel style ... Browse Code »
    56

    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
     

09 Feb, 2018

1 commit

  • 1811a928c   Move most CONFIG_HAVE_BLOCK_DEVICE to Kconfig ... Browse Code »

    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
     

30 Nov, 2017

1 commit

06 Nov, 2017

1 commit

  • bb021013b   gpt: Use cache aligned buffers for gpt_h and gpt_e ... Browse Code »

    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

  • ae0e0228e   disk: efi: correct the overlap check on GPT header and PTE ... Browse Code »

    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

1 commit

04 Oct, 2017

1 commit

  • 9b643e312   treewide: replace with error() with pr_err() ... Browse Code »
    40

    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

  • ff98cb905   part: extract MBR signature from partitions ... Browse Code »
    40

    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
     

03 Sep, 2017

4 commits

  • 79c5912e8   part: efi: Disable overlap check ... Browse Code »

    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
     
  • 47d7ee47b   part: efi: make gpt_fill_pte take the device descriptor ... Browse Code »

    The gpt_fill_pte will need to access the device block size. Let's pass the
    device descriptor as an argument.

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

    Maxime Ripard
     
  • 5276e8b62   part: efi: rework the partition start and size in gpt_fill_pte ... Browse Code »

    The start variable is only used inside a loop, and is never affected inside
    it, so it's a purely local variable.

    In the same way the partition size is accessed several times, so we can
    store it in a variable.

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

    Maxime Ripard
     
  • 89d33a2c0   part: efi: Fix offset ... Browse Code »

    Both the config option and the DT options specify the offset to set the GPT
    at in bytes, yet the code treats those values as block numbers.

    Fix that.

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

    Maxime Ripard
     

04 Aug, 2017

2 commits

21 Mar, 2017

1 commit

  • 02e43537b   part_efi: support padding between the GPT header and partition entries ... Browse Code »

    Some architectures require their SPL loader at a fixed address within
    the first 16KB of the disk. To avoid an overlap with the partition
    entries of the EFI partition table, the first safe offset (in bytes,
    from the start of the device) for the entries can be set through
    CONFIG_EFI_PARTITION_ENTRIES_OFF (via Kconfig)

    When formatting a device with an EFI partition table, we may need to
    leave a gap between the GPT header (always in LBA 1) and the partition
    entries. The GPT header already contains a field to specify the
    on-disk location, which has so far always been set to LBA 2. With this
    change, a configurable offset will be translated into a LBA address
    indicating where to put the entries.

    Now also allows an override via device-tree using a config-node (see
    doc/device-tree-bindings/config.txt for documentation).

    Tested (exporting an internal MMC formatted with this) against Linux,
    MacOS X and Windows.

    Signed-off-by: Philipp Tomsich
    Reviewed-by: Simon Glass
    [trini: __maybe_unused on config_offset to avoid warning]
    Signed-off-by: Tom Rini

    Philipp Tomsich
     

18 Mar, 2017

1 commit

09 Feb, 2017

1 commit

  • e163a931a   cmd: gpt: backup boot code before writing MBR ... Browse Code »
    14

    On some cases the first 440 bytes of MBR are used to keep an additional
    information for ROM boot loader. 'gpt write' command doesn't preserve
    that area and makes boot code gone.

    Preserve boot code area when run 'gpt write' command.

    Signed-off-by: Vincent Tinelli
    Signed-off-by: Brennan Ashton
    Signed-off-by: Andy Shevchenko
    Reviewed-by: Simon Glass

    Vincent Tinelli
     

28 Jan, 2017

2 commits

02 Oct, 2016

1 commit

  • 87b8530fe   disk: part: implement generic function part_get_info_by_name() ... Browse Code »

    So far partition search by name has been supported only on the EFI partition
    table. This patch extends the search to all partition tables.

    Rename part_get_info_efi_by_name() to part_get_info_by_name(), move it from
    part_efi.c into part.c and make it a generic function which traverses all part
    drivers and searches all partitions (in the order given by the linked list).

    For this a new variable struct part_driver.max_entries is added, which limits
    the number of partitions searched. For EFI this was GPT_ENTRY_NUMBERS.
    Similarly the limit is defined for DOS, ISO, MAC and AMIGA partition tables.

    Signed-off-by: Petr Kulhavy
    Reviewed-by: Tom Rini
    Acked-by: Steve Rae

    Petr Kulhavy
     

06 Aug, 2016

1 commit

  • c2fdd3456   cmd: gpt: fix the wrong size parse for the last partition ... Browse Code »

    The calculation of "dev_desc->lba - 34 - 1 - offset" is not correct for
    size '-', because both fist_usable_lba and last_usable_lba will remain
    34 sectors.

    We can simply use 0 for size '-' because the part_efi module will decode
    the size and auto extend the size to maximum available size.

    Signed-off-by: Kever Yang

    Kever Yang
     

26 Jul, 2016

1 commit

27 May, 2016

1 commit

  • a56538676   disk: part_efi: fix check of the max partition size ... Browse Code »

    the last value acceptable value for offset is last_usable_lba + 1
    and not last_usable_lba - 1

    issue found with SDCARD partition commands on u-boot 2015.10
    but this part of code don't change

    1- create GPT partion on all the card
    > gpt write mmc 0 name=test,start=0,size=0
    > 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 0x003a9fde "test"
    attrs: 0x0000000000000000
    type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
    type: data
    guid: b710eb04-45b9-e94a-8d0b-21458d596f54

    => Start = 0x22*512 = 0x4400
    => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00

    2- try to recreate the same partition with the next command
    (block size:512 bytes = 0x200)

    > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00
    Writing GPT: Partitions layout exceds disk size

    > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800
    Writing GPT: Partitions layout exceds disk size

    > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600
    Writing GPT: success!

    Partition Map for MMC device 0 -- Partition Type: EFI

    Part Start LBA End LBA Name
    Attributes
    Type GUID
    Partition GUID
    1 0x00000022 0x003a9fdc "test"
    attrs: 0x0000000000000000
    type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
    type: data
    guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0

    the max LBA when the size is indicated (0x003a9fdc) is lower than
    when u-boot compute the max allowed value with size=0 (0x003a9fde)

    in the code :

    /* partition ending lba */
    if ((i == parts - 1) && (partitions[i].size == 0))
    /* extend the last partition to maximuim */
    gpt_e[i].ending_lba = gpt_h->last_usable_lba;
    else
    gpt_e[i].ending_lba = cpu_to_le64(offset - 1);

    so offset = gpt_h->last_usable_lba + 1 is acceptable !
    but the test (offset >= last_usable_lba) cause the error

    END

    Signed-off-by: Patrick Delaunay disk: part_efi: fix check of the max partition size
    the last value acceptable value for offset is (last_usable_lba + 1)
    and not (last_usable_lba - 1)

    issue found with SDCARD partition commands on u-boot 2015.10
    but this part of code don't change

    1- I create GPT partion on all the card (start and size undefined)

    > gpt write mmc 0 name=test,start=0,size=0
    > 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 0x003a9fde "test"
    attrs: 0x0000000000000000
    type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
    type: data
    guid: b710eb04-45b9-e94a-8d0b-21458d596f54

    => Start = 0x22*512 = 0x4400
    => Size = (0x003a9fde-0x22+1) * 512 = 0x753F7A00

    2- I try to recreate the same partition with the command gpt write
    and with start and size values (block size:512 bytes = 0x200)

    > gpt write mmc 0 name=test,start=0x4400,size=0x753F7A00
    Writing GPT: Partitions layout exceds disk size

    > gpt write mmc 0 name=test,start=0x4400,size=0x753F7800
    Writing GPT: Partitions layout exceds disk size

    > gpt write mmc 0 name=test,start=0x4400,size=0x753F7600
    Writing GPT: success!

    I check the partition created :

    > 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 0x003a9fdc "test"
    attrs: 0x0000000000000000
    type: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
    type: data
    guid: 36ec30ef-7ca4-cd48-97cd-ea9fb95185d0

    => but the max LBA when the size is indicated (0x003a9fdc) is lower than
    when u-boot compute the max allowed value with size=0 (0x003a9fde)

    3- in the code, just after my patch, line 446

    /* partition ending lba */
    if ((i == parts - 1) && (partitions[i].size == 0))
    /* extend the last partition to maximuim */
    gpt_e[i].ending_lba = gpt_h->last_usable_lba;
    else
    gpt_e[i].ending_lba = cpu_to_le64(offset - 1);

    so offset = gpt_h->last_usable_lba + 1 is acceptable !
    (it the value used when size is 0)

    but today the test (offset >= last_usable_lba) cause the error
    my patch only solve this issue

    END

    Signed-off-by: Patrick Delaunay

    Patrick Delaunay
     

23 Mar, 2016

2 commits

15 Mar, 2016

1 commit