LEDE Table of Hardware: Data field terminology

Talk about Documentation
1

I am looking at the "Techdata" page for the EA3500, a device with which I am familiar, and reflecting upon the "correctness" of the "Dataentry". A few things stand out that make me uncomfortable, that I would be inclined to change. But then, I'd like to see if other people have strong preferences for keeping things as they are.

First, I see that the term "CPU" is being used, rather than the term "SoC". To me, these are quite different things. Consider the SoC used in the Linksys EA3500, which I have discussed here. The part number listed in the Dataentry is clearly wrong, by simply looking at the part number marked on the actual device. And the 88F6282 part listed was never marketed as an 800MHz part. But then, the apparent part number, the 88F6W01, was not a part number published by Marvell, and would appear to be a custom OEM part number, for an earlier generation part with two PCIe interfaces, two RGMII networking interfaces, and no SATA interfaces.

So I would be inclined to change the part number to "88F6W01", though no one will be able to find a Marvell publication for that part by searching on that part number.

And then, the Marvell SoC series, related to the 88F6W01, was originally marketed as the "Kirkwood" series, using the "Feroceon" CPU, and later marketed as the "Armada 300" series, using the "Shiva" CPU, after a process shrink from 150nm to 65nm.

The "core" CPU is marketed as something entirely distinct: the "Feroceon" 88FR131 processor core, and the "Shiva" 88SV131 processor core, independently designed by Marvell, but fully compatible with the ARMv5TE processor architecture. The "Feroceon" and "Shiva" ARMv5TE processor cores are not the same thing as the "Kirkwood" or "Armada 300" series SoC families, even though they are related, where the CPU implies the SoC, and the SoC implies the CPU. With the EA3500, "cat /proc/cpuinfo" will tell us explicitly the name of the "Core CPU":

model name : Feroceon 88FR131 rev 1 (v5l)

So I would like to see the term "SoC" used, as distinct from "CPU". And then, using the term "Core CPU" instead of "CPU" would make this distinction more clear.

SoC: Marvell 88F6W01
Core CPU: Feroceon 88FR131 rev 1 (v5l)

That brings me to my second uncomfortable issue. I see the terms "Target" and "Subtarget" being used in the "Dataentry", in this case, with "Target: Kirkwood".

Now "Kirkwood" is the SoC family marketing name for the "Feroceon" Core CPU. And "Kirkwood" is also the name that LEDE uses to designate the software for this Linksys router, and it is the name used in the linux kernel "Documentation/arm/Marvell/README" file that ties together the SoC family, the SoC part number, the Core CPU name, and the underlying processor architecture, ARMv5. But I have an issue with calling "Kirkwood" a "Target".

You see, the term "Target" is a particular "term of art", used with the GNU gcc toolchain, and the GNU gcc toolchain is directly pertinent to the software being provided for the Linksys EA3500. "Target" should not be some sloppy "throw away" term, in this context.

For instance, looking at "GNU Compiler Collection (GCC) Internals" 6.1 Configure Terms and History, we see that gcc "configure" uses the very particular terms "--build=, --host=, and --target=". And then we see that the term "target" only has a meaning when a gcc compiler is being compiled, and then, only when that compiler is being compiled to run on a machine architecture that is different from the machine architecture for which that compiler being compiled will be compiling application software. In that case, and only in that case, there are three machine architectures involved: the machine compiling a compiler, the machine on which the compiler being compiled will actually run, and the machine for which the compiler being compiled will be compiling.

The thing is, in all other cases, and particularly, in the case in which LEDE will actually be compiling application software, the technical "term of art" used by the official GNU documentation, for the machine architecture for which the linux kernel, the C library, and all of the application software will be compiled, is "host". GNU calls that machine the "host" machine, not the "target" machine. What was previously the "host" machine, when compiling the compiler, has now become the "build" machine, when that compiler is actually run and compiling applications. And, what would have been the "target" machine, then becomes the "host" machine, the machine for which all this software is being compiled, which is the machine that will actually be running the LEDE kernel and packages. "Host", not "target".

So, I think that calling the SoC family the "Target", instead of, say, the "Host", is just going to confuse anyone who might have reason to think about building a GNU gcc toolchain for their own embedded device. That's not the "target" machine. It is the "host" machine.

So, rather than argue about "host" vs "target", I would suggest using the same existing terminology already being used by the linux kernel, as is seen in the linux "Documentation/arm/Marvell/README" file:

Family: kirkwood

and then,

Subfamily: generic

Thirdly, finally, nowhere in the "Dataentry" is the underlying machine architecture listed. I would think people would be fairly interested in that. For the EA3500, I would suggest something like:

Architecture: ARMv5TE

What do you think? Can we change the "Dataentry" terminology in the "Techdata"?

  1. Add "SoC"
  2. Add "Architecture"
  3. Change "CPU" to "Core CPU"
  4. Change "Target" to "Family"
  5. Change "Subtarget" to "Subfamily"

And then, if I were to change the EA3500 SoC part number to the actual part number shown on the part, instead of some fantasy next generation part number found on other web sites, and show the "Core CPU" as the actual core CPU found by the kernel, would that be acceptable?

2

Hi James,

  1. Although SoC would be the correct term, I'd like to stick to CPU to keep the commonality with wikidevi, which uses the same term, see e.g. https://wikidevi.com/wiki/D-Link_DIR-505_rev_A1
    Sidenote: Todays "CPU" was "Platform" in the OpenWrt wiki. A term coming from development, and not aimed at and not well understood by users. To present the user something more recognizable, Platform was changed to CPU when building the LEDE ToH.
  2. Architecture / Instructionset is kind of available, but hidden since the introduction of "Package architecture". Info from c/o OpenWrt dataentries is still there (see https://lede-project.org/toh/views/toh_dev_arch-target-cpu), but not requested for new dataentries in favour of Package architecture.
  3. See 1; The SoC already defines what is in it.
3

James,

I also am intimately familiar with this router model and much of the detail on the Wikidev site was entered by me after inspection of my two units. The conclusion that the SoC is an 88F6282 comes from the stock U-Boot as seen below:

** WNC BOARD: audi R2.2 LE ** 

U-Boot 1.1.4 (Jan 2 2012 - 19:59:08) Marvell version: 3.5.9 

U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006CFB20 

Soc: 88F6282 A1CPU running @ 800Mhz L2 running @ 400Mhz 
SysClock = 400Mhz , TClock = 200Mhz

Note the next to the last line there indicates a 88F6282 A1 CPU running @ 800Mhz. I'm inclined to believe the Uboot used to initialize the system.