Update Master to match LEDE Upstream - WIP #5
Conversation
We do tons of things here as we prepare to merge upstream * Move sp5100_tco watchdog patches to the proper location, and unsquash them * Move the nct5104d driver to x86 (this may go back to generic later) * Work on adding AES-NI accell (NOT WORKING YET, BUILDS WILL FAIL!) * Add modules for drivers not needed during init (aka, all but LEDs) * Other layout changes
This fixes up the building of the Intel AES_NI support needed for acceleration.
This includes a few more fixes/changes from requests in the RFC thread. - Enable AES-NI (Verified working using openssl speed) - Add Beep package - Remove custom x86 base config for beep - Update default package/modules - Build ath10k without hwmon kernel support
This config calls the APU2 profile, and only adds the following: - Luci with OpenSSL as the SSL engine - openssl-utils for the openssl binary for AES-NI testing and whatnot
Forgot to update this last commit.
Lede upstream port
This was not working on older BIOS builds due to a different DMI name. This new comparsion should fix that.
Let's cleanup board detection on the driver to prevent dmesg spam on non APU boards, as well as fixup the reset button script based on feedback from the mailinglist.
Title says it all. 1. Fix a kernel panic on other x86 systems when leds-apu2 is loaded 2. Fixup definition of the kmod for nct5104d as it's shared with APU1 as well. 3. Remove the rc.button/reset file as this is a sperate patch not directly associated with this board port. 4. Update our base commit.
This ensures we do a clean so any driver changes are tested.
|
V2 of the RFC was just posted at http://lists.infradead.org/pipermail/lede-dev/2016-October/003536.html which is based on the repo in it's current state. |
This remoevs the AESNI ccm(AES) patch as it's not properly implemented, as well as adds kmod-usb-serial to the APU2 profile per request on the mailing list. Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
Lots of new changes * Move sp5100_tco patches to x86 * Enable the LED & GPIO driver within the kernel config * Remove the Modules for sp5100_tco and gpio-nct5104d * Add board detection code to gpio-nct5104d (needed as it's in the kernel config now) * Minor updates to leds-apu2 * Update build.sh to use latest revision
|
@CRCinAU I2C is a bit tricky on the APU2 due to it's implementation. Long story short, you will need to pick between having I2C, or having the SoC Watchdog driver (sp5100_tco). By default I will leave the Watchdog as the default option, but if you want to enable I2C the process is as follows:
This will then disable the hardware watchdog, and enable the i2c bus. Later down the line research can be done into adding watchdog support into the nct5104d driver, as this would give users an option to have a hardware watchdog and I2C at the same time. With that said, after doing the above steps the I2C interface shows up on my APU2: |
This applies the changes mentioned at https://github.com/DEvil0000 /linux-gpio-nct5104d/commit/b9d1be3812c2673703cfe4a6d287d27b47eb1acd to help fix support on 3.18+ kernels.
Now that this driver uses DMI to only run on PC Engine boards due to the way the driver is designed, we need to make sure this is mentioned in the help info for the driver.
|
Ok, interesting to know. I just finished the code for the Arduino to now drive the LEDs and call it from the i2c bus via: The fields are: I'll start packaging this up soon and publish the info on how to build. Its a very easy way to add an 8 LED RGB status indication system to the APU2 (or really any i2c capable device) |
This adds the igb spin lock patch to help prevent the panics reported when used with netdev as an LED trigger. We also update our base to the latest revision.
This moves our watchdog back to a kmod module so users can manually enable i2c if they prefer. We also update our LED driver to have the proper dependencies.
This was missed somehow. Needed for sp5100_tco
Just another small upstream while I wait on news from other patches currently in the mailinglist.
Update default config to enable CONFIG_LEDS_GPIO
|
This is kind of on hold ATM as I am waiting for a few of my previous ML submissions to get replies from upstream maintainers. Until then, there is no real reason to do the next RFC. |
Let's move LEDs to eth0/eth1, as not all users may have wireless cards and we should do our best to offer a great "OOB" experience.
|
@riptidewave93 which submissions in particular? would be nice to reference them here! |
|
@rotanid Sure thing, currently the two in waiting are: x86 also needs it's makefile remade in the new format, which I was assuming the maintainer would want to take care of. This was mentioned in the last RFC cover letter: http://lists.infradead.org/pipermail/lede-dev/2016-October/003536.html |
Fixup a typo in the LED script, and update the base revision for the repo.
|
@riptidewave93 maybe you have to bump the issues to get attention? |
|
@rotanid sadly I won't have time for another PR until after the holidays, so sadly I would not expect this to be in the first "official" release. |
|
PR for beep binary added to OpenWRT feeds at openwrt/packages#3833 |
Update our repo base & rebuild our kernel config from recent commits.
Without this, flashrom is unable to access the bootloader of the device.
It seems fstrim was removed from the OpenWRT feed and blkdiscard is available locally, so let's include it for users of SSDs. Note it needs to be ran manually.
This trashes the SSD, and minor update while we are at it.
Thanks to https://github.com/lede- project/source/commit/6e7fdf07b7134fddff0e0c9e24bd39d1ed4b4954, this is now changed from the actual config and not the kernel config for the target.
New kernel, new base. Also update modules file to match upstream.
|
More patches submitted upstream for review: |
This change adds the sp5100_tco driver as a kernel module for the x86 target. Specifically, this can be used by the PCEngines APU2/APU3. The reason for having this as a kernel module is to allow users to load/unload it on demand, as the I2C interface on the APU2/APU3 will not work while this module is loaded. More info can be found on GitHub at riptidewave93/LEDE-APU2#5 (comment) Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
Now that some of our patches are upstream, let's clean out old code that is no longer needed.
Signed-off-by: Florian Eckert <Eckert.Florian@googlemail.com>
Signed-off-by: Florian Eckert <Eckert.Florian@googlemail.com>
add gpio-nct5104d as kernel package
This moves us away from the old inline kernel patch method.
This moves leds-apu2 out of a kernel patch and to a kernel module. I can also confrim that the module still works to drop into failsafe mode, and does not impact usability.
This has been an issue when trying to submit a patch to LEDE in the past, so I guess I will maintain this. /shrug
This gets us up to the latest of everything, based on the recent upstream patches submitted for the GPIO/LED drivers.
Somehow this gained some spaces that were preventing merges upsream. This fixes that.
Now that our drivers have been merged upstream, remove them from this repo.
New kernel, new goodies, and more pains! :D
This change adds the sp5100_tco driver as a kernel module for the x86 target. Specifically, this can be used by the PCEngines APU2/APU3. The reason for having this as a kernel module is to allow users to load/unload it on demand, as the I2C interface on the APU2/APU3 will not work while this module is loaded. More info can be found on GitHub at riptidewave93/LEDE-APU2#5 (comment) Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
Remove the old igb patch as this should not be needed anymore, per the comments at https://github.com/riptidewave93/LEDE- APU2/issues/8#issuecomment-276812892
Minor changes to how network handles undetected boards.
Now that the "Core" parts are all merged up, we can remove targeted builds as the only addition we have left is the board profile. :)
This is a PR to track the progress of the RFCs and code changes made to get this working upstream. All changes in this branch/PR are from the feedback provided via the LEDE-Dev Mailing Lists for the APU2 RFC.