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.

[daym]

Sure. I've checked the diff between v1.4.2 and master and it seems usb handling in fel got refactored entirely and is now in fel_lib.c . If you want you can give me some commits to try - if not, I'll try a binary search between 85943df (v1.4.2) and 7128c73.

[daym]

When I try to execute the bin/uart0-helloworld-sdboot.sunxi of v1.4.2 it apparently never works (also when I try to execute the old bin/uart0-helloworld-sdboot.sunxi of v1.4.2 using master fel - and when I try to execute it using v1.4.2 fel it doesn't work either).

So I'd say that v1.4.2's bin/uart0-helloworld-sdboot.sunxi binary is somehow broken. Checking the source code diff (not objdump!) doesn't reveal any obvious culprit.

The sinovoip uboot never works via fel - no matter which fel I use.

Chen-Yu's U-Boot works using v1.4.2 fel and master fel.

Would it be possible to make sunxi-fel distinguish between "transfer error" and "execution error" ? It's quite confusing to get an USB timeout (see my first message here) when it in fact apparently already started executing something and that is broken. The part that gives the timeout is aw_fel_read at the end of aw_fel_write_and_execute_spl. If that's too complicated would it be possible to write out a hint about "invoke sunxi-fel with the '-v' option for more information" on any such error?

[ssvb]

So I'd say that v1.4.2's bin/uart0-helloworld-sdboot.sunxi binary is somehow broken.

I think that's because the uart0-helloworld-sdboot.sunxi binary was only refreshed in 382bb4c and the v1.4.2 has an old version of it (while it still can be compiled from sources).

The sinovoip uboot never works via fel - no matter which fel I use.

I have no idea why it does not even start booting. In theory it should, and older boot0 releases for older SoCs worked. But if the mainline U-Boot with works (with the patches from @wens), then we probably don't need to worry.

Thanks for providing all this information!

[ssvb]

Would it be possible to make sunxi-fel distinguish between "transfer error" and "execution error" ?

Most likely not. It's similar to having a server in the Internet. If it does not respond to your requests anymore, then it is either a network connectivity issue or maybe the server itself has crashed or got powered down. But we can't really distinguish between these two cases in a reliable way.

In the case of FEL, we can try to make some guesses, but they will be never perfectly accurate.