• Announcements

    • 1. Check power supply, check SD card and check other people experiences

      Power supply issues are one of the three biggest issues you'll face when starting with Single Board Computers (SBCs). SD card issues, whether fake or faulty, are another and issues resulting from poor board design is the other common issues you can encounter.   Power supply issues can be tricky. You might have a noisy power supply that works with one board because it has extra filtering, but won't work with another. Or you're using that cheap phone charger because your board has a microUSB connector, and it is either erratic, or doesn't start up, or even becomes the cause of some SD card issues.    Some tips to avoid the most common causes of problems reported:   Don't power via micro USB  - unless you have optimised your setup for low power requirements. Micro USB is great for mobile phones because they are simply charging a battery. It's bad for SBCs. Yes, it does work for a lot of people, but it also causes more problems and headaches over time than it is worth, unless you know exactly what you are doing. If you have a barrel jack power connector on your SBC, use it instead! If there is an option for powering via header connections, use that option!
        Don't use mobile phone chargers. They might be convenient and cheap, but this is because they are meant for charging phones, not powering your SBC which has particular power requirements.
        When you are evaluating a power supply, make sure you run some stress tests on your system to ensure that it will not cause issues down the path.   (Micro) SD card issues can be sneaky. They might appear right at the start causing strange boot and login errors, or they might cause problems over time. It is best to run a test on any new SD card you use, to ensure that it really is what it is, and to ensure that isn't faulty. Armbian provides you a simple way to do this   --   armbianmonitor -c /path/to/device/to/test  
    • 2. Make sure to collect and provide all necessary information

      We can only help if you provide quality information for us to work with. All stable images from the download section are tested, most stable upgrades are tested and we have tens of thousands of users. Even with regular and extensive testings, bugs sometimes do slip through. This is a voluntary support service and is unrelated to board makers, and is not obligated to provide you any answers. Repeated asking the same questions because you're not happy with the answers will result in you being ignored.

      Before you post a question, use the forum search as someone else might have already had the same problem and resolved it. And make sure you've read the Armbian documentation. If you still haven't found an answer, make sure you include the following in your post:   1. Logs when you can boot the board: armbianmonitor -u (paste URL to your forum post)   2. If your board does not boot, provide a log from serial console or at least make a picture, where it stops.   3. Describe the problem the best you can and provide all necessary info that we can reproduce the problem. We are not clairvoyant or mind readers. Please describe your setup as best as possible so we know what your operating environment is like.     We will not help in cases you are not using stable official Armbian builds, you have a problem with 3rd party hardware or reported problem would not be able to reproduced.

SolidRun MicroSoM rev. 1.5 does not boot
1 1

8 posts in this topic

Recommended Posts

I am unable to boot the latest armbian version on my hummingboard using a MicroSoM i1 rev. 1.5. 

It seems to be an DTB problem. The boot error is "no valid device tree binary"

 

Does anybody have the same problem or a solution?

 

Share this post


Link to post
Share on other sites

This is my output, nothing happens after that:

 

 

U-Boot 2017.11-armbian (Dec 15 2017 - 13:29:26 +0100)

CPU:   Freescale i.MX6SOLO rev1.3 996 MHz (running at 792 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 32C
Reset cause: POR
Board: MX6 Hummingboard
DRAM:  512 MiB
MMC:   FSL_SDHC: 0
*** Warning - bad CRC, using default environment

No panel detected: default to HDMI
Display: HDMI (1024x768)
In:    serial
Out:   serial
Err:   serial
Net:   FEC
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
1816 bytes read in 121 ms (14.6 KiB/s)
## Executing script at 12000000
0 bytes read in 78 ms (0 Bytes/s)
78 bytes read in 96 ms (0 Bytes/s)
37846 bytes read in 278 ms (132.8 KiB/s)
4333097 bytes read in 363 ms (11.4 MiB/s)
5236152 bytes read in 415 ms (12 MiB/s)
## Loading init Ramdisk from Legacy Image at 14800000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4333033 Bytes = 4.1 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 18000000
   Booting using the fdt blob at 0x18000000
   Using Device Tree in place at 18000000, end 1800c3d5

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
 

 

Share this post


Link to post
Share on other sites

Mount SD card on some Linux and add:

fdt_file=imx6dl-hummingboard-som-v15.dtb

or if you have HB2

fdt_file=imx6dl-hummingboard2-som-v15.dtb

to the /boot/armbianEnv.txt

If you have eMMC version then imx6dl-hummingboard-emmc-som-v15.dtb and imx6dl-hummingboard2-emmc-som-v15.dtb

Share this post


Link to post
Share on other sites

Thank you for your quick response, unfortunately this does not solve the problem.

I am not using a HB2, so i added the line 

15 hours ago, Igor said:

fdt_file=imx6dl-hummingboard-som-v15.dtb

the resulting armbianEnv.txt is attached

 

 

armbianEnv.txt

 

Update:

 

I am able to login using HDMI and a Keyboard. Serial Terminal still does not work.

Share this post


Link to post
Share on other sites
59 minutes ago, sescsen said:

I am able to login using HDMI and a Keyboard.

 

Nice!

 

59 minutes ago, sescsen said:

Serial Terminal still does not work.


Known (upstream) bug, AFAIK unresolved.

Share this post


Link to post
Share on other sites

Ok, thank you!

 

I would like to host a wifi access point, but it seems like there is a Problem with the ti wl18xx driver modules. 

Is this known?

Share this post


Link to post
Share on other sites

Dont know anything about this wireless chip found on recent boards. All mine have old Broadcomm chips which works. Perhaps only firmware is missing?

Wrote on mobile

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

1 1

  • Support the project

    We need your help to stay focused on the project.

    Choose the amount and currency you would like to donate in below.