Re: understanding Debian support on ARM architecture
On Sun, 10 Aug 2014 14:14:53 -0400
Celejar <celejar@gmail.com> wrote:
> On Sun, 10 Aug 2014 18:22:41 +0400
> Reco <recoverym4n@gmail.com> wrote:
>
> > Hi.
> >
> > On Sun, 10 Aug 2014 17:09:58 +0300
> > Martin T <m4rtntns@gmail.com> wrote:
> >
> > > Reco,
> > >
> > > thanks for this explanation! Could you please explain this
> > > hardware enumeration provided by x86/x86-64 CPU's to kernel bit
> > > more? What kind of information is provided to kernel in case of
> > > x86/x86-64 CPU?
> >
> > Sure:
> >
> > 1) Obtain any x86 hardware.
> >
> > 2) Boot Linux.
> >
> > 3) Run lspci. Observe a non-empty result, which will probably
> > include SATA, Ethernet, USB, Memory controllers and probably much
> > more.
> >
> > 4) Repeat steps 1-3 with any ARM board (assuming successful boot, of
> > course). Observe exactly one line that says (in my case, and that's
> > good one, usually there's nothing at all):
> >
> > 00:00.0 Host bridge: Marvell Technology Group Ltd. 88F6281
> > [Kirkwood] ARM SoC (rev 03)
> >
> > And that particular hardware has at least Memory, Ethernet, 4-port
> > SATA controller and USB.
> >
> >
> > That's they mean then they talk about hardware enumeration - it's
> > all there yet ARM platform has no means to discover it or to tell
> > Linux kernel its there.
> >
> > So, you count the hardware, produce device tree, compile it into the
> > kernel - and you can work with said hardware.
> >
> > You have a different set of hardware - you'll need a different
> > device tree. And that means a different kernel.
>
> Thanks for this explanation. I also run Debian on a Kirkwood platform
> (a Seagate GoFlex Net (STAK100)) (in addition to my x86 hardware), and
> I kept seeing all this talk about flattened device trees, and was
> aware of the need for special kernels, but I never really understood
> why ...
>
> http://forum.doozan.com/read.php?2,12096,12096
>
> Now, I'm still not sure about the difference between flattened and
> non-flattened trees, and what they're relative advantages and
> disadvantages are ...
>
One of the reasons for the complication is that all ARMs are not
created equal. The ARM is not a processor, but a set of macros in a
semiconductor design language. Various manufacturers are licensed to
use the ARM core, and may add a variety of other hardware, effectively
as subroutines. The chip may have a numeric co-processor or not. So
there's no standardisation of hardware architecture such as the
'IBM-compatible PC' ('will it run Lotus 123?') had thirty years ago. The
kernel needs to know what the composite chip contains and how to drive
it, and how it talks to the rest of the system.
For example, the Raspberry Pi, a well-known small ARM-based computer,
uses a Broadcom 'System-on-Chip' processor, about which not much
information is available. The kernel of Raspbian isn't actually part of
Raspbian, but comes from the Raspberry Pi Foundation, and is closed
source, and presumably is proprietary to Broadcom. I suspect that few
ARM licensees provide full specifications of their devices.
--
Joe
Reply to: