Hi John, On Sat, 4 Nov 2023 at 13:59, John Paul Adrian Glaubitz <glaub...@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