please choosego to mobile | Continue to access the PC version
View: 7703|Reply: 5

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

[Copy link]

1

threads

5

posts

73

credits

Registered member

Rank: 2

credits
73
Published in 2017-12-24 02:03:17 | Show all floors |Read mode
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. ## Reset cause : 0x00000000

  3. ## Communication interface version : 0x00010001

  4. ## Power-on key is not pressed for normal boot.
  5. ## ****** Shutdown is needed later ******

  6. ## Init mdcom channels ... Done
  7. load boot image ...
  8. found part 'boot' offset: 0xa00000 length: 0x800000
  9. read 0x800 bytes from 'boot' offset: 0xa00000
  10. read 0x3b2800 bytes from 'boot' offset: 0xa00000
  11. Factory already loaded
  12. Does not find bootlogo name, using default
  13. boot_linux_from_mem, data: 82000000
  14. kernel @0x80008000 (0x00371800 bytes)
  15. ramdisk @0x81000000 (0x00040800 bytes)
  16. 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
  17. Uncompressing Linux... done, booting the kernel
  18. * * *
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;

62

threads

653

posts

5192

credits

Administrator

Rank: 9Rank: 9Rank: 9

credits
5192
Published in 2017-12-25 16:10:13 | Show all floors
I am not sure whether i remembered it correct: 2G-IOT could only supply Android for Nand booting.

1

threads

5

posts

73

credits

Registered member

Rank: 2

credits
73
 Author| Published in 2017-12-25 19:58:57 | Show all floors
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!

62

threads

653

posts

5192

credits

Administrator

Rank: 9Rank: 9Rank: 9

credits
5192
Published in 2017-12-26 14:27:06 | Show all floors
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.

1

threads

5

posts

73

credits

Registered member

Rank: 2

credits
73
 Author| Published in 2017-12-28 12:04:23 | Show all floors
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

1

threads

5

posts

73

credits

Registered member

Rank: 2

credits
73
 Author| Published in 2017-12-28 18:15:00 | Show all floors
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.
You need to log in before you can reply login | Register

Points Rule

Quick reply Top Return list