Orange Pi 2g IoT: Some bootloader logs are missing on UART

alnn

Hello all,
Recently I bought an Orange Pi 2G IoT and trying to setup/configure it.
When I select to boot off MMC, I can see no readable info on serial port (Debug TTL UART).
For NAND boot I can see some info, but it looks like logs from early stage of boot process are missing (or sent with different baud rate/params).

For NAND boot the log begins like this:

1. Done
   
2. 
   
3. ## Reset cause : 0x00000000
   
4. 
   
5. ## Communication interface version : 0x00010001
   
6. 
   
7. ## Power-on key is not pressed for normal boot.
   
8. ## ****** Shutdown is needed later ******
   
9. 
   
10. ## Init mdcom channels ... Done
    
11. load boot image ...
    
12. found part 'boot' offset: 0xa00000 length: 0x800000
    
13. read 0x800 bytes from 'boot' offset: 0xa00000
    
14. read 0x3b2800 bytes from 'boot' offset: 0xa00000
    
15. Factory already loaded
    
16. Does not find bootlogo name, using default
    
17. boot_linux_from_mem, data: 82000000
    
18. kernel @0x80008000 (0x00371800 bytes)
    
19. ramdisk @0x81000000 (0x00040800 bytes)
    
20. cmdline mem=236M selinux=1 androidboot.selinux=permissive console=ttyS0,921600 root=/dev/ram rw rdinit=/init flash_if=normal emmc_id=140 androidboot.serialno=1234567890abcdef lcd=auto mtdparts=rda_nand:28M@0(dummy),145M(systl
    
21. Uncompressing Linux... done, booting the kernel
    
22. * * *

Copy code

Before this, I can see (for about 2 seocnds) a few tons of (seemingly binary) info, but I cannot read it. This should be the logs from Boot ROM and UBoot (bootloaders), as I can see, e.g., in this page: https://github.com/RDA8810/linux-RDA8810/issues/23
As boot from MMC does not work for me either, logs from UBoot are very important.
I tried different baud rates (at least 921600, 115200, 57600, 460800) and parameters, but no luck so far.

Can you, please, suggest, what might be wrong with my setup and how I can fix this, so, I can see logs on "Debug TTL UART" interface from bootloaders?

Environment/tools/HW used: Orange Pi 2G IoT, Kubuntu 16.04, minicom, PL2303HX based USB/UART converter;

admin

I am not sure whether i remembered it correct: 2G-IOT could only supply Android for Nand booting.

alnn

admin replied at 2017-12-25 11:10
I am not sure whether i remembered it correct: 2G-IOT could only supply Android for Nand booting.

...

Thank you for your reply!
Right, at least for now, code that boots from NAND looks like Android, as I can see "/system" directory, which, to my mind, indicates Android.To me, the problem with Android in NAND is that it quickly goes to "Suspending console(s)" mode shortly after it fully boots, and it is a bit tricky to enter commands in the shell. When I press "Power" button, the shell prompt comes back for a couple of seconds, so, I can enter some "not-too-logs" commands, like "ls -l /system" or similar, but it quickly returns to "Suspending condole(s)" mode, so, I need to press the "Power" button again. It prints, that I can "use no_console_syspend to debug", but if I understand correctly, I cannot update this kernel flag at run time, only at boot time and I need access to the bootloader (Das U-Boot?). Am I right, or can I update no_console_syspend at run time (after boot)?



Anyway, what I really want for now - is to be able to communicate with the bootloader(s) (I suppose it should be Das U-Boot?), so I can, at least, see what is wrong with my MMC. But when I switch to boot from MMC, I can see no readable info, only binary something (similar binary logs are seen for NAND boot for a few first seconds of boot process, as I explained in my 1st message in this thread), I tried really hard using different baud rates and other parameters, but no luck so far to see what my Dev Board wants to tell me during boot from MMC.

To me, this looks like, probably, it takes a while for the PLL to correctly setup the right clocks, but probably, the code does not wait for the clock to stabilize (this is only my guess)? But this does not explain why boot from MMC does not work (probably, wrong MMC, but the same MMC worked like magic with my Raspberry Pi(es), after I flashed the right image of course).

---
Thank you!

admin

alnn replied at 2017-12-25 19:58
Thank you for your reply!
Right, at least for now, code that boots from NAND looks like Android, a ...

Sorry i have't made it work like this before, cannot give you advice.

alnn

For information: tit is possible to disable he "suspending console(s)" with the following command(s):

1. $ su
   
2. # echo name > /sys/power/wake_lock

Copy code

alnn

Hello all,
Managed to access Das UBoot and even boot off MMC, here is some info how I did this (for those, who might be having the same issue).
1) Choose "Boot selector": NAND;
2) Attach USB(PC)-UART(DevBoard) converter, UART settings: 921600, 8N1;
3) Attach the power adapter to the "OTG+power supply" socket, turn it on;
4) On PC side in a serial terminal (I use minicom) I can see a few seconds of binary data, and after a while the board starts sending good and readable boot progress;
5) Wait until the shell prompt (for me, it is /system/bin/sh) starts working, no login is required;
6) Send the following commands ('su' does not require credentials), so, the board does not go to console suspend mode too often:

1. $ su
   
2. # echo name > /sys/power/wake_lock

Copy code

7) Without powering off, move the "boot selector" to "MMC boot";
8) Send the following command in the shell prompt:

1. # reboot

Copy code

At this point the board starts restarting, I can see (!!!) logs from ROM boot and Das UBoot bootloaders;
It is possible now to enter the Das UBoot prompt, for this you need to press any key when UBoot starts (the prompt "Hit any key to stop autoboot" appears for a second on default).
FYI: to resume usual boot, you can use the following UBoot command ("RDA >" is a prompt, "boot" and "bootd" are identical):

1. RDA > bootd

Copy code

9) Now, boot from mmc starts (I use "Debian Server" distribution for now) and after a while I can see login prompt, I can login with usual credentials and everything works like magic.

So, it looks like "ROM boot" does have a bug, and it does not initialize correctly (at least - my) Dev Board.
To me, this is quite critical, as my Dev Board does not boot without these magic steps above; if I just power on the board, it gives a few seconds of binary logs in Debug UART port, and after this, the board gives up, even power LED is off.

How do you usually track bugs, do you have a bug tracking system?
I could help in collecting additional info, if required, but I am not sure if I have enough expertise to fix it myself.

PS: before all this steps, I tried updating the NAND image, update finished successfully, but this did not resolve the issue.