Re: Need advise with u-boot on SH-7785LCR
On 11/6/23 21:42, Simon Glass wrote: +Marek Vasut +Vagrant Cascadian On Mon, 6 Nov 2023 at 10:33, John Paul Adrian Glaubitz < glaub...@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.
Re: Need advise with u-boot on SH-7785LCR
+Marek Vasut +Vagrant Cascadian On Mon, 6 Nov 2023 at 10:33, John Paul Adrian Glaubitz < glaub...@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: > > > https://people.debian.org/~glaubitz/u-boot-sh7785lcr/ > > 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 >
Re: Need advise with u-boot on SH-7785LCR
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: > https://people.debian.org/~glaubitz/u-boot-sh7785lcr/ 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
Re: Need advise with u-boot on SH-7785LCR
Hi John, On Mon, 6 Nov 2023 at 15:00, John Paul Adrian Glaubitz wrote: > > Hi Simon, > > On Sun, 2023-11-05 at 16:29 +, 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 0x-0x03ff] > [1.604000] physmap-flash.0: Found 2 x16 devices at 0x0 in 32-bit bank. > Manufacturer ID 0x01 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
Re: Need advise with u-boot on SH-7785LCR
Hi Simon, On Sun, 2023-11-05 at 16:29 +, 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 0x-0x03ff] [1.604000] physmap-flash.0: Found 2 x16 devices at 0x0 in 32-bit bank. Manufacturer ID 0x01 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 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Need advise with u-boot on SH-7785LCR
Hi John, On Sun, 5 Nov 2023 at 09:37, John Paul Adrian Glaubitz wrote: > > Hi Simon, > > On Sat, 2023-11-04 at 19:42 +, 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
Re: Need advise with u-boot on SH-7785LCR
Hi Simon, On Sat, 2023-11-04 at 19:42 +, 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 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Need advise with u-boot on SH-7785LCR
Hi John, On Sat, 4 Nov 2023 at 13:59, John Paul Adrian Glaubitz 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 0x8900 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 0x8900 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 0x8900 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 8900 ... >Image Name: Linux-6.6.0-rc1-7-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 0x8900 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 > 0x890. 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
