# Packages for instruction sets

**URL:** <https://forum.openwrt.org/t/packages-for-instruction-sets/95>\
**Category:** Installing and Using OpenWrt\
**Created:** [October 29, 2016, 11:37pm UTC](https://forum.openwrt.org/t/packages-for-instruction-sets/95 "2016-10-29T23:37:13Z")\
**Posts on this page:** 12\
**Page:** 1

<div class="post-metadata">

**Author:** ![RangerZ](https://forum.openwrt.org/letter_avatar/rangerz/32/5_5575768a8748004e209b776fc1b2916d.png) [@RangerZ](https://forum.openwrt.org/u/RangerZ)\
**Post date:** [October 29, 2016, 11:37pm UTC](https://forum.openwrt.org/t/packages-for-instruction-sets/95/1 "2016-10-29T23:37:13Z")

</div>

I am trying to install LEDE for the first time.

The [WIKI =\> Downloads](https://wiki.lede-project.org/downloads) page and the [Projects Download](https://www.lede-project.org/downloads.html) page both take the user to the 'traditional' [Targets](https://downloads.lede-project.org/snapshots/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.  
[https://downloads.lede-project.org/snapshots/packages/](https://downloads.lede-project.org/snapshots/packages/) **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](https://wiki.lede-project.org/toh/hwdata/gl.inet/gl-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.

---

<div class="post-metadata">

**Author:** ![tmomas](https://forum.openwrt.org/letter_avatar/tmomas/32/5_5575768a8748004e209b776fc1b2916d.png) [@tmomas](https://forum.openwrt.org/u/tmomas)\
**Post date:** [October 30, 2016, 3:47pm UTC](https://forum.openwrt.org/t/packages-for-instruction-sets/95/2 "2016-10-30T15:47:03Z")

</div>

> [@RangerZ](#):
>
> 1 - add to the first section " Get the Current LEDE Snapshot Firmware" a link to the packages

Done.

> [@RangerZ](#):
>
> 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.

In progress via [https://wiki.lede-project.org/toh/views/toh\_dev\_instructionset](https://wiki.lede-project.org/toh/views/toh_dev_instructionset)  
As soon as the conversion to the LEDE naming of instructionsets is done, the above datatable will lead you the way.  
The faster [https://wiki.lede-project.org/instructionset/instructionset\_conversion](https://wiki.lede-project.org/instructionset/instructionset_conversion) 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.

> [@RangerZ](#):
>
> 3 - add a link to the FTP page for each target that is a short cut to the Packages folder appropriate to the target

Link to package download folder is automatically created in the instructionset page, e.g. [https://wiki.lede-project.org/instructionset/arm\_cortex-a7](https://wiki.lede-project.org/instructionset/arm_cortex-a7)

---

<div class="post-metadata">

**Author:** ![RangerZ](https://forum.openwrt.org/letter_avatar/rangerz/32/5_5575768a8748004e209b776fc1b2916d.png) [@RangerZ](https://forum.openwrt.org/u/RangerZ)\
**Post date:** [October 30, 2016, 4:17pm UTC](https://forum.openwrt.org/t/packages-for-instruction-sets/95/3 "2016-10-30T16:17:54Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![jow](https://forum.openwrt.org/user_avatar/forum.openwrt.org/jow/32/13_2.png) [@jow](https://forum.openwrt.org/u/jow)\
**Post date:** [October 31, 2016, 8:17am UTC](https://forum.openwrt.org/t/packages-for-instruction-sets/95/4 "2016-10-31T08:17:22Z")

</div>

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

## Package arch -\> targets

- **aarch64\_armv8-a**  
arm64/generic

- **arc\_arc700**  
arc770/generic

- **arc\_archs**  
archs38/generic

- **arm\_arm1176jzf-s\_vfp**  
brcm2708/bcm2708

- **arm\_arm926ej-s**  
at91/legacy, mcs814x/generic, mxs/generic

- **arm\_cortex-a15\_neon-vfpv4**  
ipq806x/generic

- **arm\_cortex-a5**  
at91/sama5d3

- **arm\_cortex-a53\_neon-vfpv4**  
brcm2708/bcm2710

- **arm\_cortex-a7**  
mediatek/generic

- **arm\_cortex-a7\_neon-vfpv4**  
brcm2708/bcm2709

- **arm\_cortex-a8\_vfpv3**  
sunxi/generic

- **arm\_cortex-a9**  
bcm53xx/generic

- **arm\_cortex-a9\_neon**  
imx6/generic, zynq/generic

- **arm\_cortex-a9\_vfpv3**  
mvebu/generic, omap/generic

- **arm\_fa526**  
gemini/raidsonic, gemini/wiligear

- **arm\_mpcore**  
oxnas/generic

- **arm\_mpcore\_vfp**  
cns3xxx/generic, realview/generic

- **arm\_xscale**  
kirkwood/generic

- **armeb\_xscale**  
ixp4xx/generic, ixp4xx/harddisk

- **i386\_geode**  
x86/geode

- **i386\_i486**  
x86/legacy

- **i386\_pentium4**  
x86/generic, x86/xen\_domu

- **mips64\_mips64**  
malta/be64

- **mips64\_octeon**  
octeon/generic

- **mips64el\_mips64**  
malta/le64

- **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**  
ramips/rt288x

- **powerpc\_440**  
ppc44x/generic

- **powerpc\_464fp**  
apm821xx/nand, apm821xx/sata

- **powerpc\_8540**  
mpc85xx/generic, mpc85xx/p1020

- **x86\_64**  
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 [https://git.lede-project.org/?p=buildbot.git;a=blob;f=phase1/dumpinfo.pl](https://git.lede-project.org/?p=buildbot.git;a=blob;f=phase1/dumpinfo.pl) within a LEDE buildroot.

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

---

<div class="post-metadata">

**Author:** ![bobafetthotmail](https://forum.openwrt.org/user_avatar/forum.openwrt.org/bobafetthotmail/32/39_2.png) [@bobafetthotmail](https://forum.openwrt.org/u/bobafetthotmail)\
**Post date:** [November 1, 2016, 12:27pm UTC](https://forum.openwrt.org/t/packages-for-instruction-sets/95/5 "2016-11-01T12:27:17Z")

</div>

[quote="jow, post:4, topic:95, full:true"]To obtain the target-to-arch mapping, run `./dumpinfo.pl targets`, to obtain the architectures-to-targets mapping, run `./dumpinfo.pl 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.

---

<div class="post-metadata">

**Author:** ![jow](https://forum.openwrt.org/user_avatar/forum.openwrt.org/jow/32/13_2.png) [@jow](https://forum.openwrt.org/u/jow)\
**Post date:** [November 1, 2016, 12:43pm UTC](https://forum.openwrt.org/t/packages-for-instruction-sets/95/6 "2016-11-01T12:43:20Z")

</div>

Yes, I thought about the same.

---

<div class="post-metadata">

**Author:** ![bobafetthotmail](https://forum.openwrt.org/user_avatar/forum.openwrt.org/bobafetthotmail/32/39_2.png) [@bobafetthotmail](https://forum.openwrt.org/u/bobafetthotmail)\
**Post date:** [November 4, 2016, 12:12pm UTC](https://forum.openwrt.org/t/packages-for-instruction-sets/95/7 "2016-11-04T12:12:33Z")

</div>

[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:

arm\_cortex-a9\_neon-vfpv4/  
mips64\_xlp/  
mips64\_xlr/  
mipsel\_1004kc/

---

<div class="post-metadata">

**Author:** ![jow](https://forum.openwrt.org/user_avatar/forum.openwrt.org/jow/32/13_2.png) [@jow](https://forum.openwrt.org/u/jow)\
**Post date:** [November 4, 2016, 12:13pm UTC](https://forum.openwrt.org/t/packages-for-instruction-sets/95/8 "2016-11-04T12:13:55Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![RangerZ](https://forum.openwrt.org/letter_avatar/rangerz/32/5_5575768a8748004e209b776fc1b2916d.png) [@RangerZ](https://forum.openwrt.org/u/RangerZ)\
**Post date:** [November 4, 2016, 10:33pm UTC](https://forum.openwrt.org/t/packages-for-instruction-sets/95/9 "2016-11-04T22:33:06Z")

</div>

Can you please expose the sub target field in the [Instructionset](https://wiki.lede-project.org/toh/views/toh_dev_instructionset?datasrt=target) 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.

---

<div class="post-metadata">

**Author:** ![tmomas](https://forum.openwrt.org/letter_avatar/tmomas/32/5_5575768a8748004e209b776fc1b2916d.png) [@tmomas](https://forum.openwrt.org/u/tmomas)\
**Post date:** [November 4, 2016, 11:35pm UTC](https://forum.openwrt.org/t/packages-for-instruction-sets/95/10 "2016-11-04T23:35:12Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![RangerZ](https://forum.openwrt.org/letter_avatar/rangerz/32/5_5575768a8748004e209b776fc1b2916d.png) [@RangerZ](https://forum.openwrt.org/u/RangerZ)\
**Post date:** [November 5, 2016, 4:48pm UTC](https://forum.openwrt.org/t/packages-for-instruction-sets/95/11 "2016-11-05T16:48:48Z")

</div>

Thanks!

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

---

<div class="post-metadata">

**Author:** ![tmomas](https://forum.openwrt.org/letter_avatar/tmomas/32/5_5575768a8748004e209b776fc1b2916d.png) [@tmomas](https://forum.openwrt.org/u/tmomas)\
**Post date:** [November 5, 2016, 9:52pm UTC](https://forum.openwrt.org/t/packages-for-instruction-sets/95/12 "2016-11-05T21:52:52Z")

</div>

> [@RangerZ](#):
>
> 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?

What can easily be done:  
If Platform = Allwinner A10 -\> subtarget = generic  
See [https://wiki.lede-project.org/toh/views/toh\_fwdownload2?datasrt=platform](https://wiki.lede-project.org/toh/views/toh_fwdownload2?datasrt=platform)

> [@RangerZ](#):
>
> 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 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.
