summaryrefslogtreecommitdiff
path: root/board/liebherr/btt
AgeCommit message (Collapse)Author
2026-06-24treewide: move bi_dram[] from bd to gdIlias Apalodimas
Currently, the bi_dram[] information is stored in the board info structure (bd). Because bd is only valid after reserve_board(), dram_init_banksize() must be called late in the initialization process. This limitation is problematic, as it forces us to rely on a variety of bespoke functions to determine board RAM, bank memory sizes, and other early setup requirements. By moving bi_dram[] into the global data (gd), we can run it earlier. This is particularly convenient since boards define their own dram_init_banksize() routines, which do not always rely on parsing Device Tree (DT) memory nodes. Additionally, U-Boot defaults to relocating to the top of the first memory bank. While boards currently use custom functions to override this behavior, having the DRAM bank information available earlier in gd makes relocating to a different bank trivial and standardizes the process. Reviewed-by: Anshul Dalal <[email protected]> Tested-by: Michal Simek <[email protected]> # Versal Gen 2 Vek385 Tested-by: Anshul Dalal <[email protected]> Reviewed-by: Simon Glass <[email protected]> Signed-off-by: Ilias Apalodimas <[email protected]> Tested-by: Christophe Leroy (CS GROUP) <[email protected]>
2026-04-07global: Correct duplicate U_BOOT_DRIVER entry namesTom Rini
The U_BOOT_DRIVER macro creates a list of drivers used at link time, and all entries here must be unique. This in turn means that all entries in the code should also be unique in order to not lead to build failures later with unexpected build combinations. Typically, the problem we have here is when a driver is obviously based on another driver and didn't update this particular field and so while the name field reflects something unique the linker entry itself is not. In a few places this provides a more suitable string name as well, however. Reviewed-by: Marek Vasut <[email protected]> Reviewed-by: Svyatoslav Ryhel <[email protected]> # Tegra Reviewed-by: Peter Robinson <[email protected]> Reviewed-by: Heiko Schocher <[email protected]> Reviewed-by: Simon Glass <[email protected]> Signed-off-by: Tom Rini <[email protected]>
2026-03-16liebherr: btt: Fix buffer overflow in board_fit_config_name_matchFrancois Berder
The maximum length of the board name is not 11 characters but 14: 11 bytes for the prefix + 3 bytes for the u8 + 1 NULL byte. Hence, this commit increases the size of the name buffer variable to 15. Also, this commit fixes the format specifier for the rev_id variable. Signed-off-by: Francois Berder <[email protected]>
2025-10-30liebherr: btt: shrink spl_board_initRasmus Villemoes
This board is very tight on space in SPL; in fact with my compiler it ends up just exactly on the wrong side: spl/u-boot-spl.bin exceeds file size limit: limit: 0xa000 bytes actual: 0xa014 bytes excess: 0x14 bytes The repeated "lookup and request" pattern in spl_board_init() suggests a low-hanging fruit for reducing the code size. This reduces the object size of spl/board/liebherr/btt/btt.o by 300 bytes. I've left the lack of error handling as-is; there isn't really anything to do if it fails, so I suppose the printfs are the best that can be done. Signed-off-by: Rasmus Villemoes <[email protected]>
2025-06-16ARM: imx: mxs: Add support for imx287 based BTT devicesLukasz Majewski
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 <[email protected]>