- Jan 14, 2022
-
-
For debugging purposes it is good to know where the binary image would be loaded and also it is needed to know if printed size is image size or the size of header together with image. Make it unambiguous by showing that printed size is not the size of the whole header, but only the size of executable code, and print also the executable offset of this binary image. Load/execute address is the offset relative to the base address (either 0x40004000 or 0x40000000). Signed-off-by:
Pali Rohár <pali@kernel.org> Reviewed-by:
Stefan Roese <sr@denx.de>
-
Data delay is stored as 8-bit number in kwbimage structure. Ensure the given value is at most 255. Signed-off-by:
Marek Behún <marek.behun@nic.cz> Reviewed-by:
-
BootROMs on pre-A38x SoCs enabled its output on UART by default, but A38x' BootROM has its output on UART disabled by default. To enable BootROM output on A38x SoC, it is required to set DEBUG flag (which only enables BootROM output and nothing more) in kwbimage. For UART images this DEBUG flag is ignored by BootROM. Enable kwbimage DEBUG flag for all A38x boards. With this change BootROM prints the following (success) information on UART before booting U-Boot kwbimage: BootROM - 1.73 Booting from SPI flash Signed-off-by:
-
This alignment is required only for platforms based on Sheeva CPU core which are A370 and AXP. Now when U-Boot build system correctly propagates LOAD_ADDRESS there is no need to have enabled 128-bit boundary alignment on platforms which do not need it. Previously it was required because load address was implicitly rounded to 128-bit boundary and U-Boot build system expected it and misused it. Now with explicit setting of LOAD_ADDRESS there is no guessing for load address anymore. Signed-off-by:
-
U-Boot SPL for mvebu platform is not compiled as position independent. Therefore it is required to instruct BootROM to load U-Boot SPL at the correct address. Loading of kwbimage binary code at specific address can be now achieved by the new LOAD_ADDRESS token as part of BINARY command in kwbimage config file. Update mvebu Makefile to put value of $(CONFIG_SPL_TEXT_BASE) into LOAD_ADDRESS token when generating kwbimage.cfg from kwbimage.cfg.in. It is required to update regex for sed to find replacement tokens at any position on a line in kwbimage config file and not only at the beginning of the line. This is because LOAD_ADDRESS is specified at the end of line containing the BINARY command. It looks like all Armada boards set CONFIG_SPL_TEXT_BASE to value 0x40004030 or 0x40000030. Why this value? It is because main kwbimage header is at address 0x40004030 or 0x40000000 and it is 32 bytes long. After the main header there is the binary header, which consist of 1 byte for type, 3 bytes for size, 1 byte for number of arguments, 3 reserved bytes and then 4 bytes for each argument. After these arguments comes the executable code. So arguments start at address 0x40004028 or 0x40000028. Before commit e6571f38 ("arm: mvebu: Remove dummy BIN header arguments for SPL binary") there were two (dummy) arguments, which resulted in load address of 0x40004030 or 0x40000030, always. After that commit (which removed dummy arguments), load address stayed same due to the 128-bit alignment done by mkimage. This patch now reflects the dependency between $(CONFIG_SPL_TEXT_BASE), load address and dummy kwbimage arguments, and allows the user to adjust $(CONFIG_SPL_TEXT_BASE) config option to some other value. For unsupported values, when mkimage/kwbimage cannot set chosen load address as specified by $(CONFIG_SPL_TEXT_BASE), the build process now fails, instead of silently generating non-working kwbimage. Removal of this alignment between $(CONFIG_SPL_TEXT_BASE) and LOAD_ADDRESS can only be done by compiling U-Boot SPL as position independent. But this currently is not possible for 32-bit ARM version of U-Boot SPL. Signed-off-by:
-
kwbimage needs to know CPU type, so set it in kwbimage config file. Signed-off-by:
-
BootROM loads kwbimage header to L2-SRAM and BootROM reserve only 192 kB for it. Signed-off-by:
-
Function image_headersz_v1() may return zero on fatal errors. In this case the function already printed an error message. Check the return value of image_headersz_v1() in kwbimage_generate(), and exit on zero value with EXIT_FAILURE. Signed-off-by:
-
ARM executable code included in kwbimage binary header, which is not position independent, needs to be loaded and executed by BootROM at the correct fixed address. Armada BootROMs load kwbimage header (in which the executable code is also stored) at fixed address 0x40004000 or 0x40000000 which is mapped to L2-SRAM (L2 Cache as SRAM). Address 0x40004000 is used on Armada platforms with Sheeva CPU core (A370 and AXP) where BootROM uses MMU with 0x4000 bytes for MMU translation table. Address 0x40000000 is used on all other platforms. Thus the only way to specify load and execute address of this executable code in binary kwbimage header is by filling dummy arguments into the binary header, using the same mechanism we already have for achieving 128-bit boundary alignment on A370 and AXP SoCs. Extend kwbimage config file parser to allow to specify load address as part of BINARY command with syntax: BINARY path_to_binary arg1 arg2 ... argN LOAD_ADDRESS address If the specified load address is invalid or cannot be used, mkimage will throw fatal error and exit. This will prevent generating kwbimage with invalid load address for non-position independent binary code. If no load address is specified, kwbimage will not fill any the dummy arguments, thus it will behave the same as before this change. Signed-off-by: -
For other changes it is required to know if CPU core is Sheeva or not. Therefore add a new command CPU for specifying CPU. Signed-off-by:
-
Usage of $(call cmd,...) is standard way to call other commands which generate things. It also has the advantage of printing build information in the form KWBCFG arch/arm/mach-mvebu/kwbimage.cfg if verbosity is disabled, and printing the build command otherwise. Note that the '#' character needs to be escaped in Makefile when used as value for make variable assignment. Signed-off-by:
-
Preserve the order of BINARY, DATA and DATA_DELAY commands as they appear in the input file. They may depend on each other. Signed-off-by:
-
Register set header consists of sequence of DATA commands followed by exactly one DATA_DELAY command. Thus if we are generating image with multiple DATA_DELAY commands, we need to create more register set headers. Fix calculation of image size with multiple DATA_DELAY commands and correctly set pointer to struct register_set_hdr_v1 when initializing new register set header. Signed-off-by:
-
Deduplicate code that finishes OPT_HDR_V1_REGISTER_TYPE header by extracing it into separate function. Signed-off-by:
-
Mark all local functions as static. Signed-off-by:
-
This is a cleaned up and fixed version of a patch mv_ddr: a380: fix SPLIT_OUT_MIX state decision in each pattern cycle the bus state can be changed in order to avoide it, need to back to the same bus state on each pattern cycle by Moti Boskula <motib@marvell.com> The original patch is not in Marvell's mv-ddr-marvell repository. It was gives to us by Marvell to fix an issues with DDR training on some boards, but it cannot be applied as is to mv-ddr-marvell, because it is a very dirty draft patch that would certainly break other things, mainly DDR4 training code in mv-ddr-marvell, since it changes common functions. I have cleaned up the patch and removed stuff that seemed unnecessary (when removed, it still fixed things). Note that I don't understand completely what the code does exactly, since I haven't studied the DDR training code extensively (and I suspect that no one besides some few people in Marvell understand the code completely). Anyway after the cleanup the patch still fixes isssues with DDR training on the failing boards. There was also a problem with the original patch on some of the Allied Telesis' x530 boards, reported by Chris Packham. I have asked Chris to send me some logs, and managed to fix it: - if you look at the change, you'll notice that it introduces subtraction of cur_start_win[] and cur_end_win[] members, depending on a bit set in the current_byte_status variable - the original patch subtracted cur_start_win[] if either BYTE_SPLIT_OUT_MIX or BYTE_HOMOGENEOUS_SPLIT_OUT bits were set, but subtracted cur_end_win[] only if the first one (BYTE_SPLIT_OUT_MIX) was set - from Chris Packham logs I discovered that the x530 board where the original patch introduced DDR training failure, only the BYTE_HOMOGENEOUS_SPLIT_OUT bit was set, and on our boards where the patch is needed only the BYTE_SPLIT_OUT_MIX is set in the current_byte_status variable - this led me to the hypothesis that both cur_start_win[] and cur_end_win[] should be subtracted only if BYTE_SPLIT_OUT_MIX bit is set, the BYTE_HOMOGENEOUS_SPLIT_OUT bit shouldn't be considered at all - this hypothesis also gains credibility when considering the commit title ("fix SPLIT_OUT_MIX state decision") Hopefully this will fix things without breaking anything else. Signed-off-by:Chris Packham <judge.packham@gmail.com>
-
I got an <dirk.eibach@gdsys.cc>: host mxlb.ispgateway.de[80.67.18.126] said: 554 Sorry, no mailbox here by that name. (in reply to RCPT TO command) when sending e-mail to dirk.eibach@gdsys.cc. Drop Dirk Eibach from MAINTAINERS of board/gdsys/a38x and board/gdsys/mpc8308. The latter would be left maintainerless, add Mario Six <mario.six@gdsys.cc> (he is also maintainer of the former board). Signed-off-by:
-
Before commit 4c289425752f ("mv_ddr: a38x: add support for ddr async mode"), Asynchornous Mode was only used when the CPU Subsystem Clock Options[4:0] field in the SAR1 register was set to value 0x13: CPU at 2 GHz and DDR at 933 MHz. Then commit 4c289425752f ("mv_ddr: a38x: add support for ddr async mode") added support for Asynchornous Modes with frequencies other than 933 MHz (but at least 467 MHz), but the code it added to check for whether Asynchornous Mode should be used is wrong: it checks whether the frequency setting in board DDR topology map is set to value other than MV_DDR_FREQ_SAR. Thus boards which define a specific value, greater than 400 MHz, for DDR frequency in their board topology (e.g. Turris Omnia defines MV_DDR_FREQ_800), are incorrectly put into Asynchornous Mode after that commit. The A38x Functional Specification, section 10.12 DRAM Clocking, says: In Synchornous mode, the DRAM and CPU clocks are edge aligned and run in 1:2 or 1:3 CPU to DRAM frequency ratios. Change the check for whether Asynchornous Mode should be used according to this explanation in Functional Specification. Signed-off-by: -
Add myself as maintainer. Signed-off-by:
Tony Dinh <mibodhi@gmail.com> Reviewed-by:
-
- Add board_late_init function to enable pci_init Signed-off-by:
-
- Add MVEBU PCIe configs - Also add SYS_THUMB_BUILD to keep u-boot image size within 512K Signed-off-by:
-
The DT properties for the "enable-arbiter" and "keep-config" config knobs were previously named inconsistently: - The u-boot driver used "nand-enable-arbiter" and "nand-keep-config" names, without Marvell prefixes. - The Linux driver uses "marvell,nand-keep-config" ("enable-arbiter" does not exist anymore in recent kernels, but it also used to be "marvell,nand-enable-arbiter"). - The device trees almost all use "marvell," prefixed names, except for one single instance of "nand-enable-arbiter" without vendor prefix. This commit standardizes on the vendor prefixed version, making the u-boot driver read from DT props "marvell,nand-enable-arbiter" and "marvell,nand-keep-config". The one device tree using the unprefixed version is also changed to use the new naming. This has the side effect of making the previously no-op "marvell," config knobs already present in some DTs actually do something. This was likely the original intention of the DT authors, but note that this commit was not tested on every single impacted board. Signed-off-by:Pierre Bourdon <delroth@gmail.com>
-
As explained in commit 3bedbcc3 ("arm: mvebu: a38x: serdes: Don't overwrite read-only SAR PCIe registers") it is required to set Maximum Link Width bits of PCIe Root Port Link Capabilities Register depending of number of used serdes lanes. As this register is part of PCIe address space and not serdes address space, move it into pci_mvebu.c driver. Read number of PCIe lanes from DT property "num-lanes" which is used also by other PCIe controller drivers in Linux kernel. If this property is absent then it defaults to 1. This property needs to be set to 4 for every mvebu board which use PEX_ROOT_COMPLEX_X4 or PEX_BUS_MODE_X4. Enabling of PCIe port needs to be done afer all registers in PCIe address space are properly configure. For this purpose use new mvebu-reset driver (part of system-controller) and remove this code from serdes code. Because some PCIe ports cannot be enabled individually, it is required to first setup all PCIe ports and then enable them. This change contains also all required "num-lanes" and "resets" DTS properties, to make pci_mvebu.c driver work correctly. Signed-off-by:
-
Enabling and disabling PCIe ports is done via address space of system controller. All 32-bit Armada SoCs use low 4 bits in SoC Control 1 Register for enabling and disabling some or more PCIe ports. Correct mapping needs to be set in particular DTS files. DT API for mvebu-reset is prepared for implementing resets also for other HW blocks, but currently only PCIe is implemented via index 0. Currently this driver is not used as PCIe ports are automatically enabled by SerDes code executed by U-Boot SPL. But this will change in followup patches. Signed-off-by: -
After function mvebu_pcie_probe() returns U-Boot DM expects that PCIe link is already up. In followup patches link initialization will be moved from SPL to proper and therefore explicitly link up delay is required. Delay mvebu_pcie_probe() for 100ms to ensure that PCIe link is up after function finish. In the case when no card is connected to the PCIe slot, this will delay probe time by 100ms, which should not be problematic. This change fixes detection and initialization of some QCA98xx cards on the first serdes when configured in x1 mode. Default configuration of the first serdes on A385 is x4 mode, so it looks as if some delay is required when x4 is changed to x1 and card correctly links with A385. Other PCIe serdes ports on A385 are x1-only, and so they don't have this problem. Signed-off-by: -
In first phase just parse DT properties and fill struct mvebu_pcie. In second phase setup all PCIe links (without enabling them). And in the last third phase enable all PCIe links and create UCLASS_PCI device for each one. Because parsing of DT is done before UCLASS_PCI is created, we cannot use DM for this action anymore. So remove .of_to_plat callback and replace it by ad-hoc function for parsing DT properties and filling struct mvebu_pcie. Signed-off-by: -
SoC specific macro SOC_REGS_PHY_BASE is used for two things: * calculation of base PCIe port address * filling PCIe register with address of internal registers For calculating base PCIe port address use function ofnode_translate_address() which translates DT "assigned-addresses" to final PCIe port address. And for calculating address of internal registers use untranslated and translated DT "assigned-addresses". Basically this change reads SOC_REGS_PHY_BASE address indirectly from DT. Signed-off-by: -
Function mvebu_pcie_port_parse_dt() is called only from mvebu_pcie_of_to_plat() function. Both these function parse DT properties required to setup mvebu pcie. So inline mvebu_pcie_port_parse_dt() function into mvebu_pcie_of_to_plat() to have all code related to parsing DT properties at one place. Signed-off-by: -
Do not call pci_set_region() for resources which were not properly mapped. This prevents U-Boot to access unmapped memory space. Update MBUS_PCI_MEM_SIZE and MBUS_PCI_IO_SIZE macros to cover all PCIe MEM and IO ranges. Previously these macros covered only address ranges for the first PCIe port. Between MBUS_PCI_IO_BASE and MBUS_PCI_MEM_BASE there is space for six 128 MB long address ranges. So set MBUS_PCI_MEM_SIZE to value of 6*128 MB. Similarly set MBUS_PCI_IO_SIZE to 6*64 KB. Function resource_size() returns zero when start address is 0 and end address is -1. So set invalid resources to these values to indicate that resource has no mapping. Split global PCIe MEM and IO resources (defined by MBUS_PCI_*_* macros) into PCIe ports in mvebu_pcie_bind() function which allocates per-port based struct mvebu_pcie, instead of using global state variables mvebu_pcie_membase and mvebu_pcie_iobase. This makes pci_mvebu.c driver independent of global static variables (which store the state of allocation) and allows to bind and unbind the driver more times. Signed-off-by:
-
A385 controlcenterdc board does not use PCI DM properly and touches some PCIe devices directly in its board code. This controlcenterdc spl_board_init() function expects that PCIe link is already initialized. Link itself is initialized in a38x serdes code but this will change in future and link initialization will be postponed from U-Boot SPL to proper U-Boot. So explicitly enable PCIe link 2 in spl_board_init() function via SoC Control Register 1 to not break this code by future changes. This board has PCIe link 2 just x1, so no additional initialization (except enabling PCIe port) is needed. Signed-off-by: -
The only user of board_pex_config() weak function is A385 controlcenterdc board. It looks like that code in its board_pex_config() function needs to be executed after PCIe link is up. Therefore put this code into spl_board_init() function which is called after a38x serdes initialization, and therefore it is after the serdes hws_pex_config() function finishes (which is the state before this change). With this change completely remove board_pex_config() function as it is not used anymore. Signed-off-by:
-
- Jan 13, 2022
-
-
https://source.denx.de/u-boot/custodians/u-boot-dmTom Rini authored
bloblist prep for standard passage switch order of pinctrl and power domain calls various minor fixes
-
Simon Glass authored
This implementation is intended to be copied to other projects and modified, to as to foster a standard means of communcating runtime information between firmware projects. The GPL-2 license is too restrictive for some projects, e.g. those intended as reference implementations rather than designed for collaborative open-source development. Update the license to make this easier to share. Signed-off-by:Simon Glass <sjg@chromium.org>
-
Simon Glass authored
FIx up various minor errors and add the API documentation to the bloblist docs, since it is quite useful to see it in the same place. Signed-off-by: -
Simon Glass authored
Add a few convenience functions to obtain useful information about the bloblist. Signed-off-by: -
Simon Glass authored
At present we do support allocating the bloblist but the Kconfig is a bit strange, since we still have to specify an address in that case. Partly this is because it is a pain to have CONFIG options that disappears when its dependency is enabled. It means that we must have #ifdefs in the code, either in the C code or header file. Make use of IF_ENABLED_INT() and its friend to solve that problem, so we can separate out the location of bloblist into a choice. Put the address and size into variables so we can log the result. Add the options for SPL as well, so we can use CONFIG_IS_ENABLED(). Signed-off-by: -
Simon Glass authored
We typically refer to the different U-Boot builds that a board runs through as phases. This avoids confusion with the word 'stage' which is used with bootstage, for example. Fix up some bloblist Kconfig help which uses the wrong term. Signed-off-by: -
Simon Glass authored
Use the convenience functions to improve readability. Signed-off-by: -
Simon Glass authored
At present if someone adds a tag in the middle of the list it works well enough within a U-Boot build. But if these tags are used in another project, or with an older version of SPL, the numbers make become inconsistent. Use explicit tag numbers that never change, to resolve this problem. Allocate areas for existing U-Boot tags and set up an area for use by projects and vendors, as well as for private use. Keep tags above 0x10000 unallocated for now. Update bloblist_tag_name() and the tests to work with this new setup. Signed-off-by: -
Simon Glass authored
The EC event log tag is no-longer used. The vboot handoff is now handled by the vboot context instead. Drop these unused tags. Signed-off-by:
-
