September 2020 - U-Boot

[PATCH] acpi: device: Fix check for sequence number
by Wolfgang Wallner 21 Sep '20

21 Sep '20

Currently the function acpi_check_seq() checks whether dev->req_seq is unequal to "-1", but it should actually check dev->seq. Change it to check dev->seq. For req_seq the value "-1" would be a valid (meaning 'any'), while for seq the value "-1" means 'none' and is not valid. Quoting the description of udevice in device.h: * @req_seq: Requested sequence number for this device (-1 = any) * @seq: Allocated sequence number for this device (-1 = none). * This is set up when the device is probed and will be unique * within the device's uclass. Signed-off-by: Wolfgang Wallner <wolfgang.wallner(a)br-automation.com> Fixes: commit fefac0b0643b ("dm: acpi: Enhance acpi_get_name()") --- lib/acpi/acpi_device.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/lib/acpi/acpi_device.c b/lib/acpi/acpi_device.c index 3c75b6d962..76194ea1b4 100644 --- a/lib/acpi/acpi_device.c +++ b/lib/acpi/acpi_device.c @@ -743,12 +743,12 @@ static const char *acpi_name_from_id(enum uclass_id id) static int acpi_check_seq(const struct udevice *dev) { - if (dev->req_seq == -1) { + if (dev->seq == -1) { log_warning("Device '%s' has no seq\n", dev->name); return log_msg_ret("no seq", -ENXIO); } - return dev->req_seq; + return dev->seq; } /* If you change this function, add test cases to dm_test_acpi_get_name() */ -- 2.27.0

3 5

[PATCH] usb: storage: increase retries to 20
by Stefan Agner 20 Sep '20

20 Sep '20

A JMicron JMS583 based NVMe to USB 3.1 enclosure connected to a Raspberry Pi 4 fails to enumerate as a USB Mass Storage device on first try: ... startig USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devces... Device NOT ready Request Sense returned 02 04 01 4 USB Device(s) found scanning usb for storage devices... 0 Sorage Device(s) found However, it consistently works on the second try. It seems that the device takes longer than 1s to detect the media. With debug enabled it shows that the 11th retry count typically works. Increase retries to 20 for a startup time of up to 2s. Signed-off-by: Stefan Agner <stefan(a)agner.ch> --- common/usb_storage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/usb_storage.c b/common/usb_storage.c index ff25441995..04910de21f 100644 --- a/common/usb_storage.c +++ b/common/usb_storage.c @@ -1019,7 +1019,7 @@ static int usb_request_sense(struct scsi_cmd *srb, struct us_data *ss) static int usb_test_unit_ready(struct scsi_cmd *srb, struct us_data *ss) { - int retries = 10; + int retries = 20; do { memset(&srb->cmd[0], 0, 12); -- 2.28.0

1 1

[PATCH 0/5] x86: Updates to some commands
by Simon Glass 20 Sep '20

20 Sep '20

This series adds a few more features to some x86-specific commands. Simon Glass (5): x86: hob: Add way to show a single hob entry x86: hob: Try to show a name instead of a GUID x86: Allow showing details about a HOB entry x86: Add support for more than 8 MTRRs x86: video: Show information about each video device arch/x86/cpu/mtrr.c | 12 ++-- arch/x86/include/asm/fsp/fsp_hob.h | 25 ++++++++ arch/x86/include/asm/mtrr.h | 15 ++++- cmd/bdinfo.c | 26 +++++++- cmd/x86/hob.c | 100 +++++++++++++++++++++++++++-- cmd/x86/mtrr.c | 9 +-- 6 files changed, 167 insertions(+), 20 deletions(-) -- 2.28.0.681.g6f77f65b4e-goog

1 0

Pull request for UEFI sub-system for efi-2020-10-rc5 (2)
by Heinrich Schuchardt 20 Sep '20

20 Sep '20

Hello Tom, The following changes since commit 9de3126e80cdac7ee15b6671065a952184533dda: Merge branch '2020-09-16-assorted-fixes' (2020-09-17 09:53:57 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git tags/efi-2020-10-rc5-2 for you to fetch changes up to 8f0ac536d4937d07a95fcc56756c14ef7a94e397: efi: change 'env -e -i' usage syntax (2020-09-18 22:23:58 +0200) Gitlab CI and Travis CI showed no problems: https://gitlab.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/4709 https://travis-ci.org/github/xypron2/u-boot/builds/728440733 ---------------------------------------------------------------- Pull request for UEFI sub-system for efi-2020-10-rc5 (2) The following bugs are fixed: * incorrect online help for setenv and env * description of function efi_mem_carve_out() * replace printf() by log_err() in stm32mp1_rng driver A unit test is provided to check that the boot hart id is available in the RISC-V device-tree. ---------------------------------------------------------------- Heinrich Schuchardt (3): rng: stm32mp1: use log() instead of printf() efi_selftest: rework device tree test efi_selftest: check for RISC-V boot-hartid in FDT Maxim Uvarov (2): efi_memory: refine overlap_only_ram description efi: change 'env -e -i' usage syntax cmd/nvedit.c | 4 +-- drivers/rng/stm32mp1_rng.c | 4 ++- lib/efi_loader/efi_memory.c | 2 +- lib/efi_selftest/efi_selftest_fdt.c | 68 +++++++++++++++++++++++++++++-------- 4 files changed, 60 insertions(+), 18 deletions(-)

2 1

RPi4 U-Boot freeze
by Stefan Agner 20 Sep '20

20 Sep '20

Hi, I noticed a quite common freeze when running 32-bit U-Boot 2020.01 (rpi_4_32b_defconfig) on a 2GB RPi4 model: U-Boot 2020.01 (Aug 07 2020 - 13:00:23 +0000) DRAM: 1.9 GiB <freeze, no more output> This happens fairly often, I would say 4 out of 5 boot tries. However, if it boots, everything seems to run fine. The issue seems to go away when using 2020.04 or any newer release, however, when trying to find the actual patch fixing the issue using git bisect I ended up with a MMC merge request which really seems unrelated (36bdcf7f3b). It seems that the problem is quite evasive and disappears if certain structure are aligned differently etc. Enabling initcall debugging showed that U-Boot crashes right after relocation: ... initcall: 00016f2c RAM Configuration: Bank #0: 0 948 MiB Bank #1: 40000000 1 GiB Bank #2: 0 0 Bytes Bank #3: 0 0 Bytes DRAM: 1.9 GiB initcall: 00016bb8 New Stack Pointer is: 3af6d9e0 initcall: 00016da4 initcall: 00016ef0 initcall: 00016ef8 initcall: 00016d38 Relocation Offset is: 3b375000 Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0 initcall: 00016ec8 [clear_bss] initcall: 0004465c [display_options?? only appears sometimes] <freeze> I realized when using CONFIG_SYS_(I|D)CACHE_OFF=y the problem seems to disappear. But to be 100% certain that it is cache related, I used my original configuration (which is known to "reliably" freeze), and replaced 00016ec8 with 00008688 manually in the binary, essentially swapping out function pointers in "init_sequence_f" [00008688 is cleanup_before_linux, which flushes and disables I-cache/D-cache]. And indeed, that hacked up binary does boot reliably every time: ... initcall: 00016f2c RAM Configuration: Bank #0: 0 948 MiB Bank #1: 40000000 1 GiB Bank #2: 0 0 Bytes Bank #3: 0 0 Bytes DRAM: 1.9 GiB initcall: 00016bb8 New Stack Pointer is: 3af6d9e0 initcall: 00016da4 initcall: 00016ef0 initcall: 00016ef8 initcall: 00016d38 Relocation Offset is: 3b375000 Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0 initcall: 00008688 initcall: 3b38c10c initcall: 3b38c114 initcall: 000172e0 (relocated to 3b38c2e0) initcall: 0001712c (relocated to 3b38c12c) ... >From what I understand on RPi4 caches are enabled when entering U-Boot. I was wondering if the relocation code really can handle that? -- Stefan

5 9

[PATCH 1/1] sandbox: support CTRL-C processing in U-Boot
by Heinrich Schuchardt 20 Sep '20

20 Sep '20

Currently if SIGINT is received, it terminates U-Boot. This does not allow testing the handling of CTRL-C in U-Boot and in UEFI applications. It is especially annoying when working with the 'mm' command. Let the serial console driver provide character 0x03 if SIGINT occurs. We can still exit U-Boot using the reset or poweroff command. Adjust the sandbox test_ctrl_c() Python test accordingly. Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- arch/sandbox/cpu/os.c | 15 ++++++++++++--- drivers/serial/sandbox.c | 11 ++++++++--- include/os.h | 14 ++++++++++++++ test/py/tests/test_sandbox_exit.py | 10 +++++++++- 4 files changed, 43 insertions(+), 7 deletions(-) diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c index e7ec892bdf..b5cfa38a32 100644 --- a/arch/sandbox/cpu/os.c +++ b/arch/sandbox/cpu/os.c @@ -161,6 +161,7 @@ err: static struct termios orig_term; static bool term_setup; static bool term_nonblock; +static bool pending_ctrlc; void os_fd_restore(void) { @@ -176,11 +177,19 @@ void os_fd_restore(void) } } +void os_clear_ctrlc(void) +{ + pending_ctrlc = false; +} + +bool os_get_ctrlc(void) +{ + return pending_ctrlc; +} + static void os_sigint_handler(int sig) { - os_fd_restore(); - signal(SIGINT, SIG_DFL); - raise(SIGINT); + pending_ctrlc = true; } /* Put tty into raw mode so <tab> and <ctrl+c> work */ diff --git a/drivers/serial/sandbox.c b/drivers/serial/sandbox.c index f09d291e04..e510d51e27 100644 --- a/drivers/serial/sandbox.c +++ b/drivers/serial/sandbox.c @@ -72,9 +72,6 @@ static int sandbox_serial_probe(struct udevice *dev) os_tty_raw(0, state->term_raw == STATE_TERM_RAW_WITH_SIGS); priv->start_of_line = 0; - if (state->term_raw != STATE_TERM_RAW) - disable_ctrlc(1); - return 0; } @@ -118,6 +115,9 @@ static int sandbox_serial_pending(struct udevice *dev, bool input) increment_buffer_index(serial_buf_write); ssize_t count; + if (os_get_ctrlc()) + return true; + if (!input) return 0; @@ -139,6 +139,11 @@ static int sandbox_serial_getc(struct udevice *dev) { int result; + if (os_get_ctrlc()) { + os_clear_ctrlc(); + return 0x03; + } + if (!sandbox_serial_pending(dev, true)) return -EAGAIN; /* buffer empty */ diff --git a/include/os.h b/include/os.h index 1874ae674f..0cbf737d57 100644 --- a/include/os.h +++ b/include/os.h @@ -355,4 +355,18 @@ int os_read_file(const char *name, void **bufp, int *sizep); */ void *os_find_text_base(void); +/** + * os_get_ctrlc() - check if a CTRL+C has occurred + * + * Return: true if CTRL+C has occurred + */ +bool os_get_ctrlc(void); + +/** + * os_clear_ctrlc() - clear CTRL+C + * + * Mark a previous CTRL+C event as handled. + */ +void os_clear_ctrlc(void); + #endif diff --git a/test/py/tests/test_sandbox_exit.py b/test/py/tests/test_sandbox_exit.py index a301f4b559..4bc703ea56 100644 --- a/test/py/tests/test_sandbox_exit.py +++ b/test/py/tests/test_sandbox_exit.py @@ -15,7 +15,15 @@ def test_reset(u_boot_console): @pytest.mark.boardspec('sandbox') def test_ctrl_c(u_boot_console): - """Test that sending SIGINT to sandbox causes it to exit.""" + """Test that SIGINT is handled as CTRL-C.""" u_boot_console.kill(signal.SIGINT) + u_boot_console.wait_for('<INTERRUPT>') + u_boot_console.run_command('echo') + + u_boot_console.run_command('\x03', wait_for_echo=False, wait_for_prompt=False) + u_boot_console.wait_for('<INTERRUPT>') + u_boot_console.run_command('echo') + + u_boot_console.kill(signal.SIGKILL) assert(u_boot_console.validate_exited()) -- 2.28.0

2 5

Cold boot consistently fails to load file from SD
by Mauro Condarelli 20 Sep '20

20 Sep '20

Hi, I'm facing a new problem for my Mt7628/vocore2 target. I moved the Linux kernel from a ext4 partition to the "proper" SquashFS partition (I say "proper" because I'm using a dual-system with fallback to avoid updating the currently working rootFS and kernel lies into rootFS). I am using u-boot v2020.10-rc3 plus the attached patches (one pertains SquashFS). Problem is a real cold boot (target off for more than one minute) leads to a load failure for the kernel. A warm boot ("reboot" from a running Linux) or a not-so-cold boot (turn target off and power it on again after a few seconds) seems to work as expected. I tried to insert delays and/or "mmc rescan", but that does not seem to have any effect. Also error message is not always the same; sometimes I get: Error: too many data blocks to be read. Failed to load '/boot/uImage' other times: ** fs_devread read error - block Failed to mount ext2 filesystem... ** Unrecognized filesystem type ** My full environment is: BOOT_CURRENT=A SYSTEM_R=/dev/mtdblock5 arch=mips baudrate=115200 board=vocore2 board_name=vocore2 boot_a=echo "Loading System A";part=6;run boot_x boot_b=echo "Loading System B";part=7;run boot_x boot_now=if test "${BOOT_CURRENT}" = A; then run boot_a; elif test "${BOOT_CURRENT}" = B; then run boot_b; fi; if env exists BOOT_A_GOOD; then run boot_a; fi; if env exists BOOT_B_GOOD; then run boot_b; fi; run boot_r boot_r=echo "Loading Recovery"; setenv bootargs "${default_bootargs} mtdparts=${mtdparts} root=/dev/mtdblock5"; bootm bc050000 boot_x=load mmc 0:${part} 85000000 /boot/uImage && setenv bootargs "${default_bootargs} mtdparts=${mtdparts} root=/dev/mmcblk0p${part}" && bootm ${fileaddr} bootcmd=run do_boot bootcount=1 bootdelay=2 cpu=mips32 default_bootargs=earlyprintk rootwait console=ttyS2,115200 do_boot=test ${bootcount} -gt 1 && run remove_boot; run boot_now fdtcontroladdr=86f6d340 fileaddr=84000000 filesize=154 fupdate=mmc rescan && load mmc 0:1 84000000 uboot.scr && fatrm mmc 0:1 uboot.scr && source 84000000 && echo Flash updated || Flash update FAILED! mtdids=nor0=spi0.0 mtdparts=spi0.0:312k(u-boot),4k(env),4k(factory),2368k(kernel),-(filesystem) remove_boot=if env exists BOOT_CURRENT; then setenv BOOT_CURRENT; saveenv; elif env exists BOOT_A_GOOD; then setenv BOOT_A_GOOD; saveenv; elif env exists BOOT_B_GOOD; then setenv BOOT_B_GOOD; saveenv; fi soc=mt7628 stderr=uart2@e00 stdin=uart2@e00 stdout=uart2@e00 vendor=vocore ver=U-Boot 2020.10-rc3 (Sep 16 2020 - 19:43:03 +0200) It was suggested (on IRC) it could be a cache problem. unfortunately trying to enable cache control (CONFIG_CMD_CACHE) raises error in compilation: ... LD u-boot /home/valeria/MyProject/VoCore/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd: cmd/built-in.o: in function `do_icache': cmd/cache.c:(.text.do_icache+0x5c): undefined reference to `icache_disable' /home/valeria/MyProject/VoCore/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x6c): undefined reference to `icache_enable' /home/valeria/MyProject/VoCore/Buildroot-2/recov/per-package/uboot/host/bin/mipsel-linux-ld.bfd: cmd/cache.c:(.text.do_icache+0x8c): undefined reference to `icache_status' Makefile:1753: recipe for target 'u-boot' failed make[2]: *** [u-boot] Error 1 package/pkg-generic.mk:266 <http://pkg-generic.mk:266>: recipe for target '/home/valeria/MyProject/VoCore/Buildroot-2/recov/build/uboot-v2020.10-rc3/.stamp_built' failed make[1]: *** [/home/valeria/MyProject/VoCore/Buildroot-2/recov/build/uboot-v2020.10-rc3/.stamp_built] Error 2 Makefile:23: recipe for target '_all' failed make: *** [_all] Error 2 and I have no idea how to fix this. Any hint would be very welcome as this is a real show-stopper for me. Thanks in Advance Mauro

2 2

[PATCH v1 00/10] mips: octeon: Add bootoctlinux command for Octeon Linux kernel booting
by Stefan Roese 19 Sep '20

19 Sep '20

This patchset adds the platforms specific bootoctlinux command, which is used to boot the MIPS Octeon Linux kernel (4.9.x). A special command is necessary here, as very platform specific data is passed to the kernel via the bootinfo / bootmem format. This patchset also includes various required infrastructure code for this (octeon-feature, coremask, bootinfo). The code for booting the additional cores is also included in this patchset. Tested on Octeon 7304 EBB with all 16 cores. Thanks, Stefan Aaron Williams (7): mips: octeon: Add header cvmx-regs.h mips: octeon: Add header octeon-feature.h mips: octeon: Add header cvmx-fuse.h mips: octeon: Add header cvmx-bootinfo.h mips: octeon: Add coremask support mips: octeon: Add bootmem support mips: octeon: Add bootoctlinux command Stefan Roese (3): mips: octeon: octeon-model.h: Enable inclusion from assembler files mips: octeon: lowlevel_init.S: Add NMI handling code for SMP Linux booting mips: octeon: octeon_common.h: Increase CONFIG_SYS_BOOTM_LEN arch/mips/mach-octeon/Makefile | 3 + arch/mips/mach-octeon/bootoctlinux.c | 661 ++++++++ arch/mips/mach-octeon/cvmx-bootmem.c | 1460 +++++++++++++++++ arch/mips/mach-octeon/cvmx-coremask.c | 366 +++++ .../mach-octeon/include/mach/bootoct_cmd.h | 54 + .../mach-octeon/include/mach/cvmx-bootinfo.h | 350 ++++ .../mach-octeon/include/mach/cvmx-bootmem.h | 533 ++++++ .../mach-octeon/include/mach/cvmx-coremask.h | 752 +++++++++ .../mips/mach-octeon/include/mach/cvmx-fuse.h | 71 + .../mips/mach-octeon/include/mach/cvmx-regs.h | 144 ++ .../mach-octeon/include/mach/octeon-feature.h | 442 +++++ .../mach-octeon/include/mach/octeon-model.h | 4 + arch/mips/mach-octeon/lowlevel_init.S | 76 + include/configs/octeon_common.h | 2 + 14 files changed, 4918 insertions(+) create mode 100644 arch/mips/mach-octeon/bootoctlinux.c create mode 100644 arch/mips/mach-octeon/cvmx-bootmem.c create mode 100644 arch/mips/mach-octeon/cvmx-coremask.c create mode 100644 arch/mips/mach-octeon/include/mach/bootoct_cmd.h create mode 100644 arch/mips/mach-octeon/include/mach/cvmx-bootinfo.h create mode 100644 arch/mips/mach-octeon/include/mach/cvmx-bootmem.h create mode 100644 arch/mips/mach-octeon/include/mach/cvmx-coremask.h create mode 100644 arch/mips/mach-octeon/include/mach/cvmx-fuse.h create mode 100644 arch/mips/mach-octeon/include/mach/cvmx-regs.h create mode 100644 arch/mips/mach-octeon/include/mach/octeon-feature.h -- 2.28.0

2 11

[PATCH v3 0/9] mips: Add Octeon DDR4 init code
by Stefan Roese 19 Sep '20

19 Sep '20

This patch adds the DDR4 init code. It is ported from the 2013 Cavium / Marvell U-Boot version with no functional change. This was done intentionally, as this code is very large and complex and is known to work on many boards "as-is". So any functional change might have introduced (hidden) incompatibilities. Please note that the code has undergone many hours (read many days) of code cleanup and restructuring. Unfortunately its still not 100% checkpatch clean, as some warnings and checks can practically not be removed / addresses, like these here: CHECK: Prefer kernel type 's8' over 'int8_t' -> 's8' can't be used on MIPS platforms, as its a register macro or: WARNING: Too many leading tabs - consider code refactoring + while (xor != 0) { -> I've restructured the code already and its very hard to remove all these "Too many leading tabs" warnings. or other warnings / checks. But compared to the original code in much better shape (checkpatch wise). I would have liked to include a checkpatch summary in this cover- letter, showing the "before" (original code) and "after" (this code) numbers, but unfortunately currently running checkpatch on the really big file (octeon3_lmc.c) leads to many false errors. I can only suspect that checkpatch has an issue handling this big file because of its size. This code is tested on the Octeon3 EBB7304 EVK and works without any known issues with 1 or 2 DDR4 DIMM configurations (8 & 16 GiB). Thanks, Stefan Changes in v3: - Remove "https://spdx.org/licenses" line - Move multiple comment blocks into one - Remove "https://spdx.org/licenses" line - Remove "https://spdx.org/licenses" line - Remove inclusion of "common.h" - Remove duplicate comment line - Remove "test-only" comment (leftover after cleanup) - Remove "https://spdx.org/licenses" line - Remove inclusion of "common.h" - Remove all internal defines that resulted in dead code, as they have never been changed via external config files or Kconfig. This results in a smaller (~13KiB of source code saved, > 450 lines removed) and much cleaner code base. - Remove "https://spdx.org/licenses" line - Remove "https://spdx.org/licenses" line - Remove inclusion of "common.h" Changes in v2: - Some unsupported Octeon families removed (only Octeon 2 & 3 supported in general) - Some unsupported Octeon families removed (only Octeon 2 & 3 supported in general) - Use readq/writeq in cvmx_read64_uint64/cvmx_write64_uint64 instead of readl/writel - Don't re-init after relocation - Some unsupported Octeon families removed (only Octeon 2 & 3 supported in general) - Only map 256MiB of RAM in U-Boot and print total size as well - Add year to copyright line Aaron Williams (6): mips: octeon: Add octeon-model.h header mips: octeon Add cvmx/cvmx-lmcx-defs.h header mips: octeon: Add octeon_ddr.h header ram: octeon: Add MIPS Octeon3 DDR4 support (part 1/3) ram: octeon: Add MIPS Octeon3 DDR4 support (part 2/3) ram: octeon: Add MIPS Octeon3 DDR4 support (part 3/3) Stefan Roese (3): mips: octeon: dts: mrvl,cn73xx.dtsi: Add memory controller DT node mips: octeon: dram.c: Add RAM driver support mips: octeon: octeon_ebb7304: Add DDR4 support arch/mips/dts/mrvl,cn73xx.dtsi | 17 + arch/mips/mach-octeon/dram.c | 72 +- .../include/mach/cvmx/cvmx-lmcx-defs.h | 4574 +++++++ .../mach-octeon/include/mach/octeon-model.h | 313 + .../mach-octeon/include/mach/octeon_ddr.h | 982 ++ board/Marvell/octeon_ebb7304/board.c | 25 +- board/Marvell/octeon_ebb7304/board_ddr.h | 447 + configs/octeon_ebb7304_defconfig | 3 + drivers/ram/Kconfig | 1 + drivers/ram/Makefile | 2 + drivers/ram/octeon/Kconfig | 17 + drivers/ram/octeon/Makefile | 8 + drivers/ram/octeon/dimm_spd_eeprom.c | 407 + drivers/ram/octeon/octeon3_lmc.c | 11030 ++++++++++++++++ drivers/ram/octeon/octeon_ddr.c | 2728 ++++ include/configs/octeon_common.h | 11 +- 16 files changed, 20622 insertions(+), 15 deletions(-) create mode 100644 arch/mips/mach-octeon/include/mach/cvmx/cvmx-lmcx-defs.h create mode 100644 arch/mips/mach-octeon/include/mach/octeon-model.h create mode 100644 arch/mips/mach-octeon/include/mach/octeon_ddr.h create mode 100644 board/Marvell/octeon_ebb7304/board_ddr.h create mode 100644 drivers/ram/octeon/Kconfig create mode 100644 drivers/ram/octeon/Makefile create mode 100644 drivers/ram/octeon/dimm_spd_eeprom.c create mode 100644 drivers/ram/octeon/octeon3_lmc.c create mode 100644 drivers/ram/octeon/octeon_ddr.c -- 2.28.0

2 10

[PATCH v4 0/8] mips/usb: Add Octeon xHCI USB support
by Stefan Roese 19 Sep '20

19 Sep '20

This patchset adds xHCI USB support for MIPS Octeon. After the xHCI code has been fixed to support mapped addresses (virt != phys), this patchset now adds the missing code pieces to enable USB support on Octeon. This is mainly the USB glue code for Octeon and the MIPS platform specific changes (cache fixes, platform specific swapping based on address areas, DT & defcopnfig changes). Thanks, Stefan Changes in v4: - Add Reviewed-by tag from Bin - Add Reviewed-by tag from Bin - Correct another missed multi-line comment style Changes in v3: - Add Reviewed-by tag from Bin - Minor corrections to the commit text as suggested by Bin - Minor corrections of the commit text as suggested by Bin - Minor corrections in comments as suggested by Bin - Removed empty driver remove() function - Use macros for clock values instead of numbers - Add Reviewed-by tag from Bin - Correct multi-line comment style Changes in v2: - Completely remove BUG_ON() for this trans_event.buffer check - Reword commit text - Only use SPDX format for license info Stefan Roese (8): usb: xhci: xhci-dwc3.c: Use dev_remap_addr() instead of dev_get_addr() usb: xhci: xhci_bulk_tx: Don't "BUG" when comparing addresses usb: xhci: octeon: Add DWC3 glue layer for Octeon mips: octeon: cpu.c: Add table for selective swapping mips: octeon: Add mangle-port.h mips: octeon: cache.c: Flush all pending writes in flush_dcache_range() mips: octeon: Add USB DT nodes mips: octeon: octeon_ebb7304_defconfig: Enable USB support arch/mips/dts/mrvl,cn73xx.dtsi | 60 +++ arch/mips/dts/mrvl,octeon-ebb7304.dts | 24 ++ arch/mips/mach-octeon/cache.c | 12 +- arch/mips/mach-octeon/cpu.c | 21 ++ arch/mips/mach-octeon/include/mangle-port.h | 56 +++ configs/octeon_ebb7304_defconfig | 17 + drivers/usb/host/Kconfig | 9 + drivers/usb/host/Makefile | 1 + drivers/usb/host/dwc3-octeon-glue.c | 393 ++++++++++++++++++++ drivers/usb/host/xhci-dwc3.c | 2 +- drivers/usb/host/xhci-ring.c | 2 - 11 files changed, 588 insertions(+), 9 deletions(-) create mode 100644 arch/mips/mach-octeon/include/mangle-port.h create mode 100644 drivers/usb/host/dwc3-octeon-glue.c -- 2.28.0

2 9