Are there any official docs or path, with tests to be done on a device, to make it go into a snapshot build?
Which are the minimum requirements overall?
Yes I forgot to say that I've read that page but it doesn't talk about tests to be done to confirme that the firmware is right.
Consider that I don't use 99,99% of the features of any OpenWrt device. Personally I've been on OpenWrt for the AP and Mesh features for a good while (lately fiddling with a packaged name DAWN that delights me every day). But for example, I'm not into VLANS, advanced routing, and other capabilities.
So I'm not sure if there is a testing suite or something like that to be run on my side to confirm that a firmware is working and ready to go to the mainstream branch
1 Like
There are no specific requirements because the drivers and most of the infrastructure are platform-dependent, not device-dependent. There are exceptions though, and sometimes fixes are applied later on.
Your PR or patch to the mailing list has to undergo code review. If stuff doesn't make sense, looks untested or improvised, it won't be merged before you make the necessary changes. Don't get discouraged, it is very likely that the first version will have to be improved.
If you are adding support for a highly demanded device, like the WSM20, chances are good that it will see a lot of testing either before being merged or immediately afterwards.
Another thing. I think that LEDS and hard buttons (reset + WPS) will take me a lot, to have them implemented. I have asked for Open Source'd DTS from ZyXEL to fixed them, but I will try nevertheless to support them meanwhile
My question: A build without a fully functioning device (leds and buttons in this case) may pass controls? Basically I will be building and testing a very core build with the most fundamental elements which obviously are ethernet and wireless.
The GPIOs for LEDs and buttons are really easy - just try them out from user space. Takes 10 minutes if you know what you're doing. There is a Wiki article on this.
EDIT: See here: https://openwrt.org/docs/techref/hardware/port.gpio#finding_gpio_pins_on_the_pcb
This for GPIO leds and buttons?
If parts are missing, like buttons, recovery, leds or a combination of those you will have difficulty getting the device accepted.
1 Like
that if i remember correct is on gpio 6
As you see in my reply for a very specific device
The LED used for this device are omega wierd. Not the classic leds indicating if "wifi is up" if "wps is active" leds for the ethernet, etc... This is a weird color schema.
What is expected within OpenWrt for this special scenario?
If the leds cannot be controlled you can explain that in the commit. Though fixed function leds will usually work without any setup. If they are not working in openwrt then they likely are addressable.
Usually that’s done in the dts or via an expansion bus module, that factory firmware should indicate how they are being triggered
3 Likes
Oh and you don’t need to replicate the factory behaviour - just make it possible to control the LEDs.