3

I am curious to know about the significance of Board/Machine ID. I have a few questions pertaining to it:

  1. Is machine ID equal to that of board ID or different?
  2. What is the significance of this ID when it comes to boot-loader and kernel booting?
  3. Who decides the board ID?
  4. Is the ID relevant to only ARM architecture, or is the concept applicable to other platforms as well?
  5. How to view the board ID of a particular machine?
  6. Is is specific to booting Linux?

Any other info. in addition to these questions are welcome.

Thanks in advance.

raghav3276
  • 1,088
  • 8
  • 14
  • 1
    http://stackoverflow.com/questions/21014920/arm-linux-atags-vs-device-tree, http://stackoverflow.com/questions/23695627/how-uboot-passes-hardware-information-to-kernel-without-using-dts, http://stackoverflow.com/questions/15548004/why-do-we-need-a-bootloader-in-an-embedded-device, etc – artless noise Aug 12 '14 at 18:48

1 Answers1

6

The "Machine ID" in this context is specific to ARM Linux, and the numbers were assigned by the ARM kernel maintainer. Machines supported in mainline are listed in arch/arm/tools/mach-types; the full registry can be found here.

ARM systems are problematic in that there is no "standard" hardware layout (e.g. the IBM PC-compatible for x86), no standard firmware (e.g. ACPI BIOS), and most peripherals are directly connected to the CPU rather than being behind a probable bus (e.g. PCI). Hence the ARM kernel had to rely on the bootloader telling it what machine it's running on, thus which hard-coded hardware definition/support code to use (see arch/arm/mach-*/).

Note that this system is now obsolete and the preferred way of describing hardware is with Device Tree, which removes most of the need to fill the kernel with machine-specific code (indeed many of those older systems that are still supported are being converted from "boardfiles" to DT).

Notlikethat
  • 20,095
  • 3
  • 40
  • 77
  • So is this specific only to ARM architecture? – raghav3276 Aug 13 '14 at 04:32
  • @raghav3276 Yes, this particular implementation is specific to ARM Linux. Obviously the general concept is so simple I wouldn't be surprised if it existed in other forms elsewhere - there are certainly other platforms with the same non-discoverable hardware problem. – Notlikethat Aug 13 '14 at 08:43
  • @Notlikethat, "Machine ID" for newer ARM boards has *not* been defined in mach-types"(as you pointed). Then where its been defined in Kernel source or concept of "Machine ID" is totally obsolete? U-boot only passes the Processor ID into r1 , basis on which we select proc_info_list structure for specific processor type, right ? – Amit Singh Tomar Aug 27 '16 at 09:06
  • @Amit The only purpose of the machine ID is to select the appropriate hard-coded machine description (boardfile), because there can be more than one built into the kernel image. There's no such thing with DT boot, because the FDT you pass to the kernel _is_ the machine description. – Notlikethat Aug 27 '16 at 09:33
  • Thanks, It helped. Also, I think we still *only* needs the "Processor ID" to be passed from U-boot to Kernel. Is this understanding ok ? – Amit Singh Tomar Aug 27 '16 at 10:12
  • @Amit if you're booting a legacy boardfile system, you need a machine number and an ATAGS list. If you're booting a DT system, you need an FDT. There is no overlap from the boot protocol perspective (although it is possible to build a single kernel supporting both protocols). If you think the boot protocol has anything to do with the CPU type for `proc_info`, I suggest you take a closer look at head.S and how the early boot process works (hint: MIDR). – Notlikethat Aug 27 '16 at 21:54