Re: [U-Boot] [RESEND][PATCH 00/24] sh: add generic board support and fixes
Hi Tom,
On 11/28/2016 05:43 PM, Tom Rini wrote:
On Mon, Nov 28, 2016 at 12:15:12AM +0200, Vladimir Zapolskiy wrote:
This is a combined series of the fixes to SH2/SH3/SH4/SH4A architecture port of U-boot on top of the master branch, there is no functional difference between this series and 3 my series sent in August 2016 for 2016.09, however due to many positive generalization updates to U-boot sources the old unreviewed series can not be cleanly applied anymore:
- [PATCH 0/6] sh4: fix and simplify cache manipulation
- [PATCH 0/5] sh4: fixes to SH7751 PCI host controller
- [PATCH] common: sh: add necessary define bits to board_f
- [PATCH 00/12] sh: change arch and boards code to generic board
I have to resend the changes, because apparently Nobuhiro Iwamatsu is too busy to maintain SH port and I ask Tom/Simon/Marek and other active U-boot developers to review and apply the changes, it is highly desirable to have a possibility to run modern U-boot on boards powered by SH cores.
First, would you be interested in taking up the SH maintainership?
clearly Renesas abandoned SH architecture as a legacy one (and probably as a competing with R-Car one), but until J4 core as a replacement for Renesas SH4 is released by j-core.org project it is desirable to keep U-Boot running on SH platforms.
I'm interested in maintainership of SH and thereafter J-Core cores, but practically I have only one SH4 powered board on hand, unfortunately begging for hardware donations was not so successful. At the moment U-Boot contains SH2A/SH3/SH4/SH4A arch support and boards, I have to figure out where to get more boards to cover more SoC flavours, and getting legacy hardware is always a problem, because it is not on a store's shelf.
To start from I would recommend to decouple u-boot-sh.git fork into independent SH and ARM R-Car repositories, the latter one will be maintained by Renesas associates.
Second, I know before you told me how to get QEMU to run, but with this series and: qemu-system-sh4 -M r2d -kernel r2dplus/current/r2dplus/u-boot.bin -nographic -serial null -serial vc
I get: QEMU 2.5.91 monitor - type 'help' for more information (qemu) long write to SH7750_WCR1_A7 (0x000000001f800008) ignored long write to SH7750_WCR2_A7 (0x000000001f80000c) ignored long write to SH7750_WCR3_A7 (0x000000001f800010) ignored long write to SH7750_MCR_A7 (0x000000001f800014) ignored word write to SH7750_RTCNT_A7 (0x000000001f800020) ignored word write to SH7750_RTCOR_A7 (0x000000001f800024) ignored Write access to refresh count register word write to SH7750_RTCSR_A7 (0x000000001f80001c) ignored Read access to refresh count register, incrementing long write to SH7750_MCR_A7 (0x000000001f800014) ignored long read to SH7750_WCR1_A7 (0x000000001f800008) ignored long read to SH7750_WCR2_A7 (0x000000001f80000c) ignored long read to SH7750_WCR3_A7 (0x000000001f800010) ignored long read to SH7750_MCR_A7 (0x000000001f800014) ignored
and the qemu monitor/debug prompt.
The displayed qemu output is expected and can be ignored, currently SH port in qemu is in "odd fixes" maintainership stage, hopefully I'll find time to send a patch to silence this.
Without -serial args I just get the hang. Any ideas? I ask since I'm keen to add r2dplus to test.py and travis-ci once it's working, thanks!
I use this list of components to build and test U-Boot on r2dplus qemu target and SH7751 powered board I have on hand (it is quite similar to r2dplus devkit):
* SH4 toolchain from buildroot distro with musl (libc flavour most probably is unrelated to U-boot or kernel): - gcc-5.3.0 - musl-1.1.12 - linux-4.4 headers
* qemu-system-sh4 is from standard Debian qemu-system-misc package: - qemu-system-misc-1:2.6+dfsg-3 - qemu-2.6.50 vanilla build also works for me fine
* U-Boot compilation:
% make ARCH=sh CROSS_COMPILE=sh4-buildroot-linux-musl- CC='sh4-buildroot-linux-musl-gcc -Wall' r2dplus_defconfig
% make ARCH=sh CROSS_COMPILE=sh4-buildroot-linux-musl- CC='sh4-buildroot-linux-musl-gcc -Wall' u-boot.bin
Command to run qemu with output directly to a console is similar to the command you mentioned above (press Ctrl-C to terminate):
% qemu-system-sh4 -M r2d -kernel u-boot.bin -monitor null -serial null -serial stdio -nographic
This is an example of testing on my end (omitting "long write .. ignored" messages):
U-Boot 2016.11-00195-ge01f392eab43 (Nov 29 2016 - 02:55:25 +0200)
CPU: SH4 BOARD: Renesas Solutions R2D Plus DRAM: 64 MiB Flash: ERROR: too many flash sectors 8 MiB *** Warning - bad CRC, using default environment
PCI: SH7751 PCI host bridge found. long read to SH7750_WCR1_A7 (0x000000001f800008) ignored long read to SH7750_WCR2_A7 (0x000000001f80000c) ignored long read to SH7750_WCR3_A7 (0x000000001f800010) ignored long read to SH7750_MCR_A7 (0x000000001f800014) ignored PCI: Bus Dev VenId DevId Class Int PCI: 00:00.0 - 1054:350e - Bridge device 00:02.0 - 10ec:8139 - Network controller In: serial Out: serial Err: serial Net: RTL8139#0 Error: RTL8139#0 address not set.
IDE: Bus 0: not available => bdinfo mem start = 0x8C000000 mem size = 0x04000000 flash start = 0xA0000000 flash size = 0x00800000 flash offset = 0xFFE5D444 ethaddr = (not set) IP addr = <NULL> baudrate = 115200 bps => pci Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 00.00.00 0x1054 0x350e Bridge device 0x00 00.02.00 0x10ec 0x8139 Network controller 0x00
-- With best wishes, Vladimir
On Tue, Nov 29, 2016 at 02:58:41AM +0200, Vladimir Zapolskiy wrote:
Hi Tom,
On 11/28/2016 05:43 PM, Tom Rini wrote:
On Mon, Nov 28, 2016 at 12:15:12AM +0200, Vladimir Zapolskiy wrote:
This is a combined series of the fixes to SH2/SH3/SH4/SH4A architecture port of U-boot on top of the master branch, there is no functional difference between this series and 3 my series sent in August 2016 for 2016.09, however due to many positive generalization updates to U-boot sources the old unreviewed series can not be cleanly applied anymore:
- [PATCH 0/6] sh4: fix and simplify cache manipulation
- [PATCH 0/5] sh4: fixes to SH7751 PCI host controller
- [PATCH] common: sh: add necessary define bits to board_f
- [PATCH 00/12] sh: change arch and boards code to generic board
I have to resend the changes, because apparently Nobuhiro Iwamatsu is too busy to maintain SH port and I ask Tom/Simon/Marek and other active U-boot developers to review and apply the changes, it is highly desirable to have a possibility to run modern U-boot on boards powered by SH cores.
First, would you be interested in taking up the SH maintainership?
clearly Renesas abandoned SH architecture as a legacy one (and probably as a competing with R-Car one), but until J4 core as a replacement for Renesas SH4 is released by j-core.org project it is desirable to keep U-Boot running on SH platforms.
I'm interested in maintainership of SH and thereafter J-Core cores, but practically I have only one SH4 powered board on hand, unfortunately begging for hardware donations was not so successful. At the moment U-Boot contains SH2A/SH3/SH4/SH4A arch support and boards, I have to figure out where to get more boards to cover more SoC flavours, and getting legacy hardware is always a problem, because it is not on a store's shelf.
To start from I would recommend to decouple u-boot-sh.git fork into independent SH and ARM R-Car repositories, the latter one will be maintained by Renesas associates.
I'm interesting in having J-Core work and be maintained in U-Boot, so lets make this work. With regards to legacy platforms, I'm happy to drop things which are unavailable / non-functional and just note in doc/README.scrapyard when things were removed. We did this a lot around a year ago and probably should again.
And then yes, the R-Car patches should come in via another repository rather than u-boot.sh as was previously convenient.
Second, I know before you told me how to get QEMU to run, but with this series and: qemu-system-sh4 -M r2d -kernel r2dplus/current/r2dplus/u-boot.bin -nographic -serial null -serial vc
I get: QEMU 2.5.91 monitor - type 'help' for more information (qemu) long write to SH7750_WCR1_A7 (0x000000001f800008) ignored long write to SH7750_WCR2_A7 (0x000000001f80000c) ignored long write to SH7750_WCR3_A7 (0x000000001f800010) ignored long write to SH7750_MCR_A7 (0x000000001f800014) ignored word write to SH7750_RTCNT_A7 (0x000000001f800020) ignored word write to SH7750_RTCOR_A7 (0x000000001f800024) ignored Write access to refresh count register word write to SH7750_RTCSR_A7 (0x000000001f80001c) ignored Read access to refresh count register, incrementing long write to SH7750_MCR_A7 (0x000000001f800014) ignored long read to SH7750_WCR1_A7 (0x000000001f800008) ignored long read to SH7750_WCR2_A7 (0x000000001f80000c) ignored long read to SH7750_WCR3_A7 (0x000000001f800010) ignored long read to SH7750_MCR_A7 (0x000000001f800014) ignored
and the qemu monitor/debug prompt.
The displayed qemu output is expected and can be ignored, currently SH port in qemu is in "odd fixes" maintainership stage, hopefully I'll find time to send a patch to silence this.
Ah, OK.
Without -serial args I just get the hang. Any ideas? I ask since I'm keen to add r2dplus to test.py and travis-ci once it's working, thanks!
I use this list of components to build and test U-Boot on r2dplus qemu target and SH7751 powered board I have on hand (it is quite similar to r2dplus devkit):
- SH4 toolchain from buildroot distro with musl (libc flavour most probably is unrelated to U-boot or kernel):
- gcc-5.3.0
- musl-1.1.12
- linux-4.4 headers
- qemu-system-sh4 is from standard Debian qemu-system-misc package:
- qemu-system-misc-1:2.6+dfsg-3
- qemu-2.6.50 vanilla build also works for me fine
- U-Boot compilation:
% make ARCH=sh CROSS_COMPILE=sh4-buildroot-linux-musl- CC='sh4-buildroot-linux-musl-gcc -Wall' r2dplus_defconfig
% make ARCH=sh CROSS_COMPILE=sh4-buildroot-linux-musl- CC='sh4-buildroot-linux-musl-gcc -Wall' u-boot.bin
Command to run qemu with output directly to a console is similar to the command you mentioned above (press Ctrl-C to terminate):
% qemu-system-sh4 -M r2d -kernel u-boot.bin -monitor null -serial null -serial stdio -nographic
This is an example of testing on my end (omitting "long write .. ignored" messages):
U-Boot 2016.11-00195-ge01f392eab43 (Nov 29 2016 - 02:55:25 +0200)
CPU: SH4 BOARD: Renesas Solutions R2D Plus DRAM: 64 MiB Flash: ERROR: too many flash sectors 8 MiB *** Warning - bad CRC, using default environment
PCI: SH7751 PCI host bridge found. long read to SH7750_WCR1_A7 (0x000000001f800008) ignored long read to SH7750_WCR2_A7 (0x000000001f80000c) ignored long read to SH7750_WCR3_A7 (0x000000001f800010) ignored long read to SH7750_MCR_A7 (0x000000001f800014) ignored PCI: Bus Dev VenId DevId Class Int PCI: 00:00.0 - 1054:350e - Bridge device 00:02.0 - 10ec:8139 - Network controller In: serial Out: serial Err: serial Net: RTL8139#0 Error: RTL8139#0 address not set.
IDE: Bus 0: not available => bdinfo mem start = 0x8C000000 mem size = 0x04000000 flash start = 0xA0000000 flash size = 0x00800000 flash offset = 0xFFE5D444 ethaddr = (not set) IP addr = <NULL> baudrate = 115200 bps => pci Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 00.00.00 0x1054 0x350e Bridge device 0x00 00.02.00 0x10ec 0x8139 Network controller 0x00
Ah, OK. With that exact command line I can get things going. My gut feeling, having played with other qemu boards as a user, is that there's something odd going on in how qemu is parsing the arguments and assigning things as the defaults "should" provide this too, but instead we're disabling the defaults for monitor and serial (which can usually be multiplexed) and then only giving serial to stdio.
But, the good news is that this means I can get travis-ci going and make add r2dplus to the list of tested-every-time platforms. I'll follow up to your series with patches for that hopefully tomorrow.
participants (2)
-
Tom Rini -
Vladimir Zapolskiy