Basuc ARM/SoC Question

[Draget]

Greetings,

I have a few questions about ARM SoCs and how things play together in the embedded world. Maybe some experienced embedded developer can help and explain/correct a few things. In my Post I will mark statements and question with Numbers [x] so it is easier to reference to them.

ARM sells their CPU-Designs to companies who build socalled System-On-Chip packages that are based on the ARM Arch and have a bunch of extra features. Such SoCs are Allwinner A10 (based on ARM Cortex A8 with the instructionset ARMv7) or BCM2835 (based on ARM1176 with arch ARMv6) popular through r-pi and android devices..
[1] I can compile software for this particular ARM-Arch (e.g. ARMv7) and it will run on any of these SoC (if there is the correct kernel underneath), correct? Or does it also depend on other things even among the same arch, like thumb, hardfloat or whatnot?

[2] These SoC doe not really have a BIOS but rather some basic bootcode that runs some magic blob on a SD-Card to load the kernel? Where exactly do traditional bootloader like grub or things like u-boot fit in there?

[3] Do these SoC have standard-buses or somthing to report which hardware they have inside? Can the kernel figure out on its own that this particular SoC has a sata-controller inside?

[4] A kernel compiled for the correct arch is still useless on any SoC because (maybe due to [3]) it does not have a clue about any way to adress the usb-controller, memory, whatnot, correct? How does a kernel maintainer for such a SoC configure this? Is there like some file that maps address spaced to hardware inside the SoC? Or is all hardware inside the SoC completely a black box and only accesable via properitarian binary modules given out by the vendor? How are such simple things like memory addressing, MMUs, TBL whatnot managed? Such things cannot be loaded as a module, if I am not mistaken.

There are public repos for modified kernels - maybe exactly these provide the basic things for each SoC. [5] If they support kernel 3.2.1 for example and I want to run 3.2.2, assuming the changes allow the same patches to apply cleanly, could I simply create a diff to the vanilla kernel sources for their 3.2.1 repo and apply the same patches to the vanilla 3.2.2 kernel?


How do the boards (PCB) on which the SoC sits change the situation - the Allwinner A10 is built into a ton of difference devices, from stick-sized mini-android-PCs over various tablets to the mele m1000. [6] Do all these devices run with a general 'Allwinner A10'-Kernel? I mean, these devices connect all additional hardware (like ethernet chips, additional usb controllers or wifi-modules) to some bus which is already supported by said kernel, so the kernel detects them, boots and runs? Ofcourse, the additional hardware itself (the ethernet controller, the lcd driver etc) might not have a correct kernel driver and thus might not work, but basic booting should always work?
Or do you need such magic configurations settings that are somehow tied to the kernel (see question [4]) for all boards, because there is no way for the kernel to figure out how to adress any hardware?

Especially with the Allwinner A10 there are a ton of very similar devices - some with same CPU-Freq, connections and maybe just differently sized ram - [7] will a system that runs on one of them also run on the others?

Already alot of thanks for anyone who helps me clearing up the relatively new ARM world to me =)

-draget-

[b0nafide]

[1] If you disable stuff like thumb or NEON then you'll have slow, yet compatible, code. Seeing as you're asking in a gentoo forum - use the correct toolchain with full support. It's better.
[2] For a good description of the possibilities see here
[3] these days try lsusb or i2cdetect or other tools for the bus in question to enumerate things
[4] use the kernel source from the manufacturer.
[5] see [4]
[6] Nah.
[7] Nope.

[NeddySeagoon]

Draget,

Welcome to Gentoo.

Lets step back a stage to CPU design. ARM do not design or make CPU silicon. Vendors licence a 'soft' design that they embed in their SoC.
Likewise other vendors provide other parts of the system as 'soft' designs. The SoC vendor puts all of this parts together in a custom single chip design, in much the same was as a traditional motherboard vendor designs and assembles hardware parts into a motherboard.

This means that all these SoC are different. You may be able to make a generic kernel to run on a wide range of these devices but the ARM and embedded world is not as mature as the Intel/AMD world so don't be surprised if you come across drivers that don't play nicely if the hardware they expect to find isn't present.

Traditional bootloaders are an Intel/AMD PC thing. that don't fit into the embedded world at all.
Some embedded devices expect to run the kernel from FLASH by addressing it directly, much as a PC runs its BIOS.

No buses report what hardware is connected. Those busses which appear to do this, like USB, I2C and PCI don't really. They provide a mechanisim for software to safely search for devices.

Kernel maintainers get to know about how the internals of a SoC work because vendor make the information available. How varies, some is published on the web, some needs a Non Disclosure Agreeement ... and some as you say, its a cause of use our binary bob.

The special kernels for individual SoC are normally required - that have patches when are not in vanilla. If it was as easy as you suggest to migrate the patch set, the kernel maintainer would alreay have done it ... but your theory is sound.

To run the kernel on the various boards, you need to build the kernel with support for the various devices found on these boards. You don't have to be able to operate all of the devices to be able to boot.

You should read the gentoo-embedded handbook and maybe join #gentoo-embedded on freenode.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Draget]

Hello,

thank you very much for your informations.
By the way, I am not really new, just registered under a new name since I did not use/need my old one anymore.


So basically it is all about putting data to the right memory addresses and punching the right registers. So no matter how similar two SoCs are, if they are not exactly the same model, they might be wired completely differently and it is possible that most/all features do not work without the proper patches from the vendor.

Pretty sad


But there are busses - once the USB controller works, the kernel can use the established ways of communicating with the hardware. And the drivers in the kernel for such devices is pretty platform-independent, right? So I can expect just about any wifi-usb-stick to work on an ARM platform once I managed to boot the kernel?

And I am already in the channel, lurking =)

Greetings
Draget

[NeddySeagoon]

Draget,

If you can get the kernel driver and user space tools to build for your target, you hare half way there.
I say half way because building is only the first step. The user space tools are known to work on ARM or there would be a lot of unhappy Raspberry Pi owners out there.

Kernel drivers will vary. If you have a fairly rare USB stick, you might be first to try the kernel driver on ARM.
Now, the driver is GPL, if it breaks, you can keep the pieces ... or you can fix it, for yourself and everyone else.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.