Packages for instruction sets

I am trying to install LEDE for the first time.

The WIKI => Downloads page and the Projects Download page both take the user to the 'traditional' Targets page.

As these are nightly builds, I used wget for the packages in the "packages" subdir. I noticed that it took very little time to download and then that these are mostly KMODs.

After about 10 minutes of frustration I tripped across the Packages folder one level up in the FTP hierarchy. I was unable to find a reference to this anywhere.

Now I have a new issue. What is the correct instruction set for the Target? I had to go to the TOH to look this up. Even then the instruction set in the TOH is not exactly the same as in the folders. I realize this is a work in progress, not pointing a finger here.

For my GLi.MIFI (AR71XX) there is "Instruction Set MIPS32 and Sub Instruction Set: MIPS32 24K/E series". I do not know what I want here: mipsel_mips32, mipsel_mips32r2, mipssel_24kc, mips_24kc or mips_mips32.

I think this process could be very problematic for new users. There is too much opportunity for error as currently written, and could lead to users with missing or incorrect repositories. Both of these may lead to avoidable forum posts.

I would like to suggest the following resolves.
1 - add to the first section " Get the Current LEDE Snapshot Firmware" a link to the packages
2 - add to the same section a link to a new document with a cross ref chart for these elements and links from there to the appropriate packages folder.
3 - add a link to the FTP page for each target that is a short cut to the Packages folder appropriate to the target

I expect the driver to this reorg is a large savings in disk space, but if there are other reasons I would appreciate understanding this.


In progress via
As soon as the conversion to the LEDE naming of instructionsets is done, the above datatable will lead you the way.
The faster is filled in, the faster this will be converted and working. If a LEDE IS is not yet existent: Click on it, create new page (will be filled automagically via namespace template), save.

Link to package download folder is automatically created in the instructionset page, e.g.

1 Like

This looks great! Thanks very much!

Should there be some additional menus for nav in the WIKI for this (eventually)? Opening the arm page link, I see "downloads" highlighted in Blue (which does not seem to move as one navigates to say Documentation), but a path Home/Instuctionset/arm_Cotex-a7

As promised in the other thread, here's the complete mapping of package architectures to targets using them:

Package arch -> targets

  • aarch64_armv8-a

  • arc_arc700

  • arc_archs

  • arm_arm1176jzf-s_vfp

  • arm_arm926ej-s
    at91/legacy, mcs814x/generic, mxs/generic

  • arm_cortex-a15_neon-vfpv4

  • arm_cortex-a5

  • arm_cortex-a53_neon-vfpv4

  • arm_cortex-a7

  • arm_cortex-a7_neon-vfpv4

  • arm_cortex-a8_vfpv3

  • arm_cortex-a9

  • arm_cortex-a9_neon
    imx6/generic, zynq/generic

  • arm_cortex-a9_vfpv3
    mvebu/generic, omap/generic

  • arm_fa526
    gemini/raidsonic, gemini/wiligear

  • arm_mpcore

  • arm_mpcore_vfp
    cns3xxx/generic, realview/generic

  • arm_xscale

  • armeb_xscale
    ixp4xx/generic, ixp4xx/harddisk

  • i386_geode

  • i386_i486

  • i386_pentium4
    x86/generic, x86/xen_domu

  • mips64_mips64

  • mips64_octeon

  • mips64el_mips64

  • mips_24kc
    ar71xx/generic, ar71xx/nand, ar71xx/mikrotik, lantiq/xrx200 lantiq/xway, lantiq/xway_legacy, malta/be

  • mips_mips32
    adm5120/router_be, ath25/generic, brcm63xx/generic, brcm63xx/smp

  • mipsel_24kc
    malta/le, ramips/rt305x, ramips/mt7620 ramips/mt7621 ramips/mt7628 ramips/mt7688

  • mipsel_74kc
    brcm47xx/mips74k, ramips/rt3883

  • mipsel_mips32
    adm5120/router_le, adm5120/rb1xx, adm8668/generic, ar7/generic, ar7/ac49x, au1000/au1500 au1000/au1550 brcm47xx/generic, brcm47xx/legacy, rb532/generic, xburst/qi_lb60

  • mipsel_mips32r2

  • powerpc_440

  • powerpc_464fp
    apm821xx/nand, apm821xx/sata

  • powerpc_8540
    mpc85xx/generic, mpc85xx/p1020

  • x86_64

Target -> package arch

  • adm5120/rb1xx => mipsel_mips32
  • adm5120/router_be => mips_mips32
  • adm5120/router_le => mipsel_mips32
  • adm8668/generic => mipsel_mips32
  • apm821xx/nand => powerpc_464fp
  • apm821xx/sata => powerpc_464fp
  • ar7/ac49x => mipsel_mips32
  • ar7/generic => mipsel_mips32
  • ar71xx/generic => mips_24kc
  • ar71xx/mikrotik => mips_24kc
  • ar71xx/nand => mips_24kc
  • arc770/generic => arc_arc700
  • archs38/generic => arc_archs
  • arm64/generic => aarch64_armv8-a
  • at91/legacy => arm_arm926ej-s
  • at91/sama5d3 => arm_cortex-a5
  • ath25/generic => mips_mips32
  • au1000/au1500 => mipsel_mips32
  • au1000/au1550 => mipsel_mips32
  • bcm53xx/generic => arm_cortex-a9
  • brcm2708/bcm2708 => arm_arm1176jzf-s_vfp
  • brcm2708/bcm2709 => arm_cortex-a7_neon-vfpv4
  • brcm2708/bcm2710 => arm_cortex-a53_neon-vfpv4
  • brcm47xx/generic => mipsel_mips32
  • brcm47xx/legacy => mipsel_mips32
  • brcm47xx/mips74k => mipsel_74kc
  • brcm63xx/generic => mips_mips32
  • brcm63xx/smp => mips_mips32
  • cns3xxx/generic => arm_mpcore_vfp
  • gemini/raidsonic => arm_fa526
  • gemini/wiligear => arm_fa526
  • imx6/generic => arm_cortex-a9_neon
  • ipq806x/generic => arm_cortex-a15_neon-vfpv4
  • ixp4xx/generic => armeb_xscale
  • ixp4xx/harddisk => armeb_xscale
  • kirkwood/generic => arm_xscale
  • lantiq/xrx200 => mips_24kc
  • lantiq/xway => mips_24kc
  • lantiq/xway_legacy => mips_24kc
  • malta/be => mips_24kc
  • malta/be64 => mips64_mips64
  • malta/le => mipsel_24kc
  • malta/le64 => mips64el_mips64
  • mcs814x/generic => arm_arm926ej-s
  • mediatek/generic => arm_cortex-a7
  • mpc85xx/generic => powerpc_8540
  • mpc85xx/p1020 => powerpc_8540
  • mvebu/generic => arm_cortex-a9_vfpv3
  • mxs/generic => arm_arm926ej-s
  • octeon/generic => mips64_octeon
  • omap/generic => arm_cortex-a9_vfpv3
  • oxnas/generic => arm_mpcore
  • ppc44x/generic => powerpc_440
  • ramips/mt7620 => mipsel_24kc
  • ramips/mt7621 => mipsel_24kc
  • ramips/mt7628 => mipsel_24kc
  • ramips/mt7688 => mipsel_24kc
  • ramips/rt288x => mipsel_mips32r2
  • ramips/rt305x => mipsel_24kc
  • ramips/rt3883 => mipsel_74kc
  • rb532/generic => mipsel_mips32
  • realview/generic => arm_mpcore_vfp
  • sunxi/generic => arm_cortex-a8_vfpv3
  • x86/64 => x86_64
  • x86/generic => i386_pentium4
  • x86/geode => i386_geode
  • x86/legacy => i386_i486
  • x86/xen_domu => i386_pentium4
  • xburst/qi_lb60 => mipsel_mips32
  • zynq/generic => arm_cortex-a9_neon

You can generate this lists yourself by executing;a=blob;f=phase1/ within a LEDE buildroot.

To obtain the target-to-arch mapping, run ./ targets, to obtain the architectures-to-targets mapping, run ./ architectures


[quote="jow, post:4, topic:95, full:true"]To obtain the target-to-arch mapping, run ./ targets, to obtain the architectures-to-targets mapping, run ./ architectures
[/quote]I think it would be cool to have the buildbot run this script on its own and dump the results in a text file called like "Target -> package arch list" or a more generic "README" in the /packages folder.

So we can just direct people to that always up-to-date file in guides and things.

Yes, I thought about the same.

[quote="jow, post:4, topic:95, full:true"]As promised in the other thread, here's the complete mapping of package architectures to targets using them:[/quote]I've been adding them to the page in the wiki, and I noticed that in the download page there are 4 package architectures that don't have a target.
Who is using packages of those architectures? Here a list:


1 Like

They're stale, I'll purge them from the mirror later.

Can you please expose the sub target field in the Instructionset view.

I just happen to know that the PC-Engines ALIX are incorrect and is actually an x86 Geode, which should map to i386_geode.

Most most sub-targets should have a value of generic, but there are about 9 targets whose sub-targets have differing instruction sets. This would make it easier to validate.

Subtarget added.
Please mind: The subtarget field is not yet filled correctly for all devices.

1 Like


If we assume the LEDE Targets are correct where they exist, is there an easy way to update the sub-target field for those targets with only a single generic sub-target?

If the targets are wrong (not saying they are) it's a different issue anyhow.

Am I correct in assuming that the data that you have imported will be the data we are working with. I recall in developing the OpenWrt TOH there were multiple imports.

I will fix the GEODE data

What can easily be done:
If Platform = Allwinner A10 -> subtarget = generic

I plan to do a final dataimport from OpenWrt once the structure of the dataentries has stabilized, hence mentioning that all edits to the current LEDE ToH will be gone with the next update.