- Oct 30, 2020
-
-
PX30.Core is an EDIMM SOM based on Rockchip PX30 from Engicam. General features: - Rockchip PX30 - Up to 2GB DDR4 - eMMC 4 GB expandible - rest of PX30 features PX30.Core needs to mount on top of Engicam baseboards for creating complete platform boards. Possible baseboards are, - EDIMM2.2 - C.TOUCH 2.0 Add support for it. Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Signed-off-by:
Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by:
Kever Yang <kever.yang@rock-chips.com>
-
Engicam EDIMM2.2 Starter Kit is an EDIMM 2.2 Form Factor Capacitive Evaluation Board. Genaral features: - LCD 7" C.Touch - microSD slot - Ethernet 1Gb - Wifi/BT - 2x LVDS Full HD interfaces - 3x USB 2.0 - 1x USB 3.0 - HDMI Out - Mini PCIe - MIPI CSI - 2x CAN - Audio Out SOM's like PX30.Core needs to mount on top of this Evaluation board for creating complete PX30.Core EDIMM2.2 Starter Kit. Add support for it. Signed-off-by:
-
The Rockchip boot ROM expects little-endian values in the image header. When running mkimage on a big-endian machine, these values need to be byteswapped before writing or verifying the header. This change fixes cross-compiling U-Boot SPL for the RK3399 SoC from a big-endian ppc64 host machine. Signed-off-by:
Samuel Holland <samuel@sholland.org> Reviewed-by:
Kever <Yang<kever.yang@rock-chips.com>
-
Enable Console multiplexing in ROCKPi N8 which would is required to video out the console buffer. Enable it. Signed-off-by:
-
Like, rk3399 the rk3288 also supports 4K resolution. So, enable it for rk3288 with HDMI platforms. Right now, rockchip video drivers are supporting for rk3288, rk3399 SoC families, so mark the 4K resolution by default if it's an HDMI video out. Signed-off-by:
-
Add chosen node in -u-boot.dtsi for ROCK-Pi N8 board. This will help to get serial out messages. Signed-off-by:
-
Enable Console multiplexing in ROCKPi N10 which would is required to video out the console buffer. Enable it. Signed-off-by:
-
Found this by comparing it to the coreboot driver, a form of this call was introduced there in their commit b9a7877568cf ("rockchip/*: refactor edp driver"). This is copy-pasted from U-Boot's link_train_cr() slightly above it. Without this on a gru-kevin chromebook, I have: clock recovery at voltage 0 pre-emphasis 0 requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 1 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 2 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 3 voltage 0.4V pre_emph 3.5dB using signal parameters: voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 1 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 2 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 3 voltage 0.4V pre_emph 3.5dB using signal parameters: voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 1 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 2 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 3 voltage 0.4V pre_emph 3.5dB using signal parameters: voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 1 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 2 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 3 voltage 0.4V pre_emph 3.5dB using signal parameters: voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 1 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 2 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 3 voltage 0.4V pre_emph 3.5dB using signal parameters: voltage 0.4V pre_emph 3.5dB channel eq failed, ret=-5 link train failed! rk_vop_probe() Device failed: ret=-5 With this, it looks like training succeeds: clock recovery at voltage 0 pre-emphasis 0 requested signal parameters: lane 0 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 1 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 2 voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 3 voltage 0.4V pre_emph 3.5dB using signal parameters: voltage 0.4V pre_emph 3.5dB requested signal parameters: lane 0 voltage 0.4V pre_emph 6dB requested signal parameters: lane 1 voltage 0.4V pre_emph 6dB requested signal parameters: lane 2 voltage 0.4V pre_emph 6dB requested signal parameters: lane 3 voltage 0.4V pre_emph 6dB using signal parameters: voltage 0.4V pre_emph 6dB requested signal parameters: lane 0 voltage 0.4V pre_emph 0dB requested signal parameters: lane 1 voltage 0.4V pre_emph 0dB requested signal parameters: lane 2 voltage 0.4V pre_emph 0dB requested signal parameters: lane 3 voltage 0.4V pre_emph 0dB using signal parameters: voltage 0.4V pre_emph 0dB channel eq at voltage 0 pre-emphasis 0 config video failed rk_vop_probe() Device failed: ret=-110 The "config video failed" error also goes away when I disable higher log levels, and it claims to have successfully probed the device. Signed-off-by:Alper Nebi Yasak <alpernebiyasak@gmail.com> Reviewed-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
-
The SRAM on the PX30 is not big enough to hold multiple DDR configs so it needs to be selected during build. So far simply the DDR3 config was always selected and getting DDR4 or LPDDR2/3 initialized would require a code modification. So add Kconfig options similar to RK3399 to allow selecting the DDR4 and LPDDR2/3 options instead, while DDR3 stays the default as before. Signed-off-by:
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Reviewed-by:
-
Fix up USB config options so keyboards and other USB devices work. Signed-off-by:
Peter Robinson <pbrobinson@gmail.com> Reviewed-by:
-
The property reg-shift with the same value is present in the base device tree already. Remove unnecessary node from rk3288-tinker.dts. Signed-off-by:
Stefan Agner <stefan@agner.ch> Reviewed-by:
-
The I2C EEPROM is present on Tinker Board S as well. Move the i2c node to the shared, U-Boot specific rk3288-tinker-u-boot.dtsi device tree. Cc: Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
-
In order to correctly calculate the designware watchdog timeouts, the watchdog clock is required. Implement required clocks to facilitate this. Signed-off-by:
Jack Mitchell <ml@embed.me.uk> Reviewed-by:
Philipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by:
-
- Oct 08, 2020
-
-
https://gitlab.denx.de/u-boot/custodians/u-boot-cfi-flashTom Rini authored
- Fix devicetree address determination seen on QEMU ARM64 - Use DMA for reads is available
-
The cfi-flash driver uses an open-coded version of the generic algorithm to decode and translate multiple frames of a "reg" property. This starts off the wrong foot by using the address-cells and size-cells properties of *this* very node, and not of the parent. This somewhat happened to work back when we were using a wrong default size of 2, but broke about a year ago with commit 0ba41ce1 ("libfdt: return correct value if #size-cells property is not present"). Instead of fixing the reinvented wheel, just use the generic function that does all of this properly. This fixes U-Boot on QEMU (-arm64), which was crashing due to decoding a wrong flash base address: DRAM: 1 GiB Flash: "Synchronous Abort" handler, esr 0x96000044 elr: 00000000000211dc lr : 00000000000211b0 (reloc) elr: 000000007ff5e1dc lr : 000000007ff5e1b0 x0 : 00000000000000f0 x1 : 000000007ff5e1d8 x2 : 000000007edfbc48 x3 : 0000000000000000 x4 : 0000000000000000 x5 : 00000000000000f0 x6 : 000000007edfbc2c x7 : 0000000000000000 x8 : 000000007ffd8d70 x9 : 000000000000000c x10: 0400000000000003 x11: 0000000000000055 ^^^^^^^^^^^^^^^^ Signed-off-by:
Andre Przywara <andre.przywara@arm.com> Reviewed-by:
Stefan Roese <sr@denx.de>
-
When possible use DMA for reading from CFI flash, this provides upto 5x improvement in read performance with high speed CFI compliant flashes like HyperFlash. Code will gracefully fallback to CPU copy when DMA is unavailable. Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by:
-
Caller would need gracefully handle failures of dma_get_device(), therefore reduce pr_err() to pr_debug() when DMA device is not found. Signed-off-by:
-
- Oct 07, 2020
-
-
https://gitlab.denx.de/u-boot/custodians/u-boot-mipsTom Rini authored
- mips: octeon: add support for DDR4 memory controller - mips: octeon: add support for DWC3 USB - mips: octeon: add support for booting Linux
-
Increase CONFIG_SYS_BOOTM_LEN to 64MiB for Linux kernel booting. Signed-off-by: -
Octeon needs a platform specific cmd to boot the Linux kernel, as specific parameters need to be passed and special handling for the multiple cores (SMP) is needed. Co-developed-by:
Aaron Williams <awilliams@marvell.com> Signed-off-by:
Daniel Schwierzeck <daniel.schwierzeck@gmail.com> -
This is needed for Linux booting, as the memory infos need to be passed in this bootmem format to the Linux kernel. Signed-off-by:
-
This patch adds the coremask handling functions. Signed-off-by:
-
Add header to handle bootinfo support, needed for Octeon Linux kernel booting. Signed-off-by:
-
Add header to handle Octeon fuse access. Signed-off-by:
-
This header includes the Octeon feature detection used in many Octeon drivers. Signed-off-by:
-
This header includes common register defines and accessor functions. Signed-off-by:
-
This patch adds the necessary lowlevel init code, to enable SMP Linux booting. This code will be used with the platform specific Octeon Linux boot command "bootoctlinux", which starts a configurable number of cores into Linux. Additionally some erratas and lowlevel register initializations are copied from the original Cavium / Marvell U-Boot source code, enabling booting into the Linux kernel. Signed-off-by: -
Add the #ifdef __ASSEMBLY__ checks to enable inclusion of this header from assembler files. Signed-off-by: -
This patch enables USB support with some helpful commands, like fs support. Signed-off-by: -
Add the USB device tree nodes to the Octeon dts/dtsi files. Signed-off-by:
Bin Meng <bmeng.cn@gmail.com> -
As noticed while working on the USB xHCI support, Octeon needs to flush all pending writes so that the values are present in the memory. Add this "syncw" instruction (twice) to flush_dcache_range(). Signed-off-by: -
Import platform specific mangle-port.h header, allowing a area specific swapping, which is needed on Octeon for USB & PCI areas. Imported from Linux v5.7. Signed-off-by: -
Import octeon_should_swizzle_table[] which is needed for the area specific swapping. It will be used by the platform specific mangle-port.h header. Imported from Linux v5.7. Signed-off-by: -
This patch adds the glue layer for the MIPS Octeon SoCs. It's ported mainly from the Linux code. Signed-off-by:
Bin Meng <bmeng.cn@gmail.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Marek Vasut <marex@denx.de> -
Octeon uses mapped addresses for virtual and physical memory. It's not that easy to calculate the resulting addresses here. So let's remove this BUG_ON() completely, as it's not really helpful. Please also note, that BUG_ON() is not recommended any more in the Linux kernel. Signed-off-by:
Bin Meng <bmeng.cn@gmail.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Marek Vasut <marex@denx.de> -
On MIPS platforms, mapping of the base address is needed. This patch switches from dev_get_addr() to dev_remap_addr() to get the mapped base address of the xHCI controller. Signed-off-by:
Bin Meng <bmeng.cn@gmail.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Marek Vasut <marex@denx.de> -
This patch adds the board specific configuration (struct) for the Octeon 3 EBB7304 EVK. This struct is ported from the 2013er Cavium / Marvell U-Boot repository. Also, the Octeon RAM driver is enabled in the board defconfig for its usage. Tested with one and two DIMMs on the EBB7304 EVK (8 & 16 GiB). Signed-off-by: -
This patch adds the initialization call for the Octeon RAM driver to the Octeon platforms code. So if enabled via Kconfig, the DDR driver will be called and the RAM will be configured and used. If the RAM driver is not enabled, the L2 cache is still used as RAM. Signed-off-by: -
This Octeon 3 DDR driver is ported from the 2013 Cavium / Marvell U-Boot repository. It currently supports DDR4 on Octeon 3. It can be later extended to support also DDR3 and Octeon 2 platforms. Part 3 includes the DIMM SPD handling code and the Kconfig / Makefile integration. Signed-off-by:
-
This Octeon 3 DDR driver is ported from the 2013 Cavium / Marvell U-Boot repository. It currently supports DDR4 on Octeon 3. It can be later extended to support also DDR3 and Octeon 2 platforms. Part 2 includes the very complex Octeon 3 DDR4 configuration Signed-off-by:
-
