FEL mode times out on writing some images to BananaPi M2 Ultra

[daym]

It seems that FEL mode times out on writing on BananaPi M2 Ultra (R40).

$ sudo sunxi-fel version
AWUSBFEX soc=00001701(R40) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000
$ sudo sunxi-fel -p spl sunxi 
usb_bulk_send() ERROR -7: Operation timed out
$ sudo sunxi-fel version
usb_bulk_send() ERROR -7: Operation timed out

I then disconnect and reconnect the USB cable (I had no external power supply connected so that cuts all the power to it and then provides it again).

$ sudo sunxi-fel version
AWUSBFEX soc=00001701(R40) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 
$ sudo sunxi-fel dump 0 1000000 > Q
$ ls -l Q
-rw-r--r-- 1 dannym users 1000000 Mar 19 17:13 Q
$ sudo sunxi-fel fill 0x47000000 1000 0x42
usb_bulk_send() ERROR -7: Operation timed out
$ sudo sunxi-fel clear 0x47000000 1000
usb_bulk_send() ERROR -7: Operation timed out

Do I have to press some button on the device? Because I didn't.

All this was done without a SD card in the device, so it's not interfering. I have a serial console attached and it doesn't log any messages either (which is good - so nothing is booting up when it shouldn't).

On the other hand, booting normally from the SD card works fine (booting to their Ubuntu port).

[ssvb]

What kind of 'sunxi' file are you using? Is it a U-Boot bootloader? You can also add '-v' option to the command line for more verbose reporting.

As for the "sunxi-fel fill 0x47000000 1000 0x42" command, it is expected to fail because the DRAM is not initialized yet at that point. We had an idea to add a sanity check and print a comprehensive error message in this case, but nobody has implemented it yet.

[daym]

It's the U-Boot bootloader that I got from the SD card with skip=8 bs=1024; the first few bytes of it contain "eGON.BT0" without quotes.

Why does dumping work then? Is that all SRAM? Edit: Apparently. With dump 0x47000000 it errors, too.

Could you give me some commands to test it with?

Also, can I make it print something on the serial port?

[ssvb]

It's the U-Boot bootloader that I got from the SD card with skip=8 bs=1024; the first few bytes of it contain "eGON.BT0" without quotes.

Do you have a log from running "sunxi-fel -v spl sunxi"?

Why does dumping work then? Is that all SRAM?

You can check the memory map in the R40 user manual. SRAM should work in sunxi-fel, but DRAM will not work unless it is initialized.

Could you give me some commands to test it with?

As for some basic testing, you can try to run "sunxi-fel -v spl uart0-helloworld-sdboot.sunxi" first and check if it can print something on the UART serial console.

[daym]

Do you have a log from running "sunxi-fel -v spl sunxi"?

$ sunxi-fel -v spl sunxi
Stack pointers: sp_irq=0x00002000, sp=0x00005E08
MMU is not enabled by BROM
usb_bulk_send() ERROR -7: Operation timed out

And

$ sunxi-fel -v spl uart0-helloworld-sdboot.sunxi
Stack pointers: sp_irq=0x00002000, sp=0x00005E08
MMU is not enabled by BROM
=> Executing the SPL... done.

It doesn't seem to print anything to UART in either case. What speed and settings? Edit: 115200 8N1 according to the source code.

[ssvb]

Are you by chance running it in a virtual machine? There is #98 about this.

[daym]

No, it's native on a Thinkpad X200 (using sunxi-tools 1.4.2).

[ssvb]

You can try to debug what's wrong with uart0-helloworld-sdboot.sunxi first. Some time ago @wens added R40 support to sunxi-tools via #86.

Are you sure that your UART serial console works properly? Does it print anything when you are booting the stock firmware from the SD card?

[daym]

I tried using sunxi-tools master's sunxi-fel from git to do the spl helloworld now - it works!

The U-Boot still doesn't, though. That might be because it's not mainline uboot (I think) but the version that sinovoip had.

Hello from Allwinner R40!
Returning back to FEL.

Also works multiple times - so the return to FEL mode also works.

Nice :)

Are you sure that your UART serial console works properly?

Yes. I also made sure not to close the client application when reconnecting without sd so that it indeed continues working.

Does it print anything when you are booting the stock firmware from the SD card?

Yes.

Thanks for your help!

I think I have Chen-Yu's U-Boot compiled somewhere, I'll try that one next...

[ssvb]

I tried using sunxi-tools master's sunxi-fel from git to do the spl helloworld - it works!

OK, it's good to know that at least uart0-helloworld-sdboot.sunxi works correctly.

The U-Boot still doesn't, though. That might be because it's not mainline uboot (I think) but the version that sinovoip had.

Yes, the non-mainline U-Boot does not support FEL boot. Still it should be started correctly, print something to the serial console and attempt to continue booting from the SD card rather than returning control back to sunxi-fel.

[daym]

Trying Chen-Yu's U-Boot (r40 branch):

$ ./sunxi-fel -v spl u-boot-sunxi-with-spl.bin 
Stack pointers: sp_irq=0x00002000, sp=0x00005E08
MMU is not enabled by BROM
=> Executing the SPL... done.
Writing image "U-Boot 2017.03-rc3-g440d8ae for ", 384353 bytes @ 0x4A000000.

And on the serial console:

U-Boot SPL 2017.03-rc3-g440d8ae (Mar 19 2017 - 18:39:50)
DRAM: 2048 MiB
Trying to boot from FEL

Is that good?

[ssvb]

The "Trying to boot from FEL" message means that the control is supposed to be transferred back to the FEL handler in the BROM. And sunxi-fel should be able to execute commands to read/write DRAM and other things.

You can run the "sunxi-fel uboot" command instead of "sunxi-fel spl". You can find some examples at https://linux-sunxi.org/FEL/USBBoot#Booting_U-Boot_over_USB

[daym]

And sunxi-fel should be able to execute commands to read/write DRAM and other things.

Yes, that indeed works. Also reading and writing DRAM using fel works.

You can run the "sunxi-fel uboot" command instead of "sunxi-fel spl".

Yep, tried it. It works, too.

Can I easily make that U-Boot autoboot a kernel?

It might make sense to release a version of sunxi-tools with these fixes...

[ssvb]

Excellent! I guess, everything is resolved then.

It might make sense to release a version with these fixes...

Which fixes do you mean? The last released version of sunxi-tools just does not support Allwinner R40 yet. Though I wonder why did it identify the SoC type correctly in your original report?

[daym]

Excellent! I guess, everything is resolved then.

Yeah, sorry for the noise.

Which fixes do you mean?

R40 fel not timing out.

The last released version of sunxi-tools just does not support Allwinner R40 yet.

Oh sorry.

Though I wonder why did it identify the SoC type correctly in your original report?

I don't know. I checked now which it was: It was the github tarball from 1.4.2 (as installed by the Guix system distribution). Can I make the sunxi tools print the version in order to make sure?

[ssvb]

I have just checked the v1.4.2 tag and it actually seems to have some support for R40. Could you please investigate what's wrong with it? Maybe by doing a quick bisecting. I don't have any R40 hardware myself. Thanks!

Edit: Just to make it clear, this issue seems to be all about the v1.4.2 version having problems with R40 support. We want to get it fixed (by tagging a new release) but it would be also nice to know what's going on.