<Jookia>
apritzel: bunnie made that slide of fear vs known threats, and people are really scared about the extremely hard to implement attacks like hardware backdoors, chip doping, etc- but ignoring things like buggy boot ROMs
<apritzel>
yeah, I agree. To top this off: in contrast to Intel CPUs, to the best of my knowledge no one has actually demonstrated a successful Spectre/Meltdown attack on a vulnerable(!) Arm based CPU
mirko has quit [Remote host closed the connection]
mirko has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
montjoie has joined #linux-sunxi
montjoie_ has quit [Ping timeout: 480 seconds]
ftg has quit [Read error: Connection reset by peer]
hentai has joined #linux-sunxi
macromorgan has quit [Ping timeout: 480 seconds]
junari has joined #linux-sunxi
junari has quit [Remote host closed the connection]
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
<KREYREN_oftc>
> <apritzel> and I find it amazing that software people are always scared about CPU errata, when there are so many more bugs and vulnerabilities, with a much higher hit rate, lurking in software < I can fix software, but i can't fix CPU chipsets
<KREYREN_oftc>
> norton> KREYREN_oftc: https://0x0.st/Hde5.txt < Thanks! will be reading through it! ^-^
<KREYREN_oftc>
That looks really good I don't see anything that would be indicative of an issue which is great! ^-^ Once I figure out the kernel for Teres I will figure out a way to maintain these boards too bcs thats really cool
<KREYREN_oftc>
also more than likely enables better development of teres-2 as i can use OLIMEX's SOM standard with the A20 on it
KREYREN_oftc has quit [Remote host closed the connection]
JohnDoe_71Rus has joined #linux-sunxi
KREYREN_oftc has joined #linux-sunxi
apritzel has joined #linux-sunxi
warpme has joined #linux-sunxi
<KREYREN_oftc>
fraolt, do you have any issue/lore that is relevant to the anx6345 being broken on ~6.7.2+ ? i would like to document it
<fraolt>
My current understandig is, that the bug in 6.5 and 6.6 are two different bugs. diego71 tracked down the specific commit in 6.5 that broke the panel (see his post on the sunxi mailing list). The reason here is probably that pre-6.5 the SoC was able to closely fulfill the panels request for a specific rate (because tcon was using pll-video0-2x as it's parent). 6.5 only allowed pll-mipi as the parent and pll-mipi was probably not able to give
<fraolt>
the rate as closely as requested by the panel.
<fraolt>
In 6.6 I added support for pll-mipi to set a closer rate by a) overshooting and b) setting the parent rate.
<fraolt>
It seems that allowing to overshoot fixes the issues on teres-I but the fact that it can set the parent rate, breaks it.
<KREYREN_oftc>
6.7.4 reported broken by gentoo without the provided hotfix patch btw
<fraolt>
That's the only explanation I have for this weird behaviour. I'm currently at a loss, why setting the parent rate breaks it. As per your suggestion, I asked in the olimex forum if somebody can spare their teres-I. The post is under moderation.
<KREYREN_oftc>
fraolt, olimex post noted i try to ask some users who want to gift the device for development
<KREYREN_oftc>
fraolt, you said in the post that you are located in germany, are you by any chance close to any hackerspace?
<fraolt>
Yes, but I have no relationship with any.
<KREYREN_oftc>
i will likely be self-manufacturing few teres-1 boards soon for the teres-2 development, they should be identical in terms of components, but the wiring will be different (basically turning that design into a System On a Module) that i intent to distribute to hackerspaces
<KREYREN_oftc>
fraolt, can you DM me which one? i try to prioritize it
<maz>
apritzel: errr... yes, we have demonstrated it a while ago. full Meltdown was shown on partner silicon, including across VMs.
<maz>
and it is hardware you have access to (it's called mystery-roach for a reason).