The number of cores is already included, e.g. "2x500" = 2 cores at 500MHz.
Type of CPU: Does this information need to be included in a filterable list? Would this info be a benefit for the average user or only for a developer?

Reason for asking: I'd consider myself as an average user (no developer), and I don't care at all about the type of CPU, as long as MHz / Flash / RAM are in the range I'd like to have. There might be usecases, but given my limited knowledge, I'm having difficulties to understand how this could be useful.

Strolling through the "WLAN Hardware" column, I ask myself:

What's the difference between :
- BCM4318 (onboard)
- BCM4318 (integrated)

?

IS there any difference between onboard and integrated?
If yes, what is it? If no, which one would be preferred?
What's the definition of "onboard" and "integrated"?
Does the onboard/integrated only serve as differentiator to extension cards like PCI?

About the CPU speed... I think the point of the column is that it gives an idea of the performance. If it says 233MHz you know it is old and slow, and if it says 900MHz you now it is pretty powerful. MHz is not everything, but at least it is an objective number.

To me, the not-super-expert-reader, I dont care if it is onboard or integrated. I dont need either information. And BCM4318 also tells me nothing about if it is state-of-the-art or 15 year-old-tech. I do understand a kernel developer cares!

To me, the amateur and reader of the ToH, I would want to know (in order)
1) Clock speed
2) Instruction Set (ARM, MIPS, PowerPC)
3) Sub-instruction-set (ARMv5, MIPS 24k)
4) Manufacturer of chip
5) Chip version
6) How it is physically attached to the system board

I understand other people can read BCM4318 and draw conclusions about what things are expected to work. I think, for that, it would be more relevant to have a support-column that mentions if wifi or other things dont work properly for an otherwise "supported" device.

Completely agree with you richbhanover.
And also the device pages need work...

I dont think anyone is going to really give you explicit permission to edit the key/top-level pages. And I think your work will be (silently) appreciated if you do it. I suggest start fixing things slowly. I encourage it. It is after all a wiki and old versions are saved. You could start a new topic called "Improve the Wiki first pages", but I think it may be more practical to just use this topic (I dont mind if you do).

Updated http://wiki.openwrt.org/toh/dataentry_t … try_values

Added sub-/Instructionset + Bootloader, since this is typically found on the device pages (the better ones).
Comments welcome!

More changes to 'wireless nic' -> update please!

Sidenote: Slowly I'm getting tired and I want to "arrive" somewhere.... *sigh*

I can understand this. So... what else do we need to do to use this (great) new data file to create an alternate TOH page, and put links to it several places around the site?

I would gladly put a link to it on the new "Installing OpenWrt" page at http://wiki.openwrt.org/doc/howto/installopenwrt

More on "arriving somewhere"... I saw an interesting note on the "Buyer's Guide" wiki page: http://wiki.openwrt.org/toh/buyerguide# … e_hardware

It contains an Amazon link that does a search for "OpenWrt". Not surprisingly, this turns up a number of routers that all mention OpenWrt. This gets around the strong policy that "OpenWrt does not recommend hardware". Instead, Amazon (and its customers) do the recommending.

So I can envision a buyers guide page that starts by telling people to look several places:

- Look for "OpenWrt" on Amazon, and read the individual reviews that mention OpenWrt on Amazon, to see people's experience
- Look at the individual Detail page to see if a) there's a link to firmware and b) installation instructions
- Look up the router in the Forum to see whether people report problems

Between all three of these, a novice would likely get a router that's going to be an easy install and work well for them.

I definitely believe this is valuable to anyone looking for the fastest CPU core, which has implications today on bandwidth shaping (QoS/SQM), VPN speeds, samba transfer rates, anything related to encryption, etc.

Think Pentium 4 with speeds in the 3+ GHz range but nowhere near as fast as today's CPUs in the 1.x GHz range. Intel abandoned the MHz race back then and never looked back. MHz is just not enough. Up until now, we have basically been stuck with MIPS CPUs in our routers for years where MHz was close enough. However, I believe we are at an inflection point right now where embedded CPUs are going to get considerably faster thanks to the rapid acceleration in ARM deployment everywhere.

I think it's worthwhile to at least specify the instruction set and preferably either the sub-instruction set or the core codename (preferred) - e.g. 1.2GHz dual core ARM A9 or 2 x 1.2GHz ARM A9. This doesn't take much space or add much effort.

One super important thing for that page is to point out that trunk builds do not include a web GUI. This question comes up multiples times per week and everyone thinks their router is bricked. If we're trying to make this newbie friendly, I would strongly suggest we discourage trunk installs, at least as the first experience with OpenWrt.

Inevitably, some routers are only supported in trunk, but this is also why it's a good idea to have stable releases every 6 months or so.

This is a separate question, but I wonder why this is. None of the current CC trunk builds are interesting on a router that's short on RAM/Flash memory... Not having the GUI just hamstrings people who'd like to try it out. (Perhaps the trunk developers are hoping to minimize the number of newbies on the *developer* list...) PS - I updated that "Installing OpenWrt" page with the warning.

The people in this topic are working hard to come up with a better path through the OpenWrt site, so that new people have a good shot at getting OpenWrt installed with a minimum of tears.

But the stable/trunk dichotomy makes it more important than ever for the individual device details page to give explicit instructions for installing BB and CC...

Actually the top-level page cannot be edited by mere mortals/site members. See http://wiki.openwrt.org/start?do=edit

I plan to try out various pages (such as Installing OpenWrt - http://wiki.openwrt.org/doc/howto/installopenwrt ) on this thread before doing anything interesting.

I will also poke around gently to see how changes to the top level page(s) are approved...

Ahh... didn't know
I at least ran the update again: https://dl.dropboxusercontent.com/u/906 … index.html

I will, some day, navigate around the site, read the different suggestions and look at the new suggested pages... right now I dont really have a very qualified opinion about the site structure.

I think we kind of agree here. So I think what is suggested here looks very good
  http://wiki.openwrt.org/toh/dataentry_t … try_values
(someone has been working on this one since last time I checked it I think )

One more update please. I've been busy again cleaning up the "Wireless NIC" column.
YES, we're improving! *jump*

SCNR ;-)

(I still like those oldschool smilies)

By the way: This comparison of toh versions from the start of the cleanup until today shows the changes that have been done.

http://wiki.openwrt.org/toh/start?do=di … sidebyside

I think there are some very good reasons to keep inexperienced users away from trunk releases:

• Trunk releases are volatile - one version might be rock stable, another one might brick your device.

• Because of their volatile nature, a user wanting to install package X say, a week, after installing the trunk build, might be unable to do so (especially for kernel module packages). For a newbie, that means: install another trunk build.

• Newbies don't compile themselves, don't check the git or SVN logs, and even if they did, they wouldn't know which commits might break stuff.

Those are three simple facts that invalidate trunk usage for newbies. If you're a newbie to OpenWrt but can read the commit logs, build packages or firmware images yourself, you don't qualify as a newbie - you're someone with a development background that can find his way around. Whether it's deliberate or not, I think the developers' decision not to include LuCi in trunk builds is a sound one.

Ever newbie installing a trunk build will end up in the IRC channel or on the forum and will get away with an impression of OpenWrt as unstable, and - depending on the response he gets - maybe even unfriendly. That is not the image you want to convey. Newbies look for stable releases, not for bleeding edge stuff.

If someone wants to play with trunk, that's fine - they just need to suck it up. The fact that Chaos Calmer might be close to release (I think developers aimed at releasing it around the beginning of 2015, but that plan obviously tanked) and maybe rather stable as a result does not change anything to that. Trunk is meant for development, stuff breaks. One should not recommend trunk to new users.

(Last edited by Borromini on 29 Apr 2015, 22:18)

Great reasons. I have revised the "Installing OpenWrt" page to motivate people away from trunk builds. http://wiki.openwrt.org/doc/howto/installopenwrt

I don't fully understand it either, except possibly as a deterrent to those that don't know what they're doing. Alternatively, I suppose you could have something that breaks and figuring out whether it is Luci or the core firmware could be slightly harder if they were integrated together. The nightlies really are intended for developers and there are other issues that users can run into with trunk. Like the inability to install packages after a new revision is uploaded since the kernel versions no longer match. This is also a common question that comes up on the forums.

I really strongly urge that new users stick to stable releases unless they have a very compelling reason to use something newer and are fairly savvy with the linux command line.

Cleaned up some of the chipsets listed for newer TP-Link routers, which are pretty easy to find and relatively cheap. In general, this is what I recommend to most people. They also don't play too many games with complete changes to the hardware between revisions, although it is an occasional issue. Also changed them to say 14.07 for supported version.

*Speaking of hardware version issues - should we put an * (or other warning) by routers where this may be an issue to alert users? It's often mentioned on the detail page, but not always. D-Link has a bad track record with this, but they're not alone.

Just to make sure I'm doing the right thing, we are editing the tables in the wiki directly? Not via dropbox or elsewhere?

(Last edited by drawz on 30 Apr 2015, 05:29)

I think it makes sense to be be specific about it, when V1 works, but V2 is not supported.

I updated: https://dl.dropboxusercontent.com/u/906 … index.html

drawz: it means I run a local script on my computer (first wget the actual pages from OpenWrt.org, second a nodejs script to parse the information and produce output), generating https://dl.dropboxusercontent.com/u/906 … toh_all.js
I then update that file on Dropbox with a single cp. So, Yes, edit the wiki as usual. I posted the (now outdated) sources to the entire thing a while ago... no one showed any interest, but I can update them in case anyone is interested.

Had you considered putting those sources in github? That would immediately do two things:

1) They'd be publicly available for anyone to use/modify
2) You get great backup

I don't know if everyone has seen it, but eshultz is also interested in solving the problem of making OpenWrt approachable to people. Some people here have already commented there. The thread is on the Community Documentation forum at https://forum.openwrt.org/viewtopic.php?pid=274619

Not really (considered). But I added a link to the source to the bottom of the page, and uploaded the source as well.
The data has been updated.