[coreboot] Re: Baytrail issue to communicate with superios.

[Rudolf Marek]

Hi Jose,

Dne 05. 12. 23 v 11:06 Jose Trujillo via coreboot napsal(a):

Good day Rudolf/All,


OK so it does work.


Yesterday I copy/pasted the subroutine and its definitions used to enable 
SERIRQ and set the mode (sc_enable_serial_irqs) and now I can see serial output 
but no input on ttyS0.


Are you sure you got it right in minicom on both sides? For example, you could 
have a hardware flow control set, which would cause data not to be 
send/delivered. Second problem would be if you have /dev/ttyS0 device opened 
multiple times, you will receive data to the random ends...

Do you see in cat /proc/interrupts IRQ 3 or IRQ 4 increasing when you try to 
send and/or receive data (depends on what UART do you use)

Alternatively you can do isadump -f 0x3f0 16 and check offset 0x3f8 to see if 
your data was received by the UART but no interrupt was raised.

I'm unsure with isadump syntax, but you get the idea...

If there are other UARTs in the system how they are configured? Do they work if 
there are connected to something?
The w83627dhg also supports UARTs. Are they present on your system, how they 
are configured? Is there some potential collision?

I don't have baytrail datasheet. If it has uarts as well how they are 
connected? Like PCI device? Or somehow those can be living on IRQ4/IRQ3 as well?


At this point I am trying to understand what you already told me:


The dumps from yesterday from Fintek SIO, confirms that your fintek UARTS have 
the standard settings,

60: 03 f8 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
70: 04 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
 

[2.207098] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 
16550A
[2.208096] 00:06: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 
16550A


Which is fine. However maybe the IRQ is wrongly shared with other UARTS?


1.- To dump ELCR (I/O port register 0x4d0) to check if it is correctly 
programmed to EDGE


This is done by Linux, you can likely check it with
isadump -f 0x4d0 16

But It may freeze your machine if the ACPI C2 register is nearby.


2.- To do some PNP device in ACPI to let linux infer the IRQ.


I think standard uarts on well known addresses should be discovered even  
without ACPI


3.- To try to disable the IRQ from SoC internal UART.


Aha so there is more and not only that Winbond.


For #1 the question is which linux command I can use to dump ELCR registers to 
check if misconfigured?


isadump -f 0x4d0 16


For #2 the question is if the linux command "dmesg | grep 'tty'" output which 
shows the irq set on coreboot devicetree is still not evidence that linux is aware of the 
port IRQs?

[2.207098] 00:05: ttyS0 at I/O 0x3f8 (irq = 4, base_baud = 115200) is a 
16550A
[2.208096] 00:06: ttyS1 at I/O 0x2f8 (irq = 3, base_baud = 115200) is a 
16550A


This shows that linux is fine with that UARTs.


I am including fintek's superio.asl which tell linux the resources of this 
device.
May be I still dont understand #2 or there is something else.

For #3 is straightforward for me and I am working on it.


OK please check Winbond chip as well.


I am aware of this and I have been concerned on this issue for a while, but, I 
think I need to try to make this system functional and suggest the target user 
not to use this feature.


OK please use continuous mode for now, because I think it needs to first be in this mode 
before switching to "quiet".
Maybe there is some issue with CLKRUN. Try to disable this feature somehow as 
well and/or make sure Fintek side is
configured properly as well.

Maybe you can try to do infinite loop to keep the chip busy and see if your 
serial input works. If yes, I would assume it
is likely CLKRUN.

while true; do sudo isadump -y -k 0x87,0x87 0x4e 0x4f 1 ; done

Sorry so this is probably all I can think of to debug this issue.

Thanks,
Rudolf

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Baytrail issue to communicate with superios.

[Rudolf Marek]

Hi Jose,

Dne 04. 12. 23 v 10:48 Jose Trujillo via coreboot napsal(a):

Printed "B" on the other side of the RS-232 cable on the ttyS0 port.


OK so it does work.


Do you know if is possible to enable SERIRQ and set SCNT_CONTINUOUS in the 
actual baytrail code?


Well sorry I don't know. It has been long time I did something with coreboot. What I do 
recall is that those Baytrail and later Apollo lake intel atom CPUs have some issue and 
setting LPC to the "continous" will shorten some life of the transistor driving 
the LPC bus, thus the system will malfunction sooner than later.


SERIRQ code was supported in fsp_baytrail but not in baytrail, but now, maybe is 
supported indirectly in "common" code?


Sorry don't know.

Thanks,
Rudolf



Thanks again,
Jose Trujillo.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Baytrail issue to communicate with superios.

[Rudolf Marek]

Hi,

Dne 01. 12. 23 v 16:04 Jose Trujillo via coreboot napsal(a):

Using "superiotool" to scan for SIO devices finds Winbond W83627DHG and dumped 
all its registries but doesn't show Fintek f81803 because of lack of support, so, data 
exchange between the processor and the SIO chips via LPC port seems to be fine, maybe 
just need to fix the interrupt issues.


Sorry I don't know much about your particular system. Can you get coreboot 
serial console on your fintek superio?
If yes, then likely something is wrong with interrupts.

You can use isadump to try to obtain UART1 and UART2 configurations (LDN 1 / 
LDN 2)

isadump -k 0x87,0x87 0x4e 0x4f 1
isadump -k 0x87,0x87 0x4e 0x4f 2

Says what?

You can also try to setup UART in linux as if those were working, like setting 
up baudrate / minicom
but then doing:

isaset -f 0x3f8 0x42

Should print "B" on the other side on COM1 (check address where your fintek 
uart is)

Thanks,
Rudolf
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot Machine-Check Exception

[Rudolf Marek]

Hi,

On 09. 01. 23 6:09, Ahmet Fenerci via coreboot wrote:


Lastly, I checked the "Intel® 64 and IA-32 Architectures Software Developer’s Manual 
Volume 4: Model-Specific Registers" to solve problem, but I couldn't find the source 
of the problem. I have a few questions ;


You need to modify the machine check handler routine to print the machine check 
bank registers which are described in the volume 4, and then decode the numbers.
Every CPU model has different amount of register banks. You will likely need to 
patch the handler to print it in there, or use some kind of hardware debugger.


1- What is the source of the machine-check exception problem and why does it 
happen occasionally?


Basically  machine check means that something seriously went wrong. Possible 
causes:

1) ECC memory errors/misconfigured memory setup
2) PCI resource allocation problem (e.g. something overlaping I/O apic area)
3) CPU erratum - I remember some CPU suffer from fake machine check exception
4) system memory map wrong?


2- As seen in the MC Exception error content in the given google drive link ( 
Unexpected Exception:18 @ 10:7f998256 ) , at here ;18 indicates to 
Machine-Check Exception. What does 10 indicate here? ( 7f998256 is an address 
at Ramstage)


10 would be the selector value of CS.


3- 0xdeadbeef errors are seen at some addresses of ramstage, what is the reason?


This is probably just a stackguard. What is interesting is that your 
machinecheck happens while SeaBIOS is already running and also somehow
it seems that it then tries to boot the openbsd.

I think SeaBIOS changes the IDT table so only possible explanation is that the 
machinecheck happens somehow during SMM mode.

Again, sorry I don't know more because I did not work on coreboot for very long 
time.

Thanks,
Rudolf








___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Stuck on SB clock to SIO.

[Rudolf Marek]

Hi,

On 07. 10. 22 22:16, Pedro Erencia wrote:

Hi everyone.


I'm a bit stuck on this.
As I've said before in other emails here, I'm trying to bring up an AsRock 
FM2A88X+ with coreboot. I've used as a model the code for the a88xm-e and 
accomplished my first goal, which was to have a working UART, but I need to 
boot with the original AMI BIOS first (first boot after mechanical off) for it 
to work.


What SIO chip you have? Is it different? Do you have SIO datasheet? Maybe it is 
strapped to something else than 48MHz input. Like you are outputing clocks from 
chipset and at the same time you are outputting something from SIO. That would 
explain you don't see it.

I would suggest to have a look to all SIO registers (especially those which are 
powered on through 5V standby) and including undocumented bits of that SIO 
registers.

You can also try to have a look to early SEC stage of original BIOS to see what 
it is doing early.

Thanks,
Rudolf





The problem seems to be the 48 MHz clock that SB feeds to the SIO. Coreboot's 
a88xm-e code has the code to configure it early, in sbxxx_enable_48mhzout, and 
so have I, but I've checked it with an oscilloscope and there's no clock there,


So I turned to the docs. Regarding that clock, we can read,


"The USBCK/14M_25M_48M_OSC pin (G8) as well as the 14M_25M_48M_OSC pin (J26) 
output a 14.318MHz clock on
the first power up if the internal system clock generator mode strap is 
selected. [1]


14M_25M_48M_OSC is the pin we are interested in. From what I see on the 
boardfile, the strap is configured as internal system clock.


Later,


"The output will generate 12.5 MHz on power up after the FCH PWR_GOOD is 
asserted.
The output frequency will be 12.5 MHz until the internal PLL is initialized 
after which time
the output will switch to 14.318 MHz clock." [2]


So, it seems that, after the FCH PWR_GOOD and *without any firmware 
intervention*, we should get 12.5 MHz on that pin. I've checked it with the 
original AMI BIOS and that's correct, ~150 ms after the assertion of PWR_GOOD 
we get the 12.5 MHz clock. On the other hand, with my coreboot image, FCH 
PWR_GOOD is asserted, but there is no clock.


 From what I said, I deduce that the AMI BIOS must be doing something that I do 
not, but, as I understand the databook, the 12.5 MHz should be *automatic* 
after a PWR_GOOD.


Maybe someone with more experience with AMD chipsets could help me here, 
especially considering that we have a working image with the same chipset.


I'd appreciate any hints or advice about how to proceed.


[1] Bolton Databook 
(https://www.amd.com/system/files/TechDocs/Bolton_D2-D2H-D3-D4_Databook.pdf 
), 
Chapter 4, Table 13
[2] Bolton Databook, Chapter 6, Table 52

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Invalid opcode exception(06) while loading network drivers in CamelBack Mountain CRB (Coreboot-4.11 + Uefipayload)

[Rudolf Marek]

Hi,

On 27. 08. 22 11:31, Noyal Johnson wrote:

Hi,
 X64 Exception Type - 06 (#UD - Invalid Opcode)

CPU Apic ID -  

!!! Cant find image information !!!


Do you know what kind of instruction it is? Probably dumping "RIP" + some bytes 
around
and then decoding it would help.

I suspect probably your compiler emits something not quite enabled. Typical 
problems in some other projects was that GCC emited some SSE instruction for 
memcpy().
This might not be enabled in coreboot startup (sorry, don't know it is long 
time ago I looked). The UEFI itself has some ABI which mandates what should be 
enabled (FPU unit for example).

Also, make sure you use right GCC to compile everything. Maybe the defaults for 
your compiler are not sane.

Thanks,
Rudolf





I tried loading Uefipayload in which network stack drivers are merged at 
compile time, still the result was same.


But, when I tried loading the network stack drivers compiled in same edk2 tool 
and network controller driver in the actual BIOS present in CRB, all the 
network stack drivers was successfully loaded and ethernet was initilized.


I am suspecting that network stack driver / controller driver is trying to 
execute a particular instruction which is not supported in coreboot. Whether 
any instruction sets I have to separately enable in coreboot. If no, what could 
be the reason for this exception.


Regards,

Noyal Johnson

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: 2022-03-29 - coreboot UEFI working group meeting minutes

[Rudolf Marek]

Hi,

On 19. 04. 22 11:42, Arthur Heymans wrote:

Nice catch!
Regardless of the upshot of this it's worth fixing this problem in the coreboot 
tables implementation.
I'm not very knowledgeable on the topic but don't a lot of CPU ARCH support 
unaligned pointer access in hardware but it slows things down?


Yes a bit. But mostly for SIMD instructions.


The way you find coreboot table structs is by looping over ->size, since 
payloads may not know
some tags. So aligning the size up to 8 bytes when generating the coreboot 
tables should do the trick.


Yes and no. Problem is if you have following layout in your struct:

u32 x
u64 y

On 64-bit you will get "space" in the middle of your struct.

u32 x
u32 hidden_padding
u64 y (aligned to 8 byte boundary)

and on 32-bit you will get:

u32 x
u64 y (aligned to 4 byte boundary)

And similar thing happens at the end of the struct where extra padding is 
inserted, but the size depends on the actual ABI/Architecture.
Linux uses other ABI than UEFI for example. You can play with that using gcc. 
Just add -Wpadded to your
compiler flags.

The problem above exactly happens with coreboot memory entries (when there is 
more then one). See libpayload/include/coreboot_tables.h
which introduces for this reason struct cbuint64 which is 64-bit datatype split 
to 2 32-bit parts to fix this oversight.

Have a look what multiboot2 folks did. In general multiboot2 [1] got this 
"right". It aligns the start of the entries and I think there are no such 
issues. Also it defines the machine state at the point of handoff which is nice. Also, it 
has some infrastructure to pass various strange future memory lists in the memory tag.


Thanks,
Rudolf

[1] https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html



Kind regards
Arthur


On Tue, Apr 19, 2022 at 10:44 AM Rudolf Marek mailto:r.ma...@assembler.cz>> wrote:

Dne 12. 04. 22 v 0:04 Peter Stuge napsal(a):
 > I propose that coreboot tables are a good alternative - fight me! :)

Challenge accepted. They aren't because they are defined with ABI/compiler:

- 64-bit data type alignment is different in 32-bit ABI (4 bytes) and 
different
in 64-bit ABI (8 bytes). Not even sure how the other ABIs got this.

- CB structures like framebuffer struct are not padded to the size compiler 
likes.

   The "packed" attribute would be bit dangerous because then compiler might
complain like "error: taking address of packed member of 'struct 
cb_framebuffer'
may result in an unaligned pointer value [-Werror=address-of-packed-member]"

Alternatively one could add "pad[2]" member to the end to the fb structure 
to
fix this, but maybe this will break some payloads which don't check the 
->size
of specific tag...

Anyway, hope this illustrates the problem a bit.

Thanks,
Rudolf

___
coreboot mailing list -- coreboot@coreboot.org 
<mailto:coreboot@coreboot.org>
To unsubscribe send an email to coreboot-le...@coreboot.org 
<mailto:coreboot-le...@coreboot.org>


___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: 2022-03-29 - coreboot UEFI working group meeting minutes

[Rudolf Marek]

Dne 12. 04. 22 v 0:04 Peter Stuge napsal(a):

I propose that coreboot tables are a good alternative - fight me! :)


Challenge accepted. They aren't because they are defined with ABI/compiler:

- 64-bit data type alignment is different in 32-bit ABI (4 bytes) and different 
in 64-bit ABI (8 bytes). Not even sure how the other ABIs got this.


- CB structures like framebuffer struct are not padded to the size compiler 
likes.

 The "packed" attribute would be bit dangerous because then compiler might
complain like "error: taking address of packed member of 'struct cb_framebuffer' 
may result in an unaligned pointer value [-Werror=address-of-packed-member]"


Alternatively one could add "pad[2]" member to the end to the fb structure to 
fix this, but maybe this will break some payloads which don't check the ->size

of specific tag...

Anyway, hope this illustrates the problem a bit.

Thanks,
Rudolf

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: 2022-03-01 - coreboot UEFI working group meeting minutes

[Rudolf Marek]

Hi,

On 01. 03. 22 20:21, coreboot org wrote:

 * [Nate] Might need to save the efi memory map so that data isn’t
lost when converting to an e820 memory map and back. Linux may rely on
GRUB doing that - so look into GRUB.


Looks like the the superset of various memory region types is defined in ACPI 
spec,
see [1] And especially nice mapping table here [2]. Probably you can also 
consult multiboot2 [3]
to see what is defined in there. Look for ( MULTIBOOT_MEMORY_)  But, I suspect 
the broadest range is still [1].


* [Daniel] Trammell Hudson is working on Getting UEFI mapped into
linux.  Coreboot could boot into something that provides a UEFI
environment, then into linux, which could then load other operating
systems.


What about the video BIOS stuff/OptionROM stuff? Using Linux would perhaps 
eliminate that.

Or another idea - recycling SeaBIOS drivers and doing UEFISeaBIOS instead?

Please note that Windows 11 require UEFI secureboot to boot (among other things)

Thanks,
Rudolf

[1] 
https://uefi.org/specs/ACPI/6.4/15_System_Address_Map_Interfaces/Sys_Address_Map_Interfaces.html?highlight=reclaim#system-address-map-interfaces
[2] 
https://uefi.org/specs/ACPI/6.4/15_System_Address_Map_Interfaces/uefi-getmemorymap-boot-services-function.html#uefi-getmemorymap-boot-services-function
[3] https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Accessing extended capabilities PCI registers?

[Rudolf Marek]

Hi,

On 25. 11. 20 20:26, Rafael Send wrote:
> Any ideas for what I could try here, or reasons why it might not (be expected 
> to) work?

The extended PCI configuration space access requires a special memory region 
(up 256MiB) which translate accesses to
the PCI configuration cycles. It is exported via ACPI table MMCONFIG. Each 4K 
basically is one PCI/PCIe device
first is bus 0, device 0, fn 0 second is fn 1 etc etc.

So, this information about this special area has to be somehow available to 
your EFI shell. Sorry I don't know
how this works I could only give you this general overview.

Some chipsets also support backdoor access to the extended PCIe config space, 
by utilizing the reserved bits
in the 0xcf8 access I/O port to address the extra offsets. This is non-standard 
chipset dependent feature
which is usually even off.

Thanks,
Rudolf
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Asus F2A85-M Pro: Accessing DMA1_RESET_REG in `isa_dma_init()` hangs system

[Rudolf Marek]

Hi,


Dne 03. 10. 20 v 16:16 Paul Menzel napsal(a):
> I’ll try to figure out, what is wrong with the Super I/O settings in the 
> devicetree. Removing the devicetree Super I/O configuration already gets rid 
> of the hang, but causes other problems. Help is appreciated.

Please can you check how the LPC decode registers are setup? The 14.3 device 
has some registers
to setup what is going to be sent to LPC bus. 
There are bits for fixed legacy regions like COM1 etc, and then there are 
bigger 3? programmable ranges.

Maybe this is in conflict with legacy I/O which causes the hang.

I don't know the right file, maybe it is in

src/southbridge/amd/agesa/hudson/lpc.c  see 
hudson_lpc_enable_childrens_resources()
Maybe booting with debug verbosity would tell.

"hudson lpc decode:%s, base=0x%08x, end=0x%08x\n",

Thanks,
Rudolf
> 
> 
> Kind regards,
> 
> Paul
> 
> 
>>> [1]: https://review.coreboot.org/c/coreboot/+/39371/
>>> [2]: https://review.coreboot.org/c/coreboot/+/39377/
> [3]: 
> https://review.coreboot.org/cgit/board-status.git/commit/asus/f2a85-m/4.10-942-ga89c82e4021/2019-10-08T12_59_37Z/cbfs.txt?id=a922631d481cec9951be67b2c6c208f74054676f
> [4]: https://review.coreboot.org/c/coreboot/+/35855
> [5]: https://review.coreboot.org/c/coreboot/+/35086
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: KGPE-d16 recent microcode (Adds IBPB) produces kernel panics

[Rudolf Marek]

Dne 30. 07. 19 v 11:18 Kinky Nekoboi napsal(a):
> loading the microcode via Linux Kernel works.
> 
> including it via coreboot causes General Protection Faults.

It fails on MSR write:

   17.170377] RSP: 0018:9d003e10 EFLAGS: 00010046
[   17.175699] RAX: 0001 RBX: 8b289d93a040 RCX: 0049

The RCX is set to 0x49 which is the new IBPB barrier MSR.

[   17.151362] Code: 7d 08 49 83 c5 18 4c 89 fa 31 f6 e8 1e 68 99 00 49 8b 45 
00 48 85 c0 75 e5 e9 73 ff ff ff b9 49 00 00 00 b8 01 00 00 00 31 d2 <0f> 30 e9 
86 fc ff ff e9 81 00 00 00 48 c7 c2 e0 18 02 00 31 c0 65

And failing opcode is WRMSR (0f 30)

Failing CPU is CPU 0, which is not what I was hoping for.
My hypothesis was that maybe some of the processors are not receiving the 
microcode update properly.
I would expect that CPU0 would have it correctly.

For some reason CPU is advertising that it can do IBPB via CPUID but still 
failing to do that in reality. Very strange.

Thanks,
Rudolf
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Are AMD CPUs as researched as Intel ones (was Re: New Intel microcode release for migiating ZOMBIELOAD FALLOUT AND OTHERS)

[Rudolf Marek]

Hi

On 15. 05. 19 17:28, Nico Huber wrote:

Hi Ivan,
I'm curious. Did you do or know somebody who did as much research on AMD
processors, as was necessary to find these vulnerabilities? If not, how
can you make such comparisons?


Here [1] is a official AMD paper on the speculation behavior in AMD 
architectures. Intro:


This document provides in depth descriptions of AMD CPU micro-architecture and 
how it handles speculative execution in a variety of architectural scenarios. 
This document is referring to the latest Family 17h processors which include 
AMD’s Ryzen™ and EPYC™ processors, unless otherwise specified. This document 
does necessarily describe general micro-architectural principles that exist in 
all AMD microprocessors. AMD’s processor architecture includes hardware 
protection checks that AMD believes help AMD processors not be affected by many 
side-channel vulnerabilities. These checks happen in various speculation 
scenarios including during TLB validation, architectural exception handling, 
loads and floating point operations.


Thanks,

Rudolf

[1] https://www.amd.com/system/files/documents/security-whitepaper.pdf

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: New API to clear DRAM at boot

[Rudolf Marek]

Hi,

Dne 26. 02. 19 v 22:58 Nico Huber napsal(a):
> On 26.02.19 20:16, ron minnich wrote:
>> On Tue, Feb 26, 2019 at 6:41 AM Patrick Rudolph
>>  wrote:
>>>
>>> Hi coreboot folks,
>>> in order to support TEE like Intel TXT it is necessary to be able to
>>> clear all DRAM at boot on request.
>>>
>>> As all of the x86 coreboot code is x86_32, it is necessary to make use
>>> of PAE to clear memory.

Why PAE, you can you can use 64-bit paging data structures while still running 
in 32-bits!
You simply don't leave compatibility mode and thats all.

0) setup 64bit paging structures, set CR3
1) set EFER.LME 
2) enable paging in CR0.PG
3) you are done, because now you run in 32-bits but paging structures are 
64-bit...

>>
>> I would much rather we consider getting into the current century and
>> having coreboot be able to
>> run x86_64 :-)>
>> can we do that?
> 
> Would be a lot easier if coreboot were open source on x86. But it's
> still doable, even in the presence of 32-bit blobs.
> 
> Though, as it seems, we allow blobs to call into coreboot code now. This
> means we wouldn't only have to wrap calls into a 32-bit blob, we'd also
> have to wrap everything that may be called by the blob.

Yes, I can only add that you can jump from/to 64-bit mode using JMP/CALL FAR or 
equivalent. It is just a matter of changing the CS selector to the desired one.
With that, you can have some wrapper to call some routine from 64-bit to 32-bit 
and vice versa. The only pain is LP64, because "long" is 64-bit...

Thanks,
Rudolf
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] [AMD family16h] What need to be done in coreboot to support the Virtual Wire mode

[Rudolf Marek]

Hi,

Dne 25. 10. 18 v 9:17 Zheng Bao napsal(a):
> Any more ideas? Thanks.

Maybe the bus topology is different in coreboot. It would explain why SATA 
works, because it is on bus 0.

Thanks,
Rudolf


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

Re: [coreboot] [AMD family16h] What need to be done in coreboot to support the Virtual Wire mode

[Rudolf Marek]

Hi,

Dne 23. 10. 18 v 1:57 Marc Jones napsal(a):
> Does VxWorks use the ACPI tables for IRQ routing? You might need that.

Yes good question. Usually OS uses ACPI, or MPTable or what BIOS provided in
the PCI device itself.

It seems because you are asking for the virtual wire mode IOAPIC is not 
supported and legacy PIC mode
maybe needed?

Does this OS configure LINT0 for ExtINT on at least one CPU? (this is how 
virtual wire can be implemented)

Or second way to do that, is to program IO-APIC 0 or 2 depending on chipset to 
ExtInt. This will cause PIC interrupts 
to be delivered to the CPU.

Please note that for PCI devices you also need to program PCI IRQ router and 
ELCR register if you are going to use the PIC mode,

Thanks
Rudolf


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

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

[Rudolf Marek]

Hi,

Sifive did great job [1] [2] and everything is now opensource including mask 
rom loader.

"Today we’re finally able to rectify this issue by releasing the FU540-C000’s 
ZSBL and FSBL as an open source project, which can be found on GitHub like all 
of SiFive’s other open source projects."

And I guess someone could be interested in:

"A Challenge

Now that the bootloader code has been released it’s time for a little 
challenge. Since the ZSBL lives in a mask ROM on the FU540-C000 there is no way 
to replace it, but you can at least re-generate the contents of the ROM and 
then verify that it matches the contents of a real HiFive Unleashed. We’ve 
posted a copy of the contents of the mask ROM at 
https://github.com/sifive/freedom-u540-c000-bootloader, the first person to 
submit a pull request that can exactly reproduce that ROM will get a HiFive 
Unleashed board!"

Thanks
Rudolf


[1] 
https://www.sifive.com/blog/2018/09/06/an-open-source-release-of-the-freedom-u540-c000s-bootloader/
[2] https://github.com/sifive/freedom-u540-c000-bootloader



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

Re: [coreboot] L1TF

[Rudolf Marek]

Hi,
On 15.8.2018 15:58, Shawn wrote:
According to the vulnerability analysis, the SMM is affected by L1TF. Since 
SMM code base in coreboot is much smaller than OEM's firmware, IMOHO L1TF is 
not practical on coreboot. Any idea about is coreboot vulnerable to L1TF?
You need an updated microcode, so the RSM will flush L1 cache (if L1D flush is 
advertised)
else perhaps you will need as a workaround read at least 64KB of memory (L1 is 
32KB but
replacement policy is "not exactly LRU") also, you need to make sure that that 
all SMM cores will enter SMM same time. I don't remember how coreboot does that 
on Intel chips. Perhaps it is so.


Remember that with L1TF you can only read any secrets which could be stored in 
L1. If coreboot has no secrets
there, you don't need to do anything. Modification of data is not possible with 
this attack.


Thanks
Rudolf

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

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

[Rudolf Marek]

Hi all

See [1]

> terpstraWesley W. TerpstraVerified SiFive Account
> 2d
> 
> I saw a few posts on the internet, which misrepresented what I was 
> expressing. I never suggested reverse engineering our partner’s IP!
> 
> SiFive is committed to supporting the open-source community. We are pleased 
> to report that after discussions with our IP partners, we are now able to 
> make available all the source code required to initialize the HiFive 
> Unleashed board. The board’s boot sequence is described in the manual. The 
> assembly code in the initial reset ROM is listed in the manual Chapter 6.1 
> “Reset Vector”. The firmware in the ZSBL mask ROM is directly readable by 
> software on the chip, and we will be making the full source code available 
> shortly. The source code for FSBL including the DDR initialization will also 
> be available shortly. We can attest there is no other firmware run by the 
> system during boot.

And yes there is at least a chapter 20.3 Reset and Initialization in [2], which 
boils down of taking stuff out of reset, programming clocks and sets all 
values. 

Thanks
Rudolf

[1] 
https://forums.sifive.com/t/ddr-controller-configuration-register-values-for-hifive-unleashed/1334/8
[2] https://static.dev.sifive.com/FU540-C000-v1.0.pdf now.

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

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

[Rudolf Marek]

Hi,

Dne 25.6.2018 v 09:01 Jonathan Neuschäfer napsal(a):
> If this is the Denali DDR controller, do you think it would be possible
> to simply read the initial configuration out of the registers of a
> booted system?  (In any case, that's probably worth trying.)

Perhaps it could work with the existing coreboot code. Basically it seems the 
PHY addresses are
just black boxes and the configuration is mostly black box. Plus some logic is 
needed. See rockchip/rk3399/sdram.c
Maybe some bits needs to be initially 0, and written later.

Another suspicious coincidence that it is denali is this:

/*
 * work around controller bug:
 * Do not program DRAM_CLASS until NO_PHY_IND_TRAIN_INT is programmed
 */
copy_to_reg(_ctl[1], _ctl[1],
sizeof(struct rk3399_ddr_pctl_regs) - 4);
write32(_ctl[0], params_ctl[0]);

You see, it writes the first register last. As the DRAM_CLASS is defined to be 
first register in sifive
manual in bits 11:8. The LPDDR3 seems to be 6 in coreboot sources, and the 
sifive manual says DDR3 is 6 and DDR4 is 0xa
which matches and also bit position seems to match!

There is also some denali support in the u-boot it seems.

Plus this seems to be some old iteration:

http://www.fujitsu.com/downloads/MICRO/fme/displaycontrollers/rd-mb86r12-emerald-p-register-rev0-04.pdf

Seems to document some of it.

Search terms: "denali"  "CASLAT_LIN"
or "denali" "dram_class"

Thanks
Rudolf


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

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

[Rudolf Marek]

Hi,

Lets do some speculation that some off the shelf DDR memory controller is used.

Maybe it could be same as the RockChip aka Denali High-Speed DDR PHY IP from 
Cadence?
It has also some "interrupt status" bits and such and "bstlen" which sounds 
same as the few 
regs named as the documentation.

Thanks
Rudolf

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

Re: [coreboot] RISC-V HiFive Unleashed board added to coreboot - has PCI-e slots via exp board

[Rudolf Marek]

Hi Ron,

Dne 24.6.2018 v 20:59 ron minnich napsal(a):
> and ... there ends my interest in the hifive. A shame.

Well perhaps because the DDR controller is third party IP, see [1] FAQ or here:
 
> The Freedom U540 SoC is based on the Freedom Unleashed Platform, which has 
> been open sourced. The Freedom Platform is available at 
> https://github.com/sifive/freedom and is maintained by SiFive. In the Freedom 
> Platform, you will find:
> 
> RISC-V Rocket CPU
> TileLink, a free and open coherent SoC interconnect
> Low-speed Peripherals: SPI, UART, PWM, GPIO, I2C
> High-speed Xilinx FPGA Peripheral Wrappers: DDR, PCIe blocks
> The Freedom U540 contains many 3rd-party IP: cells, pads, PLL, OTP, DDR, 
> GbE, ROM, which are not open-sourced

And,

On Sun, Jun 24, 2018 at 11:47 AM Jonathan Neuschäfer  
wrote
> "While we’d love to provide you with this information, we believe we
> cannot. However, we can’t prevent anyone from disassembling the fsbl and
> copying the values sent to the blackbox DDR register map."

I think they are even asking to actually make some open version of FSBL

Thanks
Rudolf

[1] https://www.sifive.com/products/hifive-unleashed/


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

Re: [coreboot] Problem with W83627DHG in Baytrail I (Possible IRQ conflict or overlapped SOC legacy COM1)

[Rudolf Marek]

Hi,

In general I would check ELCR (I/O port register 0x4d0) to check if it is 
correctly programmed to EDGE/LEVEL (it should be edge)

Also, how the Linux is supposed to detect the I/O port irq? I think you need 
some PNP device in ACPI to let linux infer the IRQ.

I would also try to disable the IRQ from SoC, you just need to check how they 
are enabled (sorry not an expert here)
and also I would use the legacy 0x3f8 instead.

Thanks
Rudolf

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

Re: [coreboot] AMD IMC open source firmware replacement

[Rudolf Marek]

Dne 30.5.2018 v 16:06 Mike Banon napsal(a):
> Hi Rudolf,
> 
> Regarding this part:
> " To check if IMC is active check if PCI 0:14.3 0x40 bit7 set. "
> what command do I need to use to check this?
Try:

sudo setpci -s 14.3 40.b

Despite command name, it will print the value.

Thanks
Rudolf

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

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[Rudolf Marek]

Hi again,

Dne 23.5.2018 v 21:52 Rudolf Marek napsal(a):
> For some reason this firmware update deletes microcode for Trinity CPUs, I 
> tried to contact the person who commit this
> without any luck. As I have previously written the github page has even newer 
> microcode.

This was fixed, however the old (same) microcode was provided again.

Thanks
Rudolf

 


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

Re: [coreboot] AMD IMC open source firmware replacement

[Rudolf Marek]

Hi Mike,

My firmware was just a proof of concept. It was never anything else. I was just
able to run some program and that was all.

Please make sure your IMC is active using info on wiki page. I suspect 
usually it wasnt used as laptop EC.

Thanks
Rudolf




Dne 25.5.2018 v 14:31 Mike Banon napsal(a):
> Good day Rudolf,
> 
> This page [1] tells that you have developed a open source firmware
> replacement of AMD IMC firmware and it is available under request.
> Please tell, did it made to a coreboot? If not, 1) why? (stability
> problems, or something else) 2) is the source code available somewhere
> publicly? I have Lenovo G505S coreboot-supported laptop with AMD
> Richland 15h CPU (A10-5750M) and it is probably using this IMC blob -
> thats why I am curious
> 
> [1] - https://www.coreboot.org/AMD_IMC
> 
> Best regards,
> Mike Banon
> 

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

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[Rudolf Marek]

Hi all,

Dne 22.5.2018 v 07:03 taii...@gmx.com napsal(a):
> AMD has at long last coughed up the stuff to the linux-firmware people
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/diff/amd-ucode/microcode_amd_fam15h.bin?id=77101513943ef198e2050667c87abf19e6cbb1d8
> 
> The fam15h microcode update adds IBPB
> 
>   * Indirect Branch Prediction Barrier (IBPB)
>     * PRED_CMD MSR is available:  YES
>     * CPU indicates IBPB capability:  YES  (IBPB_SUPPORT feature bit)

For some reason this firmware update deletes microcode for Trinity CPUs, I 
tried to contact the person who commit this
without any luck. As I have previously written the github page has even newer 
microcode.

> The question is what about the other stuff? IBRS, STIBP? This is
> confusing due to zero documentation on these updates from amd...Why

Not true, check:
https://developer.amd.com/resources/speculative-execution/

You only need IBPB + retpoline in kernel + RSB clear on CPL switch.

> don't they have those in this update? Would it be possible to easily add
> the support flags without microcode for those who use libreboot?

So libreboot guys don't want any fixes for a CPU?

> Would it still be a good idea to add the lfence msr as rmarek mentioned?

You could, but OS will do that for you (at least Linux). Moreover the Variant 
4, can
be mitigated on fam15h by switch off some chicken bits in the CFG_LS see above.

I think I have seen some commit in Linux to do that.

Thanks
Rudolf


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

Re: [coreboot] Re : Re: When does AMD release the fam15 spectre microcode updates?

[Rudolf Marek]

Hi Florentin,

Dne 25.4.2018 v 18:42 eche...@free.fr napsal(a):
> Hello Rudolf,
> First thank your for finding these blobs and the hack to use them, and for 
> testing and validating them.
> But please could you tell us what was the setup for your tests :
>  - what was your hardware : cpu + mobo (chipset)?

Sorry for the delay, it is Asus F2A85-M
and trinity APU CPU fam15h model 10h
cpuid: 0x00610f01

>  - what was your linux kernel version?

It was 4.16

Thanks
Rudolf

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

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[Rudolf Marek]

Hi,

Dne 17.4.2018 v 12:09 awokd via coreboot napsal(a):
> At what byte locations in the header is the equivalence table? I was
> looking for this...

Hm I'm not aware where is it documented, or if there is some tool to manipulate 
it/dump the structure. Maybe
it could be added to some existing tool?

 Here is what I deduced from Linux arch/x86/kernel/cpu/microcode/amd.c
+ header files

+ 0 u32 UCODE_MAGIC 
+ 4 u32 UCODE_EQUIV_CPU_TABLE_TYPE (0x0)
+ 8 u32 size of following equiv table say "N"

Then this follows, the last table has installed_cpu_cpuid == 0

u32 installed_cpu_cpuid
u32 fixed_errata_mask
u32 fixed_errata_compare
u16 equiv_cpu
u16 res

+ N u32 UCODE_UCODE_TYPE (0x1)
+ N + 4 u32 sizeof blob (without this header)
+ N + 8 microcode blob from github follows here
...
Then after that, there clould be again

+ X u32 UCODE_UCODE_TYPE
+ X + 4 u32 SECTION_SIZE
+ X + 8 microcode header (blob from github follows here)

The microcode blob has the header which already matches the usual microcode 
header:

struct microcode_header_amd {
u32 data_code;
u32 patch_id;
u16 mc_patch_data_id;
u8  mc_patch_data_len;
u8  init_flag;
u32 mc_patch_data_checksum;
u32 nb_dev_id;
u32 sb_dev_id;
u16 processor_rev_id;
u8  nb_rev_id;
u8  sb_rev_id;
u8  bios_api_rev;
u8  reserved1[3];
u32 match_reg[8];
} __attribute__((packed));

Thanks
Rudolf





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

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[Rudolf Marek]

Hi,

I found new microcode here [1], I used 
cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin as a microcode for my Trinity 
family15h CPU.
I hacked together a new microcode header which contains the equivalence table 
etc to be able to load this microcode into the CPU from Linux.

dd if=/lib/firmware/amd-ucode/microcode_amd_fam15h.bin bs=1 count=84 
of=header.bin
cat header.bin cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin > 
microcode_amd_fam15h.bin

copy the file to same location and trigger update:

echo 1 >  /sys/devices/system/cpu/microcode/reload

[ 6032.948243] microcode: CPU0: new patch_level=0x0600111f
[ 6032.964913] microcode: CPU2: new patch_level=0x0600111f

Please note that the header.bin does contain a size of the microcode blob, but 
it happens to be the same, so it works. Normally the container
may contain more microcode blobs. But in my case I use just "right" one for my 
CPU.

The new microcode seems to be adding the IBPB feature.

Thanks
Rudolf


[1] https://github.com/platomav/CPUMicrocodes

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

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[Rudolf Marek]

Hi,

There is slight update from AMD [1], relevant part for you:

*AMD Microcode Updates for GPZ Variant 2/Spectre*

In addition, microcode updates with our recommended mitigations addressing 
Variant 2 (Spectre) have been released to our customers and ecosystem partners 
for AMD processors dating back to the first “Bulldozer” core products introduced 
in 2011.


AMD customers will be able to install the microcode by downloading BIOS updates 
provided by PC and server manufacturers and motherboard providers.  Please check 
with your provider for the latest updates.


Unfortnately, I dont know where to get that microcode. Any ideas?

And also, it changed in [2] the claims that IBPB should be made on context 
switch.

Thanks
Rudolf

[1] https://www.amd.com/en/corporate/security-updates
[2] 
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf


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

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[Rudolf Marek]

Hi,

Dne 29.3.2018 v 20:39 taii...@gmx.com napsal(a):
>> Plus make sure you enable "LFENCE is dispatch serializing" - perhaps 
>> coreboot can do that :) it is simple
>> MSR write on fam 10h 12h+ the fam 11h and 0fh dont have this MSR but LFENCE 
>> is dispatch serilizing.
> Hmm do you have more info links about this?

Yes sure, goto [1] click on [2] and check "MITIGATION G-2". Basically just set:
MSR C001_1029[1]=1 on 10h/12h/14h/15h/16h/17h the 0fh and 11h don't have it but 
there is LFENCE dispatch serializing already.

Thanks
Rudolf

[1] https://www.amd.com/en/corporate/security-updates
[2] 
https://developer.amd.com/wp-content/resources/Managing-Speculation-on-AMD-Processors.pdf

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

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[Rudolf Marek]

Hi,

What do you want to protect? If you want to protect the kernel, retpolines are 
OK on AMD.
And you don't need any microcode update. Your CPU needs to have SMEP, otherwise
you would need to clear RSB on CPL change (the paper on mentined page says that 
you need to do that
always, but at least on Ryzen, the attack using RSB is not working (we tried 
that out, maybe it works
only on some circumstances).

If you want to protect userspace, the RSB will be clear by IBPB (which you 
would need if you don't have userspace compiled
with retpolines). I don't know if intel clears RSB on IBPB... probably not

To sum it up on AMD:

kernel:
retpolines, RSB clear on CPL change on CPU without SMEP (see above)

userspace:
retpolines, RSB clear on context switch necessary or IBPB (needs microcode 
update).

Plus make sure you enable "LFENCE is dispatch serializing" - perhaps coreboot 
can do that :) it is simple
MSR write on fam 10h 12h+ the fam 11h and 0fh dont have this MSR but LFENCE is 
dispatch serilizing.

Besides that, you don't need any microcode update.

Plus of course there is a spectre variant 1, which is more difficult to 
mitigate, basically you need to check all the software
and look for any pattern like array_x[array_z[untrusted_index] * any 
transformation].

The first access would leak just address (ASLR defated), second will leak data.
The variant 1 works on user/user attack and as well as user/kernel.

As far I know there are no automated tools to check for this.


Thanks
Rudolf









Dne 18.2.2018 v 12:48 Mike Banon napsal(a):
> Maybe its' a good idea to write to AMD support regarding this question
> - please share a reply if you would get an answer. I'm curious about
> other fam15 CPUs as well, e.g. A10-5750M microcode update would be
> nice, maybe a request could be more general, e.g. : what is the
> estimated release date for the microcode updates for fam15 AMD CPUs
> (so a request is  not about "opterons only")
> 
> On Sun, Feb 18, 2018 at 2:47 PM, Mike Banon  wrote:
>> Maybe its' a good idea to write to AMD support regarding this question
>> - please share a reply if you would get an answer. I'm curious about
>> other fam15 CPUs as well, e.g. A10-5750M microcode update would be
>> nice, maybe a request could be more general, e.g. : what is the
>> estimated release date for the microcode updates for fam15 AMD CPUs
>> (so a request is  not about "opterons only")
>>
>> On Sun, Feb 18, 2018 at 4:30 AM, taii...@gmx.com  wrote:
>>> They said they would be releasing opteron microcode updates in a few weeks
>>> but it has been over a month and I am wondering when this is going to happen
>>> or if it already has and I should re-compile coreboot?
>>>
>>> https://www.amd.com/en/corporate/speculative-execution
>>> "We expect to make updates available for our previous generation products
>>> over the coming weeks."
>>>
>>> Thanks!
>>>
>>>
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://mail.coreboot.org/mailman/listinfo/coreboot
> 

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

Re: [coreboot] AMG G-series - Steppe eagle - PCI IRQ Routing to 8259 PIC

[Rudolf Marek]

Hi Abhishek,

Please can you check if you programmed the ELCR registers 0x4d0/0x4d1
to level for PCI registers?

In other words, you should set bits to 1 to corresponding IRQ to be level
triggered. Eg. for IRQ 5, you need to write 1 to bit5 to 8bit I/O port 0x4d0 For
IRQ 9, you need to program bit 1 of 0x4d1

You can also check the PCI status register (reg  of Ethernet device, there is
"interrupt pending" bit, to verify that the device actually tries to trigger the
IRQ. Also, you can check if INTX disable is not set in PCI register by accident.

lspci -vvv
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping-
SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] FYI: Reverse Engineering x86 Processor Microcode

[Rudolf Marek]

Hi all,

I think some of you might already noticed a nice paper:

Microcode is an abstraction layer on top of the physical
components of a CPU and present in most generalpurpose
CPUs today. In addition to facilitate complex and
vast instruction sets, it also provides an update mechanism
that allows CPUs to be patched in-place without requiring
any special hardware. While it is well-known that CPUs
are regularly updated with this mechanism, very little is
known about its inner workings given that microcode and
the update mechanism are proprietary and have not been
throughly analyzed yet.

In this paper, we reverse engineer the microcode semantics
and inner workings of its update mechanism of conventional
COTS CPUs on the example of AMD’s K8 and
K10 microarchitectures. Furthermore, we demonstrate
how to develop custom microcode updates. We describe
the microcode semantics and additionally present a set of
microprograms that demonstrate the possibilities offered
by this technology. To this end, our microprograms range
from CPU-assisted instrumentation to microcoded Trojans
that can even be reached from within a web browser
and enable remote code execution and cryptographic implementation
attacks.

https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-koppe.pdf

which is about unencrypted AMD K8 microcode. It should throw some light on how
the microcode works, and also why is it good to apply the fixes. Please note
that I don't want another flamewar about why not doing the microcode updates
would make my system more free.

There seems to be just one detail missing, the microcode triads are somehow
obfuscated, and the paper does not tell how.

Happy hacking,
Rudolf

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

Re: [coreboot] Howto enable AMD Cool'n'Quiet support

[Rudolf Marek]

Hi,

Sorry for the delay.> CPU ID 0x8001: fc0

So your CPU is revision "DH" which is pre "F".

> But I have also seen that CONFIG_K8_REV_F_SUPPORT is not set in .config

nope this is for some other CPUs.

If you look to coreboot/src/cpu/amd/model_fxx/powernow_acpi.c, your CPU 0xfc0
has an entry there.

You need to check pstates_algorithm() function. It may not be executed at all,
or there is something wrong with that. Make sure that you look to the later one,
there is #ifdef in this file! The first one is for CONFIG_K8_REV_F_SUPPORT.

This functionality is called from amd_generate_powernow()
which goes from via/k8t890/traf_ctrl.c

I suspect that this old VIA chipset has no PCI device for this thus the

.acpi_fill_ssdt_generator = southbridge_acpi_fill_ssdt_generator

Is never called. I did not do the support for the K8T800 chipset so I don't
know. Maybe you can provide lspci -xxx -n from linux to see what kind of PCI
devices you have. Perhaps then the callback can be added elsewhere to the PCI
device you have such as  northbridge_driver_t800_old.

You can try attached patch, maybe it will move you further. I remember it was
real pain to get the cool-n-quiet working, there was a lot of southbridge tweaks
necessary (and undocumented bits!). Just give it a try. In worst case you will
see some messages in dmesg about Targ stuck bits...

Thanks
Rudolf


diff --git a/src/southbridge/via/k8t890/host.c b/src/southbridge/via/k8t890/host.c
index 2155594..2dd2896 100644
--- a/src/southbridge/via/k8t890/host.c
+++ b/src/southbridge/via/k8t890/host.c
@@ -82,12 +82,26 @@ static void host_init(struct device *dev)
 
 }
 
+
+#if IS_ENABLED(CONFIG_HAVE_ACPI_TABLES)
+
+static void southbridge_acpi_fill_ssdt_generator(device_t dev) {
+
+	amd_generate_powernow(0, 0, 0);
+	acpigen_write_mainboard_resources("\\_SB.PCI0.MBRS", "_CRS");
+}
+#endif
+
 static const struct device_operations host_ops_old = {
 	.read_resources		= pci_dev_read_resources,
 	.set_resources		= pci_dev_set_resources,
 	.enable_resources	= pci_dev_enable_resources,
 	.enable			= host_old_enable,
 	.init			= host_old_init,
+#if IS_ENABLED(CONFIG_HAVE_ACPI_TABLES)
+	.write_acpi_tables  = acpi_write_hpet,
+	.acpi_fill_ssdt_generator = southbridge_acpi_fill_ssdt_generator,
+#endif
 	.ops_pci		= 0,
 };
 
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Howto enable AMD Cool'n'Quiet support

[Rudolf Marek]

Hi,


I checked coreboot.rom-file and my vendor BIOS for that but can't find it.


The coreboot provides the _PSS ACPI objects and not that PSB table. I guess you 
miss the _PSS objects for some reason.


Did I miss to enable something in make menuconfig? Can someone give me a hint 
how to find the missing blob.


If your CPU is pre rev F family 0xf, the _PSS object is generated using a 
hardcoded table. Perhaps your CPU is missing there. See powernow_acpi.c

coreboot should also complain if the CPU is missing there:

"Unknown CPU, please update the powernow_acpi.c"

Thanks
Rudolf


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

Re: [coreboot] Overheating on f2a85-m

[Rudolf Marek]

Hi,

> temporarily you could just wire your fan so that it will always work on the 
> max speed instead of taking the fan control commands from the motherboard


Yes it can be switched to max RPM of fan like this:

ruik ruik # echo 1 >  /sys/class/hwmon/hwmon1/device/pwm1_enable
ruik ruik # echo 255 >  /sys/class/hwmon/hwmon1/device/pwm1

Maybe you will have something else than hwmon1

Thanks
Rudolf

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

Re: [coreboot] Overheating on f2a85-m

[Rudolf Marek]

Hi again,

Sorry, I pasted wrong dump. Before I installed right /etc/sensors3.conf

radeon-pci-0008
Adapter: PCI adapter
temp1:+35.0°C  (crit = +120.0°C, hyst = +90.0°C)

it8603-isa-0290
Adapter: ISA adapter
Vcore:+1.27 V  (min =  +1.12 V, max =  +2.96 V)  ALARM
in1:  +1.66 V  (min =  +2.69 V, max =  +0.08 V)  ALARM
+12V:+12.38 V  (min = +14.98 V, max =  +0.00 V)  ALARM
+5V:  +5.07 V  (min =  +3.96 V, max =  +0.12 V)  ALARM
in4:  +1.20 V  (min =  +1.92 V, max =  +0.12 V)  ALARM
3VSB: +3.31 V  (min =  +0.79 V, max =  +2.88 V)  ALARM
Vbat: +3.14 V
+3.3V:+3.36 V
CPU Fan: 2824 RPM  (min =  200 RPM)
CHA Fan:0 RPM  (min =  600 RPM)  ALARM
CPU Temp: +64.0°C  (low  = +50.0°C, high = -126.0°C)  ALARM  sensor = 
thermistor
M/B Temp: +38.0°C  (low  = +100.0°C, high = +122.0°C)  sensor = thermistor
temp3:   -128.0°C  (low  = -24.0°C, high =  +0.0°C)  sensor = thermistor
intrusion0:  OK

k10temp-pci-00c3
Adapter: PCI adapter
temp1:+48.9°C  (high = +70.0°C)
   (crit = +70.0°C, hyst = +69.0°C)

Thanks
Rudolf

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

Re: [coreboot] Overheating on f2a85-m

[Rudolf Marek]

Hi Piotr,

Are you sure that it is overheating? I would suspect RAM issues if you see
some crashes. Is your CPU Trinity or Richland?

If you modprobe it87 and you have some more recent kernel, you should see some
temps reading:

#sensors

radeon-pci-0008
Adapter: PCI adapter
temp1:+36.0°C  (crit = +120.0°C, hyst = +90.0°C)

it8603-isa-0290
Adapter: ISA adapter
in0:  +1.26 V  (min =  +1.12 V, max =  +2.96 V)  ALARM
in1:  +1.66 V  (min =  +2.69 V, max =  +0.08 V)  ALARM
in2:  +2.06 V  (min =  +2.50 V, max =  +0.00 V)  ALARM
in3:  +2.03 V  (min =  +1.58 V, max =  +0.05 V)  ALARM
in4:  +1.20 V  (min =  +1.92 V, max =  +0.12 V)  ALARM
3VSB: +3.31 V  (min =  +0.79 V, max =  +2.88 V)  ALARM
Vbat: +3.14 V
+3.3V:+3.36 V
fan1:2860 RPM  (min =  200 RPM)
fan2:   0 RPM  (min =  600 RPM)  ALARM
temp1:+65.0°C  (low  = +50.0°C, high = -126.0°C)  ALARM  sensor =
thermistor
temp2:+38.0°C  (low  = +100.0°C, high = +122.0°C)  sensor = thermistor
temp3:   -128.0°C  (low  = -24.0°C, high =  +0.0°C)  sensor = thermistor
intrusion0:  OK

k10temp-pci-00c3
Adapter: PCI adapter
temp1:+48.8°C  (high = +70.0°C)
   (crit = +70.0°C, hyst = +69.0°C)



Here is my /etc/sensors3.conf for Asus F2A85-M

chip "it8603-*"
label temp1 "CPU Temp"
label temp2 "M/B Temp"

label in0 "Vcore"
label in1 "in1"
label in2 "+12V"
label in3 "+5V"
label fan1 "CPU Fan"
label fan2 "CHA Fan"
label fan3 "PWR Fan"

compute in2  @ * (12/2), @ / (12/2)
compute in3  @ * (25/10), @ / (25/10)

Thanks
Rudolf

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

Re: [coreboot] Does the Core2Quad Mobile Q9100 require microcode updates?

[Rudolf Marek]

Hi Timothy,

Many thanks for pointing this out! We should put this somewhere to Wiki, in
VERY LARGE letters as over the years I'm also very sensitive to all the people
not liking to do their microcode update.

I always failed to explain that microcode is not a program (despite the "code"
in the word). I concluded that people are preventing doing the microcode
update because of religious reasons as I failed to identify any other reason.
I also do think that if one trusts the CPU one should also trust the update,
otherwise it makes more sense to go for RISC-V CPU in FPGA approach.

Thanks
Rudolf




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

Re: [coreboot] coreboot assembly at 33c3

[Rudolf Marek]

Hi

I think I seen this. I hope it is accurate.

https://events.ccc.de/congress/2016/wiki/Assembly:Coreboot

Thanks
Rudolf

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

Re: [coreboot] DMA protection? [AMD-Vi]

[Rudolf Marek]

Hi all,

Let me jump in. From the OS point of view the BME should be set for:

1) PCI bridges

2) for PCI class of IOAPIC devices (otherwise OS will not get any interrupt!)
This PCI IOAPIC is for example on more high-end Xeons

3) sometimes it needs to be set on internal chipset devices. I remember that if
440BX had clear special cycle cleared it would refuse to poweroff - hard to
debug! I guess per chipset it must be checked if it works with BME off...

4) the rest of the devices should have BME off

Side note:

BME is ignored by Intel integrated graphics - the DMA runs even if the BME is
clear (this happens on core i7 chipsets for example) Thus thatswhy it needs RMRR
IOMMU range for VGA...

Thanks
Rudolf




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

Re: [coreboot] Searching for datasheets concerning AMD SB950 southbridge chipset

[Rudolf Marek]

Hi Marty,

What is the northbridge? Is it also 9xx line?

https://www.coreboot.org/Datasheets#AMD_990FX.2F990X.2F970

The southbridge should be the same as SB800 series, it should be SB850, only a
name changed.

The page above has a link to SB950 errata sheet.

Hope it helps,
Rudolf

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

Re: [coreboot] Why is subsystemid required to find a uPD7020200

[Rudolf Marek]

Hi,

As far I know it is because some drivers can detect workarounds based on
subsystem IDs or under Windoze the drivers are often locked to particular
subsystemID - 0x17aa is levovo. What OS do you use?

Thanks
Rudolf

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

Re: [coreboot] X120e AGESA hangs

[Rudolf Marek]

Hi,

You can use Bolton datasheets, should be same/similar.
http://support.amd.com/TechDocs/51192_Bolton_FCH_RRG.pdf

The said register access is forcing to use overriden EFUSE values, so I would 
say you have to check how their are programmed. Maybe you are trying to enable 
the EC without EC firmware? Or perhaps the chip does not like the override efuses.


I guess you should also use have a look to AGESA fam15h code as it has Proc/Fch 
directory for Hudson, no idea why you are trying to use old cimx code? (perhaps 
to avoid AGESA?)


Thanks
Rudolf


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

Re: [coreboot] AMD platform: IO-APIC => Local APIC delivery modes

[Rudolf Marek]

Hi again,

> It would be interesting to test 0x00...300 and 0xff...400 just for 
> completeness.

The 0x00...300 does the same (NMI delivered on all CPUs) and the other one does
nothing.

> That would be great.  I am really curious about the official clarification on
> the issue.  Maybe there is a configuration bit that they forgot to set or
> something like that.

I try to get someone responsible for this.

> I found a really old document about AMD-8131 chipset which seems like 
> something
> that later morphed into the APIC component of the southbrdiges and in that
> document they discuss APIC -> HT mapping quite extensively.   I wonder what 
> went
> wrong later on.
> In this copy of the document it's on page 67
> http://www.tautec-electronics.de/Datenblaetter/Schaltkreise/AMD8131.pdf

I think the SB600 series was an ATI design, so perhaps it is just bug.

Thanks
Rudolf



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

Re: [coreboot] AMD platform: IO-APIC => Local APIC delivery modes

[Rudolf Marek]

Hi Andriy,

Thanks for the very detailed emails. It was great I could help.

> I set Delivery Mode in the redirection table to the HyperTransport defined NMI
> message type, 0_011, and it worked!

Great, so there is a bug! Do you have some USB image I can try on more recent
AMD system (with Hudson chipset). Or we can try to report this to AMD, but I
have read somewhere that the new chipsets are done by Asmedia.

Thanks
Rudolf


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

Re: [coreboot] AMD platform: IO-APIC => Local APIC delivery modes

[Rudolf Marek]

Hi again

>> You can perhaps generate NMI using MSI/MSI-X or HPET (i tried with this)

I did the HPET NMI generator on Intel PCH, it works fine. I just fill the MSI
addr/data in a way that it was delivering NMI to certain CPU - physical delivery
to a CPU with a certain ID.

If this does not work on AMD, perhaps there is some problem with chipset
configuration. Please check the HT specs and try to sort out the MT3 setup.

Thanks
Rudolf





-- 
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] Help find datasheet on amd R780L

[Rudolf Marek]

Hi Alexey,

It is this one:

http://support.amd.com/TechDocs/43451.pdf

Have fun,
Rudolf


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

Re: [coreboot] Help find datasheet on amd R780L

[Rudolf Marek]

Hi,

Please provide the PCI id for device 0:0.0

Thanks
Rudolf

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

[coreboot] UEFI project ideas

[Rudolf Marek]

Hi all,

I noticed that seabios/libpayload could have interresting use cases and I want
to share/discuss them.

1) Have a SeaBIOS be a UEFI application. This would benefit on UEFI platforms
without CSM.

2) Provide a minimum UEFI environment. As I noticed u-boot started to have such
support. In fact it has UEFI glue to u-boot drivers. As such it provides a
minimal boot services + minimum runtime services. In seabios, it is almost
there, only PE loader and filesystem support is missing.

The 2) could be perhaps be some independent project utilizing the coreboot
libpayload library.

Maybe those can be done in next year GSoC.

I guess 2) could be useful to boot future OSes without legacy support.

Thanks
Rudolf

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

Re: [coreboot] Discussion about dynamic PCI MMIO size on x86

[Rudolf Marek]

Hi all,

Most of 32-bit kernels (Unix/OS/whatever) usually have PAE support, so in fact 
they can cope with 36 bits of memory. The CPU PAE support started around 
Pentium. Windows XP+ has support for this.


I think one can go with 2GB MMIO hole. The PCIe > 4GB is a question, I don't 
think Windows have good support for this. So, using 2GB memory hole and having 
MMIO < 4GB seems like a good idea.


Thanks
Rudolf


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

Re: [coreboot] ASRock E350M1: MSR 0x00000175 SYSENTER_ESP has 1 inconsistent values across 2 CPUs

[Rudolf Marek]

Hi all,

> Could you please confirm that disabling the other two MSR tests for CS and
> EIP is also the right thing to do?

Yes I think this is OK. The SYSENTER MSRs are used by the OS and there is
nothing which BIOS needs to setup.

Same case is the SYSCALL MSR, GS/FS base and KERNEL GS base and possibly also
MSR_TSC_AUX.

#define MSR_STAR0xc081 /* legacy mode SYSCALL target */
#define MSR_LSTAR   0xc082 /* long mode SYSCALL target */
#define MSR_CSTAR   0xc083 /* compat mode SYSCALL target */
#define MSR_SYSCALL_MASK0xc084 /* EFLAGS mask for syscall */
#define MSR_FS_BASE 0xc100 /* 64bit FS base */
#define MSR_GS_BASE 0xc101 /* 64bit GS base */
#define MSR_KERNEL_GS_BASE  0xc102 /* SwapGS GS shadow */
#define MSR_TSC_AUX 0xc103 /* Auxiliary TSC */

Thanks
Rudolf


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

Re: [coreboot] ASRock E350M1: MSR 0x00000175 SYSENTER_ESP has 1 inconsistent values across 2 CPUs

[Rudolf Marek]

Hi all,

This MSR is used when SYSENTER instruction is used by OS/application. The ESP
MSR usually points to to the kernel stack of current thread, so if two
different threads execute on different CPUs it will be different. False
positive, and they should fix it.

Thanks
Rudolf





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

Re: [coreboot] how to route IRQ4 (COM1) on LPC bus for bayleybay_fsp

[Rudolf Marek]

Hi

What does it mean not available? Maybe you can check if you programmed ELCR
register to edge for IRQ4.

You can't share the IRQ4 with PCI IRQ I think thats why it does not work.

You need to route the the PIRQA to something else, like IRQ3.

Thanks
Rudolf

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

Re: [coreboot] Where is the first instrucion?

[Rudolf Marek]

Hi,

I guess your question is more general than the coreboot related right?

If you have a firmware image dump of the flash (not the file you download from
board vendor) then yes, first location to be executed is the instruction located
16 bytes before end of the image.

In coreboot see in build/ bootblock_inc.S which also has reset16.inc and
entry16.inc which is a real start. Consult the Intel or AMD manual to see the
CPU state after reset. The CPU starts in real mode, but CS base is shifted to
last 64KB before end of 4GB address space. In general your CPU starts in
compatible mode with 8086 manufactured in 1978.

Thanks
Rudolf

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

Re: [coreboot] Hudson-D4 (A88X): IRQ routing of XHCI seems incomplete?

[Rudolf Marek]

Hi


 In AMD Bolton FCH Register Reference Guide (51192), page 2-154, this
 register Interrupt Line – RW – 32 bits - [PCI_Reg:3Ch] is 0x12/0x11
 while having booted the vendor binary and 0xff/0xff when having booted
 coreboot.

Well this register is used only by OS when MPTABLE/ACPI PCI routing fails. The
register is only a storage, it does not drive any logic.Btw 12/11 is wrong as
PCI specs says it can be 0-15 range.

So the issues must be something else.

Thanks
Rudolf


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

Re: [coreboot] [Bug?] 3 different bytes in VGAbios after upgrade to coreboot

[Rudolf Marek]

Hi all,


Dne 7.6.2015 v 02:12 Vladimir napsal(a):
 Thank you very much for solving this riddle!
 And one more question for Rudolf: please tell, are you using atomDis
 utility to disassemble atombios into C code? Or there are some other
 special tools, which probably have more recent versions? (latest version of
 atomDis is already 4 years old...)

I think there was some effort to make VGA BIOS from scratch. I think the guys
used a script to rewrite it to C. I don't remember anymore.

Thats all I know,

Thanks
Rudolf

 
 On 3 June 2015 at 20:27, Rudolf Marek r.ma...@assembler.cz wrote:
 
 Hi all,

 First byte after IBM is usually a checksum. So in fact only two bytes
 differ.
 Now you may ask what it is... and it is a IOBASE :)

 typedef struct _ATOM_ROM_HEADER
 {
   ATOM_COMMON_TABLE_HEADER sHeader;
   UCHAR uaFirmWareSignature[4];/*Signature to distinguish between
 Atombios
 and non-atombios,atombios should init it as ATOM, don't change the
 position */
   USHORT usBiosRuntimeSegmentAddress;
   USHORT usProtectedModeInfoOffset;
   USHORT usConfigFilenameOffset;
   USHORT usCRC_BlockOffset;
   USHORT usBIOS_BootupMessageOffset;
   USHORT usInt10Offset;
   USHORT usPciBusDevInitCode;
   USHORT usIoBaseAddress; ---this changes

 I guess IOBASE of PCI device changes also...

   USHORT usSubsystemVendorID;
   USHORT usSubsystemID;
   USHORT usPCI_InfoOffset;.
   USHORT usMasterCommandTableOffset; /*Offset for SW to get all command
 table
 offsets, Don't change the position */
   USHORT usMasterDataTableOffset;   /*Offset for SW to get all data table
 offsets, Don't change the position */
   UCHAR  ucExtendedFunctionCode;
   UCHAR  ucReserved;
 }ATOM_ROM_HEADER;

 You can use atomDis to dump it I guess (Did not check if it dumps also the
 header.

 Thanks
 Rudolf

 
 
 

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

Re: [coreboot] [Bug?] 3 different bytes in VGAbios after upgrade to coreboot

[Rudolf Marek]

Hi all,

First byte after IBM is usually a checksum. So in fact only two bytes differ.
Now you may ask what it is... and it is a IOBASE :)

typedef struct _ATOM_ROM_HEADER
{
  ATOM_COMMON_TABLE_HEADER sHeader;
  UCHAR uaFirmWareSignature[4];/*Signature to distinguish between Atombios
and non-atombios,atombios should init it as ATOM, don't change the position */
  USHORT usBiosRuntimeSegmentAddress;
  USHORT usProtectedModeInfoOffset;
  USHORT usConfigFilenameOffset;
  USHORT usCRC_BlockOffset;
  USHORT usBIOS_BootupMessageOffset;
  USHORT usInt10Offset;
  USHORT usPciBusDevInitCode;
  USHORT usIoBaseAddress; ---this changes

I guess IOBASE of PCI device changes also...

  USHORT usSubsystemVendorID;
  USHORT usSubsystemID;
  USHORT usPCI_InfoOffset;.
  USHORT usMasterCommandTableOffset; /*Offset for SW to get all command table
offsets, Don't change the position */
  USHORT usMasterDataTableOffset;   /*Offset for SW to get all data table
offsets, Don't change the position */
  UCHAR  ucExtendedFunctionCode;
  UCHAR  ucReserved;
}ATOM_ROM_HEADER;

You can use atomDis to dump it I guess (Did not check if it dumps also the 
header.

Thanks
Rudolf

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

Re: [coreboot] Soft-Reset when enabling resources on Sun Ultra 40 M2

[Rudolf Marek]

Hi,

Sorry just a quick note, I need to go now. Usually it happens when resources 
assigned are wrong (like overlapping local APIC or the area  ffe which is 
used to deliver IRQs.


CHeck resource allocation. I assume your problem happens when you enable the 
bridge decoding.


Thanks
Rudolf

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

Re: [coreboot] AMD technical contact? / CAR issue

[Rudolf Marek]

Hi Sevan,

Well for this problem, I would like to see someone who is designated to help. I 
thought we had someone, but it looks like there is none.


Thanks
Rudolf



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

Re: [coreboot] AMD technical contact? / CAR issue

[Rudolf Marek]

Hi all,

You a short update,

1) I still dont know whom to ask for help :/

2) I analyzed the CAR teardown routine from vendor BIOS and from coreboot. There
are some changes jnb - jmp and similar changes in AP teardown logic. The
gcccar.inc in the binaryPI is perhaps ported from coreboot so the fix is not 
there.

But if someone has access to AMD sources (even newer AGESA, because often they
have support for CAR for other processsors) please check the
AMD_DISABLE_STACK_FAMILY_HOOK_F15 and ENABLE stuff for possible changes. It
would spare me from playing binary hide and seek,

Thanks
Rudolf




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

Re: [coreboot] coreboot code of conduct

[Rudolf Marek]

Hi all

Just out of curiosity why do we need this? Was there some problem now or in the 
past?


I just read the c c of c and I got this impression that we must be really bad 
that we need regulation  arbitration. If nothing like this ever happened I 
would like to see some statement that this c c of c is there just to comply with 
future problems (or similar like it is trendy ;)


Thanks
Rudolf

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

[coreboot] AMD technical contact?

[Rudolf Marek]

Hi all,

Who is the current AMD technical contact? I would like to know whom to ask for
the help with the S3 CAR issue of fam15h.

The CAR teardown routine has wbinvd instead of invd and memory is currupted with
CAR contents during resume from suspend. Replacing WBINVD with INVD does not
work, coreboot will crash during cold boot (perhaps due to unconsistent L2 
state).

Thanks
Rudolf

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

Re: [coreboot] coreboot Prague meeting - details

[Rudolf Marek]

Hi all,

Photos from cesnet were already removed but you can find a copy here:

http://assembler.cz/praguemeeting/

There are 2 dirs, cesnet and mine photos. Please dont share the face photos
without permission from the subjects on social networks (or elsewhere).

Thanks
Rudolf



Dne 19.10.2014 v 09:50 Rudolf Marek napsal(a):
 photos from CESNET available here:
 
 https://filesender.cesnet.cz/?vid=21041c18-626a-b3e8-a2fe-1c38d083
 
 Ruik
 

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

[coreboot] disable from: rewrite?

[Rudolf Marek via coreboot]

Hi all,

Is there a mailman option on our ml to stop rewriting the From header of the 
email? It is quite retarded...


Thanks
Coreboot coreboot@coreboot.org


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

Re: [coreboot] coreboot Prague meeting - details

[Rudolf Marek]

photos from CESNET available here:

https://filesender.cesnet.cz/?vid=21041c18-626a-b3e8-a2fe-1c38d083

Ruik


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

Re: [coreboot] coreboot Prague meeting - details

[Rudolf Marek]

Hi

Hotel reception has non-stop. You can go to hotel first.

Thanks
Rudolf

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

Re: [coreboot] coreboot hackaton/meeting in Prague - october 2014 - official date set

[Rudolf Marek]

Hi all,

I have some more people which signed up in the doodle. I need an email to send
them details. If someone knows their email, please let me know.

Cris Sommerland
Philipp Deppenwiese 
Kai Michaelis

Thanks
Rudolf

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

Re: [coreboot] coreboot hackaton/meeting in Prague - october 2014 - official date set

[Rudolf Marek]

Hi all,

I would like to remind you our Prague hackaton meeting in October (16-19). I
managed to get patronage from dean of the Faculty of Information Technology,
Czech Technical University and also patronage from CESNET (Czech education and
science network)

To properly size the event room (so far I counted with 15 people, but we are
nearly there!) and also for the hotel booking, I would like to ask you to sign
in on doodle ASAP!

If you intend to come, please
use http://doodle.com/h6yar2mtxarvhv3x and sign in. If you are still unsure, but
you want to most likely to come. Indicate that in the doodle too. I can do you
some speculative booking of the hotel (which is penalty free, up to 16 
september)

I'm handling the people which are already on the doodle, via a private emails
except for Cris Sommerland. He is prehaps using a nickname and I dont have any
email of him. Cris, please can you write me an email? Or someone who has yours 
;)

If your email is not in the email conference archive, please write me an email 
too.

The hotel is part of student dormitory, just google for The Masarykova
Dormitory hotel and it has very reasonable prices and it is not far from the
actual event place.

The people which are already on the doodle list received an email from me where
I'm asking them to fill in some details in the form, please do so! (if you dont
have my email, please ping me too)

I want to do the hotel booking tomorrow afternoon GMT +2. That does not mean
that the hotel is full, I just can't promise you the room later. For late birds,
I will try to get reservation in the early september, but I can't promise 
anything.

Thanks
Rudolf


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

[coreboot] FYI: latest ACPICA acpidump is broken

[Rudolf Marek]

Hi,

ruiktest ~ # /tmp/acpidump
Could not get ACPI tables, AE_BAD_HEADER

It seems there is a bug in ACPICA, coreboot is using revision 0 (ACPI 1.0) if
there is no XSDT. But ACPICA expect always ACPI 2.0 style which have a len
record. This is bit more complicated, coreboot creates a header with revision 0,
but provides all other fields as it would be ACPI 2.0, but SeaBIOS correctly
strips that.

I created a bug report at ACPICA:

https://bugs.acpica.org/show_bug.cgi?id=1097

Thanks
Rudolf


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

Re: [coreboot] coreboot hackaton/meeting in Prague - october 2014 - official date set

[Rudolf Marek]

Hi all,

I updated the dates to the proposed dates 16,17,18,19 of October. This are now 
the fixed dates and won't change ever again.


The doodle link remains the same. I updated the list except for Paul Menzel 
which I dont know if he could attend.


Please if you want to come, sign in in the doodle. It would help to know soonish 
to make planning easier.


http://doodle.com/h6yar2mtxarvhv3x

The current plan is to start on Thursday and continue until Sunday. I will 
create some more official program depending on the arrival/departure time.


So far I forsee the classic hackaton/hacking session with a social session in 
the evening.


In the meanwhile I will try to get offer for some cheaper accodommation in the 
student dormitory as the last time. If this does not work, I will try to find 
something affordable.


Prague is reachable by plane (Vaclav Havel Airport) or by busses/cars/. If you 
want to travel from nearby countries I can recommend the  http://zluty.cz - it 
has nice buses and nice service too.


Looking forward to meet you all (again),

Thanks
Rudolf


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

Re: [coreboot] Help for Coreboot project

[Rudolf Marek]

Hi Антон

I think this could be used to develop something like native radeon video init.
Perhaps similar approach was used by ron  co develop native intel video init.

Thanks
Rudolf

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

Re: [coreboot] F2A85-M: Chassis Fan Not Working

[Rudolf Marek]

Hi

I think this is the problem: change the following line in the devicetree.cb

register hwm_fan2_ctl_pwm = 0x80

To 0x00 For some reason automatic settings for fan2 does not work... or is badly 
set up.


Idwer: He uses the extra fan, not only the CPU fan.

Please let us know if this helps,

Thanks
Rudolf

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

Re: [coreboot] F2A85-M: Chassis Fan Not Working

[Rudolf Marek]

On 6.7.2014 23:05, ron minnich wrote:

So Rudolf, this just takes the control loop out of the picture and always
enables the fan? This stuff always confuses me.


Yes it should. I used the same programming as in orig BIOS but perhaps I missed 
something. I will check later what went wrong. The change should make it manual 
mode (which has some non-zero pwm by default, so fan should spin)


Thanks
Rudolf




ron


On Sun, Jul 6, 2014 at 1:47 PM, Rudolf Marek r.ma...@assembler.cz
mailto:r.ma...@assembler.cz wrote:

Hi

I think this is the problem: change the following line in the devicetree.cb

register hwm_fan2_ctl_pwm = 0x80

To 0x00 For some reason automatic settings for fan2 does not work... or is
badly set up.

Idwer: He uses the extra fan, not only the CPU fan.

Please let us know if this helps,

Thanks
Rudolf


--
coreboot mailing list: coreboot@coreboot.org mailto:coreboot@coreboot.org
http://www.coreboot.org/__mailman/listinfo/coreboot
http://www.coreboot.org/mailman/listinfo/coreboot






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

Re: [coreboot] coreboot hackaton/meeting in Prague - september 2014 - date shift?

[Rudolf Marek]

Hi all,

What about 16 17 18 19 of October then? It is already in the university semester 
so there could be trouble with dormitory accommodation, but I think no trouble 
with some room @university.


I would like to shift the date only once, if there is anyone with objections 
(especially those which are on the doodle list) please speak up.


Thanks
Rudolf




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

Re: [coreboot] coreboot hackaton/meeting in Prague - september 2014

[Rudolf Marek]

Hi David

Thanks for the offer. I think we can go to university I have pre-arranged it
there. The google office hint was that you can most likely work from there and
thus stay longer here if you want to explore Prague for more days.

Thanks
Rudolf

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

Re: [coreboot] F2A85-M: Chassis Fan Not Working

[Rudolf Marek]

Hi,

I implemented the initialization of hardware monitor ldn inside the ite chip. 
What do you mean not working stopped spinning?


Thanks
Rudolf

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

[coreboot] coreboot hackaton/meeting in Prague - september 2014

[Rudolf Marek]

Hi all,

First of all sorry that it took so long to get back to this.

I have in plan to organize a coreboot meeting in the Prague on 19,20,21 of
September. I created the doodle here:

http://doodle.com/h6yar2mtxarvhv3x

I put there also Thursday if we want to meet earlier. The programme is to hack a
coreboot and enjoy Prague together. This time we will have a room at the Czech
Technical university near the the Masarykova dormitory (that one which was used
last time).

Please let me know if anyone has questions / ideas what to do / talk about /
Does the date fit well?

We have some co-working center in Prague so it could be possible to stay longer
in Prague and do office stuff from there (besides that google has office in
Prague too).

Thanks
Rudolf

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

Re: [coreboot] AMD A76M chipset?

[Rudolf Marek]

Hi all,

I'm CCing Bruce, maybe he knows.

According to random googled page:

The A76M FCH is an upgraded A70M FCH, or better yet A76M = Bolton M3 and A70M =
Hudson M3.

Does anyone know if there are public docs for the A76M (possibly under
another name), and how feasible it is to drive it with current public
(or to-be-released) AGESA?

Anyway, how it looks with AMD/AGESA story?

I think bolton should be very similar to Hudson, and googling for A88X its
revision number starts at 16h (the hudson had 11-14h)

There is a good chance that Bolton will somewhat work with current hudson I
think - even PCI IDs match.

Maybe we can try first to support some FM2+ board with bolton and see how it
goes. I'm all for that considering the effort I put into the FCH/Trinity AGESA
it would be a shame if it is wasted just with a single board ;)

Possible candidates:
Looks quite new (seems released this year)

ASUS A88X-PLUS  (Lunched 09/11/2013)
ASUS A88X-PRO (Lunched in January?)
A88XM-A (Lunched 07/29/2013)

Most promising:
ASUS A78M-E - AMD A78 (very new, microITX, cheap, ITE sio)

Very similar:
ASUS A78M-A (but more dimm slots, supported SIO, launched February?)

Is here someone who wants to work on this perhaps together with me? (of course
donations welcome ;) I will buy some / work on that only if someone else buys it
too.

Thanks
Rudolf

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

Re: [coreboot] PIC instead of APIC mode for KolibriOS - mouse fix

[Rudolf Marek]

Hi all,

1) we should provide at least the MP-Table. There is a still lot of OS without 
ACPI support (various homebrew OS, RTOS etc) which don't want to carry the 
ACPICA just to get idea how to route IRQs...


2) if we want to setup the PCI for PIC we need to do:

a) setup the PCI router (just couple of regs in the SB)
This is done by: pirq_assign_irqs()
b) setup the ELCR (0x4d0/0x4d1) set IRQs to level, this is done by: 
i8259_configure_irq_trigger()
c) setup the 0x3c values in the PCI regs this is done by: pirq_route_irqs() 
which does the job if CONFIG_PIRQ_ROUTE


Oh yes coreboot knows how to do that if PIR table is present in quite generic 
way. Setting this up should not break things, except that AMD SB700 or similar 
needs to disable the IRQ routing to PIC in ASL code in _PIC method. I don't know 
if this necessary.


Thanks
Rudolf

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

Re: [coreboot] ASUS F2A85-M (Pro)

[Rudolf Marek]

Hi Kete

Yes it looks like the ASUS F2A85-M is already phased out. It s a pity because I 
always fix everything when it is already quite late.


I checked the PRO variant and it has other SuperIO chip and other ASIC chips for 
the advanced overclocking. The board is very different from the coreboot 
perspective, however there is still a chance that some basic things will work 
out of the box if implemented as new board.


It would be the best if I could get this board to make it work. It depends on 
your budget. I can try to help via email but it will be quite slow process 
because the board is quite different.


Maybe someone else from coreboot community is willing to buy this board?

Thanks
Rudolf


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

[coreboot] eventlong backtrace support

[Rudolf Marek]

Hi all,

I'm still suffering with following errors ONLY when using 4 core Trinity CPU on 
the F2A85-M:


EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.
...

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.

EventLog:  EventClass = 2, EventInfo = 8040100.
  Param1 = a00a, Param2 = 0.
  Param3 = 0, Param4 = 0.
agesawrapper_amdinitpost failed: 4
Got past agesawrapper_amdinitpost

There is about 10? of them. System seems to boot fine. I still dont know what 
those are but I decided to attack the problem via a backtrace.


I implemented a simple backtracer which I placed in the AGESA PutEventLog() 
function. Once the function is visited I print:


agesawrapper_amdinitreset Fch OEM config in INIT RESET Done
EVENT BACKTRACE:
0xff82cfa7
0xff82f333
0xff82f377
0xff834e5a
0xff8349b2
0xff838bf3
0xff83663d
0xff837495
0xff861999
0xff8346f1
0xff82d661
0xff81db3c
0xff81a355

EVENT BACKTRACE:
...


Then with simple(stupid) script:

cat - | while read line ; do
unset A
if  echo $line | grep ^0x  /dev/null  ; then
A=`addr2line -e build/cbfs/fallback/romstage_xip.elf  $line | tr -d \n`
fi
echo $line $A

done

It turns to:
agesawrapper_amdinitreset Fch OEM config in INIT RESET Done
EVENT BACKTRACE:
0xff82cfa7 
/home/ruik/coreboot/src/vendorcode/amd/agesa/f15tn/Proc/CPU/heapManager.c:662
0xff82f333 
/home/ruik/coreboot/src/vendorcode/amd/agesa/f15tn/Proc/Common/S3SaveState.c:217
0xff82f377 
/home/ruik/coreboot/src/vendorcode/amd/agesa/f15tn/Proc/Common/S3SaveState.c:256
0xff834e5a 
/home/ruik/coreboot/src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbCommonLib/GnbLibPciAcc.c:96
0xff8349b2 
/home/ruik/coreboot/src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbCommonLib/GnbLib.c:161
0xff838bf3 
/home/ruik/coreboot/src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GnbRegisterAccTN.c:1241
0xff83663d 
/home/ruik/coreboot/src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GfxLibTN.c:330
0xff837495 
/home/ruik/coreboot/src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GnbEarlyInitTN.c:840
0xff861999 
/home/ruik/coreboot/src/vendorcode/amd/agesa/f15tn/Proc/GNB/Common/GnbLibFeatures.c:99
0xff8346f1 
/home/ruik/coreboot/src/vendorcode/amd/agesa/f15tn/Proc/GNB/GnbInitAtEarly.c:122
0xff82d661 
/home/ruik/coreboot/src/vendorcode/amd/agesa/f15tn/Proc/Common/AmdInitEarly.c:270

0xff81db3c /home/ruik/coreboot/src/mainboard/asus/f2a85-m/agesawrapper.c:234
0xff81a355 /home/ruik/coreboot/src/mainboard/asus/f2a85-m/romstage.c:135

EVENT BACKTRACE:

It makes me wonder why we dont have such backtrace function available? Or did I 
miss something? Anyway I'm attaching a diff how this was hacked in. I wont have 
time for this for couple of days. It could be handy for someone else, or even 
better make it a real feature :)


Thanks
Rudolf





diff --git a/Makefile.inc b/Makefile.inc
index 315a9d9..ea57a8b 100644
--- a/Makefile.inc
+++ b/Makefile.inc
@@ -223,7 +223,8 @@ CFLAGS += -Wstrict-aliasing -Wshadow
 ifeq ($(CONFIG_WARNINGS_ARE_ERRORS),y)
 CFLAGS += -Werror
 endif
-CFLAGS += -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer
+CFLAGS += -fno-common -ffreestanding -fno-builtin 
+#-fomit-frame-pointer
 
 additional-dirs := $(objutil)/cbfstool $(objutil)/romcc $(objutil)/ifdtool \
 		   $(objutil)/ifdfake $(objutil)/options
diff --git a/src/arch/x86/lib/c_start.S b/src/arch/x86/lib/c_start.S
index faea22d..8df4324 100644
--- a/src/arch/x86/lib/c_start.S
+++ b/src/arch/x86/lib/c_start.S
@@ -88,6 +88,7 @@ _start:
 #if CONFIG_GDB_WAIT
 	call gdb_stub_breakpoint
 #endif
+	xorl %ebp, %ebp /* construct valid stackframe */
 	call	main
 	/* NOTREACHED */
 .Lhlt:
diff --git a/src/cpu/amd/agesa/cache_as_ram.inc b/src/cpu/amd/agesa/cache_as_ram.inc
index 449cf69..288f5d2 100644
--- a/src/cpu/amd/agesa/cache_as_ram.inc
+++ b/src/cpu/amd/agesa/cache_as_ram.inc
@@ -76,6 +76,7 @@ cache_as_ram_setup:
 
   pushl %ebx  /* init detected */
   pushl %edx  /* bist */
+  xorl %ebp, %ebp /*set stack frame end */
   call  cache_as_ram_main
 
   /* Should never see this postcode */
diff --git a/src/cpu/x86/lapic/secondary.S b/src/cpu/x86/lapic/secondary.S
index 6edcd0a..5c79e87 100644
--- a/src/cpu/x86/lapic/secondary.S
+++ b/src/cpu/x86/lapic/secondary.S
@@ -59,7 +59,7 @@ __ap_protected_start:
 	movl	secondary_cpu_index, %edi
 	pushl	%edi
 	movl	%eax, secondary_stack
-
+	xorl %ebp, %ebp /* valid stackframe */
 	call	secondary_cpu_init
 1:	hlt
 	jmp	1b
diff --git a/src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuEventLog.c b/src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuEventLog.c
index f73f50b..c02a7b0 100644
--- a/src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuEventLog.c
+++ b/src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuEventLog.c
@@ -189,6 +189,29 @@ EventLogInitialization (
  * @param[in]   StdHeaderHeader for library and services
  

Re: [coreboot] Flash access on ASUS F2A85 variants

[Rudolf Marek]

Hi Stefan,
 I could not find any details but the error message one receives:

ERROR: State of SpiAccessMacRomEn or SpiHostAccessRomEn prohibits full
access.


Found ITE Super I/O, ID 0x8603 on port 0x2e
Found chipset AMD FCH with PCI ID 1022:780e. Enabling flash write... SPI base 
address is at 0xfec1

Hudson-2/3/4 detected.
SpiRomEnable=1, PrefetchEnSPIFromIMC=0, PrefetchEnSPIFromHost=1
(0x6f4c2105) SpiArbEnable=1, SpiAccessMacRomEn=1, SpiHostAccessRomEn=0, 
ArbWaitCount=7, SpiBridgeDisable=1, SpiBusy=0

ERROR: State of SpiAccessMacRomEn or SpiHostAccessRomEn prohibits full access.


If I read the documentation of SpiHostAccessRomEn correctly then it
should not bother us at all. It indicates it the ethernet firmware can
access the host partition of the flash chip. If however the other bit
(SpiAccessMacRomEn) is reset to 0 then we indeed have a problem.


Yes I tried to disable the check and got following (I was testing BIOS version 
6502)

Found Winbond flash chip W25Q64.V (8192 kB, SPI).
This chip may contain one-time programmable memory. flashrom cannot read
and may never be able to write it, hence it may not be able to completely
clone the contents of this chip (see man page for details).
coreboot last image size (not ROM size) is 8388608 bytes.
Manufacturer: ASUS
Mainboard ID: F2A85-M
Reading old flash chip contents... FIFO pointer corruption! Pointer is 0, 
wanted 3
Something else is accessing the flash chip and causes random corruption.
Please stop all applications and drivers and IPMI which access the flash chip.
FAILED.


Can someone please send me the verbose output of flashrom to confirm
which one it is? And I am also looking for testers with these boards,
because I think the abort on SpiHostAccessRomEn is a bug in flashrom.


Hm looks like something will happen, becuase it does not work. This board has 
external ethernet chip. So the only master accessing the chip could be USB 3.0
firmware. But, this works fine with coreboot and also removing the XHCI drivers 
did not help.


Maybe some protection bits are set elsewhere.

This is dump of MMIO space:

hexdump -C a.bin
  05 21 4c 6f 00 00 00 00  00 06 00 00 00 70 00 02  |.!Lo.p..|
0010  06 20 04 04 06 04 9f 05  03 0b 0a 02 ff 88 00 3b  |. .;|
0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
*

It looks like (look to 48751 Rev 3.00 - May 30, 2013 BKDG for AMD Family 16h 
Models 00h-0Fh Processors)


SPIx1D Alt_SPI_CS  0x88

SpiProtectEn0. IF (SPIx1D[SpiProtectLock]==1) THEN Read-only. ELSE Read-write. 
ENDIF.


Reset: 0. 1=Enable SPI read/write protection ranges specified by 
D14F3x[5C,58,54,50].


Funny is that the SPiProtectLock is not set to 1

00:14.3 ISA bridge: Advanced Micro Devices [AMD] Hudson LPC Bridge (rev 11)
00: 22 10 0e 78 0f 00 20 02 11 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 27 85
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 04 00 00 00 d5 ff 03 ff 07 ff 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

And all protection ranges are 0 anyway...

60: 00 00 00 00 30 02 00 00 00 00 0f 00 00 ff ff ff
70: 67 45 23 00 00 00 00 00 9c 00 00 00 05 0b 00 00
80: 08 00 03 a8 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 00 c1 fe 2f 01 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 e9 45 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 17 00 82 ff
d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

And clearing the bit 4 of 1d also did not help. So it must be something else 
elsewhere.


I hope this is enough information for the start ;)

Thanks
Rudolf


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

Re: [coreboot] Flash access on ASUS F2A85 variants

[Rudolf Marek]

Hi Stefan,

I just tried with v6402 which is open:

00:14.3 ISA bridge: Advanced Micro Devices [AMD] Hudson LPC Bridge (rev 11)
00: 22 10 0e 78 0f 00 20 02 11 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 27 85
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 04 00 00 00 d5 ff 03 ff 07 ff 00 00 00 00 00 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 30 02 00 00 00 00 0f 00 00 ff ff ff
70: 67 45 23 00 00 00 00 00 9c 00 00 00 05 0a 00 00
80: 08 00 03 a8 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 02 00 c1 fe 2f 01 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 e9 45 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 17 00 82 ff
d0: 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

ruiktest ~ # hexdump -C a.bin
  05 21 cc 6f 00 00 00 00  00 00 00 00 00 70 00 02  |.!.o.p..|
0010  06 20 04 04 06 04 9f 05  03 0b 0a 02 ff 88 00 3b  |. .;|
0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||

The newer (locked) version from last email:

hexdump -C a.bin
  05 21 4c 6f 00 00 00 00  00 06 00 00 00 70 00 02  |.!Lo.p..|
0010  06 20 04 04 06 04 9f 05  03 0b 0a 02 ff 88 00 3b  |. .;|
0020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  ||
*

It looks that the the SPI CMD 06 is now restricted CMD for MAC and 
SPIhostaccesRomEn is clear.


I tried to boot with open version v6402 and then just clear the
SpiHostAccessRomEn without setting any other bits and I receive failure even for 
read:


./flashrom/flashrom -V -p internal  -r bios_open.bin

Found Winbond flash chip W25Q64.V (8192 kB, SPI).
This chip may contain one-time programmable memory. flashrom cannot read
and may never be able to write it, hence it may not be able to completely
clone the contents of this chip (see man page for details).
Reading flash... FIFO pointer corruption! Pointer is 0, wanted 3
Something else is accessing the flash chip and causes random corruption.
Please stop all applications and drivers and IPMI which access the flash chip.
Read operation failed!
FAILED.

Yes it looks like something is happening with flashrom / controller if 
SpiHostAccessRomEn is cleared.


Thanks
Rudolf

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

Re: [coreboot] S3 Resume on AMD Trinity APU

[Rudolf Marek]

Hi,

It works fine with DVI ans SUB. No need to re-run anything at least in the 
Linux.

Thanks
Rudolf

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

Re: [coreboot] I've turned on paging as a test

[Rudolf Marek]

Hi all,

1) As for NULL checkes I did something similar years ago:

http://www.coreboot.org/pipermail/coreboot/2011-July/065792.html


Here is a PoC of NULL pointer dereference checking in coreboot x86. It is
surprisingly easy to implement.

It uses strange expand down segments, making a data segment from 4KB-4GB (with
base 0). It should catch most NULL derefence symbols. Unfortunately we access
0x500 while placing the coreboot tables. The hack in the patch just swaps the ds
selector work arounding that.

More advanced method would use paging and PAE, first 4MB with 4KB pages rest
with 4MB pages identity mapped. We could even mark other than coreboot RAM range
as missing allowing more fine grained tests what is where accessed.

Even the segment hack above could be used to check the stack overflows, but I
think we will need in IDT instead of interrupt gate a task gate and set there a
exception stack, otherwise it will end very badly while CPU is trying to safe
stack yet again during the exception.


2) There is a performance impact if you map first 2MB/4MB of RAM via ONE PAE 
page It is described in intel manual, but I don't recall on which page. I don't 
know how big the impact is. (there is a impact because of MTRR regions for 
0-1MB), so one might use 4KB pages for first 1MB...


3) To solve a problem with legit BDA stuff... Just add some function to remap 
parts to some other and use virtual address to do that. We might eventually 
define some region like D-seg to be on 0x instead on 0xd and problem 
solved


4) some processors have bugs in PAT, mainly with WC override. Linux says:
 /*
 * There is a known erratum on Pentium III and Core Solo
 * and Core Duo CPUs.
 *  Page with PAT set to WC while associated MTRR is UC
 *   may consolidate to UC 
 * Because of this erratum, it is better to stick with
 * setting WC in MTRR rather than using PAT on these CPUs.
 *
 * Enable PAT WC only on P4, Core 2 or later CPUs.
 */
if (c-x86  0x6 || (c-x86 == 6  c-x86_model = 15))
return;

pat_disable(PAT WC disabled due to known CPU erratum.);
return;

Thanks
Rudolf


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

Re: [coreboot] F2A85-M coreboot not working

[Rudolf Marek]

Hi all,

I'm back. Any news on this issue?

Thanks
Rudolf

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

Re: [coreboot] Unable to start correctly coreboot on Asus f2a85-m REV 1.02

[Rudolf Marek]

Hi all,

I checked the BKDG on AMD website and there is not much register differences 
between those CPUs:


42300 Rev 3.10 - June 04, 2013 BKDG for AMD Family 15h Models 10h-1Fh 
Processors:

1.5.4 Changes For Revision RL-A1
• Changes that may result in BIOS modifications.
• Added 2.5.9.1 [Hybrid Boost]
• Added D0F0xBC_x1F428[HybridBoostEn]
• Other changes
• Added D0F0xBC_x1F8EC

It is just related to hybridboost enable.

The only thing which might really need an update is a SMU firmware. It would be 
interesting to try with original BIOS if some other SMU firmware is used when 
trinity or richland CPU is used.


Do you own also Trinity CPU?

As for the errata, I think I have seen somewhere that the processors share the 
lists.


I wrote just a note to the board wiki page about Richland, maybe we can do some 
#ifdef config option which would enable this hack via configuration option.


We would also need some more sane error handling code in AGESA. I guess we can 
fix it with some patch. Any takers?


Thanks
Rudolf





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

Re: [coreboot] Unable to start correctly coreboot on Asus f2a85-m REV 1.02

[Rudolf Marek]

Perfect thank you for this whole procedure. This is what I obtain:

My rom (with my vga bios):
coreboot-4.0-5394-gba6b07e Thu Jan 30 19:48:58 CET 2014 starting...
BSP Family_Model: 00610f31
cpu_init_detectedx = 
agesawrapper_amdinitreset


OK. Please can you enable AGESA debug stuff. It should produce more
output.

You can do that by uncommenting #define IDSOPT_IDS_ENABLED in mainboard 
directory OptionsIds.h file.


We dont have a menuconfig for that yet.

Thanks
Rudolf


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

Re: [coreboot] Plans to give the DSPIF away at FOSDEM WAS: Re: Dual SPI Flash adapter attempt 2.0

[Rudolf Marek]

On 25.1.2014 12:01, Oliver Schinagl wrote:

Nobody interested at all?


Well not true :) I thought immediately oh nice I always wanted to design that. I 
was not in the FOSDEM this year, but if usual suspect have them, I will ask them 
if they could ship it to me!


Anyway thanks for a great tool.

Thanks
Rudolf

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

Re: [coreboot] Unable to start correctly coreboot on Asus f2a85-m REV 1.02

[Rudolf Marek]

On 31.1.2014 13:53, HacKurx wrote:

No way. You will need to use serial port. Just plug the header to mainboard and 
use some USB 2 serial from other computer (together with null
modem cable) if you need more info please let me know.

Do you have any links, diagram or picture for this method? Thanks


Yes sure. You will need at least those things:

1) serial header connector

http://www.ebay.com/itm/DB9-Male-RS232-COM-Port-Serial-Header-Cable-for-Asus-Gigabyte-ATX-Motherboard-/151124424976?pt=LH_DefaultDomain_0hash=item232fb7b910

You can take any from some old motherboard. Usually there where two variants of 
pinout. The newer one fits the most mainboards. You need to plug it to a header 
on the f2a85-m board. (pin1 to the color stripe on the cable)  I think it is 
called COM header in the manual.


2) null modem cross cable

The header from 1) needs to be plugged to 2)

This cable is very common. It is also called crossed cable with female/female 
9 pin connector.


http://www.ebay.com/itm/Serial-RS232-Null-Modem-Cable-Female-to-Female-DB9-FTA-/270787845377?pt=AU_CablesConnectorshash=item3f0c369d01

(female / female)

3) USB to serial cable

Either find some other computer which has a serial header (and you will need 
second header from 1)) or buy this convertor. Most of them use pl2303 or ftdi 
chip which is well supported under linux.


http://www.ebay.com/itm/USB-to-RS232-Serial-Port-9-Pin-DB9-Cable-Serial-COM-Port-Adapter-Convertor-2014-/201011761929?pt=US_Parallel_Serial_PS_2_Cables_Adaptershash=item2ecd3c1309

4) other computer (any laptop/desktop)

Plug in the USB serial with all cables plugged, and use /dev/ttyUSB0

use minicom or hyperterminal if you use windows. Set it 115200 8N1 (8 byte 1 
stop bit no parity)


You should see some output of coreboot. Capture it via (ctrl a l shortcut in 
minicom) to a file and send it back to list.


If is something unclear, please let us know. You need to make it up to next 
Friday. I will be then long time AFK and I will back in March.


Thanks
Rudolf


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

Re: [coreboot] Unable to start correctly coreboot on Asus f2a85-m REV 1.02

[Rudolf Marek]

On 30.1.2014 11:03, HacKurx wrote:

Is it Richland or Trinity? Seems it is Richland. I haven't tried with Richland 
yet.

Yes indeed it's Richland.


It would be helpful if you could include log from serial console. Maybe you hit 
some other problem.

How without serial port?


No way. You will need to use serial port. Just plug the header to mainboard and 
use some USB 2 serial from other computer (together with null modem cable) if 
you need more info please let me know.



Is it Richland or Trinity? Seems it is Richland. I haven't tried with
Richland yet.
It looks some people can send me some money and I could buy the richland to see 
if it workks... but this could happen somewhere in March.



Can you send me a link to a known-good image that you use? So that i can
verify my hardware is compatible.


The image I sent to you will most likely not POST the image because of different 
IDs, but X.org could initialize it.


Thanks
Rudolf

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

Re: [coreboot] Unable to start correctly coreboot on Asus f2a85-m REV 1.02

[Rudolf Marek]

Hi,

 _F2A85-M REV 1.02

_AMD A8-6600K APU (Radeon HD 8570D vga = 1002,990e)
_Corsair Value Select 4 Go DDR3 1333 MHz CL9 (CMV4GX3M1A1333C9)


Is it Richland or Trinity? Seems it is Richland. I haven't tried with Richland 
yet.


I proceeded to build a standard coreboot image using seabios as a
payload (using a local copy of the VGA bios and embedding this into
the coreboot image), leaving all the settings as
default apart from selecting the motherboard, upon writing this to the
flash and rebooting the machine I had no output from the VGA  HDMI adapter and
and my keyboard is frozen.


It would be helpful if you could include log from serial console. Maybe you hit 
some other problem.


You can also try to put memory only to blue slots.


Can you send me a link to a known-good image that you use? So that i can
verify my hardware is compatible.



 Does he work the revision 1.02 of this motherboard in coreboot?

Mine board is also 1.02 version. I think something wrong is with memory setup or 
cpu setup. Does original BIOS use 1.65V for DDR2 memory? You should select that 
in configuration too.


You can come to IRC #coreboot on freenode.net

I'm here until midnight GMT+2

Thanks
Rudolf






Thank you for your help.



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

Re: [coreboot] ATTN: ruik, others: f2a85-m frequently crashes/freezes under high load. do you have it working?

[Rudolf Marek]

Hi again,

So far I had no luck reproducing it. Can you provide output of following command 
please:


sudo setpci -s 14.0 8.b


It should print number like 11, 12, 13 or 14.

This is in fact your SB revision. I need it to check the errata sheet. Also 
please provide the clock source information I requested in the last mail.


Thanks
Rudolf


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

[coreboot] q to AMD folks - version of CIMX of fam15tn

[Rudolf Marek]

Hi all,

Please can anyone with access to AGESA check what version of AGESA and CIMX (FCH 
module) was used for coreboot release?


I want to check some erratas and AMD 48671 document 
http://support.amd.com/TechDocs/48671.pdf


Refers to CIMX versions, however there is no define with CIMX version in 
coreboot only some define for CIMX header.


Second q is more about the CPU itself. What revision of AMD errata document 
corresponds with fixes implemented in coreboot AGESA.


And last q is. Will anyone backporting fixes from AMD agesa to coreboot agesa?

Thanks
Rudolf

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

Re: [coreboot] ATTN: ruik, others: f2a85-m frequently crashes/freezes under high load. do you have it working?

[Rudolf Marek]

Hi Andrew,

ruik, do you have a working setup with a f2a85-m motherboard at the
moment (i.e. .config file, graphics card, distro/kernel version being
used?) if nothing is working for you right now, how can we narrow this down?


Yes it seems it is working fine.

You can check http://www.coreboot.org/Supported_Motherboards

Or check:

http://review.coreboot.org/gitweb?p=board-status.git;a=blob;hb=HEAD;f=asus/f2a85-m/4.0-5192-g812d624-dirty/2014-01-03T19:55:05Z/config.txt

Note that I'm using 1.65V for DDR3 memory. Please check your memory voltage in 
original bios if it is 1.5V or 1.65V. From what I seen in the longs it seems 
something dies in kernel, maybe interrupts or timer. Could be some unfixed 
errata. I run memtester in userspace today and I seen one mem problem (on 1.65V mem)


I use some Linux Mint, but mostly I just boot with this kernel.

http://review.coreboot.org/gitweb?p=board-status.git;a=blob;hb=HEAD;f=asus/f2a85-m/4.0-5005-g4eb4a1f-dirty/2013-12-07T22:13:15Z/kernel_log.txt


to anyone else: do you find that using one graphics card with coreboot,
works while others do not? any ideas on how i can resolve this issue?


I don't have any recent external graphics card. I only use internal one with 
this board. I want to use it as my next workstation, I did not do any longrun 
testing yet.




the problems i've been seeing are quite reliable. they happen when using
coreboot + one of a couple graphics card models i've tried + extended
high disk i/o, all together. at other times, these issues are more rare.
also, a somewhat older compilation of coreboot with a vga_bios and
without an external graphics card is crashing multiple times per day,
during that person's day-to-day work flow.


Hm strange I have not seen any crashes like this.


i would like to get coreboot with this motherboard working, so more
people here can use it. :)


Yep great!


my guess is that this is an issue with option roms playing nasty with
coreboot, and that this issue is for some reason brought forth by the
high i/o test. if any of those factors are absent, crashes are far less
frequent, if at all.

- - - - - - - - -

i've been seeing crashing with f2a85-m motherboards with an a8-5600k
processor. vga bioses have not been compiled in to coreboot.


My CPU is also 0x00610f01 but it is AMD A4-5300 APU with Radeon(tm) HD Graphics.



kernel-loading of recent amd microcode has not solved the problem.
option roms get loaded by seabios (




the stress test i've been using is mostly running badblocks on repeat
using a couple sata drives. the other test has been building four
kernels at once.


Can you share the scripts? I tried today reading with DD on two harddrives and 
it was fine.



if anyone has any idea of what the issue(s) may be here, or how i could
try narrowing this down, please help me out. thanks! :)


It could be some unfixed errata.

http://support.amd.com/TechDocs/48671.pdf
http://developer.amd.com/wordpress/media/2012/10/48931_15h_Mod_10h-1Fh_Rev_Guide.pdf

I think I need to reproduce the problem first. I seen some PM_timer problem. 
What is your clocksource?


cat /sys/devices/system/clocksource/clocksource0/current_clocksource

I also seen some errata about USB3.0 controllers. Can you exclude usage of USB 
3.0?

If you run memtester under Linux it is oK?

Thanks
Rudolf





-andrew





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

Re: [coreboot] coreboot on amd A85 can't work

[Rudolf Marek]

Hi 陈军根,

Please put to cc the mailing list.

I  can't find spdAddressLookup in dimmSpd.c(coreboot v4),but I find

Ahh yes it seems to move to generic wrapper code. You will need to modify 
devicetree.cb where is the table and then it is generated as static.c


 ROMSTAGE_CONST struct northbridge_amd_agesa_family15tn_config ROMSTAGE_CONST

northbridge_amd_agesa_family15tn_info_6 = {
  .spdAddrLookup =
{
 { {0xA0, 0xA4}, {0xA2, 0xA6}, }, // socket 0 - Channel 0  1 - 8-bit SPD
addresses
 { {0x00, 0x00}, {0x00, 0x00}, }, // socket 1 - Channel 0  1 - 8-bit SPD
addresses
},
};
in build/mainboard/asus/f2a85-m/static.c
  I changed the spdAddrLookup to
{ {0xA0, 0x00}, {0xA2, 0x00}, }, // socket 0 - Channel 0  1 - 8-bit SPD 
addresses
 { {0x00, 0x00}, {0x00, 0x00}, }, // socket 1 - Channel 0  1 - 8-bit SPD
addresses
and
{ {0xA0, 0x00}, {0x00, 0x00}, }, // socket 0 - Channel 0  1 - 8-bit SPD 
addresses
 { {0xA2, 0x00}, {0x00, 0x00}, }, // socket 1 - Channel 0  1 - 8-bit SPD
addressese

but I got the same error messages

assertion Failed:file
  'src/vendorcode/amd/agesa/f15tn/proc/mem/main/mmexcludedimm.c',line 236.
Do you have other options?


Yes, we need to find out what is the right mapping for the SPD, and that SPD can 
be read.


Yes you will need to do the i2c SPD address mapping procedure as I described in 
last email:



If you don't like the ad-hoc method, try booting original BIOS with only one 
DIMM in chanel 0 and do following from Linux:

modprobe i2c-dev
modprobe i2c-piix4
i2cdetect -l

This will show i2c bus of PIIX4 aka hudson, if you have a video drivers loaded 
it will be some non-zero number. I use zero as an example:

i2cdetect 0

This will detect the chips on SPD bus. If you plug your DIMM to channel zero 
and see address 0x50 is used then the first line has valid first entry. The 
second entry in first line will be zero for you because you have only 2 dimms.

So repeat the steps and plug it to second slot and see what address you will 
get. It could be 0x51 or 0x52 as suggested above.


You could also check if you get at least some valid data. You can do that by 
adding some debug information to readspd() in 
coreboot/src/northbridge/amd/agesa/family15tn/dimmSpd.c Maybe someone put some 
multiplexer or you have SPD on secondary controller.


You will need to include #include console/console.h

and do printk(BIOS_DEBUG, ...%x ..., )

Then you can also enable debug messages for AGESA, which
you can do by uncommenting #define IDSOPT_IDS_ENABLED in mainboard directory
OptionsIds.h I dont think we have a menu config option for that... we should 
have... I hope it will work.


we are usually also on IRC channel #coreboot at irc.freenode.net

Btw does your memory need 1.3 1.5 or 1.65 volts? Can you check original BIOS 
what is the voltage applied there?


Thanks
Rudolf



thank you very much!
  cjg

-- Original --
*From: * Rudolf Marekr.ma...@assembler.cz;
*Date: * Tue, Dec 17, 2013 03:57 PM
*To: * 陈军根c...@bolod.net;
*Cc: * corebootcoreboot@coreboot.org;
*Subject: * Re: [coreboot] coreboot on amd A85 can't work
On 13.12.2013 08:57, 陈军根 wrote:
  Dear all:
I run coreboot in ASUS F2A85-MLE CPU is A10-5800k, kingston ddr3

Hi

Please note that the board is F2A85-M without the LE. Maybe there is something
different. Try using only one dimm in different slots.

The M version has 4 DIMMS your seems to use only 2 dimms: You can also try to
edit:

spdAddressLookup in dimmSpd.c in the mainboard directory.
  // socket 0
  {

  {0x50  1, 0x52  1},  // channel 0 dimms
  {0x51  1, 0x53  1},  // channel 1 dimms

To something else like:

  {0x50  1, 0x00},  // channel 0 dimms
  {0x51  1, 0x00},  // channel 1 dimms
Or:

  {0x50  1, 0x00},  // channel 0 dimms
  {0x52  1, 0x00},  // channel 1 dimms

If you don't like the ad-hoc method, try booting original BIOS with only one
DIMM in chanel 0 and do following from Linux:

modprobe i2c-dev
modprobe i2c-piix4
i2cdetect -l

This will show i2c bus of PIIX4 aka hudson, if you have a video drivers loaded
it will be some non-zero number. I use zero as an example:

i2cdetect 0

This will detect the chips on SPD bus. If you plug your DIMM to channel zero and
see address 0x50 is used then the first line has valid first entry. The second
entry in first line will be zero for you because you have only 2 dimms.

So repeat the steps and plug it to second slot and see what address you will
get. It could be 0x51 or 0x52 as suggested above.

Thanks
Rudolf

  1600(kvr1600d3n9/4g),coreboot halt at assertion Failed:file
  'src/vendorcode/amd/agesa/f15tn/proc/mem/main/mmexcludedimm.c',line 236. I
  don't know how to do, can anyone help me?
  thanks very much!
 
 


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