I have an Avnet/Architech Hachiko board without SDRAM. It uses RZ/A1H R7S72100 with 10 MB SRAM SoC in QFP package. I want to run mainline U-Boot and Linux on it.
Vendor documentation on the board: http://architechboards-hachiko-tiny.readthedocs.io/en/latest/ and http://downloads.architechboards.com/doc/Hachiko/download.html
BSP that came with it from the vendor used patches to U-Boot and Linux provided in: https://github.com/bradfa/meta-hachiko
It seems there's some amount of support in mainline Linux for RZ/A1 but I'm not sure how much. It's unclear to me how much support there is in mainline U-Boot. Either way, I want to run mainline on this board as I want to learn and if needed, contribute code upstream.
- The Hachiko board seems to be really poorly designed for use as a code development tool :(
- elinux.org has some good info on the Peach board: http://elinux.org/RZ-A/Boards/GR-PEACH-mainline and http://elinux.org/RZ-A/Boards/GR-PEACH-bsp both rely on using a Segger J-Link to program the QSPI flash (which we can probably also do for Hachiko).
- There's no push-button reset on the board but ~RESET is brought out to connector CN5-4 and it's right between ground pins so we can use that. Although actually using it results in a very strange reset condition as some parts of the board seem to turn off while others stay on leading to the board not booting after a reset low is applied...
- The FTDI FT232RL that's on the board is annoyingly wired as the VBUS that comes into the USB port to the FTDI also will provide power to the rest of the board. Isolating this FTDI that it stays on while the board is off doesn't appear to be easy to do. But we can remove resistors R15 and R17 and wire in our own 3.3 V UART interface on the resistors' pads with an external FTDI (or similar). You can fix this! ;) http://www.bradfordembedded.com/2017/07/hachiko-uart-sanity-rework
- Programming the SPI flash parts with an external programmer will require holding the board in reset and lifting the SPI flash pin 3 ~RESET pin from the board as there's no isolation of the SPI flash parts' power or reset lines. So realistically, the only way to program the SPI flash is to get u-boot into SRAM and run it so we can download and write to flash, or to use JTAG (Renesas has a semi-hosting document which seems annoying to follow: http://downloads.architechboards.com/hachiko/doc/RZ_A1H_sflash_sample_rev0.01e.pdf )
- There's very little silkscreen to indicate reference designators on the board, so matching up physical components with schematic refdes is annoying.
- U-Boot newer than v2017.01 (ie: 2017.05 and current master branch) have a hard time dealing with non-standard CROSS_COMPILE environment variables, it seems. My normal
arm-ka-linux-gnueabi-value ends up with u-boot Makefile getting all messed up and failing to build some fdt tools. Using the Debian provided arm-linux-gnueabi-gcc toolchain and binutils seems to fix it. - Most Renesas ARM parts appear to use the "rmobile" name/brand in U-Boot.
- R7S72100 Ethernet MAC has support in drivers/net/sh_eth.{c,h} since v2014.07 release but doesn't seem to have any users of SH_ETH_TYPE_RZ as of today.
- Found a note from Anantha at PHYTECH (https://renesasrulz.com/rz/f/rz---forum/7978/sdcard-booting) which said that they are writing the "loader program" (I think) to the SD card with
sudo dd if=u-boot.bin of=/dev/sdb seek=117 bs=512 conv=fsync. They are then told to try the Renesas vkrza1h_sdhi program to create a bootable SD card. Seeking to offset 117 is very similar to how some TI SoC boot from SD card... - Renesas has a set of patches (commits) on top of u-boot 2017.05 available here: https://github.com/renesas-rz/rza_u-boot-2017.05 but looking through some of the code, it doesn't seem like the way it is implemented will be upstreamable without some work.
- Linux 4.12 seems to have MMC/SD support for R7S72100, and there's some amount of device tree files for at least one R7S72100 board with what looks like external SDRAM.
- The ArchiTech provided u-boot and Linux load Linux into SRAM and execute from SRAM but the device tree is referenced directly from QSPI. The provided Linux is loaded uncompressed into SRAM and is only 1.4 MB in size, which is quite decently small.
- When building a non-multiplatform non-LPAE ARM kernel, CONFIG_XIP_KERNEL setting allows building an XIP Linux kernel with
make xipImage. You must provide the CONFIG_XIP_PHYS_ADDR address at which the kernel will be stored to flash within the SoC's memory map. This would be useful for running from QSPI, especially on the RZ/A1L parts.
- Figure out how to boot from SD card on Hachiko board. Renesas official SoC docs do not specify in detail how to setup the SD card, but they do specify how the ROM code acts before and after loading the "loader program" 28 kiB file from the SD card into SRAM.
- Fix non-standard CROSS_COMPILE (but still valid!) ftd tools build failures in U-Boot?
- Figure out how to wire up a reset button on Hachiko board. (This is actually really annoying due to the way the reset controller is setup.)