-
Notifications
You must be signed in to change notification settings - Fork 421
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FEL mode times out on writing some images to BananaPi M2 Ultra #100
Comments
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. |
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? |
Do you have a log from running "sunxi-fel -v spl sunxi"?
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.
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. |
And
It doesn't seem to print anything to UART in either case. What speed and settings? Edit: 115200 8N1 according to the source code. |
Are you by chance running it in a virtual machine? There is #98 about this. |
No, it's native on a Thinkpad X200 (using sunxi-tools 1.4.2). |
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.
Also works multiple times - so the return to FEL mode also works. Nice :)
Yes. I also made sure not to close the client application when reconnecting without sd so that it indeed continues working.
Yes. Thanks for your help! I think I have Chen-Yu's U-Boot compiled somewhere, I'll try that one next... |
OK, it's good to know that at least uart0-helloworld-sdboot.sunxi works correctly.
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. |
Trying Chen-Yu's U-Boot (r40 branch):
And on the serial console:
Is that good? |
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 |
Yes, that indeed works. Also reading and writing DRAM using
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... |
Excellent! I guess, everything is resolved then.
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? |
Yeah, sorry for the noise.
R40 fel not timing out.
Oh sorry.
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? |
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. |
When I try to execute the So I'd say that v1.4.2's The sinovoip uboot never works via fel - no matter which 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 |
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).
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! |
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. |
It seems that FEL mode times out on writing on BananaPi M2 Ultra (R40).
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).
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).
The text was updated successfully, but these errors were encountered: