The Lex 3I380NX industrial PC has 4 ethernet controllers on board
which need pmc_plt_clk0 - 3 to function, add it to the critclk_systems
DMI table, so that drivers/clk/x86/clk-pmc-atom.c will mark the clocks
as CLK_CRITICAL and they will not get turned off.
This commit is nearly redundant to 3d0818f5eba8 ("platform/x86:
pmc_atom: Add Lex 3I380D industrial PC to critclk_systems DMI table")
but for all Lex Baytrail devices.
The original vendor firmware is only available using the WaybackMachine:
http://www.lex.com.tw/products/3I380NX.html
Signed-off-by: Michael Schöne <michael.schoene@rhebo.com>
Signed-off-by: Paul Spooren <paul.spooren@rhebo.com>
(Hans broader version for more Lex Baytrail systems, v5.15)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Chen Minqiang reported in his GitHub PR #4733 that:
With CONFIG_TARGET_INITRAMFS_COMPRESSION_LZMA=y option set,
the popular x86/amd64 target's initramfs-kernel failed to boot.
The cause for this boot failure is that the LZMA compression
uses a the first bytes to encode the compression parameters.
It does not have a fixed magic. Yes, this only works if the
the existing lzma options in the upstream are not changed.
This patch does away with OpenWrt special LZMA options tuning
since it is rather unlikely that upstream will improve the
compression algorithm detection after all this time. Even
though, the tuning produced a smaller initramfs (~1.1% in a
spot check).
Link: <https://github.com/openwrt/openwrt/pull/4733>
Reported-by: Chen Minqiang <ptpt52@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
This commit will add support for the Meraki MX100 in OpenWRT.
Specs:
* CPU: Intel Xeon E3-1200 Series 1.5GHz 2C/4T
* Memory: 4GB DDR3 1600 ECC
* Storage: 1GB USB NAND, 1TB SATA HDD
* Wireless: None
* Wired: 10x 1Gb RJ45, 2x 1Gb SFP
UART:
The UART header is named CONN11 and is found in the
center of the mainboard. The pinout from Pin 1 (marked
with a black triangle) to pin 4 is below:
Pin 1: VCC
Pin 2: TX
Pin 3: RX
Pin 4: GND
Note that VCC is not required for UART on this device.
Booting:
1. Flash/burn one of the images from this repo to a
flash drive.
2. Take the top off the MX100, and unplug the SATA
cable from the HDD.
3. Hook up UART to the MX100, plug in the USB drive,
and then power up the device.
4. At the BIOS prompt, quickly press F7 and then
scroll to the Save & Exit tab.
5. Scroll down to Boot Override, and select the
UEFI entry for your jumpdrive.
Note: UEFI booting will fail if the SATA cable for
the HDD is plugged in.
The issue is explained under the Flashing instructions.
Flashing:
1. Ensure the MX100 is powered down, and not plugged
into power.
2. Take the top off the MX100, and unplug the SATA
cable from the HDD.
3. Using the Mini USB female port found by the SATA
port on the motherboard,
flash one of the images to the system. Example:
`dd if=image of=/dev/sdb conv=fdatasync` where sdb
is the USB device for the MX100's NAND.
4. Unplug the Mini USB, hook up UART to the MX100,
and then power up the device.
5. At the BIOS prompt, quickly press F7 and then
scroll to the Boot tab.
6. Change the boot order and set UEFI: USB DISK 2.0
as first, and USB DISK 2.0 as second.
Disable the other boot options.
7. Go to Save & Exit, and then select Save Changes and
Reset
Note that OpenWRT will fail to boot in UEFI mode when
the SATA hard drive is plugged in. To fix this, boot
with the SATA disk unplugged and then run the following
command:
`sed -i "s|hd0,gpt1|hd1,gpt1|g" boot/grub/grub.cfg`
Once the above is ran, OpenWRT will boot when the HDD
is plugged into SATA. The reason this happens is the
UEFI implementation for the MX100 will always set
anything on SATA to HD0 instead of the onboard USB
storage, so we have to accomidate it since OpenWRT's
GRUB does not support detecting a boot disk via UUID.
Signed-off-by: Chris Blake <chrisrblake93@gmail.com>
This patch really annoys me, either it needs to go upstream or be
dropped, so it's going to be dropped here.
Checking drivers/platform/x86/pcengines-apuv2.c it also appears to be
incomplete since it mentions different dmi board names depending on bios
version.
/* APU2 w/ legacy BIOS < 4.0.8 */ is 'APU2'
/* APU2 w/ legacy BIOS >= 4.0.8 */ is 'apu2'
/* APU2 w/ mainline BIOS */ is 'PC Engines apu2'
So the patch, if applicable at all, only 'works' for legacy BIOS >=
4.0.8
My APU2 on mainline BIOS reboots fine without this patch. So let's see
if anyone screams and when they do question why legacy bios. If patch
DOES need to be re-introduced then it needs to go upstream first.
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Straightforward refresh of patches using update_kernel.
Run tested: x86_64 (apu2)
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Add linux 5.10 as testing kernel, copy generic/subtarget configs and target
patches from 5.4.
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
x86: update target patches for kernel 5.10
Refresh all patches while also dropping:
800-hwmon-w83627ehf-dont-claim-nct677x.patch
which is now upstreamed as:
3207408ab4cb ("hwmon: (w83627ehf) remove nct6775 and nct6776 support")
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
x86: refresh 5.10 target config
Refresh config using "make kernel_oldconfig".
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
x86: refresh and test all subtarget configs
Refresh configs using "make kernel_oldconfig CONFIG_TARGET=subtarget".
Build and run-tested using QEMU: x86/64, x86/legacy, x86/generic.
Build-tested only: x86/geode.
Signed-off-by: Tony Ambardar <itugrok@yahoo.com>
[squashed commits]
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
