dCore Import Debian Packages to Mountable SCE extensions > dCore Armv7

Porting between ARM platforms... How is it made?

(1/3) > >>

pioj:
I know every target system is a whole jungle, but I'm intrigued about how much difficult is to adapt Core from one ARM model to another...

What about those platforms based on the same architecture? like.. dunno.. The beaglebone and the beagleboard as example..


Or devices like those SheevaPlug. You know, several targets with the same CPU and/or same nucleus...


Thnx in advance

roberts:
Since I was the one that made piCore and a10Core, I can only speak to those two different platforms.
Since they differ by processor, armv6 versus arm7, everthing in the base had to be compiled.
I used Code Sourcery on x86 Tiny Core for both projects. But that is only the beginning...

The pi differs from Mele A1000 vastly in their boot loaders. Although the pi uses plain text files, it requires computed hex value for the size of Core's initrd. Other boot paramters were easy.

Mele A1000 uses compiled configuration files and uses u-boot as its boot loader. Recently I recompiled u-boot for A1000 to be able to use uEnv.txt, a plain text configuration file. Now the pi being only a single source computer is easy as a bootable imge can be made and you are done. The Mele a1000 is only one manufacturer using the allwinner A10 armv7 processor. Each device available, cubieboard, hackberry, mk802, marsboard, pcDuino, miniX, ... each has its own u-boot binary and configuration files. It is not like x86 and a bios. These arm configuration files often are specific to the size and quantity of ram chips installed and memory addresses to load your OS.

So even if you have an alternate device which uses the same, say armv7, binaries, the boot loader for your specific target will be an adventure to learn and master.

pioj:
Thx for the answer, mr. RobertS.

Yes, I suspected the uboot config is an additional step for ARM devices, meaning the main adventure is to read enough info about the platform to know exactly which hex number has to be...

As  some of the boards already have a working Debian install option, is there a way you can use that in your favor?

- To recreate the desired Rootfs?
- To "mutate" that distro into a TinyCore? I mean, once it boots, we can start modifying init scripts by hand, and go part by part...


This question is important to me because it sets certain concepts about how a GNU/Linux distribution can be created. The LFS documentation was a good read but I want to deep more into it...

roberts:
Having access to a working Debian/Ubuntu system is not too much of an advantage for Core.
Now for most typical traditional distros it is a huge advantage as one would only need to identify and recompile their binaries and swap in their rootfs. Use existing boot loader. Done. That is why shortly after Ubuntu was made available for Mele, you saw several distros become available.

Core is not traditional, it's rootfs is the initrd, so even existing Arm boot loaders need to be studied to accomodate our initrd rootfs.  Since the major work has already been done to create a minimal Core Arm based initrd, I would start with say the a10Core and try to see what adjustments would need to be made for your particular boot loader and hopefully pick a platform that supports Arm v7hf, else be prepared to identify and compile the binaries within a10Core.

I chose Allwinner, as it is one of least expensive yet quite capable Arm systems. I am currently using a 1GB MK802 as my day to day machine. I acknowledge that my needs are minimal compared to most, but I am quite happy with Core on A10.

Zendrael:
Mr. RobertS,

is the graphics 3D accelerated in the Core at Allwinner? Or 2D accelerated?

Does the drivers compilation differ from the proccess on the x86 ones?

Thanks.

Navigation

[0] Message Index

[#] Next page