- 05 11月, 2021 3 次提交
-
-
由 Tom Rini 提交于
This converts the following to Kconfig: CONFIG_SYS_HZ Signed-off-by: NTom Rini <trini@konsulko.com>
-
由 Tom Rini 提交于
When building a system that has both TPL and SPL_OS_BOOT, code which tests for CONFIG_SPL_OS_BOOT will be built and enabled in TPL, which is not correct. While there is no CONFIG_TPL_OS_BOOT symbol at this time (and likely will not ever be) we can use CONFIG_IS_ENABLED(OS_BOOT) in these common paths to ensure we only compile these parts in the SPL case. Signed-off-by: NTom Rini <trini@konsulko.com>
-
由 Tom Rini 提交于
For the symbols which are both hard-coded as enabled and used, move to Kconfig. The rest of the CONFIG_YAFFS namespace is unselected anywhere, so we leave it as is. Signed-off-by: NTom Rini <trini@konsulko.com>
-
- 04 11月, 2021 7 次提交
-
-
https://source.denx.de/u-boot/custodians/u-boot-marvell由 Tom Rini 提交于
- Improved sysreset/watchdog uclass integration (Samuel)
-
由 Samuel Holland 提交于
Instead of hardcoding the watchdog for reset, and the PMIC for poweroff, use the sysreset framework to manage the available poweroff/reset backends. This allows (as examples) using the PMIC to do a cold reset, and using a GPIO to power off H3/H5 boards lacking a PMIC. Furthermore, it removes the need to hardcode watchdog MMIO addresses, since the sysreset backends can be discovered using the device tree. Reviewed-by: NHeinrich Schuchardt <heinrich.schuchardt@canonical.com> Signed-off-by: NSamuel Holland <samuel@sholland.org> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Samuel Holland 提交于
The sysreset uclass unconditionally provides a definition of the reset_cpu() function. So does the sunxi board code. Fix the build with SYSRESET enabled by omitting the function from the board code in that case. The code still needs to be kept around for use in SPL. Reviewed-by: NHeinrich Schuchardt <heinrich.schuchardt@canonical.com> Signed-off-by: NSamuel Holland <samuel@sholland.org> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Samuel Holland 提交于
Add an option to automatically register watchdog devices with the wdt_reboot driver for use with sysreset. This allows sysreset to be a drop-in replacement for platform-specific watchdog reset code, without needing any device tree changes. Signed-off-by: NSamuel Holland <samuel@sholland.org> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Samuel Holland 提交于
Currently, the wdt_reboot driver always gets its watchdog device reference from an OF node. This prevents selecting a watchdog at runtime. Move the watchdog device reference to the plat data, so the driver can be bound with the reference pre-provided. The reference will still be acquired from the OF node if it is not already provided. Reviewed-by: NHeinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NSamuel Holland <samuel@sholland.org> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Samuel Holland 提交于
These driver probe functions are not (and should not be) called from outside the respective driver source files. Therefore, the functions should be marked static. Reviewed-by: NHeinrich Schuchardt <heinrich.schuchardt@canonical.com> Signed-off-by: NSamuel Holland <samuel@sholland.org> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Samuel Holland 提交于
None of the sysreset drivers do anything beyond providing sysreset uclass ops. They should depend on the sysreset uclass. Reviewed-by: NHeinrich Schuchardt <heinrich.schuchardt@canonical.com> Signed-off-by: NSamuel Holland <samuel@sholland.org> Reviewed-by: NStefan Roese <sr@denx.de>
-
- 03 11月, 2021 30 次提交
-
-
https://source.denx.de/u-boot/custodians/u-boot-usb由 Tom Rini 提交于
- usb: mtu3: flush cache for the first GPD when allocate GPD ring
-
https://source.denx.de/u-boot/custodians/u-boot-marvell由 Tom Rini 提交于
- pci_mvebu: Fix access to config space and PCIe Root Port (Pali) - a37xx: pci: Program the data strobe for config read requests (Pali) - kwboot: Misc improvements and fixes (Pali)
-
由 Chunfeng Yun 提交于
When allocate the GPD ring, and tell its address to the controller, then the driver starts or resumes the QMU, the controller will try to access the first GPD, so need flush the first one to avoid wrong GPD status. Reported-by: NXin Lin <Xin.Lin@mediatek.com> Signed-off-by: NChunfeng Yun <chunfeng.yun@mediatek.com>
-
由 Pali Rohár 提交于
According to the Armada 3720 Functional Specification Data Strobe applies for both read and write config requests. Data strobe bits configure which bytes from the start address should be returned for read request. Set value 0xf (all 4 bits) into Data Strobe register to read all four bytes from specified 32-bit config space register. Same value for Data Strobe register is programmed by Linux pci-aardvark.c driver for config read requests. Without this patch pci-aardvark driver sets data strobe register only during config write operations. So any followup config read operations could result with just partial datai returned (if previous write operation was not 32-bit wide). This patch fixes it and ensures that config read operations always read all bytes from requested register. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
After successful transfer of whole image only two things can happen: - BootROM starts execution of data block, which changes UART baudrate back to 115200 Bd, - board crashes and causes CPU reset In both cases UART baudrate is reset to the default speed. So there is no need to send special magic sequence to inform kwboot that baudrate is going to be reset and kwboot does not need to wait for this event and can do it immediately after BootROM acknowledges end of xmodem transfer. Move ARM code for sending magic sequence from main baudrate change section to binhdr_pre section which is executed only before changing baudrate from the default value of 115200 Bd to some new value. Remove kwboot code waiting for magic sequence after successful xmodem transfer. Rationale: sometimes when using very high UART speeds, magic sequence is damaged and kwboot fails at this last stage. Removal of this magic sequence makes booting more stable. Data transfer protocol (xmodem) is using checksums and retransmit, so it already deals with possible errors on transfer line. Signed-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
The ARM code we inject into the image to change baudrate back to the default value of 115200 Baud, which is run after successful UART transfer of the whole image, cannot use stack as at this stage stack pointer is not initialized yet. Stack can only be used when BootROM is executing binary header, to preserve state of registers, since BootROM expects that. Change the ARM baudrate code to not use stack at all and put binary header specific pre + post code (which stores and restores registers) into separate arrays. The baudrate change code now jumps at it's end and expects that there is either code which returns to the BootROM or jumps to the original exec address. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Older Armada SoCs have custom ARMv5te compatible core which does not support movt instruction. So replace mov + movt instruction pair used for immediate move construction by mov + orr instructions which are supported also by ARMv5te. After this change kwboot ARM code should be compatible with any 32-bit ARM core compatible by ARMv2 or new. At least GNU AS does not throw any error or warning. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Increase loop cycles from 600000 to 2998272, which should increase delay from 1ms to about 5ms on 1200 MHz CPU. The Number 2998272 was chosen as the nearest value around 3000000 which can be encoded into one ARM mov instruction. It avoids usage of movt instruction which is not supported by ARMv5te cores. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Kwboot puts each xmodem packet to kernel queue, then waits until all bytes of that packet are transmitted over UART and then waits for xmodem reply until it is received into kernel queue. If some reply is received during the time we are waiting until all bytes are transmitted, then kernel puts them into the queue and returns it to kwboot in next read() call. So there is no need to wait (with tcdrain() function) until all bytes from xmodem packet are transmitted over UART, since any reply received either during that time or after is returned to kwboot with the next read(). Therefore do not call tcdrain() after each xmodem packet sent. Instead directly wait for any reply after putting xmodem packet into write kernel queue. This change could speed up xmodem transfer in case tcdrain() function waits for a longer time. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
After the trasfer of last header packet, it is possible that baudrate change pattern is received, and also that NAK byte is received so that the packet should be sent again. Thus we should not clear the baudrate change state when sending retry of that packet. Move code for initializing state variables from kwboot_xm_recv_reply() to kwboot_xm_sendblock(). Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Currently when kwboot receive some garbage reply which does not understand, it waits 1s before it tries to resend packet again. The most common error on UART is that receiver sees some bit flipped which results in invalid reply. This behavior slows down xmodem transfer over UART as basically on every error kwboot is waiting one second. To fix this, try to resend xmodem packet for first 3 attempts immediately without any delay. If broken reply is received also after the 3 attempts, continue retrying with 1s delay like it was before. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
This patch does not change behavior of the code, just allows to implement new changes more easily. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Size of the header stored in kwbimage may be larger than real used size in the kwbimage header. If there is unused space in kwbimage header then use it for growing it. So update code to calculate used space of kwbimage header. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
This ensures that kwboot_img_grow_hdr() function still sees valid kwbimage header. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Expression (hdrsz % KWBOOT_XM_BLKSZ) is non-zero therefore expression (KWBOOT_XM_BLKSZ - hdrsz % KWBOOT_XM_BLKSZ) is always less than value KWBOOT_XM_BLKSZ. So there is no need to add another modulo. Also rename variable `offset` to `grow` which better describes what is stored in this variable. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
It is hard to debug why kwboot is failing when the last message is 'Finishing transfer' and no additional output. So show verbose message when kwboot finished transfer and is waiting for baudrate change magic sequence. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
For kwbimage v1, tell BootROM to send BootROM messages to UART port number 0 (used also for UART booting) with default baudrate (which should be 115200) and do not touch UART MPP configuration. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
If data part of image is modified, update 4-byte data checksum. It looks like A385 BootROM does not verify this checksum for image loaded via UART, but we do not know if other BootROMs are also ignoring it. It is always better to provide correct checksum. Signed-off-by: NPali Rohár <pali@kernel.org> [ refactored ] Signed-off-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Some vendor U-Boot kwbimage binaries (e.g. those for A375) have load address set to zero. Therefore it is not possible to inject code which changes baudrate back to 115200 Bd before the data part. So instead inject it after the data part and change kwbimage execution address to that offset. Also store original execution address into baudrate change code, so after it changes baudrate back to 115200 Bd, it can jump to orignal address. Signed-off-by: NPali Rohár <pali@kernel.org> [ refactored ] Signed-off-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Data part of the image contains 4-byte checksum. Validate it when processing the image. Signed-off-by: NPali Rohár <pali@kernel.org> [ refactored ] Signed-off-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
SPI image header and data parts do not have to be aligned to 128 byte xmodem block size. So reserve additional memory for aligning header part and additional memory for aligning data part. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Explicitly disable 2 stop bits by clearing CSTOPB flag, disable modem control flow by clearing CRTSCTS flag and do not send hangup after closing device by clearing HUPCL flag. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Explicitly zero out the rfds fd_set with FD_ZERO() before using it. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
This is a pci driver, not an eth driver. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Root Complex should be the default mode, let's set it explicitly. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Now that PCI Bridge is working, U-Boot's CONFIG_PCI_PNP code automatically enables memory access and bus mastering when it is needed. So do not prematurely enable memory access and bus mastering. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
PCI Bridge is always accessible also when link is down. So move detection of link up from mvebu_pcie_of_to_plat() function to mvebu_pcie_valid_addr() function which is used when accessing PCI config space. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Functions mvebu_pcie_get_local_bus_nr() and mvebu_pcie_get_local_dev_nr() are not used, so remove them. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
The mysterious "Memory controller" PCI device which is present in PCI config space is improperly configured and crippled PCI Bridge which acts as PCIe Root Port for endpoint PCIe card. This PCI Bridge reports in PCI config space incorrect Class Code (Memory Controller) and incorrect Header Type (Type 0). It looks like HW bug in mvebu PCIe controller but apparently it can be changed via mvebu registers to correct values. The worst thing is that this PCI Bridge is crippled and its PCI config registers in range 0x10-0x34 alias access to internal mvebu registers which have different functionality as PCI Bridge registers. Moreover, configuration of PCI primary and secondary bus numbers (registers 0x18 and 0x19) is done via totally different mvebu registers via totally strange method and cannot be done via PCI Bridge config space. Due to above fact about PCI config range 0x10-0x34, allocate a private cfgcache[] buffer in the driver, to which PCI config access requests to the 0x10-0x34 space will be redirected in mvebu_pcie_read_config() and mvebu_pcie_write_config() functions. Function mvebu_pcie_write_config() will also catch writes to PCI_PRIMARY_BUS (0x18) and PCI_SECONDARY_BUS (0x19) registers and set PCI Bridge primary and secondary bus numbers via mvebu's own method. Also, Expansion ROM Base Address register (0x38) is available, but at different offset 0x30. So recalculate register offset before accessing PCI config space. After these steps U-Boot sees working PCI Bridge and CONFIG_PCI_PNP code can finally start enumerating all PCIe devices correctly, even with more complicated PCI topology. So update also mvebu_pcie_valid_addr() function to reflect state of the real device topology. Each PCIe port is de-facto isolated and every PCI Bridge which is part of PCIe Root Complex is also isolated, so put them on separate PCI buses as (local) device 0. U-Boot already supports enumerating separate PCI buses, real (HW) bus number can be retrieved by "PCI_BUS(bdf) - dev_seq(bus)" code, so update config read/write functions to properly handle more complicated tree topologies (e.g. when a PCIe switch with multiple PCI buses is connected to the PCIe port). Local bus number and local device number on mvebu are used for determining which config request type is used (Type 0 vs Type 1). On normal non-broken PCIe hardware it is done by primary and secondary bus numbers. So correctly translate settings between these numbers to ensure that correct config requests are sent over the PCIe bus. As bus numbers are correctly re-configured, it does not make sense to print some initial bogus configuration during probe, so remove this debug code. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
When reading 8 or 16 bits from config space, use appropriate readb() or readw() calls. This ensures that PCIe controller does not read more bits from endpoint card as asked by read_config() function. Technically there should not be an issue with reading data from config space which are not later used as there are no clear-by-read registers. But it is better to use correct read operation based on requested size. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-