Re: [coreboot] AM1ML IOMMU Support / Where has the wiki page gone?

[Marshall Dawson]

If my memory is correct, the Kabini parts had no IOMMU but their follow-ons
did (at least some).  I looked up the model number for the device in the
apu2 and it's a "Steppe Eagle".  Some would argue this is a Mullins for
Embedded, however it should have an IOMMU as has been reported.  If your
Biostar board is populated with a Kabini device (CPUID 8000_0001 EAX =
0070_0F01h), it can't work.  I'm not sure what families/models AMD put into
AM1 packages.  And it seems unlikely that the IOMMU would be defeatured in
the AM1 roadmap, but I'm not sure of that either.

Thanks,
Marshall


On Mon, Sep 19, 2016 at 1:08 AM, Martin Roth  wrote:

> The AM1ML page was created as just a single dot.  I have no clue why.
>
> https://www.coreboot.org/index.php?title=Board:biostar/
> am1ml=history
>
> Martin.
>
>
> On Sunday, September 18, 2016, taii...@gmx.com  wrote:
>
>> I recently purchased one of these boards after seeing articles about 
>> coreboot support on various sites, based on the bios manual I downloaded it 
>> appeared to support IOMMU virtualization although in reality it doesn't 
>> actually work (xen spits back IOMMU not present).
>> I emailed biostar and they replied stating that AMD says that IOMMU is not 
>> actually supported in the AM1 platform (despite AMD previously telling me 
>> that it is in fact supported) then they sent me an "updated" (with a lower 
>> version number) BIOS update file that they say removes the IOMMU option from 
>> the bios (I fail to understand why anyone would bother flashing this)
>>
>> I’m also curious if anyone knows happened to the AM1ML coreboot wiki page.
>> (Somebody replaced it with a single 
>> dot)https://www.coreboot.org/Board:biostar/am1ml
>> I have not tried flashing coreboot yet because this board runs my router so 
>> I don't desire to do a seat-of-my-pants install and then spend hours 
>> re-flashing and trying to figure out why it doesn't work.
>>
>> Does anyone know of a low power and recent/useful/has pci-e actually 
>> coreboot compatible board that supports IOMMU virt if this one doesn't?
>>
>>
>> "maggie:
>> Dear Sir,
>>
>> Thanks for using Biostar's product first of all!
>>
>> Regarding to your question,
>> AM1ML initial BIOS (AKBCT304.BSS : 2014-03-04) is based on AMD initial 
>> official specification to build in IOMMU function. However,we found IOMMU 
>> problem and report to AMD,AMD reply this function does not support and ask 
>> to remove.
>>
>> Here,we modify new attached BIOS (AKBCT301.BSS : 2016-03-01) to remove IOMMU 
>>  function. Sorry for any inconvenience."
>>
>>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] FYI: ACPI ASL 2.0

[Rudolf Marek]

Hi all,

Just FYI [1], maybe you already know.

There is an alternate syntax available for ACPI ASL sources.
It just converts Polish notation  of ASL to something less geeky like C
operators. It says that the tool to convert the sources is in development (to
ratain comments). I think it would make ACPI more readable if coreboot would
switch to ASL 2.0. Note that the change is only on syntax side! Latest ACPICA
iasl already decompiles to this syntax by default!

Example before:

  Method (SRDY, 0, Serialized)
{
Store (200, Local0) // Timeout 200ms
While (Local0) {
If (And(HSTS, 0x40)) {  // IN_USE?
Sleep(1)// Wait 1ms
Decrement(Local0)   // timeout--
If (LEqual(Local0, 0)) {
Return (1)
}
} Else {
Store (0, Local0)   // We're ready
}
}

Store (4000, Local0)// Timeout 200ms (50us * 4000)
While (Local0) {
If (And (HSTS, 0x01)) { // Host Busy?
Stall(50)   // Wait 50us
Decrement(Local0)   // timeout--
If (LEqual(Local0, 0)) {
KILL()
}
} Else {
Return (0)  // Success
}
}

Return (1)  // Failure
}


After:

Method (SRDY, 0, Serialized)
{
Local0 = 0xC8
While (Local0)
{
If (HSTS & 0x40)
{
Sleep (0x01)
Local0--
If (Local0 == 0x00)
{
Return (0x01)
}
}
Else
{
Local0 = 0x00
}
}

Local0 = 0x0FA0
While (Local0)
{
If (HSTS & 0x01)
{
Stall (0x32)
Local0--
If (Local0 == 0x00)
{
KILL ()
}
}
Else
{
Return (0x00)
}
}

Return (0x01)
}


Thanks
Rudolf


[1] https://acpica.org/sites/acpica/files/ASL2.0Overview.pdf


-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Experiments with disabling the ME on Sandybridge x230

[Trammell Hudson]

Zoran --

Thanks for your insights on the ME.  It's quite a messy bit of HW
and it makes no sense to me why Intel has it shrouded in such secrecy.
There is no reason that I can see for it to be undocumented.

> [...]
> Link to the very useful presentation (I clipped the above figure):
> http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub

Igor's 2012 presentation and 2014 update have been very helpful
as I have been poking at the ME, especially the layout of some of
the structs in the firmware partition table and partition headers.

As an update to my previous message, I've built an even more
reduced ME firmware that has removed a few modules from the FTPR
partition:

UPDATE, HOSTCOMM, RSA, CLS, TDT, ClsPriv and SESSMGR can be
replaced with 0xFF and the ME will still initialize the system
correctly.  This leaves only ROMP, BUP, KERNEL, POLICY
and FTCS.

>[...]
> Essentially, talking about ME, we are talking about the PCH's HW entity,
> which has the complete CPU inside itself, called ARC (32 bit, not sure if
> this is a RISC, high probability it is)

On Sandybridge/Ivybridge it is the ARC CPU, radare2 has a dissassembler
and the files can be decompressed with http://io.netgarage.org/me/

> [...] Something like this: ME partition gets
> downloaded to PCH, where it occupies small SRAM area, for the beginning.

There must be some amount of on-chip ROM as well, since the FTPR
code is Huffman compressed.  The decompressor also checks a signature
on the partition header, so we can't modify many of the fields in
the header.

> Then ME initializes Integrated Clock Controller (ICC). Then BIOS starts
> booting. BIOS thread of execution is the following (the best I could
> invision from the patchworks reachable to me):
> 
> [1] Initializes VGA (via PCIe port);
> 
> [2] Initializes Host Embedded Controller I/F init (via HECI PCIe port);
> 
> [3] Then BIOS/HECI initiates communication with ME/MEI;
> 
> [4] BIOS continues with DDRAMx MRC;
> 
> [5] Upon finishing MRC, BIOS/HECI communicates with ME/MEI;
> 
> [6] ME starts booting ARC 32bit Threadx RTOS kernel;
> 
> [7] ME reserves on the DDRx's TOM (Top Of Memory) 32MB UMA region solely
> for its own (application) use!

That matches my understanding as well, with the exception that the
UMA region appears to be configured immediately after MRC execution in
the BIOS.

> Coreboot, upon bringing up, does NOT know about HECI I/F (my best guess)
> and ME (and MEI).

I believe Coreboot does both HECI and MEI, depending on the chipset.
For the bd82x6x it uses MEI via PCIe.  If it didn't talk to the ME, the
UMA would never be configured and (I believe) the ME wouldn't make
any progress past its bring up.

That might also be an easy way to neutralize the ME; if it is never
given any resources, can we prevent it from doing anything bad?

> [...]
> Then, it is easy to imagine that FTPR is THE only ME component, which needs
> to be executed, since it is essentially part of INTERNAL ME init!

And I'm hoping that by removing the rest of the code that there is
nothing in the on-die ROM that has additoinal backdoors.  With the
network device driver and java bytecode interpreter gone, I also
hope that the ME can not be subverted by an outside party.

-- 
Trammell

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] fsp_baytrail smi_lock bit set

[John Fastabend]

Hi,

I'm using the fsp_baytrail (minnowboard-max) code base with the Intel
provided FSP Gold4 binary for the platform.

Everything boots fine but I was looking at the SMI/smm code paths and
wanted to trigger an SMI from an I/O port write. It appears this is
being disabled the GBL_SMI_EN bit is disabled and can not be set because
the SMI_LOCK bit is being set.

I read through some of the code and it looks like other platforms such
as skylake have explicit control over this bit and clear/set it in the
coreboot source code. Even the baytrail platform (sans fsp) seems to
set/clear it directly.

For fsp_baytrail I don't see any coreboot code setting the SMI_LOCK bit
at all and some tracing seems to indicate it is being set in the FSP
parts of the code.

So two questions,

 1) Is my reading of the fsp_baytrail code correct and the SMI_LOCK bit
is really being set by the FSP code paths.

 2) Anyone know how to _not_ set the bit either via coreboot change or
FSP configuration maybe via BCT?

Sorry if this is really an FSP question I didn't see any good FSP
mailing list to CC or just send its own mail to.

For reference the SMI_LOCK bit is in this register,

General PM Configuration 2 (GEN_PMCON2)—Offset 24h

at bit 4, and the GBL_SMI_EN is in this register,

SMI_EN - SMI Control and Enable (SMI_EN)—Offset 30h

at bit 0. I use the following code snippets to add debugging into the
coreboot code paths,

+   pmc = inl(PMC_BASE_ADDRESS + 0x24);
+   printk(BIOS_INFO, "SMI# : PMC: 0x08x\n", pmc)

to read the smi_lock bit and the following to read/set the smi_enable
bit which fails due to the above bit being set,

+   outl(smi_en | 0x1, get_pmbase() + SMI_EN);
+   smi_en = inl(get_pmbase() + SMI_EN);
+   printk(BIOS_INFO, "post write SMI# : 0x08x\n", smi_en);

Any hints, help, comments would be appreciated at the moment I'm just
sort of scanning the FSP spec to try and glean something useful.

Thanks,
John

-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] AM1ML IOMMU Support / Where has the wiki page gone?

[Martin Roth]

The AM1ML page was created as just a single dot.  I have no clue why.

https://www.coreboot.org/index.php?title=Board:biostar/am1ml=history

Martin.

On Sunday, September 18, 2016, taii...@gmx.com  wrote:

> I recently purchased one of these boards after seeing articles about coreboot 
> support on various sites, based on the bios manual I downloaded it appeared 
> to support IOMMU virtualization although in reality it doesn't actually work 
> (xen spits back IOMMU not present).
> I emailed biostar and they replied stating that AMD says that IOMMU is not 
> actually supported in the AM1 platform (despite AMD previously telling me 
> that it is in fact supported) then they sent me an "updated" (with a lower 
> version number) BIOS update file that they say removes the IOMMU option from 
> the bios (I fail to understand why anyone would bother flashing this)
>
> I’m also curious if anyone knows happened to the AM1ML coreboot wiki page.
> (Somebody replaced it with a single 
> dot)https://www.coreboot.org/Board:biostar/am1ml
> I have not tried flashing coreboot yet because this board runs my router so I 
> don't desire to do a seat-of-my-pants install and then spend hours 
> re-flashing and trying to figure out why it doesn't work.
>
> Does anyone know of a low power and recent/useful/has pci-e actually coreboot 
> compatible board that supports IOMMU virt if this one doesn't?
>
>
> "maggie:
> Dear Sir,
>
> Thanks for using Biostar's product first of all!
>
> Regarding to your question,
> AM1ML initial BIOS (AKBCT304.BSS : 2014-03-04) is based on AMD initial 
> official specification to build in IOMMU function. However,we found IOMMU 
> problem and report to AMD,AMD reply this function does not support and ask to 
> remove.
>
> Here,we modify new attached BIOS (AKBCT301.BSS : 2016-03-01) to remove IOMMU  
> function. Sorry for any inconvenience."
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] AM1ML IOMMU Support / Where has the wiki page gone?

[ge...@riseup.net]

Hi,

On 16-09-19 01:26:36, taii...@gmx.com wrote:
> Does anyone know of a low power and recent/useful/has pci-e actually
> coreboot compatible board that supports IOMMU virt if this one
> doesn't?

Have a look at the quite recent apu2d platform [1] made by PC Engines.
It comes out of the box with coreboot, and according to this forum
thread [2], it's possible to get IOMMU working.

All the best,
Georg


[1] http://www.pcengines.ch/apu2.htm
[2] 
http://www.pcengines.info/forums/?page=post=77FF51E3-8ACA-4B79-BD2C-1380B9B48B5D=DF5ACB70-99C4-4C61-AFA6-4C0E0DB05B2A=bypass=1


signature.asc
Description: Digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot