Hi,
Am 18.01.2018 um 18:20 schrieb Stefan Roese:
On 17.01.2018 16:52, Andreas Färber wrote:
Am 09.06.2017 um 19:28 schrieb Marek Behún:
This is the fourth version of patches for adding support for the Turris Omnia board, a router developed by the CZ.NIC.
I'm still facing trouble testing turris_omnia on latest v2018.01.
First, that made me notice there's no README for how to test and deploy. I'm aware of temporary: sendbeacon /dev/ttyUSBx
I have to admit, that don't know anything about this "sendbeacon" tool.
./tools/kwboot -t -B 115200 /dev/ttyUSBx -b u-boot-spl.kwb -p
This is what I have used, when I tested / debugged images for Armada XP / 38x. Please note that the init sequence is somewhat "fragile" - so I added the -q and -s parameters, to optionally finetune the startup timings:
# kwboot ... -q <req-delay>: use specific request-delay -s <resp-timeo>: use specific response-timeout
You might what to play a bit with these parameters as well.
I saw them but had no idea what to pass as values. ;) I did try -a, but it worked with and without.
BTW: I don't have access to the Omnia router, so I can't test anything on this specific platform.
BTW2: Kosta from Marvell just recently added a new tool / script, to help debug / boot Marvell MVEBU boards:
tools/mrvl_uart.sh
He told me that its better to use than the "old" kwboot tool. I never found the time to use it up until now, so I have no personal experience. But I'm pretty sure that Kosta did a great job here. So please give it a try.
I did not get it to work ... or was not patient enough.
# or without -p when s/BOOT_FROM spi/BOOT_FROM uart/ and permanent: tftpboot 0x1000000 u-boot-spl.kwb sf probe sf update 0x1000000 0 $filesize
I used to have the original factory CZ.NIC U-Boot in SPI and booted test versions only via sendbeacon+kwboot.
With mainline that appears to be broken - the CONFIG_ARMADA_38X code in arch/arm/mach-mvebu/spl.c seems to run into !boot_device and instead of UART tries to boot from SPI - nothing happens then and kwboot complains. I can force it to continue booting from UART by commenting out the if. So Stefan, it looks like your auto-detection is not working here and the Kconfig option to force it was dropped prematurely.
Hmmm. Then some patch must have broken this UART boot-ability. Could you by any chance git-bisect, to check which patch broke this functionality? Perhaps some of the newer patches from Sean Nyekjaer?
I've so far found that v2017.11 had UART boot working okay.
When forcing UART, as soon as the progress surpasses 99%, it reboots into SPI SPL without any error message. Using the old U-Boot fork I've tried flashing u-boot-spl.kwb - similarly it gets stuck in the SPL trying to boot on from SPI. After a while it reboots, and so on in a loop.
So it seems that non-SPL U-Boot 2018.01 is broken, on my 2 GB model.
Hmmm. I can only
I have reconfirmed (with our GCC 7.2.1) that no version works for me:
v2017.07 did not have turris_omnia defconfig yet b6ee860b87d8accedfb7a1fd5414f7c483603234 bad (adds turris_omnia) v2017.09 bad v2017.11 bad v2018.01 bad master bad (c4cb6e64bf068eaa1f7c96cb37da7ae6d40bbbff / arc merge)
So I have nothing to bisect and wonder how Marek tested this...
I also ran into a couple DDR3 training failures when booting via UART. No such training problems observed booting from SPI.
Using the same U-Boot version, meaning same DDR init code?
Yes. Only difference being BOOT_FROM and the spl.c modification.
Thats strange. I have not really worked with Armada 38x for quite some time, but I don't remember any such problems that you describe here. I might need to dig up an Armada 38x board and give it a try myself...
Regards, Andreas