Firmware Wizard

Who is "somebody"? Where to needs the data to be added? How does this "add data" process look like? Is this a manual process where you have to enter each and every model by hand? For snapshot and releases?

@tmomas: there is a database file that maps image names to vendor and model. Every model would have to be added.

The mapping process is fuzzy, that makes it applicable to images that have a different branding.
Also, some image names are not following the common naming scheme (upper case names, v6 is used for hardware revision v2, ...).

A model has to be added once, unless the file name changes in major ways (different from the used identifiers).

@mwarning Couldn't the existing database (ToH) be of any use to you? Afaik a lot of those entries contain some (if not most) model/firmware mappings already?

@Borromini the ToH could be used to provide vendor and model data. But the image file name would still need to provided. Currently there are >800 models listed. ._.

??? It's all there?

https://lede-project.org/toh/views/toh_fwdownload

@tmomas ah, I was looking at https://lede-project.org/toh/start and did not know about https://lede-project.org/toh/views/toh_fwdownload.
I think I can get the information out of that site. thanks for the hint. :slight_smile:

2 Likes

@tmomasas I cannot parse toh_fwdownload. The underlying HTML code is horrific.
I would only need to visible contents of the table.

Something like this (in the old wiki!)?
https://wiki.openwrt.org/toh/views/datalist-csv

...and now also in the new wiki:
https://openwrt.org/toh/views/datalist-csv

That would be easy to parse, but this probably only contains old models.
The existing (json) database for the firmware selector is quite extensive already.

It would be nice to have a table export (csv, tsv or json) with manufacturer, model, install/upgrade image links etc.. Then this could be called right from the firmware selector and there would be no need for a curated list in the firmware wizard repository.

The above link to the new wiki should do just that: Delivering up to date csv data.
Which data to display can be freely configured.
What data exactly do you want to see? What is "etc"?-)

manufacturer, model, install/upgrade image link is enough.

The only remaining problem I see, is that the csv is embedded in html. Do you have a direct link?

I'm afraid, no direct link to a txt-only csv available.

Wait...

Does this help?
https://openwrt.org/toh/views/datalist-csv?do=export_xhtml
https://openwrt.org/toh/views/datalist-csv?do=export_xhtmlbody

That won't work. the wizard needs to get and parse from javascript that runs in the users browser.

Then maybe the solution would be to directly access the sqlite database that is behind all the tables.

Even if that would be able to be parsed in javascript, the download footprint would probably be rather high.
@tmomas thank you for your effort. But the only solution I see here is a tsv/csv/json download of the hardware table.

@tmomas is there something I can help you with to make a txt-only csv available?
That would finally make the wizard possible without having another curated database.

Yes, write a script that generates the requested csv directly from the sqlite DB and which is then provided to your wizard via http.

Where can I download the sqlite DB?

Hey @mwarning, this request gives an array of all devices of 18.06.0 in JSON format.

Each entry contains the following keys:

  {
    "id": 914,
    "distro": "openwrt",
    "version": "18.06.0",
    "target": "brcm2708",
    "subtarget": "bcm2708",
    "profile": "rpi",
    "model": "Raspberry Pi B/B+/CM/Zero/ZeroW"
  },

Maybe you can make use of it to automatically create a renaming table or offer device search.

The id is only for the database schema and not related to the official table of hardware.

What is needed is a list of objects containing the model name and the link to the image at minimum, served from some up to date source and in an easy to parse format. The only source we have so far is the wiki. But it only serves a big html chunk (~8MB?) that would be downloaded and parsed by each client. So that is not a way to do. That is were this effort is stuck.

@aparcar maybe I can extract some data from your api to curate my own database that I currently use. But the lack of a download link is a bit of a problem.