There is another intel ucode generator in Archlinux repo, it seems the
code is more elegant and don't require additional dependency. Do you
have any idea?
https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/intel-ucode
Best Regards,
Syrone Wong
On Thu, Jan 18, 2018 at 3:41 AM
On January 17, 2018 11:41:01 AM PST, Zoltan HERPAI wrote:
>Hi,
>
>This series will add support for microcode update on x86 targets,
>in light of the recent security issues.
>
>While other distributions use an early initramfs approach to update
>the microcode as early as possible, in OpenWrt the e
On January 17, 2018 6:06:54 PM PST, "Denis Periša" wrote:
>Hi all,
>
>I've searched three days in a row and I cannot find any more info on
>software cable tester for linux/openwrt.
>
>Many my devices support this feature as in original firmware (Mikrotik
>for example) I can see cable pairs and whi
Hi all,
I've searched three days in a row and I cannot find any more info on
software cable tester for linux/openwrt.
Many my devices support this feature as in original firmware (Mikrotik
for example) I can see cable pairs and which cable wire is not
connected and such. Even length of the cable.
On Wed, Jan 17, 2018 at 4:28 AM, Thomas Reifferscheid
wrote:
> Hi, I've lost my original uboot environment settings and would like to ask
> for your help.
> Since it's been a while from when I was playing with the hardware the uboot
> env is all messed up and I'd like to start over from scratch.
>
Am 16.01.2018 um 21:07 schrieb e9hack:
> Hi Christian,
>
> I revert all ddns related changes. It looks like that the changes are not the
> root cause. I check my old log files. The
> issue did start with my build from 16th of December.
>
> Independently of this, I'm the opinion, ddns for ipv6
- update microcodes for various CPUs
- Implements IBRS/IBPB support and enhances LFENCE: mitigation
against Spectre (CVE-2017-5715)
- downgrade microcodes for two platforms, due to reasons unknown
from Intel
Signed-off-by: Zoltan HERPAI
---
package/firmware/intel-microcode/Makefile | 4
Compiling the Intel microcode package results in a
microcode.bin and a microcode-64.bin. As we can
decide based on the subtarget which should be used,
we'll only split the required .bin file with
iucode-tool.
Instead of using the large microcode.bin/microcode-64.bin, the
splitted ucode files (sepa
Hi,
This series will add support for microcode update on x86 targets,
in light of the recent security issues.
While other distributions use an early initramfs approach to update
the microcode as early as possible, in OpenWrt the earliest place
where we can do this is preinit.
The Intel microcod
Enable for 4.9 and 4.14.
Signed-off-by: Zoltan HERPAI
---
target/linux/x86/config-4.14 | 5 -
target/linux/x86/config-4.9 | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/target/linux/x86/config-4.14 b/target/linux/x86/config-4.14
index b88fa77..9ea0d90 100644
--- a
Add tool to "compile" Intel microcode files. The tool will be
compiled for host (to split the microcode.dat) and for target
(to forcibly reload the microcode or scan the system if required).
Signed-off-by: Zoltan HERPAI
---
package/system/iucode-tool/Makefile | 47 +++
Signed-off-by: Zoltan HERPAI
---
package/firmware/linux-firmware/x86.mk | 9 +
1 file changed, 9 insertions(+)
create mode 100644 package/firmware/linux-firmware/x86.mk
diff --git a/package/firmware/linux-firmware/x86.mk
b/package/firmware/linux-firmware/x86.mk
new file mode 100644
ind
Hi Rafal,
On Wed, Jan 17, 2018 at 04:25:10PM +0100, Rafał Miłecki wrote:
> Getting better network performance (mostly for NAT) using some kind of
> acceleration was always a hot topic and people are still
> looking/asking for it. I'd like to write a short summary and share my
> understanding of cu
On 17 January 2018 at 16:25, Rafał Miłecki wrote:
> The problem with all existing implementations was they used various
> non-upstream patches for kernel integration. Some were less invasive,
> some a bit more. They weren't properly reviewed by kernel developers
> and usually were using hacks/solu
Getting better network performance (mostly for NAT) using some kind of
acceleration was always a hot topic and people are still
looking/asking for it. I'd like to write a short summary and share my
understanding of current state so that:
1) People can undesrtand it better
2) We can have some rough
Specification:
- SoC: Atheros AR9342
- Flash: 8 MiB
- RAM: 64 MiB
- UART: 1x UART on PCB - 115200 8N1
- Ethernet: 1 x 100 Mbit with passive PoE (24V/0.2A)
Doesn't work:
* Flash via TFTP with Uiquiti Uboot
Installation via vendor firmware:
- upload factory image via webinterface
Signed-off-by: Ar
Signed-off-by: Arne Zachlod
---
target/linux/ar71xx/base-files/etc/board.d/01_leds | 236 ++---
.../ar71xx/base-files/etc/board.d/03_gpio_switches | 12 +-
target/linux/ar71xx/base-files/etc/diag.sh | 40 ++--
3 files changed, 144 insertions(+), 144 deletions(-)
diff --
Shows how long an initd task took, for example:
procd: stop /etc/init.d/dropbear running - took 0.088824s
procd: Update service dnsmasq
procd: Update instance dnsmasq::dnsmasq
procd: running /etc/init.d/dnsmasq running
procd: start /etc/init.d/dnsmasq running
procd: stop /etc/init.d/dnsmasq
Hi, I've lost my original uboot environment settings and would like to
ask for your help.
Since it's been a while from when I was playing with the hardware the
uboot env is all messed up and I'd like to start over from scratch.
Would someone please send me "env print" from within the bootloader
On 2018-01-17 11:11, Karl Vogel wrote:
John Crispin writes:
On 17/01/18 10:54, Koen Vandeputte wrote:
On 2018-01-17 10:43, Karl Vogel wrote:
Shows how long an initd task took, for example:
procd: stop /etc/init.d/dropbear running - took 0.088824s
procd: Update service dnsmasq
procd
John Crispin writes:
> On 17/01/18 10:54, Koen Vandeputte wrote:
>>
>>
>> On 2018-01-17 10:43, Karl Vogel wrote:
>>> Shows how long an initd task took, for example:
>>>
>>> procd: stop /etc/init.d/dropbear running - took 0.088824s
>>> procd: Update service dnsmasq
>>> procd: Update instance d
Hello Arne,
Minor thing inline, below.
On 16.01.2018 21:43, Arne Zachlod wrote:
[...]
+lbe-m5)
+ ucidef_set_led_netdev "lan" "LAN" "ubnt:green:lan" "eth0"
+ ucidef_set_led_wlan "wlan" "WLAN" "ubnt:green:wlan" "phy0tpt"
+ ucidef_set_led_default "sys" "SYS" "ubnt:green:sys" "1
On 17/01/18 10:54, Koen Vandeputte wrote:
On 2018-01-17 10:43, Karl Vogel wrote:
Shows how long an initd task took, for example:
procd: stop /etc/init.d/dropbear running - took 0.088824s
procd: Update service dnsmasq
procd: Update instance dnsmasq::dnsmasq
procd: running /etc/init.d
On 17/01/18 10:44, Arjen de Korte wrote:
Citeren John Crispin :
On 07/01/18 18:08, Christian Beier wrote:
The existing read functionality feeds the complete JSON to jshn as a
cmdline argument, leading to `-ash: jshn: Argument list too long`
errors for JSONs bigger than ca. 100KB.
This commi
On 2018-01-17 10:43, Karl Vogel wrote:
Shows how long an initd task took, for example:
procd: stop /etc/init.d/dropbear running - took 0.088824s
procd: Update service dnsmasq
procd: Update instance dnsmasq::dnsmasq
procd: running /etc/init.d/dnsmasq running
procd: start /etc/init.d/d
Citeren John Crispin :
On 07/01/18 18:08, Christian Beier wrote:
The existing read functionality feeds the complete JSON to jshn as a
cmdline argument, leading to `-ash: jshn: Argument list too long`
errors for JSONs bigger than ca. 100KB.
This commit adds the ability to read the JSON directly
Shows how long an initd task took, for example:
procd: stop /etc/init.d/dropbear running - took 0.088824s
procd: Update service dnsmasq
procd: Update instance dnsmasq::dnsmasq
procd: running /etc/init.d/dnsmasq running
procd: start /etc/init.d/dnsmasq running
procd: stop /etc/init.d/dnsmasq
Hi John,
I ordered the device between the already existing bullet and the
rocket-ti. To me this looks like the order already in place and the
right spot because it is alphabetical for the manufacturer. In case that
this is not the right thing to do maybe we should refactor the whole
file, because
Hi
merged the first 8 patches, please rework this to additionally fold the
irq imbalance patch into the files/... dir
John
On 11/01/18 16:04, Koen Vandeputte wrote:
Signed-off-by: Koen Vandeputte
---
target/linux/cns3xxx/config-4.9| 300 -
...
On 07/01/18 18:08, Christian Beier wrote:
The existing read functionality feeds the complete JSON to jshn as a
cmdline argument, leading to `-ash: jshn: Argument list too long`
errors for JSONs bigger than ca. 100KB.
This commit adds the ability to read the JSON directly from a file if
wanted,
On 16/01/18 20:34, Stefan Lippers-Hollmann wrote:
Hi
On 2018-01-11, Rafał Miłecki wrote:
From: Rafał Miłecki
This solution is more upstream compatible as it only requires specifying
of_match_table in the parser code and doesn't depend on linux,part-probe
which is solution made generic by a
On 16/01/18 21:43, Arne Zachlod wrote:
Specification:
- SoC: Atheros AR9342
- Flash: 8 MiB
- RAM: 64 MiB
- UART: 1x UART on PCB - 115200 8N1
- Ethernet: 1 x 100 Mbit with passive PoE (24V/0.2A)
Doesn't work:
* Flash via TFTP with Uiquiti Uboot
Installation via vendor firmware:
- upload factor
On 16/01/18 10:49, Karl Vogel wrote:
Shows how long an initd task took, for example:
procd: stop /etc/init.d/dropbear running - took 0.088824 us
procd: Update service dnsmasq
procd: Update instance dnsmasq::dnsmasq
procd: running /etc/init.d/dnsmasq running
procd: start /etc/init.d/d
33 matches
Mail list logo
