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 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. Thanks, 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 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 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
u-boot fails to build on sparc64 due redefinition of 'struct termio'
Hello!
On Linux sparc64, building u-boot fails with [1]:
cc -o tools/mkenvimage tools/mkenvimage.o tools/os_support.o
tools/lib/crc32.o
In file included from /<>/tools/termios_linux.h:33,
from /<>/tools/kwboot.c:153:
/usr/include/sparc64-linux-gnu/asm/termbits.h:14:8: error: redefinition of
'struct termio'
14 | struct termio {
|^~
In file included from /usr/include/sparc64-linux-gnu/sys/ioctl.h:29,
from /<>/tools/termios_linux.h:30:
/usr/include/sparc64-linux-gnu/bits/ioctl-types.h:36:8: note: originally
defined here
36 | struct termio
|^~
Reading through tools/termios_linux.h, it seems like the problem is that
and are included at the same time. Not sure whether this is
allowed
according to the glibc documentation.
Full build log available in [1].
Adrian
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=u-boot&arch=sparc64&ver=2023.07%2
> Bdfsg-1&stamp=1699723544&raw=0
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: u-boot fails to build on sparc64 due redefinition of 'struct termio'
Hi Simon,
On Wed, 2023-11-15 at 06:40 -0700, Simon Glass wrote:
> Hi Adrian,
>
> On Wed, 15 Nov 2023 at 00:27, John Paul Adrian Glaubitz
> wrote:
> >
> > Hello!
> >
> > On Linux sparc64, building u-boot fails with [1]:
> >
> > cc -o tools/mkenvimage tools/mkenvimage.o tools/os_support.o
> > tools/lib/crc32.o
> > In file included from /<>/tools/termios_linux.h:33,
> > from /<>/tools/kwboot.c:153:
> > /usr/include/sparc64-linux-gnu/asm/termbits.h:14:8: error: redefinition of
> > 'struct termio'
> >14 | struct termio {
> > |^~
> > In file included from /usr/include/sparc64-linux-gnu/sys/ioctl.h:29,
> > from /<>/tools/termios_linux.h:30:
> > /usr/include/sparc64-linux-gnu/bits/ioctl-types.h:36:8: note: originally
> > defined here
> >36 | struct termio
> > |^~
> >
> > Reading through tools/termios_linux.h, it seems like the problem is that
> >
> > and are included at the same time. Not sure whether this
> > is allowed
> > according to the glibc documentation.
>
> Can you send a patch to fix it?
I have not yet fully understood whether the headers are being used incorrectly
or not but
I assume yes since glibc usually does not have such fundamental bugs. I will
consult glibc
upstream first, in any case. They should know.
I have just posted it here first because I hoped someone might have caught an
obvious issue.
> (BTW gmail tells me you are John when I start the email, but I noticed
> it this time and changed it)
My name is "John Paul Adrian", but I am officially called "Adrian" because my
mother thought
that would be good idea. Don't ask ;-).
Thanks,
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: U-Boot support for M68K removal
On Mon, 2023-01-30 at 17:22 +0100, John Paul Adrian Glaubitz wrote: > FWIW, m68k is still a very actively maintained architecture in the > Linux kernel and userland with even LLVM and Rust having recently > added support for m68k. > > I also own a Coldfire board myself (not sure which one without > looking), so I can offer to test U-Boot patches in the future. So, I just found my Coldfire board and it's actually a 547x/548x EVB fitted with a 5475 CPU module clocked at 266 MHz. I will get this board set up during the next weeks and I am happy to test any Coldfire kernel patches, and eventually, U-Boot patches if that board is still supported. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: U-Boot support for M68K removal
Hi Greg! On Mon, 2023-02-06 at 22:02 +1000, Greg Ungerer wrote: > I wish I had a 54415 based board in my collection. Would make it so > much easier to keep the kernel working on it :-( Maybe we can find one to buy for you. I would be happy to donate for it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: U-Boot support for M68K removal
On Mon, 2023-02-06 at 13:25 +0100, John Paul Adrian Glaubitz wrote: > On Mon, 2023-02-06 at 22:02 +1000, Greg Ungerer wrote: > > I wish I had a 54415 based board in my collection. Would make it so > > much easier to keep the kernel working on it :-( > > Maybe we can find one to buy for you. I would be happy to donate for it. Btw, what environment are you using to test Coldfire kernel patches? Do you use Buildroot to create a bootable ColdFire chroot? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
[U-Boot] Problems booting Linux 3.18 on SH7785LCR
Hello! I recently got Renesas SH7785LCR board which I am currently setting up as a Debian porterbox for sh4. Currently, all sh4 build machines at Debian for sh4 are running kernel 3.2.0 which is showing its age now, especially since newer versions of udev are complaining about the deprecated kernel. Since I am setting up my SH7785LCR board as a new machine, I wanted to start with a new kernel right away. But since I also don't have any older base system which I could use, I need to use an updated kernel anyway. While I had no problems booting an old uImage with the aforementioned 3.2.0 kernel, I haven't had any success with kernel 3.18 so far. u-boot loads the kernel, decompresses it but seems to perform a reset right away: 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 => => usb reset (Re)start USB... USB0: scanning bus 0 for devices... 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => fatload usb 0:1 0x8900 uImage-3.18 reading uImage-3.18 2977932 bytes read in 1690 ms (1.7 MiB/s) => pmb => bootm ## Booting kernel from Legacy Image at 8900 ... Image Name: Image Type: SuperH Linux Kernel Image (gzip compressed) Data Size:2977868 Bytes = 2.8 MiB Load Address: 80001000 Entry Point: 80002000 Verifying Checksum ... OK � Uncompressing Kernel Image ... OK 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 => The 3.18 uImage was created by downloading the Debian kernel image package for the SH7785LCR [1] and unpacking the package. Then I created the uImage using the following command using the same loader and entry address that are being set for the 3.2.0 uImage: mkimage -A sh -O linux -a 0x80001000 -e 0x80002000 -d vmlinuz-3.18.0-trunk-sh7785lcr.gz uImage-3.18 Does anyone know what could be wrong such that the kernel wouldn't boot as shown above? Cheers, Adrian > [1] ftp://ftp.debian-ports.org/debian/pool-sh4/main/l/linux/linux-image-3.18.0-trunk-sh7785lcr_3.18.3-1~exp1_sh4.deb -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Problems booting Linux 3.18 on SH7785LCR
Hello! I recently got Renesas SH7785LCR board which I am currently setting up as a Debian porterbox for sh4. Currently, all sh4 build machines at Debian for sh4 are running kernel 3.2.0 which is showing its age now, especially since newer versions of udev are complaining about the deprecated kernel. Since I am setting up my SH7785LCR board as a new machine, I wanted to start with a new kernel right away. But since I also don't have any older base system which I could use, I need to use an updated kernel anyway. While I had no problems booting an old uImage with the aforementioned 3.2.0 kernel, I haven't had any success with kernel 3.18 so far. u-boot loads the kernel, decompresses it but seems to perform a reset right away: 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 => => usb reset (Re)start USB... USB0: scanning bus 0 for devices... 2 USB Device(s) found scanning usb for storage devices... 1 Storage Device(s) found => fatload usb 0:1 0x8900 uImage-3.18 reading uImage-3.18 2977932 bytes read in 1690 ms (1.7 MiB/s) => pmb => bootm ## Booting kernel from Legacy Image at 8900 ... Image Name: Image Type: SuperH Linux Kernel Image (gzip compressed) Data Size:2977868 Bytes = 2.8 MiB Load Address: 80001000 Entry Point: 80002000 Verifying Checksum ... OK � Uncompressing Kernel Image ... OK 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 => The 3.18 uImage was created by downloading the Debian kernel image package for the SH7785LCR [1] and unpacking the package. Then I created the uImage using the following command using the same loader and entry address that are being set for the 3.2.0 uImage: mkimage -A sh -O linux -a 0x80001000 -e 0x80002000 -d vmlinuz-3.18.0-trunk-sh7785lcr.gz uImage-3.18 Does anyone know what could be wrong such that the kernel wouldn't boot as shown above? Cheers, Adrian > [1] ftp://ftp.debian-ports.org/debian/pool-sh4/main/l/linux/linux-image-3.18.0-trunk-sh7785lcr_3.18.3-1~exp1_sh4.deb -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: U-Boot support for M68K removal
Hi! On Mon, 2023-01-30 at 11:14 -0500, Tom Rini wrote: > On Mon, Jan 30, 2023 at 01:49:11PM +0100, Angelo Dureghello wrote: > > > Hi Tom and all, > > > > really have to apologize, had hard times these last 2 years > > and couldn't follow at all the activity, i am totally culprit > > and responsible. > > > > Now i can jump back on following, if there is any sense > > in keeping m68k/coldfire. > > Let me know, if ok i start back checking all old patches > > from tonight. Also, will have to update my email and rebase > > to master. > > I'm glad you're back. I think the first thing to do would be to > confirm > that U-Boot still works on at least some supported board, then > confirming you can still access > https://source.denx.de/u-boot/custodians/u-boot-coldfire > FWIW, m68k is still a very actively maintained architecture in the Linux kernel and userland with even LLVM and Rust having recently added support for m68k. I also own a Coldfire board myself (not sure which one without looking), so I can offer to test U-Boot patches in the future. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: [PATCH] sh: cache: Fill in invalidate_icache_all()
Good morning Geert,
On Wed, 2024-09-11 at 09:19 +0200, Geert Uytterhoeven wrote:
> Hi Marek,
>
> On Tue, Sep 10, 2024 at 7:55 PM Marek Vasut wrote:
> > On 9/10/24 7:21 PM, Tom Rini wrote:
> > > On Tue, Sep 10, 2024 at 02:15:58AM +0200, Marek Vasut wrote:
> > >
> > > > Implement invalidate_icache_all() by clearing all V bits in
> > > > IC and OC. This is done by setting CCR cache control register
> > > > ICI and OCI bits.
> > > >
> > > > Signed-off-by: Marek Vasut
> > > > ---
> > > > Cc: Ilias Apalodimas
> > > > Cc: Nobuhiro Iwamatsu
> > > > Cc: Tom Rini
> > > > Cc: u-boot@lists.denx.de
> > > > ---
> > > > arch/sh/cpu/sh4/cache.c | 11 +++
> > > > 1 file changed, 7 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/arch/sh/cpu/sh4/cache.c b/arch/sh/cpu/sh4/cache.c
> > > > index d3c480e79ed..99acc599965 100644
> > > > --- a/arch/sh/cpu/sh4/cache.c
> > > > +++ b/arch/sh/cpu/sh4/cache.c
> > > > @@ -33,8 +33,9 @@ static inline void cache_wback_all(void)
> > > > }
> > > > }
> > > >
> > > > -#define CACHE_ENABLE 0
> > > > -#define CACHE_DISABLE 1
> > > > +#define CACHE_ENABLE0
> > > > +#define CACHE_DISABLE 1
> > > > +#define CACHE_INVALIDATE2
> > > >
> > > > static int cache_control(unsigned int cmd)
> > > > {
> > > > @@ -46,7 +47,9 @@ static int cache_control(unsigned int cmd)
> > > > if (ccr & CCR_CACHE_ENABLE)
> > > > cache_wback_all();
> > > >
> > > > -if (cmd == CACHE_DISABLE)
> > > > +if (cmd == CACHE_INVALIDATE)
> > > > +outl(CCR_CACHE_ICI | ccr, CCR);
> > > > +else if (cmd == CACHE_DISABLE)
> > > > outl(CCR_CACHE_STOP, CCR);
> > > > else
> > > > outl(CCR_CACHE_INIT, CCR);
> > > > @@ -103,7 +106,7 @@ void icache_disable(void)
> > > >
> > > > void invalidate_icache_all(void)
> > > > {
> > > > -puts("No arch specific invalidate_icache_all available!\n");
> > > > +cache_control(CACHE_INVALIDATE);
> > > > }
> > > >
> > > > int icache_status(void)
> > >
> > > Thanks for filling this in, I wasn't sure how the implementation would
> > > look from a quick skim of the linux kernel code.
> > I believe it should look like the above, but lemme CC Geert to be on the
> > safe side.
>
> I have no idea. I removed the corresponding (but incomplete) code
> from Linux in commit 25c7d77d695a4104 ("sh: boot: Remove sh5 cache
> handling"), as it was a relic of sh5 cache handling.
>
> SH4 cache handling seems to be buried deeper. At least the above
> matches for invalidation:
>
> arch/sh/mm/cache-sh4.c- /* Flush I-cache */
> arch/sh/mm/cache-sh4.c: ccr = __raw_readl(SH_CCR);
> arch/sh/mm/cache-sh4.c- ccr |= CCR_CACHE_ICI;
> arch/sh/mm/cache-sh4.c: __raw_writel(ccr, SH_CCR);
Odd, I haven't received the original mail.
@Marek: Could you resent your patch CC'ing the current maintainers of arch/sh?
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
