[U-Boot] [sunxi] [RFC/RFH] Adding mainline u-boot support for the Olimex A20-SOM-EVB

[Hans de Goede]

Hi,

On 12-02-15 22:54, Karsten Merker wrote:
> Hello,
>
> I am working on adding support for the Olimex A20-SOM-EVB development
> board to mainline u-boot (and to the mainline Linux kernel, but that is
> a topic for a different thread).  The board package actually consists
> of two parts, the A20-SOM-EVB baseboard providing I/O and power supply,
> and the A20-SOM CPU/memory board that gets plugged onto the baseboard.
>
> The schematics for the boards are available online:
>
> - A20-SOM CPU module:
>    https://github.com/OLIMEX/SOM/blob/master/A20/A20-SOM/A20-SOM_board_rev_D.pdf?raw=true
>
> - A20-SOM-EVB baseboard:
>    https://www.olimex.com/Products/SOM/A20/A20-SOM-EVB/resources/A20-SOM-EVB_schematic.pdf
>
> I use the following defconfig with the master branch of
> git://git.denx.de/u-boot-sunxi.git, but I currently cannot get it to work
> fully as intended and would appreciate any advice.
>
> configs/Olimex-A20-SOM-EVB_defconfig:
> =====================================
>
> CONFIG_SPL=y
> CONFIG_SYS_EXTRA_OPTIONS="AXP209_POWER,SUNXI_GMAC,RGMII,AHCI,SATAPWR=SUNXI_GPC(3),USB_EHCI"
> CONFIG_FDTFILE="sun7i-a20-olimex-a20-som-evb.dtb"
> CONFIG_MMC0_CD_PIN="PH1"
> CONFIG_USB1_VBUS_PIN="PH6"
> CONFIG_USB2_VBUS_PIN="PH3"
> +S:CONFIG_ARM=y
> +S:CONFIG_ARCH_SUNXI=y
> +S:CONFIG_MACH_SUN7I=y
> +S:CONFIG_DRAM_CLK=384
> +S:CONFIG_DRAM_ZQ=127
> +S:CONFIG_DRAM_EMR1=4
>
> I try to start u-boot via FEL, as the Micro-SD slot on the A20-SOM is very
> difficult to reach (even using pliers) when it is plugged onto the
> baseboard, and having to change SD cards all the time while testing is
> really cumbersome.

Ah FEL mode is broken in master atm, as you've already noticed. I've Cc-ed
you on the discussion about getting this fixed.

> The first problem showing up is that starting u-boot via FEL in the
> "traditional style" (using a FEL-specific build) does not work.  The
> SPL gets transferred properly and the "fel exe" command that starts the
> SPL returns without error, although I get no output on the serial console.
> Trying to transfer the main u-boot image afterwards fails:
>
> $ make distclean
> $ make Olimex-A20-SOM-EVB_felconfig
> [...]
> $ make -j3
> [...]
> $ fel version
> AWUSBFEX soc=00001651(A20) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000
> $ fel write 0x2000 spl/u-boot-spl.bin
> $ fel exe 0x2000
> [wait a few seconds for DRAM init]
> $ fel write 0x4a000000 u-boot.bin
> [takes some time]
> libusb usb_bulk_send error -7
>
> I have no idea how to further debug this. My first thought was that my
> DRAM parameters (based on data from a manufacturer-supplied FEX file
> for the board) are wrong, so that I run into problems while writing the
> main u-boot image to DRAM, but this is probably not the reason - see
> below.
>
> Running Siarhei's new fel spl command (using a "normal" non-FEL u-boot
> build) succeeds in transferring and starting the SPL, which then - with
> a build from git://git.denx.de/u-boot-sunxi.git - either complains that
> it cannot do the SD card voltage select when no card is inserted:
>
> U-Boot SPL 2015.01-03533-gdb62a4a (Feb 12 2015 - 20:04:29)
> DRAM: 1024 MiB
> CPU: 960000000Hz, AXI/AHB/APB: 3/2/2
> Card did not respond to voltage select!
> spl: mmc init failed: err - -17
> ### ERROR ### Please RESET the board ###
>
> or boots straight into the old u-boot-sunxi that I have
> on the card:
>
> U-Boot SPL 2015.01-03533-gdb62a4a (Feb 12 2015 - 20:04:29)
> DRAM: 1024 MiB
> CPU: 960000000Hz, AXI/AHB/APB: 3/2/2
>
>
> U-Boot 2014.04-10733-gea1ac32 (Feb 08 2015 - 20:04:39) Allwinner Technology
>
> CPU:   Allwinner A20 (SUN7I)
> Board: Olimex_A20-SOM
> I2C:   ready
> DRAM:  1 GiB
> MMC:   SUNXI SD/MMC: 0
> *** Warning - bad CRC, using default environment
>
> In this case the SPL does not "know" that it is booted via FEL, so it
> tries to load the main u-boot binary from the SD card.  The fact that
> chainloading the (old) u-boot from the SD card works, shows me that the
> DRAM is working, so I suppose that my DRAM parameters are probably not
> the reason why the "old-style" FEL booting does not work.
>
> When using a u-boot build from the "20150208-fel-fixes" branch of
> Siarhei's repository at https://github.com/ssvb/u-boot-sunxi.git
> (plus Hans' config_distro_bootcmd fix from
> http://lists.denx.de/pipermail/u-boot/2015-February/204286.html)

Right, that is the right mix to use for FEL for now, sorry about FEL
being in such a bad state atm.

> as follows:
>
> $ make distclean
> [...]
> $ make Olimex-A20-SOM-EVB_defconfig
> [...]
> $ make -j3
> [...]
> $ fel version
> AWUSBFEX soc=00001651(A20) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000
> $ fel spl u-boot-sunxi-with-spl.bin
> $ fel write 0x4a000000 u-boot.bin
> $ fel exe 0x4a000000
> $
>
> u-boot boots fine until it tries to initialize the EHCI controllers:
>
> U-Boot SPL 2015.04-rc1-04039-g6385323 (Feb 12 2015 - 21:08:28)
> DRAM: 1024 MiB
> CPU: 960000000Hz, AXI/AHB/APB: 3/2/2
>
>
> U-Boot 2015.04-rc1-04039-g6385323 (Feb 12 2015 - 21:08:28) Allwinner
> Technology
>
> CPU:   Allwinner A20 (SUN7I)
> I2C:   ready
> DRAM:  1 GiB
> MMC:   SUNXI SD/MMC: 0
> *** Warning - bad CRC, using default environment
>
> In:    serial
> Out:   serial
> Err:   serial
> SCSI:  SUNXI SCSI INIT
> SATA link 0 timeout.
> AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: ncq stag pm led clo only pmp pio slum part ccc apst
> Net:   dwmac.1c50000
> starting USB...
> USB0:
>
> Then u-boot hangs. The problem appears to be with the GPIO pins that
> control the USB voltage supply.  If I run "make menuconfig" and remove the pin
> information for CONFIG_USB1_VBUS_PIN and CONFIG_USB2_VBUS_PIN, u-boot
> actually boots up and initializes the USB host ports:
>
> U-Boot SPL 2015.04-rc1-04040-g1d6a07b (Feb 12 2015 - 21:34:59)
> DRAM: 1024 MiB
> CPU: 960000000Hz, AXI/AHB/APB: 3/2/2
>
>
> U-Boot 2015.04-rc1-04040-g1d6a07b (Feb 12 2015 - 21:34:59) Allwinner
> Technology
>
> CPU:   Allwinner A20 (SUN7I)
> I2C:   ready
> DRAM:  1 GiB
> MMC:   SUNXI SD/MMC: 0
> *** Warning - bad CRC, using default environment
>
> In:    serial
> Out:   serial
> Err:   serial
> SCSI:  SUNXI SCSI INIT
> SATA link 0 timeout.
> AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
> flags: ncq stag pm led clo only pmp pio slum part ccc apst
> Net:   dwmac.1c50000
> starting USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... 1 USB Device(s) found
> USB1:   USB EHCI 1.00
> scanning bus 1 for devices... 2 USB Device(s) found
>         scanning usb for storage devices... 1 Storage Device(s) found
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> scanning bus for devices...
> Found 0 device(s).
>
> SCSI device 0:
>      Device 0: not available
>
> USB device 0:
>      Device 0: Vendor: Intenso  Rev:      Prod: Rainbow
>              Type: Removable Hard Disk
>              Capacity: 7620.0 MB = 7.4 GB (15605760 x 512)
> ... is now current device
> Scanning usb 0:1...
> Found U-Boot script /boot.scr
> reading /boot.scr
> 1263 bytes read in 22 ms (55.7 KiB/s)
> ## Executing script at 43100000
> [...]
>
> According to the board schematics PH3 supplies USB2-DRV and PH6 supplies
> USB1-DRV, and those two GPIOs are connected to the enable inputs of the two
> SY6280 power switches which in turn provide the power supply for the two USB
> host ports.  Therefore I do not understand why the USB initialization works
> if I do _not_ supply the GPIO information and stops working when I do. Any
> help in understanding this and in solving the FEL boot problem with the
> "traditional" u-boot felconfig builds is very much apprechiated.

So about the GPIO question: I've no clue, you should probably ask olimex, maybe
the pins are inverted or some such, but then things should still work you
would expect the USB scan to not find any devices.

As for the FEL stuff we're working on this. You may want to use v2015.01 for
now, although that does require you to create an old fashioned dram_foo.c
file which we've dropped in master.

>
> JFTR some additional information regarding the DRAM parameters for the
> board: the parameters I have used are the "conservative" parameters
> published by Olimex for the earlier revisions of the A20-SOM.  Newer
> versions of the board use a PCB with more layers and are supposed to
> work reliably with higher DRAM clock speeds.  This might influence the
> DRAM_ZQ value, though.  I will contact Olimex to gather further
> information regarding the possbile DRAM parameter combinations.

Thanks for working on this.

Regards,

Hans