Skip to content
Snippets Groups Projects
Select Git revision
  • u-boot-dfu-next
  • u-boot-dfu default
  • testing
  • bkp
  • u-boot-dfu-next-20250310
  • u-boot-dfu-20250211
  • u-boot-dfu-20250124
  • u-boot-dfu-20241219
  • u-boot-dfu-next-20241126
  • u-boot-dfu-20241126
  • u-boot-dfu-20241125
  • u-boot-dfu-20241025
  • u-boot-dfu-20241017
  • u-boot-dfu-next-20241003
  • u-boot-dfu-20240930
  • u-boot-dfu-20240910
  • u-boot-dfu-20240822
  • u-boot-dfu-next-20240820
  • u-boot-dfu-20240820
  • u-boot-dfu-20240711
  • u-boot-dfu-20240606
  • u-boot-dfu-20240516
  • u-boot-dfu-20240419
  • u-boot-dfu-next-20240402
24 results
Search by author
  • Any Author
  • Lukasz Majewski Lukasz Majewski lukma
  • Mattijs Korpershoek Mattijs Korpershoek mkorpershoek
  • Tom Rini Tom Rini trini
3 authors
  1. Dec 18, 2024
  3. Dec 17, 2024
  5. Dec 16, 2024
  7. Dec 15, 2024
  9. Dec 12, 2024
    • Tom Rini's avatar
      Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-usb · 88bd5701
      Tom Rini authored 
      - USB onboard-hub fix
      88bd5701
    • Tom Rini's avatar
      Merge tag 'xilinx-for-v2025.01-rc5' of https://source.denx.de/u-boot/custodians/u-boot-microblaze · 39adaa54
      Tom Rini authored 
      AMD/Xilinx changes for v2025.01-rc5

- Fix reset issue for SOM
      39adaa54
    • Sam Protsenko's avatar
      boot: fdt: Handle already reserved memory in boot_fdt_reserve_region() · 5a6aa7d5
      Sam Protsenko authored and Tom Rini's avatar Tom Rini committed 
      
The boot_fdt_add_mem_rsv_regions() function can be called twice, e.g.
first time during the board init (as a part of LMB init), and then when
booting the OS with 'booti' command:

    lmb_add_region_flags
    lmb_reserve_flags
    boot_fdt_reserve_region
    boot_fdt_add_mem_rsv_regions
               ^
               |
               +-----------------------+
               | (1)                   | (2)
    lmb_reserve_common        image_setup_linux
    lmb_init                  ...
    initr_lmb                 do_booti
    board_init_r              'booti'

That consequently leads to the attempt of reserving the same memory
areas (described in the 'reserved-memory' dts node) in LMB. The
lmb_add_region_flags() returns -EEXIST error code in such cases, but
boot_fdt_reserve_region() handles all negative error codes as a failure
to reserve fdt memory region, printing corresponding error messages,
which are essentially harmless, but misleading. For example, this is the
output of 'booti' command on E850-96 board:

    => booti $loadaddr - $fdtaddr
    ...
    ERROR: reserving fdt memory region failed
           (addr=bab00000 size=5500000 flags=2)
    ERROR: reserving fdt memory region failed
           (addr=f0000000 size=200000 flags=4)
    ...
    Starting kernel ...

The mentioned false positive error messages are observed starting with
commit 1d9aa4a2 ("lmb: Fix the allocation of overlapping memory
areas with !LMB_NONE"), which removes the check for the already added
memory regions in lmb_add_region_flags(), making it return -1 for
!LMB_NONE cases. Another commit 827dee58 ("fdt: lmb: add reserved
regions as no-overwrite") changes flags used for reserving memory in
boot_fdt_add_mem_rsv_regions() from LMB_NONE to LMB_NOOVERWRITE. So
together with the patch mentioned earlier, it makes
lmb_add_region_flags() return -1 when called from
boot_fdt_reserve_region().

Since then, the different patch was implemented, returning -EEXIST error
code in described cases, which is:

   lmb: Return -EEXIST in lmb_add_region_flags() if region already added

Handle -EEXIST error code as a normal (successful) case in
lmb_reserve_flags() and don't print any messages.

Fixes: 1d9aa4a2 ("lmb: Fix the allocation of overlapping memory areas with !LMB_NONE")
Signed-off-by: default avatarSam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: default avatarIlias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: default avatarMichal Simek <michal.simek@amd.com>
      5a6aa7d5
    • Sam Protsenko's avatar
      lmb: Return -EEXIST in lmb_add_region_flags() if region already added · 8b8b35a4
      Sam Protsenko authored and Tom Rini's avatar Tom Rini committed 
      
An attempt to add the already added LMB region using
lmb_add_region_flags() ends up in lmb_addrs_overlap() check, which
eventually leads to either returning 0 if 'flags' is LMB_NONE, or -1
otherwise. It makes it impossible for the user of this function to catch
the case when the region is already added and differentiate it from
regular errors. That in turn may lead to incorrect error handling in the
caller code, like reporting misleading errors or interrupting the normal
code path where it could be treated as the normal case. An example is
boot_fdt_reserve_region() function, which might be called twice (e.g.
during board startup in initr_lmb(), and then during 'booti' command
booting the OS), thus trying to reserve exactly the same memory regions
described in the device tree twice, which produces an error message on
second call.

Return -EEXIST error code in case when the added region exists and it's
not LMB_NONE; for LMB_NONE return 0, to conform to unit tests
(specifically test_alloc_addr() in test/lib/lmb.c) and the preferred
behavior described in commit 1d9aa4a2 ("lmb: Fix the allocation of
overlapping memory areas with !LMB_NONE"). The change of
lmb_add_region_flags() return values is described in the table below:

    Return case                        Pre-1d9   1d9    New
    -----------------------------------------------------------
    Added successfully                    0      0      0
    Failed to add                         -1     -1     -1
    Already added, flags == LMB_NONE      0      0      0
    Already added, flags != LMB_NONE      0      -1     -EEXIST

Rework all affected functions and their documentation. Also fix the
corresponding unit test which checks reserving the same region with the
same flags to account for the changed return value.

No functional change is intended (by this patch itself).

Fixes: 1d9aa4a2 ("lmb: Fix the allocation of overlapping memory areas with !LMB_NONE")
Signed-off-by: default avatarSam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: default avatarIlias Apalodimas <ilias.apalodimas@linaro.org>
Tested-by: default avatarMichal Simek <michal.simek@amd.com>
      8b8b35a4
    • Roger Quadros's avatar
      configs: am62x_evm_*: Fix USB DFU configuration · e371dfef
      Roger Quadros authored and Tom Rini's avatar Tom Rini committed 
      
CONFIG_USB_XHCI_DWC3 is not required for AM62x as the XHCI
driver is registered through the dwc3-generic driver.

CONFIG_USB_XHCI_DWC3 causes problems by hijacking the
USB controller even if it is not set for Host mode in
device tree.

'dm tree' output after 'usb start' is fixed from

 simple_bus    5  [ + ]   dwc3-am62             |   |-- dwc3-usb@f900000
 usb_gadget    0  [   ]   dwc3-generic-periphe  |   |   |-- usb@31000000
 usb           0  [ + ]   xhci-dwc3             |   |   `-- usb@31000000
 usb_hub       0  [ + ]   usb_hub               |   |       `-- usb_hub
 simple_bus    6  [ + ]   dwc3-am62             |   |-- dwc3-usb@f910000
 usb           1  [ + ]   dwc3-generic-host     |   |   |-- usb@31100000
 usb_hub       1  [ + ]   usb_hub               |   |   |   `-- usb_hub
 usb           1  [ + ]   xhci-dwc3             |   |   `-- usb@31100000
 usb_hub       2  [ + ]   usb_hub               |   |       `-- usb_hub

[notice that 'xhci-dwc3' and 'usb_hub' drivers are probed
 for both USB instances although the first instance
 is supposed to be 'peripheral' only]

to

 simple_bus    5  [   ]   dwc3-am62             |   |-- dwc3-usb@f900000
 usb_gadget    0  [   ]   dwc3-generic-periphe  |   |   `-- usb@31000000
 simple_bus    6  [ + ]   dwc3-am62             |   |-- dwc3-usb@f910000
 usb           1  [ + ]   dwc3-generic-host     |   |   `-- usb@31100000
 usb_hub       0  [ + ]   usb_hub               |   |       `-- usb_hub

Fixes: dfc2dff5 ("configs: am62x_evm_*: Enable USB and DFU support")
Signed-off-by: default avatarRoger Quadros <rogerq@kernel.org>
Reviewed-by: default avatarSiddharth Vadapalli <s-vadapalli@ti.com>
      e371dfef
  11. Dec 11, 2024

Imprint & Privacy Policy