Jump to content

Recommended Posts

Posted

Hi Guys i searched the forums but could not find anything too similar. Any advice would be welcomed.

 

Summarised version
I am currently trying to install the OrangePiPC Debian Server image of Armbian on a custom H3 board emmc and getting a kernel error (Gave up waiting for root file system device.  Common problems:) . Please see serial log  at bottom for full information.


TLDR VERSION


Objective
To install armbian directly onto the emmc.


Board Information
Board acquired from a manufactorir. It has USB_OTG, eth, Uarts, emmc and some other ports but NO SD card slot.  Using OrangePiPC as it seems the most similar.


How I am Installing
1) I mount the emmc directly to a Debian computer via using zador-blood-stained/fel-mass-storage.
2) I use etcher to burn the image to the emmc.
3) I plug in an external power supply and read the serial output (see log).
4) after the issue occurs it boot loops showing the same error.


Suspected cause of Failure
I suspect that because my hardware has differences to the OrangePiPc it is causing this issue and that i will probably need to build a custom image of armbian specifically for my board. If this is the case any information on how to proceed would be appreciated.


Other information
I have booted the OrangePiPc image using FEL boot. It boots up into Armbian and works correctly for around 10 minutes before experiencing a kernel panic.
I have set up the development environment for compilation and am a developer so hopefully compiling a custom board/kernel/uboot should be doable for me. 

 

Thanks and sorry for the wall of text,

 

Nick

 

Serial Log

  Reveal hidden contents

 

Posted

The first thing to do is to compare the schematic of your board to the schematic of whatever board you take as a reference for the image and find out all the differences, then take that board's devicetree file for u-boot and for Linux and update it with all the differences. Most of the time it's power related things that are controlled in a different way and what GPIOs are used for various controls, different pin mux settings for busses that have multiple pinouts etc...

Posted

Hi Xalius, thanks for the quick reply.

 

 

I have started comparing both boards. However i do not have a particularly clear schematic of this custom board, so it is proving difficult. I have the base linux-image (and android image) that the manufacturer provided.  Would i be able to use the uboot/kernel provided with it or be able to pull the devicetree information from it?

Posted
  On 3/29/2018 at 12:15 AM, NickFoley said:

Hi Xalius, thanks for the quick reply.

 

 

I have started comparing both boards. However i do not have a particularly clear schematic of this custom board, so it is proving difficult. I have the base linux-image (and android image) that the manufacturer provided.  Would i be able to use the uboot/kernel provided with it or be able to pull the devicetree information from it?

Expand  

 

Do you have the fex files (if BSP Linux/Android )for the custom board or the devicetree (if mainline Linux) file? You can extract the devicetree blob from your custom board's Linux image and use that maybe, what kernel is running on the custom board?

Posted
  On 3/29/2018 at 12:41 PM, Xalius said:

 

Do you have the fex files (if BSP Linux/Android )for the custom board or the devicetree (if mainline Linux) file? You can extract the devicetree blob from your custom board's Linux image and use that maybe, what kernel is running on the custom board?

Expand  

 

The kernel running on the mainline linux is 3.4.39. In the source of mainline linux i have found about 50 fex files. I have included a photo of the fex files below.  In regards to the devicetree blob, I have found a bunch of dts files and two dtd files but no btd files. Not too sure what files to investigate.

 

 

 

fexFiles.png

Posted

I fear you should invest some time into learning the basics first. 3.4.39 is not mainline and does also not use device-tree. The best source of information you have is sys_config.fex (that's HW description the 'Allwinner style'). There you should especially pay attention to the dram section and there clockspeed. You can also check for this with a running 3.4.39 kernel doing this

cat /sys/devices/platform/sunxi-ddrfreq/devfreq/sunxi-ddrfreq/cur_freq

Our OS images for Orange Pi use mostly 624 MHz DRAM clockspeed which could be way too much for 'random H3 Android device' out there.

 

To get an idea how fex files need to be (slightly) adjusted to become fully Armbian compliant look at the second commit here: https://github.com/armbian/build/commits/700c4011286dd52500979dc82501f5a782c7518f/config/fex/orangepi-r1.fex

Posted

Hi tkaiser.

 

I am reading what i can find and am learning more by the day. I checked my board's clock speed. It is  576 MHz, so quite a bit slower. I figured because it runs an H3 it should be capable of the same clock-speeds as any other H3.  Thanks for the commit history link. So what i gather you are suggesting is that I get the orangepi.fex and compare it to my sys_config.fex (included below), much like what they did in the link. Then try and compile a new image with the altered fex and see how it goes. Hopefully i am not too far off the mark.

 

  Reveal hidden contents
 

 

Posted
  On 4/4/2018 at 8:50 AM, NickFoley said:

I figured because it runs an H3 it should be capable of the same clock-speeds as any other H3

Expand  

 

Nope. Use crappy components on a board and this affects DRAM as well as CPU clockspeeds.

 

Mentioning 'crappy'. It's like that:

dram_clk = 576
pmuic_type = 0
max_freq = 1008000000

If these values are correct (who knows? Maybe the vendor just took someone else's work?) you might better choose an image for Sunvell R69 which is based on somewhat identical crappy hardware (no voltage regulation and unreliable DRAM).

 

With any of the Orange Pi images that are made for better hardware (allowing to clock both CPU and DRAM higher) kernel panics are the best you can get.

Posted

Bummer that it either has crappy components or uses incorrect values. Thanks for the reference to the Sunvel R69, i am building an image for it now and doing some reading.  Regardless of picking an image for an Orange Pi or something like the Sunvell R69 the steps i need to do is as follows

  1.  Compare their fex file with the sys_config.fex file from my board and copy over the differences.  Meaning making the R69.fex match my sys_config.fex.
  2. Build the image for the R69 (with my changes).
  3. Flash it to the emmc. Hopefully then i will be able to actually boot past the kernel into Armbian.

Correct me if i am missing some steps or over simplifying things. I appreciate the help

Posted

The Sunvell R69 stuff should work out of the box (maybe leds and other secondary peripherals need adjustments). I built images some time ago available through web.archive.org -- simply search the forum.

 

If the R69 stuff works you can also use bin2fex or fex2bin to adjust fex stuff (again: search the forum) where it's needed. But this way you remain on the smelly 3.4 kernel. For mainline Linux you would need to adopt a device-tree file (same idea: start with the R69 and adopt changes via dtc tool contained in device-tree-compiler package).

Posted

Update: I flashed on Sunvell-r69 with legacy kernel 3.4.113 and it has booted up and seems to be running nicely (No change to fex files). I tried using the mainline kernel and it had the same issue. Will try building for Orange pi with the legacy kernel also to see if that could be the cause of the issue.

 

EDIT: just saw your reply.  Thanks for your help.  I will have a play and let you know how i go.

 

Thanks,

 

Nick

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines