- Jan 14, 2022
-
-
On boards using the RK3399 SoC, the USB OHCI and EHCI controllers share the same PHY device instance. While these controllers are being stopped they both attempt to power-off and deinitialize it, but trying to power-off the deinitialized PHY device results in a hang. This usually happens just before booting an OS, and can be explicitly triggered by running "usb start; usb stop" in the U-Boot shell. Implement a uclass-wide counting mechanism for PHY initialization and power state change requests, so that we don't power-off/deinitialize a PHY instance until all of its users want it done. The Allwinner A10 USB PHY driver does this counting in-driver, remove those parts in favour of this in-uclass implementation. The sandbox PHY operations test needs some changes since the uclass will no longer call into the drivers for actions matching its tracked state (e.g. powering-off a powered-off PHY). Update that test, and add a new one which simulates multiple users of a single PHY. The major complication here is that PHY handles aren't deduplicated per instance, so the obvious idea of putting the counts in the PHY handles don't immediately work. It seems possible to bind a child udevice per PHY instance to the PHY provider and deduplicate the handles in each child's uclass-private areas, like in the CLK framework. An alternative approach could be to use those bound child udevices themselves as the PHY handles. Instead, to avoid the architectural changes those would require, this patch solves things by dynamically allocating a list of structs (one per instance) in the provider's uclass-private area. Signed-off-by:
Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Tested-by: Peter Robinson <pbrobinson@gmail.com> - Rock960
-
BOOT_TARGET_DEVICES should only be added if the corresponding u-boot command is enabled otherwise the build will fail. Signed-off-by:Piotr Kubik <piotr_kubik@vp.pl>
-
Apple's ARMv8 cores don't implement EL3 and therefore don't provide a PSCI implementation. So don't attempt to use PSCI to reset on machines using Apple SoCs. Signed-off-by:Mark Kettenis <kettenis@openbsd.org>
-
Previously, a subpage with an uncorrectable error followed by a subpage with a correctable error would return an erroneous correctable status. Signed-off-by:
Joel Peshkin <joel.peshkin@broadcom.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by:
-
Reporting the return value should always be done on error conditions, this way the developer can start debugging issues with more knowledge in-hand. Signed-off-by:Samuel Dionne-Riel <samuel@dionne-riel.com>
-
The function was missing from exports, even though it loooks like the intent of the implementation in sscanf.c was to have it exported. Signed-off-by:
-
Let the check pass when patches have these patterns in their context. Signed-off-by:Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
-
Calling 'nvme scan' followed by 'nvme detail' crashes U-Boot on Turris Omnia with the following error: undefined instruction pc : [<0a000000>] lr : [<7ff80bfc>] reloc pc : [<8a8c0000>] lr : [<00840bfc>] sp : 7fb2b908 ip : 0000002a fp : 02000000 r10: 04000000 r9 : 7fb2fed0 r8 : e1000000 r7 : 0c000000 r6 : 03000000 r5 : 06000000 r4 : 01000000 r3 : 7fb30928 r2 : 7fb30928 r1 : 00000000 r0 : 00000000 Flags: nZCv IRQs off FIQs off Mode SVC_32 Code: 0f0fb4f0 0f0fb4f0 0f0fb4f0 0f0fb4f0 (f0f04b0f) Resetting CPU ... This happens when nvme_print_info() tries to return to the caller. It looks like this error is caused by trying to allocate 8 KiB of memory on the stack by the two uses of ALLOC_CACHE_ALIGN_BUFFER(). Use malloc_cache_aligned() to allocate this memory dynamically instead. This fixes 'nvme detail' on Turris Omnia. Note that similar change was applied to file drivers/nvme/nvme.c in past by commit 2f83481d ("nvme: use page-aligned buffer for identify command"). Signed-off-by:
Pali Rohár <pali@kernel.org> Signed-off-by:
Marek Behún <marek.behun@nic.cz>
-
This test checks for output specific to the sandbox blk device "sandbox_host_blk", mark it as sandbox specific. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Attempt to handle cases with a downstream port of a PCIe switch where link training never completes and the link continues switching between speeds indefinitely with the data link layer never reaching the active state. It has been observed with a downstream port of the ASMedia ASM2824 Gen 3 switch wired to the upstream port of the Pericom PI7C9X2G304 Gen 2 switch, using a Delock Riser Card PCI Express x1 > 2 x PCIe x1 device, P/N 41433, wired to a SiFive HiFive Unmatched board. In this setup the switches are supposed to negotiate the link speed of preferably 5.0GT/s, falling back to 2.5GT/s. However the link continues oscillating between the two speeds, at the rate of 34-35 times per second, with link training reported repeatedly active ~84% of the time, e.g.: 02:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet Switch [1b21:2824] (rev 01) (prog-if 00 [Normal decode]) [...] Bus: primary=02, secondary=05, subordinate=05, sec-latency=0 [...] Capabilities: [80] Express (v2) Downstream Port (Slot+), MSI 00 [...] LnkSta: Speed 5GT/s (downgraded), Width x1 (ok) TrErr- Train+ SlotClk+ DLActive- BWMgmt+ ABWMgmt- [...] LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis+, Selectable De-emphasis: -3.5dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB [...] Forcibly limiting the target link speed to 2.5GT/s with the upstream ASM2824 device makes the two switches communicate correctly however: 02:03.0 PCI bridge [0604]: ASMedia Technology Inc. ASM2824 PCIe Gen3 Packet Switch [1b21:2824] (rev 01) (prog-if 00 [Normal decode]) [...] Bus: primary=02, secondary=05, subordinate=09, sec-latency=0 [...] Capabilities: [80] Express (v2) Downstream Port (Slot+), MSI 00 [...] LnkSta: Speed 2.5GT/s (downgraded), Width x1 (ok) TrErr- Train- SlotClk+ DLActive+ BWMgmt- ABWMgmt- [...] LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis+, Selectable De-emphasis: -3.5dB Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB [...] and then: 05:00.0 PCI bridge [0604]: Pericom Semiconductor PI7C9X2G304 EL/SL PCIe2 3-Port/4-Lane Packet Switch [12d8:2304] (rev 05) (prog-if 00 [Normal decode]) [...] Bus: primary=05, secondary=06, subordinate=09, sec-latency=0 [...] Capabilities: [c0] Express (v2) Upstream Port, MSI 00 [...] LnkSta: Speed 2.5GT/s (downgraded), Width x1 (downgraded) TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- [...] LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB [...] Make use of this observation then and attempt to detect the inability to negotiate the link speed automatically, and then handle it by hand. Use the Data Link Layer Link Active status flag as the primary indicator of successful link speed negotiation, but given that the flag is optional by hardware to implement (the ASM2824 does have it though), resort to checking for the mandatory Link Bandwidth Management Status flag showing that the link speed or width has been changed in an attempt to correct unreliable link operation (the ASM2824 does set it too). If these checks indicate that link may not operate correctly, then poll the Data Link Layer Link Active status flag along with the Link Training flag for the duration of 200ms to see if the link has stabilised, that is either that the Data Link Layer Link Active status flag has been set or that Link Training has been inactive during at least the second half of the interval. If that has indicated failure, restrict the target speed to 2.5GT/s, request a link retrain and check again if the link has stabilised. If that does not work either, then restore the original speed setting and claim defeat, otherwise we are done. NB interestingly enough with the ASM2824 vs PI7C9X2G304 configuration referred above asking the ASM2824 to retrain with a higher target link speed once the 2.5GT/s speed has been negotiated makes the two devices successfully negotiate 5.0GT/s. Lifting the 2.5GT/s speed restriction would however prevent our workaround from working with an OS that issues a reset and that is unaware of the problem. This is because the devices would then try to negotiate a higher link speed from scratch and fail, while the sticky property of the Target Link Speed setting will keep the 2.5GT/s speed restriction across a reset. Keep the 2.5GT/s speed restriction then, conservatively, if functional once applied. Signed-off-by:
Maciej W. Rozycki <macro@orcam.me.uk> Reviewed-by:
Stefan Roese <sr@denx.de>
-
CHUNK_TYPE_RAW buffer is not aligned, and flash sparse images by fastboot will report "Misaligned operation" if DCACHE is enabled. Flashing Sparse Image CACHE: Misaligned operation at range [84000028, 84001028] CACHE: Misaligned operation at range [84001034, 84002034] CACHE: Misaligned operation at range [8401104c, 8401304c] Fix it Signed-off-by:
qianfan Zhao <qianfanguijin@163.com> Reviewed-by:
Sean Anderson <sean.anderson@seco.com>
-
https://source.denx.de/u-boot/custodians/u-boot-marvellTom Rini authored
- mvebu: Move PCIe code from serdes to PCIe driver (Pali) - mtd: nand: pxa3xx: use marvell, prefix for custom DT properties (Pierre) - Add PCIe support for Iomega iConnect board (Tony) - ddr: marvell: a38x: Misc improvements / fixes (Marek) - tools: kwbimage: Load address fixes (Pali) - mvebu: db-88f6720: Fix CONFIG_SPL_TEXT_BASE and remove wrong memory layout (Pali) - mvebu: Replace hardcoded values 0x0030/0x4030 by proper calculation (Pali)
-
These hardcoded values were calculated from CONFIG_SPL_TEXT_BASE macro. Now this macro is configurable via Kconfig, so calculate values 0x0030/0x4030 at compile time via CONFIG_SPL_TEXT_BASE option. Values 0x0030/0x4030 represents offset of CONFIG_SPL_TEXT_BASE from address 0x40000000. Signed-off-by:
-
Memory layout in the comment is from Armada XP platform which uses load address 0x40004030. DB-88f6720 is Armada 375 platform which uses same load address as Armada 38x which is 0x40000030. Currently SPL support for Armada 375 is unfinished and does not work. There is missing Serdes initialization and DDR3 training code. So nobody noticed that CONFIG_SPL_* options are not correct. Fix at least CONFIG_SPL_TEXT_BASE constant and remove incorrect comments about memory layout. So it is not misleading. Signed-off-by:
-
Do not check for kwbimage configuration file when just showing information about existing kwbimage file. The check for kwbimage configuration file is required only when creating kwbimage, not when showing information about image or when extracting data from image. With this change, it is possible to call mkimage -l and dumpimage -l also for existing kwbimage file. Signed-off-by:
-
When there is no -p argument for dumpimage tool specified, extract the main data image from kwbimage file. This makes dumpimage consistent with other image formats. Signed-off-by:
-
Despite the official specification, BootROM does not look at the lowest bit of ext field but rather checks if ext field is non-zero. Moreover original Marvell doimage tool puts into the mhdr->ext field the number of extended headers, so basically it sets ext filed to non-zero value if some extended header is present. Fix U-Boot dumpimage and kwboot tools to parse correctly also kwbimage files created by Marvell doimage tool, in the same way as the BootROM is doing it when booting these images. Signed-off-by:
-
Avoid casting const to non-const. Signed-off-by:
-
To regenerate kwbimage from existing image, it is needed to have kwbimage config file. Add a new option to generate kwbimage config file from existing kwbimage when '-p 1' option is given. Signed-off-by:
-
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:
-
Data delay is stored as 8-bit number in kwbimage structure. Ensure the given value is at most 255. Signed-off-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:
-
