Need advise with u-boot on SH-7785LCR
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.
Thanks, Adrian
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
Hi Simon,
On Sat, 2023-11-04 at 19:42 +0000, Simon Glass wrote:
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.
Thanks, this is actually a very good idea. In fact, we recently restored earlyprintk support on SuperH which got disabled by accident [1], so I would have an opportunity to use it right away.
Do you have maybe any clue as for how to update u-boot on this machine?
Might be a good idea to start from the most recent version that is supported on this target. I assume the "erase" command will erase the flash. But there doesn't seem to be a "program" command.
Adrian
Hi John,
On Sun, 5 Nov 2023 at 09:37, John Paul Adrian Glaubitz glaubitz@physik.fu-berlin.de wrote:
Hi Simon,
On Sat, 2023-11-04 at 19:42 +0000, Simon Glass wrote:
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.
Thanks, this is actually a very good idea. In fact, we recently restored earlyprintk support on SuperH which got disabled by accident [1], so I would have an opportunity to use it right away.
Do you have maybe any clue as for how to update u-boot on this machine?
Might be a good idea to start from the most recent version that is supported on this target. I assume the "erase" command will erase the flash. But there doesn't seem to be a "program" command.
No, sorry I don't have any idea about that. You could check the MAINTAINERS files in U-Boot and Linux for other people, perhaps, or check commit / blame logs?
Regards, Simon
Adrian
-- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Simon,
On Sun, 2023-11-05 at 16:29 +0000, Simon Glass wrote:
No, sorry I don't have any idea about that. You could check the MAINTAINERS files in U-Boot and Linux for other people, perhaps, or check commit / blame logs?
It seems that the flash memory is mapped to block devices by the kernel:
root@tirpitz:~> dmesg|grep -i flash [ 1.592000] physmap-flash physmap-flash.0: physmap platform flash device: [mem 0x00000000-0x03ffffff] [ 1.604000] physmap-flash.0: Found 2 x16 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000001 Chip ID 0x002201 [ 1.632000] Creating 4 MTD partitions on "physmap-flash.0": root@tirpitz:~> ls -l /dev/mtdblock* brw-rw---- 1 root disk 31, 0 Sep 30 12:35 /dev/mtdblock0 brw-rw---- 1 root disk 31, 1 Sep 30 12:35 /dev/mtdblock1 brw-rw---- 1 root disk 31, 2 Sep 30 12:35 /dev/mtdblock2 brw-rw---- 1 root disk 31, 3 Sep 30 12:35 /dev/mtdblock3 root@tirpitz:~>
So, I assume, I should just be able to write u-boot.bin to /dev/mtdblock0?
Adrian
Hi John,
On Mon, 6 Nov 2023 at 15:00, John Paul Adrian Glaubitz glaubitz@physik.fu-berlin.de wrote:
Hi Simon,
On Sun, 2023-11-05 at 16:29 +0000, Simon Glass wrote:
No, sorry I don't have any idea about that. You could check the MAINTAINERS files in U-Boot and Linux for other people, perhaps, or check commit / blame logs?
It seems that the flash memory is mapped to block devices by the kernel:
root@tirpitz:~> dmesg|grep -i flash [ 1.592000] physmap-flash physmap-flash.0: physmap platform flash device: [mem 0x00000000-0x03ffffff] [ 1.604000] physmap-flash.0: Found 2 x16 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000001 Chip ID 0x002201 [ 1.632000] Creating 4 MTD partitions on "physmap-flash.0": root@tirpitz:~> ls -l /dev/mtdblock* brw-rw---- 1 root disk 31, 0 Sep 30 12:35 /dev/mtdblock0 brw-rw---- 1 root disk 31, 1 Sep 30 12:35 /dev/mtdblock1 brw-rw---- 1 root disk 31, 2 Sep 30 12:35 /dev/mtdblock2 brw-rw---- 1 root disk 31, 3 Sep 30 12:35 /dev/mtdblock3 root@tirpitz:~>
So, I assume, I should just be able to write u-boot.bin to /dev/mtdblock0?
Maybe, but you will likely brick the device if you have no other way to write to flash.
Regards, Simon
Adrian
-- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Hi Simon!
On Mon, 2023-11-06 at 10:24 -0700, Simon Glass wrote:
So, I assume, I should just be able to write u-boot.bin to /dev/mtdblock0?
Maybe, but you will likely brick the device if you have no other way to write to flash.
The flash memory is actually on a daughter board that can be easily replaced and I have multiple of these daughter boards. It turns out that just writing the image to /dev/mtdblock0 works and I can boot the board into the freshly flashed u-boot version.
However, the u-boot version 2019.01 built from git won't work while the old 2014.01 version that I copied onto disk from /dev/mtdblock0 does work when flashing it to a second daughter board.
So, flashing works indeed like this and I can successfully start u-boot after flashing it into /dev/mtdblock0. Now I just need to figure out what the difference between 2014.01 and 2019.01 is and why the latter doesn't work.
I have uploaded both versions here:
Maybe someone with more experience can spot anything obvious like incorrect address offsets etc.
PS: I'm actually called Adrian, despite the long name ;-).
Adrian
+Marek Vasut marex@denx.de +Vagrant Cascadian vagrant@debian.org
On Mon, 6 Nov 2023 at 10:33, John Paul Adrian Glaubitz < glaubitz@physik.fu-berlin.de> wrote:
Hi Simon!
On Mon, 2023-11-06 at 10:24 -0700, Simon Glass wrote:
So, I assume, I should just be able to write u-boot.bin to
/dev/mtdblock0?
Maybe, but you will likely brick the device if you have no other way to write to flash.
The flash memory is actually on a daughter board that can be easily replaced and I have multiple of these daughter boards. It turns out that just writing the image to /dev/mtdblock0 works and I can boot the board into the freshly flashed u-boot version.
However, the u-boot version 2019.01 built from git won't work while the old 2014.01 version that I copied onto disk from /dev/mtdblock0 does work when flashing it to a second daughter board.
So, flashing works indeed like this and I can successfully start u-boot after flashing it into /dev/mtdblock0. Now I just need to figure out what the difference between 2014.01 and 2019.01 is and why the latter doesn't work.
I have uploaded both versions here:
Maybe someone with more experience can spot anything obvious like incorrect address offsets etc.
PS: I'm actually called Adrian, despite the long name ;-).
Adrian
-- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On 11/6/23 21:42, Simon Glass wrote:
+Marek Vasut marex@denx.de +Vagrant Cascadian vagrant@debian.org
On Mon, 6 Nov 2023 at 10:33, John Paul Adrian Glaubitz < glaubitz@physik.fu-berlin.de> wrote:
Hi Simon!
On Mon, 2023-11-06 at 10:24 -0700, Simon Glass wrote:
So, I assume, I should just be able to write u-boot.bin to
/dev/mtdblock0?
Maybe, but you will likely brick the device if you have no other way to write to flash.
The flash memory is actually on a daughter board that can be easily replaced and I have multiple of these daughter boards. It turns out that just writing the image to /dev/mtdblock0 works and I can boot the board into the freshly flashed u-boot version.
However, the u-boot version 2019.01 built from git won't work while the old 2014.01 version that I copied onto disk from /dev/mtdblock0 does work when flashing it to a second daughter board.
So, flashing works indeed like this and I can successfully start u-boot after flashing it into /dev/mtdblock0. Now I just need to figure out what the difference between 2014.01 and 2019.01 is and why the latter doesn't work.
In U-Boot, parallel NOR flash is flashed by cp.b into the parallel NOR memory mapped address , there are hooks which do the NOR writing.
participants (3)
-
John Paul Adrian Glaubitz -
Marek Vasut -
Simon Glass