U boot 2009.11.y #3
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bootstrap options G and F are reported incorrectly (G instead of F and vice versa). This patch fixes this. Signed-off-by: Felix Radensky <felix@embedded-sol.com> Signed-off-by: Stefan Roese <sr@denx.de>
On platforms where SPD EEPROM and another EEPROM have adjacent I2C addresses SPD_EEPROM_ADDRESS should be defined as a single element array, otherwise DDR2 setup code would fail with the following error: ERROR: Unknown DIMM detected in slot 1 However, fixing SPD_EEPROM_ADDRESS would result in another error: ERROR: DIMM's DDR1 and DDR2 type can not be mixed. This happens because initdram() routine does not explicitly initialize dimm_populated array. This patch fixes the problem. Signed-off-by: Felix Radensky <felix@embedded-sol.com> Signed-off-by: Stefan Roese <sr@denx.de>
The list of 4xx SoCs that should send type 1 PCI transactions is not defined correctly. As a result PCI-PCI bridges and devices behind them are not identified. The following 4xx variants should send type 1 transactions: 440GX, 440GP, 440SP, 440SPE, 460EX and 460GT. Signed-off-by: Felix Radensky <felix@embedded-sol.com> Signed-off-by: Stefan Roese <sr@denx.de>
A newer CPLD version on the 405EX evaluation board requires a different EBC controller setup for the CPLD register access. This patch adds a CPLD version detection for Kilauea and code to reconfigure the EBC controller (chip select 2) for the old CPLD if no new version is found. Additionally the CPLD version is printed upon bootup: Board: Kilauea - AMCC PPC405EX Evaluation Board (CPLD rev. 0) Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Wolfgang Denk <wd@denx.de> Cc: Zhang Bao Quan <bqzhang@udtech.com.cn>
Update CHANGELOG Signed-off-by: Wolfgang Denk <wd@denx.de>
trini
pushed a commit
that referenced
this pull request
Aug 24, 2018
Compiling U-Boot with ubsan/asan libraries and running it in sandbox
may lead to below backtrace:
=> avb init 0
=> avb verify
## Android Verified Boot 2.0 version 1.1.0
read_is_device_unlocked not supported yet
common/avb_verify.c:407:31: runtime error: division by zero
AddressSanitizer:DEADLYSIGNAL
Reviewed-by: Igor Opaniuk <igor.opaniuk@linaro.org>
=================================================================
==9388==ERROR: AddressSanitizer: FPE on unknown address 0x0000004b467f \
(pc 0x0000004b467f bp 0x000000000000 sp 0x7ffd899fe150 T0)
#0 0x4b467e in mmc_byte_io common/avb_verify.c:407
#1 0x4b4c47 in mmc_byte_io common/avb_verify.c:532
#2 0x4b4c47 in read_from_partition common/avb_verify.c:533
#3 0x69dc0d in load_and_verify_vbmeta lib/libavb/avb_slot_verify.c:560
#4 0x6a1ee6 in avb_slot_verify lib/libavb/avb_slot_verify.c:1139
#5 0x45dabd in do_avb_verify_part cmd/avb.c:245
#6 0x4af77c in cmd_call common/command.c:499
#7 0x4af77c in cmd_process common/command.c:538
#8 0x46bafc in run_pipe_real common/cli_hush.c:1677
#9 0x46bafc in run_list_real common/cli_hush.c:1875
#10 0x46c780 in run_list common/cli_hush.c:2024
#11 0x46c780 in parse_stream_outer common/cli_hush.c:3216
#12 0x46d34b in parse_file_outer common/cli_hush.c:3299
#13 0x4ad609 in cli_loop common/cli.c:217
#14 0x4625ae in main_loop common/main.c:65
#15 0x46f2d1 in run_main_loop common/board_r.c:648
#16 0x640253 in initcall_run_list lib/initcall.c:30
#17 0x46f9d0 in board_init_r common/board_r.c:879
#18 0x40539b in main arch/sandbox/cpu/start.c:321
#19 0x7fa94925f82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#20 0x408908 in _start (/srv/R/u-boot-master/u-boot+0x408908)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE common/avb_verify.c:407 in mmc_byte_io
==9388==ABORTING
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
lbmeng
added a commit
to lbmeng/u-boot
that referenced
this pull request
Sep 19, 2018
At present the response to ARP request is copied to the transmit
packet buffer ('net_tx_packet') and sent out. This won't fail on
most cases, but unfortunately is potentially broken under certain
circumstances.
For example, considering the following packet sequence:
1: placed an ARP request to the other end, initiated by 'ping'
2: received an ARP request from the other end
3: received the ARP reply from the other end
The ICMP echo request packet was created in step u-boot#1, stored in the
transmit packet buffer, but was corrupted in step u-boot#2 when handling
the response to ARP request using the same buffer, and finally the
same buffer was sent out in step u-boot#3 as the follow-up on ARP reply.
This leads to 'ping' timeout since the ICMP echo request was never
sent out to the other end, instead a duplicated ARP reply packet
was sent out and ignored by the other end.
Similar corruption can happen with other protocols like TFTP, which
leads to TFTP transfer timeout.
Use the dedicated ARP transmit packet buffer ('arp_tx_packet') to
avoid such issue.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
lbmeng
added a commit
to lbmeng/u-boot
that referenced
this pull request
Sep 20, 2018
At present the response to ARP request is copied to the transmit
packet buffer ('net_tx_packet') and sent out. This won't fail on
most cases, but unfortunately is potentially broken under certain
circumstances.
For example, considering the following packet sequence:
1: placed an ARP request to the other end, initiated by 'ping'
2: received an ARP request from the other end
3: received the ARP reply from the other end
The ICMP echo request packet was created in step u-boot#1, stored in the
transmit packet buffer, but was corrupted in step u-boot#2 when handling
the response to ARP request using the same buffer, and finally the
same buffer was sent out in step u-boot#3 as the follow-up on ARP reply.
This leads to 'ping' timeout since the ICMP echo request was never
sent out to the other end, instead a duplicated ARP reply packet
was sent out and ignored by the other end.
Similar corruption can happen with other protocols like TFTP, which
leads to TFTP transfer timeout.
Use the dedicated ARP transmit packet buffer ('arp_tx_packet') to
avoid such issue.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
lbmeng
added a commit
to lbmeng/u-boot
that referenced
this pull request
Sep 20, 2018
At present the response to ARP request is copied to the transmit
packet buffer ('net_tx_packet') and sent out. This won't fail on
most cases, but unfortunately is potentially broken under certain
circumstances.
For example, considering the following packet sequence:
1: placed an ARP request to the other end, initiated by 'ping'
2: received an ARP request from the other end
3: received the ARP reply from the other end
The ICMP echo request packet was created in step u-boot#1, stored in the
transmit packet buffer, but was corrupted in step u-boot#2 when handling
the response to ARP request using the same buffer, and finally the
same buffer was sent out in step u-boot#3 as the follow-up on ARP reply.
This leads to 'ping' timeout since the ICMP echo request was never
sent out to the other end, instead a duplicated ARP reply packet
was sent out and ignored by the other end.
Similar corruption can happen with other protocols like TFTP, which
leads to TFTP transfer timeout.
Use the dedicated ARP transmit packet buffer ('arp_tx_packet') to
avoid such issue.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
lbmeng
added a commit
to lbmeng/u-boot
that referenced
this pull request
Sep 26, 2018
At present the response to ARP request is copied to the transmit
packet buffer ('net_tx_packet') and sent out. This won't fail on
most cases, but unfortunately is potentially broken under certain
circumstances.
For example, considering the following packet sequence:
1: placed an ARP request to the other end, initiated by 'ping'
2: received an ARP request from the other end
3: received the ARP reply from the other end
The ICMP echo request packet was created in step u-boot#1, stored in the
transmit packet buffer, but was corrupted in step u-boot#2 when handling
the response to ARP request using the same buffer, and finally the
same buffer was sent out in step u-boot#3 as the follow-up on ARP reply.
This leads to 'ping' timeout since the ICMP echo request was never
sent out to the other end, instead a duplicated ARP reply packet
was sent out and ignored by the other end.
Similar corruption can happen with other protocols like TFTP, which
leads to TFTP transfer timeout.
Use the dedicated ARP transmit packet buffer ('arp_tx_packet') to
avoid such issue.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
lbmeng
added a commit
to lbmeng/u-boot
that referenced
this pull request
Sep 27, 2018
At present the response to ARP request is copied to the transmit
packet buffer ('net_tx_packet') and sent out. This won't fail on
most cases, but unfortunately is potentially broken under certain
circumstances.
For example, considering the following packet sequence:
1: placed an ARP request to the other end, initiated by 'ping'
2: received an ARP request from the other end
3: received the ARP reply from the other end
The ICMP echo request packet was created in step u-boot#1, stored in the
transmit packet buffer, but was corrupted in step u-boot#2 when handling
the response to ARP request using the same buffer, and finally the
same buffer was sent out in step u-boot#3 as the follow-up on ARP reply.
This leads to 'ping' timeout since the ICMP echo request was never
sent out to the other end, instead a duplicated ARP reply packet
was sent out and ignored by the other end.
Similar corruption can happen with other protocols like TFTP, which
leads to TFTP transfer timeout.
Use the dedicated ARP transmit packet buffer ('arp_tx_packet') to
avoid such issue.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
lbmeng
added a commit
to lbmeng/u-boot
that referenced
this pull request
Oct 10, 2018
At present the response to ARP request is copied to the transmit
packet buffer ('net_tx_packet') and sent out. This won't fail on
most cases, but unfortunately is potentially broken under certain
circumstances.
For example, considering the following packet sequence:
1: placed an ARP request to the other end, initiated by 'ping'
2: received an ARP request from the other end
3: received the ARP reply from the other end
The ICMP echo request packet was created in step u-boot#1, stored in the
transmit packet buffer, but was corrupted in step u-boot#2 when handling
the response to ARP request using the same buffer, and finally the
same buffer was sent out in step u-boot#3 as the follow-up on ARP reply.
This leads to 'ping' timeout since the ICMP echo request was never
sent out to the other end, instead a duplicated ARP reply packet
was sent out and ignored by the other end.
Similar corruption can happen with other protocols like TFTP, which
leads to TFTP transfer timeout.
Use the dedicated ARP transmit packet buffer ('arp_tx_packet') to
avoid such issue.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Airtau
referenced
this pull request
in Airtau-A64/u-boot
Oct 17, 2018
|
u-boot community does not handle PRs on GitHub, please read https://github.com/u-boot/u-boot/blob/master/README |
trini
pushed a commit
that referenced
this pull request
Apr 14, 2019
v2019.04-rc3 sandbox U-Boot fails to boot when compiled with -fsanitize=address and linked against -lasan, reporting [1]. Git bisecting shows that the issue is contributed by v2019.01 commit 1678754 ("core: ofnode: Fix ofnode_get_addr_index function"). The root cause seems to be the mismatch between sizeof(u64) and sizeof(fdt_size_t) on sandbox. Luckily, thanks to the fact that the size argument of both of_get_address() and fdtdec_get_addr_size_fixed() is optional, we can pass NULL in its place, avoiding the problem. [1] Backtrace reported by ASAN (gcc 8.1.0): $> ./u-boot -d arch/sandbox/dts/sandbox.dtb [..] Reviewed-by: Simon Glass <sjg@chromium.org> ================================================================= ==10998==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffcc2331140 at pc 0x0000004eeeb0 bp 0x7ffcc2330f80 sp 0x7ffcc2330f70 WRITE of size 8 at 0x7ffcc2331140 thread T0 #0 0x4eeeaf in of_get_address drivers/core/of_addr.c:154 #1 0x4f7441 in ofnode_get_addr_index drivers/core/ofnode.c:263 #2 0x5b2a78 in sb_eth_ofdata_to_platdata drivers/net/sandbox.c:422 #3 0x4dccd8 in device_probe drivers/core/device.c:407 #4 0x753170 in eth_initialize net/eth-uclass.c:428 #5 0x47d9bf in initr_net common/board_r.c:557 #6 0x6bcfa7 in initcall_run_list lib/initcall.c:30 #7 0x47e1fe in board_init_r common/board_r.c:859 #8 0x4060e5 in main arch/sandbox/cpu/start.c:356 #9 0x7fb8d135482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #10 0x40a3a8 in _start (/path/to/u-boot/u-boot+0x40a3a8) Address 0x7ffcc2331140 is located in stack of thread T0 at offset 32 in frame #0 0x4f72b8 in ofnode_get_addr_index drivers/core/ofnode.c:255 This frame has 3 object(s): [32, 36) 'size' <== Memory access at offset 32 partially overflows this variable [96, 100) 'flags' [160, 168) 'node' HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow drivers/core/of_addr.c:154 in of_get_address Shadow bytes around the buggy address: 0x10001845e1d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001845e1e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001845e1f0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x10001845e200: 04 f2 f2 f2 f2 f2 f2 f2 04 f2 f2 f2 f2 f2 f2 f2 0x10001845e210: 04 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00 =>0x10001845e220: 00 00 00 00 f1 f1 f1 f1[04]f2 f2 f2 f2 f2 f2 f2 0x10001845e230: 04 f2 f2 f2 f2 f2 f2 f2 00 f2 f2 f2 f3 f3 f3 f3 0x10001845e240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x10001845e250: 00 00 00 00 f1 f1 f1 f1 00 00 f2 f2 f3 f3 f3 f3 0x10001845e260: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 0x10001845e270: f1 f1 00 f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==10998==ABORTING 'To' list: git log --since=1year drivers/core/ofnode.c | grep "\-by: .*@" | \ sed 's/.*-by: //' | sort | uniq -c | sort -rn 10 Simon Glass <sjg@chromium.org> 3 Mario Six <mario.six@gdsys.cc> 2 Martin Fuzzey <mfuzzey@parkeon.com> 2 Marek Vasut <marek.vasut+renesas@gmail.com> 1 Tom Rini <trini@konsulko.com> 1 Masahiro Yamada <yamada.masahiro@socionext.com> 1 Keerthy <j-keerthy@ti.com> 1 Jens Wiklander <jens.wiklander@linaro.org> 1 Bin Meng <bmeng.cn@gmail.com> Fixes: 1678754 ("core: ofnode: Fix ofnode_get_addr_index function") Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
aspeeddylan
referenced
this pull request
in AspeedTech-BMC/u-boot
Jul 11, 2019
greedyhao
pushed a commit
to greedyhao/u-boot
that referenced
this pull request
Nov 18, 2019
Nano v2018.01
roman3017
added a commit
to roman3017/u-boot
that referenced
this pull request
Dec 29, 2019
Add NexysA7 support
MrVan
pushed a commit
to MrVan/u-boot
that referenced
this pull request
Dec 30, 2019
This patch introduces support for i.MX28 based XEA board. This board supports DM/DTS in U-Boot proper as well as DM aware drivers in SPL (u-boot.sb) by using OF_PLATDATA. More detailed information regarding usage of it can be found in ./board/liebherr/xea/README file. U-Boot SPL 2019.10-rc1-00233-g6aa549f05c (Aug 12 2019 - 09:23:36 +0200) Trying to boot from MMC1 MMC0: Command 8 timeout (status 0xf0344020) mmc_load_image_raw_sector: mmc block read error U-Boot 2019.10-rc1-00233-g6aa549f05c (Aug 12 2019 - 09:23:36 +0200) CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: SSP SPI u-boot#3, master, 3V3 NOR Model: Liebherr (LWE) XEA i.MX28 Board DRAM: 128 MiB MMC: MXS MMC: 0 Loading Environment from SPI Flash... SF: Detected n25q128a13 with page size 256 Bytes, erase size 64 KiB, total 16 MiB OK In: serial Out: serial Err: serial Net: Warning: ethernet@800f0000 (eth0) using random MAC address - ce:e1:9e:46:f3:a2 eth0: ethernet@800f0000 Hit any key to stop autoboot: 0 Signed-off-by: Lukasz Majewski <lukma@denx.de>
trini
pushed a commit
that referenced
this pull request
Jan 7, 2020
This patch introduces support for i.MX28 based XEA board. This board supports DM/DTS in U-Boot proper as well as DM aware drivers in SPL (u-boot.sb) by using OF_PLATDATA. More detailed information regarding u 10000 sage of it can be found in ./board/liebherr/xea/README file. U-Boot SPL 2019.10-rc1-00233-g6aa549f05c (Aug 12 2019 - 09:23:36 +0200) Trying to boot from MMC1 MMC0: Command 8 timeout (status 0xf0344020) mmc_load_image_raw_sector: mmc block read error U-Boot 2019.10-rc1-00233-g6aa549f05c (Aug 12 2019 - 09:23:36 +0200) CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: SSP SPI #3, master, 3V3 NOR Model: Liebherr (LWE) XEA i.MX28 Board DRAM: 128 MiB MMC: MXS MMC: 0 Loading Environment from SPI Flash... SF: Detected n25q128a13 with page size 256 Bytes, erase size 64 KiB, total 16 MiB OK In: serial Out: serial Err: serial Net: Warning: ethernet@800f0000 (eth0) using random MAC address - ce:e1:9e:46:f3:a2 eth0: ethernet@800f0000 Hit any key to stop autoboot: 0 Signed-off-by: Lukasz Majewski <lukma@denx.de>
fbertux
referenced
this pull request
in OSSystems/u-boot
Sep 29, 2020
Compiling U-Boot with ubsan/asan libraries and running it in sandbox
may lead to below backtrace:
=> avb init 0
=> avb verify
## Android Verified Boot 2.0 version 1.1.0
read_is_device_unlocked not supported yet
common/avb_verify.c:407:31: runtime error: division by zero
AddressSanitizer:DEADLYSIGNAL
Reviewed-by: Igor Opaniuk <igor.opaniuk@linaro.org>
=================================================================
==9388==ERROR: AddressSanitizer: FPE on unknown address 0x0000004b467f \
(pc 0x0000004b467f bp 0x000000000000 sp 0x7ffd899fe150 T0)
#0 0x4b467e in mmc_byte_io common/avb_verify.c:407
#1 0x4b4c47 in mmc_byte_io common/avb_verify.c:532
#2 0x4b4c47 in read_from_partition common/avb_verify.c:533
#3 0x69dc0d in load_and_verify_vbmeta lib/libavb/avb_slot_verify.c:560
#4 0x6a1ee6 in avb_slot_verify lib/libavb/avb_slot_verify.c:1139
#5 0x45dabd in do_avb_verify_part cmd/avb.c:245
#6 0x4af77c in cmd_call common/command.c:499
u-boot#7 0x4af77c in cmd_process common/command.c:538
u-boot#8 0x46bafc in run_pipe_real common/cli_hush.c:1677
u-boot#9 0x46bafc in run_list_real common/cli_hush.c:1875
u-boot#10 0x46c780 in run_list common/cli_hush.c:2024
u-boot#11 0x46c780 in parse_stream_outer common/cli_hush.c:3216
u-boot#12 0x46d34b in parse_file_outer common/cli_hush.c:3299
u-boot#13 0x4ad609 in cli_loop common/cli.c:217
u-boot#14 0x4625ae in main_loop common/main.c:65
u-boot#15 0x46f2d1 in run_main_loop common/board_r.c:648
u-boot#16 0x640253 in initcall_run_list lib/initcall.c:30
u-boot#17 0x46f9d0 in board_init_r common/board_r.c:879
u-boot#18 0x40539b in main arch/sandbox/cpu/start.c:321
u-boot#19 0x7fa94925f82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
u-boot#20 0x408908 in _start (/srv/R/u-boot-master/u-boot+0x408908)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: FPE common/avb_verify.c:407 in mmc_byte_io
==9388==ABORTING
Signed-off-by: Eugeniu Rosca <erosca@de.adit-jv.com>
nekromant
referenced
this pull request
in RC-MODULE/u-boot
Feb 3, 2021
…8-develop * commit '2c1893c30b8cfe7f1991cf41ab48b74d14bf3098': [Fix-Eth] PHY Initialization
lbmeng
added a commit
to lbmeng/u-boot
that referenced
this pull request
Feb 7, 2021
Add a reST document to describe how to build and run U-Boot for the QEMU ppce500 machine. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Series-to: Simon, Alexander Graf <agraf@csgraf.de>, Priyanka Jain <priyanka.jain@nxp.com> Series-cc: Tom, U-Boot Cover-letter: ppc: qemu: Convert qemu-ppce500 to driver model At present when building qemu-ppce500 the following warnings are seen: ===================== WARNING ====================== This board does not use CONFIG_DM. CONFIG_DM will be compulsory starting with the v2020.01 release. Failure to update may result in board removal. UPD include/generated/timestamp_autogenerated.h See doc/driver-model/migration.rst for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_PCI Please update the board to use CONFIG_DM_PCI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_ETH (Driver Model for Ethernet drivers). Please update the board to use CONFIG_DM_ETH before the v2020.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ==================================================== The conversion of qemu-ppce500 board to driver model is long overdue. When testing the exisitng qemu-ppce500 support, PCI was found broken. This is caused by 2 separate issues: - One issue was caused by U-Boot: Commit e002474 ("pci: pci-uclass: Dynamically allocate the PCI regions") Patch u-boot#1 reverts this commit as it broken all boards that have not converted to driver model PCI. - One issue was caused by QEMU: commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space") commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs") Patch u-boot#3-4 fixed this issue to keep in sync with latest QEMU upstream Patch u-boot#5-8 are minor fixes and clean-ups. Starting from patch#9, these are driver model conversion patches. Patch u-boot#11-16 are mainly related to CONFIG_ADDR_MAP, a library to support targets that have non-identity virtual-physical address mappings. A new command 'addrmap' is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post- relocation phase. Also the initialization of this library is moved a bit earlier in the post-relocation phase otherwise device drivers won't work. Patch u-boot#18-20 are 85xx PCI driver fixes. It adds the support to 64-bit bus and cpu address as current upstream QEMU uses 64-bit cpu address. Patch u-boot#23 is minor fix to the 'virtio' command dependency. Patch u-boot#24 enables the VirtIO NET support as by default a VirtIO standard PCI networking device is connected as an ethernet interface at PCI address 0.1.0. Patch u-boot#25 moves the qemu-ppce500 boards codes to board/emulation as that is the place for other QEMU targets like x86, arm, riscv. Patch u-boot#26 adds a reST document to describe how to build and run U-Boot for the QEMU ppce500 machine. I hope we can make this series to U-Boot v2021.04 release. This series is available at u-boot-x86/qemu-ppc for testing. This cover letter is cc'ed to QEMU mailing list for a heads-up. A future patch will be sent to QEMU mailing list to bring its in-tree U-Boot source codes up-to-date. END
lbmeng
added a commit
to lbmeng/u-boot
that referenced
this pull request
Feb 7, 2021
Add a reST document to describe how to build and run U-Boot for the QEMU ppce500 machine. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Series-to: Simon, Alexander Graf <agraf@csgraf.de>, Priyanka Jain <priyanka.jain@nxp.com> Series-cc: Tom, U-Boot Cover-letter: ppc: qemu: Convert qemu-ppce500 to driver model At present when building qemu-ppce500 the following warnings are seen: ===================== WARNING ====================== This board does not use CONFIG_DM. CONFIG_DM will be compulsory starting with the v2020.01 release. Failure to update may result in board removal. UPD include/generated/timestamp_autogenerated.h See doc/driver-model/migration.rst for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_PCI Please update the board to use CONFIG_DM_PCI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_ETH (Driver Model for Ethernet drivers). Please update the board to use CONFIG_DM_ETH before the v2020.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ==================================================== The conversion of qemu-ppce500 board to driver model is long overdue. When testing the exisitng qemu-ppce500 support, PCI was found broken. This is caused by 2 separate issues: - One issue was caused by U-Boot: Commit e002474 ("pci: pci-uclass: Dynamically allocate the PCI regions") Patch u-boot#1 reverts this commit as it broken all boards that have not converted to driver model PCI. - One issue was caused by QEMU: commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space") commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs") Patch u-boot#3-4 fixed this issue to keep in sync with latest QEMU upstream Patch u-boot#5-8 are minor fixes and clean-ups. Starting from patch#9, these are driver model conversion patches. Patch u-boot#11-16 are mainly related to CONFIG_ADDR_MAP, a library to support targets that have non-identity virtual-physical address mappings. A new command 'addrmap' is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post- relocation phase. Also the initialization of this library is moved a bit earlier in the post-relocation phase otherwise device drivers won't work. Patch u-boot#18-20 are 85xx PCI driver fixes. It adds support to controller register physical address beyond 32-bit, as well as support to 64-bit bus and cpu address as current upstream QEMU uses 64-bit cpu address. Patch u-boot#23 is minor fix to the 'virtio' command dependency. Patch u-boot#24 enables the VirtIO NET support as by default a VirtIO standard PCI networking device is connected as an ethernet interface at PCI address 0.1.0. Patch u-boot#25 moves the qemu-ppce500 boards codes to board/emulation as that is the place for other QEMU targets like x86, arm, riscv. Patch u-boot#26 adds a reST document to describe how to build and run U-Boot for the QEMU ppce500 machine. I hope we can make this series to U-Boot v2021.04 release. This series is available at u-boot-x86/qemu-ppc for testing. This cover letter is cc'ed to QEMU mailing list for a heads-up. A future patch will be sent to QEMU mailing list to bring its in-tree U-Boot source codes up-to-date. END
lbmeng
added a commit
to lbmeng/u-boot
that referenced
this pull request
Feb 18, 2021
Add a reST document to describe how to build and run U-Boot for the QEMU ppce500 machine. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Series-version: 2 Series-changes: 2 - add descriptions for VirtIO BLK, RTC and power off Series-to: Simon, Alexander Graf <agraf@csgraf.de>, Priyanka Jain <priyanka.jain@nxp.com> Series-cc: Tom, U-Boot Cover-letter: ppc: qemu: Convert qemu-ppce500 to driver model and enable additional driver support At present when building qemu-ppce500 the following warnings are seen: ===================== WARNING ====================== This board does not use CONFIG_DM. CONFIG_DM will be compulsory starting with the v2020.01 release. Failure to update may result in board removal. UPD include/generated/timestamp_autogenerated.h See doc/driver-model/migration.rst for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_PCI Please update the board to use CONFIG_DM_PCI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_ETH (Driver Model for Ethernet drivers). Please update the board to use CONFIG_DM_ETH before the v2020.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ==================================================== The conversion of qemu-ppce500 board to driver model is long overdue. When testing the exisitng qemu-ppce500 support, PCI was found broken. This is caused by 2 separate issues: - One issue was caused by U-Boot: Commit e002474 ("pci: pci-uclass: Dynamically allocate the PCI regions") Patch u-boot#1 updated the non-DM fsl_pci_init driver to dynamically allocate the PCI regions, to keep in sync with the pci uclass driver - One issue was caused by QEMU: commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space") commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs") Patch u-boot#3-4 fixed this issue to keep in sync with latest QEMU upstream Patch u-boot#5-8, u-boot#34-36 are minor fixes and clean-ups. Starting from patch#9, these are driver model conversion patches. Patch u-boot#11-17 are mainly related to CONFIG_ADDR_MAP, a library to support targets that have non-identity virtual-physical address mappings. A new command 'addrmap' is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post- relocation phase. Also the initialization of this library is moved a bit earlier in the post-relocation phase otherwise device drivers won't work. Patch u-boot#19-21 are 85xx PCI driver fixes. It adds support to controller register physical address beyond 32-bit, as well as support to 64-bit bus and cpu address as current upstream QEMU uses 64-bit cpu address. Starting from patch#24, these are additional driver support patches. Patch u-boot#24, u-boot#26 are minor fix to the 'virtio' command and BLK driver dependency. Patch u-boot#25 enables the VirtIO NET support as by default a VirtIO standard PCI networking device is connected as an ethernet interface at PCI address 0.1.0. Patch u-boot#27 enables the VirtIO BLK driver support. Patch u-boot#28-30 enables the GPIO support. Patch u-boot#31-32 enables poweroff via GPIO. Patch u-boot#33 enables RTC over the I2C bus. Patch u-boot#37 moves the qemu-ppce500 boards codes to board/emulation as that is the place for other QEMU targets like x86, arm, riscv. Patch u-boot#38 adds a reST document to describe how to build and run U-Boot for the QEMU ppce500 machine. I hope we can make this series to U-Boot v2021.04 release. This series is available at u-boot-x86/qemu-ppc for testing. This cover letter is cc'ed to QEMU mailing list for a heads-up. A future patch will be sent to QEMU mailing list to bring its in-tree U-Boot source codes up-to-date. END
trini
pushed a commit
that referenced
this pull request
Feb 22, 2021
Add adc-keys device to the sandbox/test.dts and connect it to the channel #3 of the sandbox_adc driver. The default values sampled by sandbox_adc driver determines that button3 and button4 are released and button5 is pressed. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
lbmeng
added a commit
to lbmeng/u-boot
that referenced
this pull request
Feb 25, 2021
Add a reST document to describe how to build and run U-Boot for the QEMU ppce500 machine. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Priyanka Jain <priyanka.jain@nxp.com> Series-version: 3 Series-changes: 3 - rebase on top of u-boot/master Series-changes: 2 - add descriptions for VirtIO BLK, RTC and power off Series-to: Simon, Alexander Graf <agraf@csgraf.de>, Priyanka Jain <priyanka.jain@nxp.com> Series-cc: Tom, U-Boot Cover-letter: ppc: qemu: Convert qemu-ppce500 to driver model and enable additional driver support At present when building qemu-ppce500 the following warnings are seen: ===================== WARNING ====================== This board does not use CONFIG_DM. CONFIG_DM will be compulsory starting with the v2020.01 release. Failure to update may result in board removal. UPD include/generated/timestamp_autogenerated.h See doc/driver-model/migration.rst for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_PCI Please update the board to use CONFIG_DM_PCI before the v2019.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ==================================================== ===================== WARNING ====================== This board does not use CONFIG_DM_ETH (Driver Model for Ethernet drivers). Please update the board to use CONFIG_DM_ETH before the v2020.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. ==================================================== The conversion of qemu-ppce500 board to driver model is long overdue. When testing the exisitng qemu-ppce500 support, PCI was found broken. This is caused by 2 separate issues: - One issue was caused by U-Boot: Commit e002474 ("pci: pci-uclass: Dynamically allocate the PCI regions") Patch u-boot#1 updated the non-DM fsl_pci_init driver to dynamically allocate the PCI regions, to keep in sync with the pci uclass driver - One issue was caused by QEMU: commit e6b4e5f4795b ("PPC: e500: Move CCSR and MMIO space to upper end of address space") commit cb3778a0455a ("PPC: e500 pci host: Add support for ATMUs") Patch u-boot#3-4 fixed this issue to keep in sync with latest QEMU upstream Patch u-boot#5-8, u-boot#34-36 are minor fixes and clean-ups. Starting from patch#9, these are driver model conversion patches. Patch u-boot#11-17 are mainly related to CONFIG_ADDR_MAP, a library to support targets that have non-identity virtual-physical address mappings. A new command 'addrmap' is introduced to aid debugging, and a fix to arch/powerpc/asm/include/io.h is made to correct the usage of CONFIG_ADDR_MAP as it can only be used in the post- relocation phase. Also the initialization of this library is moved a bit earlier in the post-relocation phase otherwise device drivers won't work. Patch u-boot#19-21 are 85xx PCI driver fixes. It adds support to controller register physical address beyond 32-bit, as well as support to 64-bit bus and cpu address as current upstream QEMU uses 64-bit cpu address. Starting from patch#24, these are additional driver support patches. Patch u-boot#24, u-boot#26 are minor fix to the 'virtio' command and BLK driver dependency. Patch u-boot#25 enables the VirtIO NET support as by default a VirtIO standard PCI networking device is connected as an ethernet interface at PCI address 0.1.0. Patch u-boot#27 enables the VirtIO BLK driver support. Patch u-boot#28-30 enables the GPIO support. Patch u-boot#31-32 enables poweroff via GPIO. Patch u-boot#33 enables RTC over the I2C bus. Patch u-boot#37 moves the qemu-ppce500 boards codes to board/emulation as that is the place for other QEMU targets like x86, arm, riscv. Patch u-boot#38 adds a reST document to describe how to build and run U-Boot for the QEMU ppce500 machine. I hope we can make this series to U-Boot v2021.04 release. This series is available at u-boot-x86/qemu-ppc for testing. This cover letter is cc'ed to QEMU mailing list for a heads-up. A future patch will be sent to QEMU mailing list to bring its in-tree U-Boot source codes up-to-date. END
apalos
referenced
this pull request
in apalos/u-boot
Mar 4, 2021
Add adc-keys device to the sandbox/test.dts and connect it to the channel #3 of the sandbox_adc driver. The default values sampled by sandbox_adc driver determines that button3 and button4 are released and button5 is pressed. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
unframework
referenced
this pull request
in unframework/u-boot
Mar 21, 2021
Rebased PR #3 from Lichee-Pi/u-boot
Mr-Bossman
pushed a commit
to Mr-Bossman/u-boot
that referenced
this pull request
Dec 12, 2021
Post-Icenowy fixes due to changes to includes and Makefiles
Mr-Bossman
pushed a commit
to Mr-Bossman/u-boot
that referenced
this pull request
Dec 12, 2021
Nano v2018.01
svenschwermer
added a commit
to svenschwermer/u-boot
that referenced
this pull request
Feb 9, 2022
Add ccon-02 board support Approved-by: Fredrik Flornes Ellertsen
matwey
added a commit
to matwey/u-boot
that referenced
this pull request
Aug 23, 2022
There are three different kinds of EEPROM possibly present on boards.
1. 1byte address. For those we should avoid 2byte address in order
not to rewrite the data. Second byte of the address can potentially
be interpreted as the data to write.
2. 2byte address with defined behaviour. When we try to use 1byte
address they just return "FF FF FF FF ... FF"
3. 2byte address with undefined behaviour (for instance, 24LC32AI).
When we try to use 1byte address, then their internal read
pointer is changed to some value. Subsequential reads may be
broken.
To gracefully handle both case u-boot#1 and case u-boot#3 we read all required
data from EEPROM at once (about 80 bytes). So either all the data is
valid or we fallback to 2byte address.
Cc: Nishanth Menon <nm@ti.com>
Fixes: a58147c ("board: ti: common: board_detect: Do 1byte address checks first.")
Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
matwey
added a commit
to matwey/u-boot
that referenced
this pull request
Aug 23, 2022
There are three different kinds of EEPROM possibly present on boards.
1. 1byte address. For those we should avoid 2byte address in order
not to rewrite the data. Second byte of the address can potentially
be interpreted as the data to write.
2. 2byte address with defined behaviour. When we try to use 1byte
address they just return "FF FF FF FF ... FF"
3. 2byte address with undefined behaviour (for instance, 24LC32AI).
When we try to use 1byte address, then their internal read
pointer is changed to some value. Subsequential reads may be
broken.
To gracefully handle both case u-boot#1 and case u-boot#3 we read all required
data from EEPROM at once (about 80 bytes). So either all the data is
valid or we fallback to 2byte address.
Cc: Nishanth Menon <nm@ti.com>
Fixes: a58147c ("board: ti: common: board_detect: Do 1byte address checks first.")
Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/
Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
trini
pushed a commit
that referenced
this pull request
Aug 31, 2022
There are three different kinds of EEPROM possibly present on boards.
1. 1byte address. For those we should avoid 2byte address in order
not to rewrite the data. Second byte of the address can potentially
be interpreted as the data to write.
2. 2byte address with defined behaviour. When we try to use 1byte
address they just return "FF FF FF FF ... FF"
3. 2byte address with undefined behaviour (for instance, 24LC32AI).
When we try to use 1byte address, then their internal read
pointer is changed to some value. Subsequential reads may be
broken.
To gracefully handle both case #1 and case #3 we read all required
data from EEPROM at once (about 80 bytes). So either all the data is
valid or we fallback to 2byte address.
Cc: Nishanth Menon <nm@ti.com>
Fixes: a58147c ("board: ti: common: board_detect: Do 1byte address checks first.")
Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/
Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Acked-by: Nishanth Menon <nm@ti.com>
jdolanIV
pushed a commit
to accesio/u-boot
that referenced
this pull request
Jun 28, 2023
commit bf63766 upstream. There are three different kinds of EEPROM possibly present on boards. 1. 1byte address. For those we should avoid 2byte address in order not to rewrite the data. Second byte of the address can potentially be interpreted as the data to write. 2. 2byte address with defined behaviour. When we try to use 1byte address they just return "FF FF FF FF ... FF" 3. 2byte address with undefined behaviour (for instance, 24LC32AI). When we try to use 1byte address, then their internal read pointer is changed to some value. Subsequential reads may be broken. To gracefully handle both case u-boot#1 and case u-boot#3 we read all required data from EEPROM at once (about 80 bytes). So either all the data is valid or we fallback to 2byte address. Cc: Nishanth Menon <nm@ti.com> Fixes: a58147c ("board: ti: common: board_detect: Do 1byte address checks first.") Reference: https://lore.kernel.org/all/CAJs94Ebdd4foOjhGFu9Bop0v=B1US9neDLxfhgcY23ukgLzFOQ@mail.gmail.com/ Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> Acked-by: Nishanth Menon <nm@ti.com>
RadxaNaoki
pushed a commit
to RadxaNaoki/u-boot
that referenced
this pull request
Nov 13, 2024
Ilias Apalodimas <ilias.apalodimas@linaro.org> says: Hi all, This is a respin of [1] adding https support to wget. In short patch#1 enables the crypto algorithms we need in mbedTLS patches#2, u-boot#3 enable anf fix the lwIP part we need patch#4 is adding https:// parsing support in our wget patch#5 is making https:// the default for QEMU lwip defconfig so people can easily test and finaly patch#6 updates our documentation [1] https://lore.kernel.org/u-boot/20241024112449.1362319-1-ilias.apalodimas@linaro.org/ Link: https://lore.kernel.org/r/20241110083017.367565-1-ilias.apalodimas@linaro.org
raymo200915
added a commit
to raymo200915/u-boot-github
that referenced
this pull request
Nov 18, 2024
Add detailed SMBIOS information as following: 1. Missing fields in Type u-boot#3 and u-boot#4 2. Type u-boot#7 Add support to dynamic length of contained object handles and elements. As SMBIOS is a fundamental feature which is enabled for all boards, in order to avoid increasing rom size, all detailed SMBIOS information is under kconfig GENERATE_SMBIOS_TABLE_VERBOSE. Board maintainers can determine whether to select this feature. Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
raymo200915
added a commit
to raymo200915/u-boot-github
that referenced
this pull request
Nov 21, 2024
Add detailed SMBIOS information as following: 1. Missing fields in Type u-boot#3 and u-boot#4 2. Type u-boot#7 Add support to dynamic length of contained object handles and elements. As SMBIOS is a fundamental feature which is enabled for all boards, in order to avoid increasing rom size, all detailed SMBIOS information is under kconfig GENERATE_SMBIOS_TABLE_VERBOSE. Board maintainers can determine whether to select this feature. Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
raymo200915
added a commit
to raymo200915/u-boot-github
that referenced
this pull request
Dec 5, 2024
Add detailed SMBIOS information as following: 1. Missing fields in Type u-boot#3 and u-boot#4 2. Type u-boot#7 Add support to dynamic length of contained object handles and elements. As SMBIOS is a fundamental feature which is enabled for all boards, in order to avoid increasing rom size, all detailed SMBIOS information is under kconfig GENERATE_SMBIOS_TABLE_VERBOSE. Board maintainers can determine whether to select this feature. Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
RadxaNaoki
pushed a commit
to RadxaNaoki/u-boot
that referenced
this pull request
Jan 14, 2025
Add detailed SMBIOS information as following: 1. Missing fields in Type u-boot#3 and u-boot#4 2. Type u-boot#7 Add support to dynamic length of contained object handles and elements. As SMBIOS is a fundamental feature which is enabled for all boards, in order to avoid increasing rom size, all detailed SMBIOS information is under kconfig GENERATE_SMBIOS_TABLE_VERBOSE. Board maintainers can determine whether to select this feature. Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
RadxaNaoki
pushed a commit
to RadxaNaoki/u-boot
that referenced
this pull request
Jan 14, 2025
Raymond Mao <raymond.mao@linaro.org> says: Motivations for changes: Current SMBIOS library and command-line tool is not fully matching with the requirements: 1. Missing support for other mandatory types (u-boot#7, u-boot#9, u-boot#16, u-boot#17, u-boot#19). 2. Only a few platforms support SMBIOS node from the device tree. 3. Values of some fields are hardcoded in the library other than fetching from the device hardware. 4. Embedded data with dynamic length is not supported (E.g. Contained Object Handles in Type u-boot#2 and Contained Elements in Type u-boot#3) Changes: 1. Refactor the SMBIOS library and command-line tool to better align with the SMBIOS spec. 2. Create an arch-specific driver for all aarch64-based platforms to fetch SMBIOS private data from the device hardware (processor and cache). 3. Create a sysinfo driver to poppulate platform SMBIOS private data. 4. Add generic SMBIOS DTS file for arm64 platforms for those common strings and values which cannot be retrieved from the system registers. Vendors can create their own SMBIOS node using this as an example. For those boards without SMBIOS nodes, this DTS file can be included to have a generic SMBIOS information of the system. 5. Add support for Type u-boot#7 (Cache Information) and link its handles to Type u-boot#4. 6. To minimize size-growth for those platforms which have not sufficient ROM spaces or the platforms which don't need detailed SMBIOS information, new added fields are only being built when kconfig GENERATE_SMBIOS_TABLE_VERBOSE is selected. Once this patch is acceptted, subsequent patch sets will add other missing types (u-boot#9, u-boot#16, u-boot#17, u-boot#19). Tests: To test this with QEMU arm64, please follow the guide on dt_qemu.rst to get a merged DT to run with. ``` qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \ | dtc - -o merged.dtb qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \ -dtb merged.dtb ``` Link: https://lore.kernel.org/r/20241206225438.13866-1-raymond.mao@linaro.org
trini
pushed a commit
that referenced
this pull request
Jan 14, 2025
Add detailed SMBIOS information as following: 1. Missing fields in Type #3 and #4 2. Type #7 Add support to dynamic length of contained object handles and elements. As SMBIOS is a fundamental feature which is enabled for all boards, in order to avoid increasing rom size, all detailed SMBIOS information is under kconfig GENERATE_SMBIOS_TABLE_VERBOSE. Board maintainers can determine whether to select this feature. Signed-off-by: Raymond Mao <raymond.mao@linaro.org>
trini
added a commit
that referenced
this pull request
Jan 14, 2025
Raymond Mao <raymond.mao@linaro.org> says: Motivations for changes: Current SMBIOS library and command-line tool is not fully matching with the requirements: 1. Missing support for other mandatory types (#7, #9, #16, #17, #19). 2. Only a few platforms support SMBIOS node from the device tree. 3. Values of some fields are hardcoded in the library other than fetching from the device hardware. 4. Embedded data with dynamic length is not supported (E.g. Contained Object Handles in Type #2 and Contained Elements in Type #3) Changes: 1. Refactor the SMBIOS library and command-line tool to better align with the SMBIOS spec. 2. Create an arch-specific driver for all aarch64-based platforms to fetch SMBIOS private data from the device hardware (processor and cache). 3. Create a sysinfo driver to poppulate platform SMBIOS private data. 4. Add generic SMBIOS DTS file for arm64 platforms for those common strings and values which cannot be retrieved from the system registers. Vendors can create their own SMBIOS node using this as an example. For those boards without SMBIOS nodes, this DTS file can be included to have a generic SMBIOS information of the system. 5. Add support for Type #7 (Cache Information) and link its handles to Type #4. 6. To minimize size-growth for those platforms which have not sufficient ROM spaces or the platforms which don't need detailed SMBIOS information, new added fields are only being built when kconfig GENERATE_SMBIOS_TABLE_VERBOSE is selected. Once this patch is acceptted, subsequent patch sets will add other missing types (#9, #16, #17, #19). Tests: To test this with QEMU arm64, please follow the guide on dt_qemu.rst to get a merged DT to run with. ``` qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb ./dts/dt.dtb | grep -v /dts-v1/) \ | dtc - -o merged.dtb qemu-system-aarch64 -machine virt -nographic -bios u-boot.bin \ -dtb merged.dtb ``` Link: https://lore.kernel.org/r/20241206225438.13866-1-raymond.mao@linaro.org
ArchUsr64
added a commit
to ArchUsr64/u-boot
that referenced
this pull request
May 23, 2025
For properly configuring the MMU on various k3 platforms, the
reserved-memory regions need to be queried at runtime from the
device-tree and the MMU table should be updated accordingly.
For the A-core SPL, the DDR is divided into three areas as follows:
0x80000000 +------------------+ CFG_SYS_SDRAM_BASE
| |
512KiB | u-boot#1 Non cacheable | reserved for ATF/OP-TEE
| |
0x80080000 |------------------| CONFIG_SPL_TEXT_BASE
| |
128MiB | u-boot#2 Cacheable | for runtime usage by the A-core SPL
| |
0x88080000 |------------------|
| |
1.9GiB | u-boot#3 Non cacheable | reserved for DM/tifs-stub etc.
| |
0x100000000 +------------------+ End of DDR
This patch adds the required fixups to the MMU table (during proper
U-boot stage) from dram_init as follows:
1. Apply the fixups to the reserved-memory node by fdt_fixup_reserved.
2. Loop through all the subnodes in reserved-memory, marking each as
non-cacheable.
3. Query the DT for memory size and create cacheable regions spanning
the entire DDR with reserved regions carved out.
Signed-off-by: Anshul Dalal <anshuld@ti.com>
ArchUsr64
added a commit
to ArchUsr64/u-boot
that referenced
this pull request
May 28, 2025
Currently in upstream u-boot we only provide a single MMU table for
all k3 platforms, this does not scale for devices with reserved memory
outside the range 0x9e780000 - 0xa0000000 (eg j722s[1]) or for devices
with < 2GiB of memory
852C
(eg am62sip).
To properly configure the MMU on various k3 platforms, the
reserved-memory regions need to be queried at runtime from the
device-tree and the MMU table should be updated accordingly.
This patch adds the required fixups to the MMU table (during proper
U-boot stage) by marking the reserved regions as non cacheable and
the remaining area as cacheable.
For the A-core SPL, the DDR is divided into three areas as follows:
0x80000000 +------------------+ CFG_SYS_SDRAM_BASE
| |
512KiB | u-boot#1 Non cacheable | reserved for ATF/OP-TEE
| |
0x80080000 |------------------| CONFIG_SPL_TEXT_BASE
| |
128MiB | u-boot#2 Cacheable | for runtime usage by the A-core SPL
| |
0x88080000 |------------------|
| |
1.9GiB | u-boot#3 Non cacheable | reserved for DM/tifs-stub etc.
| |
0x100000000 +------------------+ End of DDR
The 128MiB size is chosen to allow for future use cases such as A53 SPL
falcon boot which would require loading kernel image from the SPL stage
while also ensuring the reserved memory regions that all exist past
0x88080000 are non cacheable.
[1]:
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/arch/arm/mach-k3/arm64/arm64-mmu.c?h=ti-u-boot-2025.01-next#n54
Depends on:
[PATCH v1] ti: k3: abstract common fdt api for reserved mem fixups
https://lore.kernel.org/u-boot/20250522150941.563959-1-anshuld@ti.com/
Boot test:
http://lcpdresults.itg.ti.com/launcher/results/28618
(*internal link*: will be removed before posting upstream)
Signed-off-by: Anshul Dalal <anshuld@ti.com>
trini
pushed a commit
that referenced
this pull request
Jun 17, 2025
The btt[c3] devices are based on imx287 SoC. U-Boot SPL 2025.04-01081-g07e086681d26 (Apr 16 2025 - 12:24:36 +0200) Trying to boot from MMC1 U-Boot 2025.04-01081-g07e086681d26 (Apr 16 2025 - 12:24:36 +0200) CPU: Freescale i.MX28 rev1.2 at 454 MHz BOOT: SSP SPI #3, master, 3V3 NOR Model: BTT3 Board: LWE BTT SoM HW rev 0 DRAM: 256 MiB Core: 86 devices, 15 uclasses, devicetree: separate MMC: MXS MMC: 0 Loading Environment from SPIFlash... SF: Detected is25lp128 with page size 256 Bytes, erase size 64 KiB, total 16 MiB OK In: serial@80074000 Out: serial@80074000 Err: serial@80074000 Net: eth0: ethernet@800f0000 Hit any key to stop autoboot: 0 Signed-off-by: Lukasz Majewski <lukma@denx.de>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.