Hi John,
On Sat, 4 Nov 2023 at 13:59, John Paul Adrian Glaubitz glaubitz@physik.fu-berlin.de wrote:
Hello!
I am Debian's maintainer for the SuperH (sh4) port as well as one of the upstream maintainers of SuperH support in the kernel. I own various SuperH boards with one of them being the Renesas SH-7785LCR board which used to be supported by u-boot up to including v2019.01.
My board is currently running v2014.01 with the following output:
U-Boot 2014.01 (Jan 30 2015 - 11:01:14)
CPU: SH4 BOARD: Renesas Technology Corp. R0P7785LC0011RL DRAM: 384MB Flash: 64MB PCI: SH7780 PCI host bridge found. PCI: Bus Dev VenId DevId Class Int 00:00.0 - 10ec:8169 - Network controller 00:01.0 - 1095:3512 - Mass storage controller In: serial Out: serial Err: serial Net: RTL8169#0 Warning: RTL8169#0 MAC addresses don't match: Address in SROM is 00:00:87:6b:bd:72 Address in environment is 74:90:50:00:02:03
Hit any key to stop autoboot: 0 => printenv baudrate=115200 bootargs=console=ttySC1,115200 root=/dev/sda1 ip=dhcp bootcmd=usb reset; fatload usb 0:1 0x89000000 uImage-git.gz; pmb ; bootm bootdelay=3 bootdevice=0:1 ethact=RTL8169#0 ethaddr=74:90:50:00:02:03 stderr=serial stdin=serial stdout=serial usbload=usb reset; fatload usb 0:1 0x89000000 uImage-git.gz; pmb ; bootm ver=U-Boot 2014.01 (Jan 30 2015 - 11:01:14)
Environment size: 396/262140 bytes =>
I am currently running into the problem that u-boot hangs after verifying the image checksum when trying to boot a cross-built kernel. This has happened in the past before while often the kernel would boot just fine after performing some resets.
When the boot hangs, it looks like this:
=> usb reset; fatload usb 0:1 0x89000000 uImage-next.gz ; pmb ; bootm (Re)start USB... USB0: scanning bus 0 for devices... 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found reading uImage-next.gz 4348967 bytes read in 2470 ms (1.7 MiB/s) ## Booting kernel from Legacy Image at 89000000 ... Image Name: Linux-6.6.0-rc1-00007-g63f1ee206 Image Type: SuperH Linux Kernel Image (gzip compressed) Data Size: 4348903 Bytes = 4.1 MiB Load Address: 80001000 Entry Point: 80002000 Verifying Checksum ... OK (hangs)
My first attempt at fixing this would be upgrading the board to v2019.01.
Unfortunately, I have not found any documentation yet which explains how to upgrade the u-boot firmware on this particular board. Does anyone know whether there are any tools for this available? I can see an "erase" command in the u-boot command list, but there is no command for writing a new u-boot firmware to flash.
I have already reached out to Nobuhiro Iwamatsu who is the original author of support for these boards in u-boot and also provided me with the particular hardware. However, I haven't heard back from him yet.
Another question that I have is the loading address. I need to load the kernel to the loading address 0x89000000 as otherwise the machine won't boot. However, according to the output of the u-boot mkimage tool, the loading address is 0x80001000 and not 0x8900000. Could the different addresses be related to the unusual memory layout of this board which has to be switched with the "pmb" command prior boot?
Also, I was wondering what it would take to convert this particular board to CONFIG_DM_USB and CONFIG_DM_PCI. I would be interested in getting support for SuperH boards in u-boot into a better shape with broader hardware support.
From the kernel side, we're currently working on converting SuperH to Device Trees, so I'm expecting SuperH Linux to be better suited to modern versions of u-boot in the future.
For now, it would be a great help if anyone could help me with the hanging boot issue.
Is it possible to check if it reaches the kernel? E.g. with earlyprintk ? It would be good to know if U-Boot managers to jump to Linux, or not.
Regards, Simon