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