[coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre

[Mike Banon]

Maybe I am very wrong here, but I just looked at this AtomBIOS disassembly
https://pastebin.com/raw/Q35JMU1b
and there are functions like "MemoryControllerInit / AdjustDisplayPll
/ AdjustMemoryController ", as well as data blocks like LVDS_Info

Could you please tell if it at least appears to be somehow useful for
the OSS implementation?

By the way, Damien Zammit wrote me that Alex (aka mrnuke) already did
95% of open source VGA init for G505S hardware:

https://www.coreboot.org/Board:hp/pavilion_m6_1035dx#Native_graphics_init
( ARUBA is GPU family to which A10-5750M 's HD 8650G belongs)

Wonder what are the remaining 5% ;-)

On Fri, Jan 12, 2018 at 1:16 PM, Nico Huber <nico.h at gmx.de> wrote:
> Hi,
>
> On 12.01.2018 10:51, Mike Banon wrote:
>> Hi Nico,
>>
>>>
>>> you seem to be misinformed about the G505s. There is no
>>> open-source gfx init for AMD (not in firmware, not in the OS),
>>> so within your requirements it's not usable as a laptop
>>>
>>
>> I've had a small discussion with bridgman from AMD (at Phoronix forums)
>> and he told me that VBIOS needed by G505S - aka "gfx init for AMD" -
>> - is "effectively open source" - a byte code which is possible to parse
>> with [AtomDis] open source interpreter
>
> well, the same holds for every program where an open-source emulator for
> its architecture exists. So thanks John Bridgman for open-sourcing the
> majority of programs in the world! lol...
>
>>
>> Only problem is that the last update of AtomDis was at 2011 - so, while it
>> should be able to parse 100% of G505S integrated / discrete GPUs AtomBIOSes
>> (because these GPUs were developed before 2011 if I am correct)
>> maybe AtomDis couldn't parse everything for the modern AMD GPUs
>
> I'm not interested in any disassembly.
>
> To my knowledge, there is no OSS implementation because it's not docu-
> mented what the AtomBIOS byte code does, i.e. how AMDs display engine
> works and is configured (I might be wrong, if so please tell me and I
> might start to write code for it soon). If that is true, it shows that
> there is no technically reason for keeping it under wraps but the de-
> cision not to document the hardware is pure political.
>
> Nico