Re: [coreboot] memtest86 reading 0k memory

[Scott Duplichan]

Timothy Pearson [mailto:tpear...@raptorengineeringinc.com] wrote:

]Sent: Thursday, February 05, 2015 06:49 PM
]To: Coreboot
]Subject: Re: [coreboot] memtest86 reading 0k memory
]
]On 02/05/2015 06:42 PM, Timothy Pearson wrote:
] On 02/05/2015 02:06 PM, Timothy Pearson wrote:
] On 02/05/2015 01:51 PM, Aaron Durbin wrote:
] Do you have the coreboot console log? Looking at memtest86 it
] constructs its own e820 when using linuxbios. Additionally, it also
] has some concept of a window to test as well as plim_lower and
] plim_upper variables that seem to add to the mix.
]
] What's super frightening is that find_chunks(int tst) is called in the
] code as find_chunks() while the find_chunks() function actually
] references tst as an array index. That's all from config.c. But I
] think that's only if you hit c on the keyboard. I wouldn't do that...
]
] I can't make heads or tails of that code at the moment. for selecting
] the window to test.
]
] Please see text log attached. It looks like the failing accesses start
] at 0xa, which (judging by memtest's effects on the screen) appears
] to be mapped to the VGA text buffer. That region is *not* reserved under
] the proprietary BIOS's e820 map.
]
] Thanks!
]
]
] I was able to resolve the lower MMIO region failures (coreboot driver
] patch in for review), but memtest86 is stubbornly insisting on testing
] reserved memory, causing a single failure at 3ffade80. The e820 map says
] that address is out of bounds but the coreboot tables do not:
]
] e820 map has 6 items:
] 0:  - 0009fc00 = 1 RAM
] 1: 0009fc00 - 000a = 2 RESERVED
] 2: 000f - 0010 = 2 RESERVED
] 3: 0010 - 3ffad000 = 1 RAM
] 4: 3ffad000 - 4000 = 2 RESERVED
] 5: e000 - f000 = 2 RESERVED
]
] coreboot table: 460 bytes.
] CBMEM ROOT 0. 3000 1000
] CONSOLE 1. 3ffdf000 0002
] TIME STAMP 2. 3ffde000 1000
] GDT 3. 3ffdd000 1000
] SMP TABLE 4. 3ffdc000 1000
] ACPI 5. 3ffb8000 00024000
] SMBIOS 6. 3ffb7000 1000
] COREBOOT 7. 3ffaf000 8000
]
] Why the discrepancy? Am I correct in assuming this is a bug in coreboot
] that needs to be fixed?
]
]
]Sorry, wrong coreboot table above:
]
]Writing coreboot table at 0x3ffaf000
]rom_table_end = 0x3ffaf000
]... aligned to 0x3ffb
]  0. -0fff: CONFIGURATION TABLES
]  1. 1000-0009: RAM
]  2. 000a-000a: RESERVED
]  3. 000b-000b7fff: RAM
]  4. 000b8000-000b: RESERVED
]  5. 000c-3ffaefff: RAM
]  6. 3ffaf000-3fff: CONFIGURATION TABLES
]  7. e000-efff: RESERVED
]
]I assume something is placing itself at 3ffad000 (coreboot? SeaBIOS?) 
]and that overwriting it is a Bad Thing, but whatever it is does not 
]update the coreboot tables and memtest86 promptly stomps on it.

I imagine SeaBIOS is taking memory from the end of free RAM below
4GB for USB structures. There is probably an incrementing frame
counter at 3ffade80. It looks like SeaBIOS builds the E820 table
to properly account for the memory it uses. If memtest86 uses the
coreboot tables even when an E820 handler is installed, that seems
wrong. Unless SeaBIOS is supposed to adjust the coreboot tables to
reflect its memory usage, which I don't think is the case.

]-- 
]Timothy Pearson
]Raptor Engineering
]+1 (415) 727-8645
]http://www.raptorengineeringinc.com



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

Re: [coreboot] AMD Mahogany Fam10 not booting

[Scott Duplichan]

Carl-Daniel Hailfinger [mailto:c-d.hailfinger.devel.2...@gmx.net] wrote:

]Sent: Tuesday, February 03, 2015 06:04 PM
]To: coreboot@coreboot.org
]Subject: Re: [coreboot] AMD Mahogany Fam10 not booting
]
]On 02.02.2015 06:30, Kyösti Mälkki wrote:
] On 02/02/2015 05:40 AM, Scott Duplichan wrote:
] I found coreboot for AMD Mahogany Fam10 is no longer working. The
] problem
] starts with this change:
] http://www.coreboot.org/pipermail/coreboot-gerrit/2013-July/002391.html
]
] Some other older AMD boards are likely affected too. [...]
]
] Known issue, I am sorry you had to bisect this one too in the lack of
] bug tracking. [...]
]
]Would the automated testsystem have caught this? If yes, which platforms
]should be present in this automated testsystem to have reasonably good
]coverage of systems still relevant to the community?

Hello Carl-Daniel,

An automated test system would catch this problem, though setting up
such a thing sounds like a lot of work. Also, RS780 boards are a couple
of generations old now and losing importance. Why did I try to boot an
old RS780 board after all these years? The reason is that I wanted to
see if the public version of AMD simnow could boot a coreboot project.
AMD simnow is the only publically available tool I know of that lets you
step through coreboot code starting from the reset vector to see how
it works. AMD simnow might still be able to boot AMD Serengeti Cheetah,
but that one uses a really old chipset. Unfortunately the public version
of simnow supports no processor newer than family 10h. The simnow 
Mahogany family 10h model is compatible with the ECS board I have, so I
chose it. Interestingly, simnow does not catch the configuration space
problem that keeps the real board from booting. Another complication is
that the simnow RS780 model doesn't correctly handle the option to make
'BAR3' read only. This results in coreboot seeing a memory BAR that
wants 4GB of space, and that causes a boot fail.

Thanks,
Scott  

]I hope to get the chance to allocate resources to run a bunch of
]platforms in my own automated testsystem. A list of maybe 5-10 desirable
]platforms/boards would be appreciated, preferably not just Thinkpads and
]Chromebooks. If this works out (should know about this by May/June),
]those boards would end up testing every mainline commit.
]
]Regards,
]Carl-Daniel



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

Re: [coreboot] AMD Mahogany Fam10 not booting

[Scott Duplichan]

Patrick Georgi [mailto:patr...@georgi-clan.de] wrote:

]Sent: Wednesday, February 04, 2015 11:57 AM
]To: Scott Duplichan
]Cc: coreboot@coreboot.org
]Subject: Re: [coreboot] AMD Mahogany Fam10 not booting
]
]Am 2015-02-04 18:01, schrieb Scott Duplichan:
] The reason is that I wanted to
] see if the public version of AMD simnow could boot a coreboot project.
] AMD simnow is the only publically available tool I know of that lets 
] you step through coreboot code starting from the reset vector to see how
] it works.
]There's QEmu that allows single stepping, and SerialICE 
](www.serialice.com)
]that is based on it allows monitoring (up to single stepping) coreboot, 
]or
]anything else, on real hardware (some limitations apply when timing 
]critical
]code is involved).

Serialice sounds useful, though only if you also have real hardware.
I think Qemu is good for developers working on certain parts of the
code. But it can't boot the same binary that boots on real hardware
like simnow can. It is unfortunate that the public version of simnow
is so limited. Simnow NDA version boot just about every AMD reference
board since Solo, the AMD 64 board from around 2000.

]I guess Sage's probe can be used with different trade-offs for similar
]purposes on supported boards.

I have used the Sage SmartProbe and it is useful. But it is a little
expensive for someone just tinkering or learning. A bigger problem
is making the jtag connection to the board. Commercial boards almost
never have the pads for soldering the jtag connector. AMD reference
boards have the needed pads, but those boards are not available to 
the general public.


]Patrick



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

Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project

[Scott Duplichan]

Yang, York [mailto:york.y...@intel.com] wrote:

]Sent: Wednesday, February 04, 2015 01:22 PM
]To: Patrick Georgi
]Cc: coreboot@coreboot.org
]Subject: Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax 
board project

]Actually we also work on a solution to build an UEFI payload easier
](open source too), but it takes time to complete.  Hence we are looking
]for a short team solution, and the binary upstreaming is just an idea to
]ask whether community is allowing such work.  Never mind, we will keep
]evaluating another solution and make it happen as soon as possible.
]Github is a very good suggestion. Thank you very much Patrick.
]York

Making your payload project easy to build is not difficult. Here are
some ideas...

1) Use the latest EDK2 trunk code instead of the UDK2014 snapshot.
2) Make the project build with gcc and Microsoft tool chains.
3) Commit the code to https://svn.code.sf.net/p/edk2/code/trunk/edk2.

1) This way, it will be an official EDK2 project. Given that most of
the recent EDK2 code commits have been for ARM or QEMU, a new Intel
project would provide some needed variety. Committing the code to
the main EDK2 repository will make getting all the needed source
code easy.

2) Many readers of this list build using gcc, so supporting gcc is
important. It is also easy because EDK2 officially supports gcc
tool chains running from Windows and Linux. Gcc tool chains for
Windows are here:
http://sourceforge.net/projects/edk2developertoolsforwindows/
With the attached patch applied to your code, build testing using
EDK2 trunk latest (SVN 16758) passes for all 48 combinations of
release/debug, 32/64, and the following tool chains: DDK3790,
VS2005, VS2008, VS2010, VS2012, VS2013, GCC44, GCC45, GCC46,
GCC47, GCC48, GCC49.

3) Committing the code to the EDK2 repository. This takes a little
work. You submit a patch and then wait for some code review. You
would have to de-tabify the code to get it past code review.
EDK2 has no automated build server. I could do build testing but
I have no way to boot test.

Here is what the patch does:

CbSupportDxe.c -- fix a function prototype that differs from the
actual function. The difference only affects gcc tool chains
because gcc builds use a default abi of sysv and not ms.

CbSupportPei.c -- add 'll' suffix to a 64-bit constant. This is
needed only for old gcc tool chains (gcc 4.4).

CbParseLib.h, CbParseLib.c -- change prototype to avoid gcc error.
Also remove unused functions to prevent a gcc build fail.

SecEntry.S -- format constant the way gas wants it.

SerialIo.c -- use extra braces around initialization data
to prevent gcc build fail.

CorebootPayloadPkg.fdf - expand binary size a little to
accommodate the gcc debug build. The gcc release build fits
without change. Gcc builds are bigger because EDK2 does not
yet enable gcc link time optimization.

--- payload.patch ---
diff -rupN original/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c 
modified/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c
--- original/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c  2014-06-24 
03:04:33.92700 -0500
+++ modified/CorebootModulePkg/CbSupportDxe/CbSupportDxe.c  2015-02-04 
22:08:06.005430400 -0600
@@ -98,9 +98,10 @@ CbReserveResourceInGcd (
 
 **/
 VOID
+EFIAPI
 OnReadyToBoot (
-  EFI_EVENT  Event,
-  VOID   *Context
+  IN  EFI_EVENT  Event,
+  IN  VOID   *Context
   )
 {  
//
@@ -122,6 +123,7 @@ OnReadyToBoot (
 
 **/
 EFI_STATUS
+EFIAPI
 CbDxeEntryPoint (
   IN EFI_HANDLE ImageHandle,
   IN EFI_SYSTEM_TABLE   *SystemTable
diff -rupN original/CorebootModulePkg/CbSupportPei/CbSupportPei.c 
modified/CorebootModulePkg/CbSupportPei/CbSupportPei.c
--- original/CorebootModulePkg/CbSupportPei/CbSupportPei.c  2014-06-24 
03:04:33.66200 -0500
+++ modified/CorebootModulePkg/CbSupportPei/CbSupportPei.c  2015-02-04 
22:12:39.551910800 -0600
@@ -239,7 +239,7 @@ CbPeiEntryPoint (
EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE
 ),
-(EFI_PHYSICAL_ADDRESS)(0x1),
+(EFI_PHYSICAL_ADDRESS)(0x1ll),
 HighMemorySize
 ); 
   }  
diff -rupN original/CorebootModulePkg/Include/Coreboot.h 
modified/CorebootModulePkg/Include/Coreboot.h
--- original/CorebootModulePkg/Include/Coreboot.h   2014-06-17 
21:15:25.81400 -0500
+++ modified/CorebootModulePkg/Include/Coreboot.h   2015-02-04 
16:38:57.524177800 -0600
@@ -45,7 +45,9 @@
 #ifndef _COREBOOT_PEI_H_INCLUDED_
 #define _COREBOOT_PEI_H_INCLUDED_
 
+#if defined(_MSC_VER)
 #pragma warning( disable : 4200 )
+#endif
 
 #define DYN_CBMEM_ALIGN_SIZE (4096)
 
diff -rupN original/CorebootModulePkg/Include/Library/CbParseLib.h 
modified/CorebootModulePkg/Include/Library/CbParseLib.h
--- original/CorebootModulePkg/Include/Library/CbParseLib.h 2014-06-24 
03:04:33.95800 -0500
+++ modified/CorebootModulePkg/Include/Library/CbParseLib.h 2015-02-04 
15:40:00.544565300 -0600

[coreboot] AMD Mahogany Fam10 not booting

[Scott Duplichan]

I found coreboot for AMD Mahogany Fam10 is no longer working. The problem
starts with this change:
http://www.coreboot.org/pipermail/coreboot-gerrit/2013-July/002391.html

Some other older AMD boards are likely affected too. Here is a workaround:

src/device/pci_ops.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/device/pci_ops.c b/src/device/pci_ops.c
index 6ddb493..22bd0b1 100644
--- a/src/device/pci_ops.c
+++ b/src/device/pci_ops.c
@@ -27,7 +27,7 @@
 
 const struct pci_bus_operations *pci_bus_default_ops(device_t dev)
 {
-#if CONFIG_MMCONF_SUPPORT_DEFAULT
+#if CONFIG_MMCONF_SUPPORT_DEFAULT  CONFIG_NORTHBRIDGE_AMD_AMDFAM10 == 0
return pci_ops_mmconf;
 #else
return pci_cf8_conf1;


-- 

The public version of AMD simnow (4.6.2) can boot Mahogany FAM10 coreboot
using the included shiner model. But the following patch is needed to
work around a simnow problem that exposes a coreboot problem:

src/device/pci_device.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/src/device/pci_device.c b/src/device/pci_device.c
index 8351e9c..c384877 100644
--- a/src/device/pci_device.c
+++ b/src/device/pci_device.c
@@ -228,6 +228,13 @@ struct resource *pci_get_resource(struct device *dev, 
unsigned long index)
 * This also catches the common case of unimplemented registers
 * that always read back as 0.
 */
+
+   // simnow workaround: clearing NB_BAR3_PCIEXP_ENABLE makes only the 
lower
+   // half of the BAR read-only, resulting in a memory BAR request for 4GB.
+   // coreboot does not support BARs of this size, and simnow boot fails. 
As
+   // a workaround, limit the BAR read-only check to the lower 32 bits. 
This
+   // causes memory BAR requests = 4GB to be ignored.
+   moving = 0x;
if (moving == 0) {
if (value != 0) {
printk(BIOS_DEBUG, %s register %02lx(%08lx), 



Thanks,
Scott


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

Re: [coreboot] Quick CK804 PCI device numbering question

[Scott Duplichan]

Timothy Pearson [mailto:tpear...@raptorengineeringinc.com] wrote:

]
]All,
]
]I have been working on porting Coreboot to a new CK804-based K10 
]mainboard; it warm boots but will not cold boot due to IRQ/MSI 
]configuration issues.
]
]While tracing the IRQ problem I noticed that the CK804 PCI function 
]numbers change from the proprietary BIOS to Coreboot:
]
]Proprietary:
]-[:00]-+-00.0  NVIDIA Corporation CK804 Memory Controller ][10de:005e]
]+-01.0  NVIDIA Corporation CK804 ISA Bridge [10de:0051]
]+-01.1  NVIDIA Corporation CK804 SMBus [10de:0052]
]...etc...
]
]Coreboot:
]-[:00]-+-01.0  NVIDIA Corporation CK804 Memory Controller ][10de:005e]
]+-02.0  NVIDIA Corporation CK804 ISA Bridge [10de:0051]
]+-02.1  NVIDIA Corporation CK804 SMBus [10de:0052]
]
]This, in turn, causes Linux to not detect the CK804 root bridge.
]
]Has anyone else seen this with the CK804 chipset?  Is there a magic 
]register somewhere that configures the CK804 to use the correct ]PCI 
]function numbers?
]
]The only pertinent quirk of this mainboard is that Asus put the ]CK804 on 
]HT link 1, not 0 or 2 as is more common.
]
]Thanks!
]
]-- 
]Timothy Pearson
]Raptor Engineering
]+1 (415) 727-8645
]http://www.raptorengineeringinc.com

If I remember correctly, PCI device IDs are assigned during non-coherent
HyperTransport initialization on these systems. Search a BKDG for unit id
for details. The solution may involve changing HT_CHAIN_UNITID_BASE and
related items. Take a look at 'swaplist' in the source code.

Thanks,
Scott


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

Re: [coreboot] why is firmware 32 bit as opposed to 64 bit

[Scott Duplichan]

ron minnich [mailto:rminn...@gmail.com] wrote:

]Sent: Sunday, August 10, 2014 06:34 PM
]To: Marc Jones
]Cc: Scott Duplichan; coreboot
]Subject: Re: [coreboot] why is firmware 32 bit as opposed to 64 bit
]
]I understand the arguments.
]
]It's worth remembering that coreboot has to date run on 5 different
]architectures. 4 of those used paging. The x86 has always been the
]outlier. Lack of paging has costs not discussed much. Rmodules would
]be a lot simpler if we had paging. We could make the code space
]readonly, which we should be doing anyway. We would have less fighting
]with the granularity and alignment restrictions of MTRRs. We could
]catch NULL pointers in hardware. These are clear benefits. And they
]all apply to the ramstage as well as other stages.
]
]As to 64 bit ramstage, I see lots of benefits for my use cases, but I
]may be the only one.
]
]In any event, this is all stuff that can be measured, and I propose to
]implement and measure it. Then we can see. I'm not convinced that a
]few percent either way on code size is a showstopper.

Certainly true about code size. Until coreboot starts using gcc link
time optimization, any talk of code size is out of place. By the way,
gcc link time optimization is finally working well. I got it working
with UEFI for x86, ARM, and AARCH64 (though boot testing on real
hardware was limited to x86). Gcc link time optimization should be 
simpler to enable on coreboot than UEFI. This is because coreboot
doesn't replace libgcc.a like UEFI does. Here some notes on using
gcc link time optimization with UEFI: http://notabs.org/uefi/gcc-lto.htm.
I abandoned the idea of submitting a UEFI patch due to lack of interest.

Another reason to convert coreboot x86 to 64-bit mode is to avoid 
negative comparisons to UEFI by those who don't know better. UEFI x86
uses 32-bit code for the first part of execution and then 64-bit for
the remainder. Some might say x86 UEFI is 64-bit, why not coreboot?

A big negative of using 64-bit execution is lack of source code needed
for recompile. What's the chance of getting Intel to support 64-bit
binaries for reference code? Zero, unless the UEFI guys decide to move
reference code execution to 64 bit mode.

I wanted to do an experimental proof of concept port of x86 coreboot to
64 bit mode. I was hoping to switch to 64-bit mode immediately. Running
romstage before the x64 switch is too much like UEFI, in that a whole
lot of execution runs in 32-bit mode.

I chose ASRock E350M1 for the experiment because I have the board and
the reference code is built from source. I did the conversion and got
it working on simnow. But it failed on real hardware. It turns out the
processor (and possibly all AMD processors) can't handle rom-based page
tables. I tried presetting dirty and accessed bits, along with every
MTRR cache setting. Nothing worked. It is possible Intel processors can
use rom based page tables. But I have not bothered to test that because
of lack of needed Intel reference code source.

Someone with some clout needs to request a solution from Intel and AMD.
While 32-bit mode includes built-in identity mapped paging, x64 mode
does not. Why did AMD leave this feature out of the original x64 design?
I imagine rom developers at the time (1999 or 2000) didn't object to its
omission. If AMD and Intel would add this feature, both UEFI and coreboot
could switch to 64-bit mode right out of the reset vector.

I almost scrapped the experiment after finding rom based page tables
couldn't be used. But I did try the next best thing, cache as ram page
tables. This works and the board boots all the way to SeaBIOS. So cache
as ram initialization runs in 32-bit mode as before, but agesa, cimx, and
everything until payload launch runs in x64 mode.

I put the experimental conversion here: 
http://notabs.org/coreboot/e350m1-x64.7z.
This is not a patch or submission. It is a proof of concept experiment only.
Only ASRock E350M1 builds. Because I am not good with makefiles, I hard-coded
the changes rather than make a 32/64 selection option. I took a lot of short-
cuts because the experiment is only intended to see if anything unexpected
would be encountered. Only features I needed are ported. I did not port
option rom execution for example. There are some inconsistent line endings.
Here is a summary of changes:

Switch compiler code generation from 32-bit to 64-bit. Switch asm code too,
except for cache as ram. Yes, I have some .intel_syntax in there. I have to
write it that way then convert afterwards.

Change GDB_DEBUG flag from -O0 to -Og to support source level debugging
without such a drastic code size increase.

Switch back to 32-bit mode for payload execution.

Add x64 code segment to GDTs and do some 64-bit changes. I skipped the
IDT to save time because it is not essential for this board.

Fix definitions like intptr_t and UINT32 to give the sizes needed for
x64 compile.

flag_is_changeable_p was not ported because it is not needed for this
test.

Fix

[coreboot] problem booting AMD RS780 boards

[Scott Duplichan]

I found the AMD mahogany Family 10h coreboot is no longer booting on my
ECS-A780GM-M3 board. The first problem it encounters is a hang after warm
reset. The hang is due to HT training fail. Using the config option to
limit the HT speed works around the problem. Though older coreboot builds
do not have this problem with my board and processor, I am not too
concerned with it at the moment.

The more serious problem is a hang at PCI: pci_scan_bus for bus 01.
This hang is due to commit http://review.coreboot.org/#/c/3606/.
If the changed default config access mechanism is reverted back to CF8 I/O,
then the board boots normally.

I noticed the comment for commit http://review.coreboot.org/#/c/3608/:
On older AMD platform PCI MMIO may not be able to fully configure all
PCI devices/nodes, while MMIO_SUPPORT_DEFAULT would be preferred due
to its atomic nature. So those can be forced to IO config instead.
I tried removing select MMCONF_SUPPORT_DEFAULT from
src\cpu\amd\model_10xxx\Kconfig. With that change, the board can
sometimes boot, but boot progress is slow and often hangs before
completing.

Any suggestions for a proper fix? I may be able to look at it more
later next week.

Thanks,
Scott 



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

Re: [coreboot] Updated coreboot build environment for Windows

[Scott Duplichan]

Peter Stuge [mailto:pe...@stuge.se] wrote:

]Sent: Sunday, December 14, 2014 02:43 PM
]To: coreboot@coreboot.org
]Subject: Re: [coreboot] Updated coreboot build environment for Windows
]
]Peter Stuge wrote:
] Peter Stuge wrote:
]  First, commit and push the change to the submodule repo. Do this by
]  changing the file in your working directory as usual, committing as
]  usual and then pushing that commit through whatever channel applies
]  to that particular repository. (Maybe also our gerrit. I don't know.)
] 
] Patrick Georgi wrote:
]  ... and ideally also push it upstream.
]  
]  They want it as mail, linux-style to linux-te...@vger.kernel.org,
]  with some note that it's for the cbootimage repository.
] 
] Right, that's the channel I was refering to. I didn't know if this
] tool is ours or from elsewhere.
]
]To clarify, it is important to wait until the neccessary change has
]been included upstream before changing the refered-to commit in
]coreboot.git - otherwise Scott is the only person in the world who
]has this particular commit. Maybe the cbootimage maintainers will
]make some change to the commit or rebase it onto some local changes
]of theirs before they publish it in their repo.
]
]It's important that coreboot.git references a commit hash which is
]actually available in the public submodule repo. Since that's not a
]repo of ours we have to wait until the change is available there.

Hello Peter. Thanks for explaining. Sounds like I did things out of
sequence. The change is now in the NVIDIA cbootimage repository at
github.com/NVIDIA/cbootimage. What steps are needed to get the change
into the coreboot repository?

Thanks,
Scott

]//Peter



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

Re: [coreboot] Updated coreboot build environment for Windows

[Scott Duplichan]

Patrick Georgi [mailto:patr...@georgi-clan.de] wrote:

]Sent: Sunday, December 14, 2014 09:38 AM
]To: coreboot@coreboot.org
]Subject: Re: [coreboot] Updated coreboot build environment for Windows
]
]Am 13.12.2014 um 15:14 schrieb Peter Stuge:
] Finally push that to gerrit for review as usual.
]... and ideally also push it upstream.
]
]They want it as mail, linux-style to linux-te...@vger.kernel.org, with
]some note that it's for the cbootimage repository.

OK, here it is,
http://thread.gmane.org/gmane.linux.ports.tegra/20348

Thanks,
Scott

]
]Patrick



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

[coreboot] Updated coreboot build environment for Windows

[Scott Duplichan]

I have maintained a coreboot build environment for Windows for a while:
http://notabs.org/coreboot/windows-build.htm

Though maintaining it has never been a priority for me,
the website log files show quite a few people download it.
For this reason I am trying to improve this project. The 
recently submitted patches get the Windows hosted coreboot
build environment working well enough for abuild to pass
for all builds using gcc: x86, ARM, and AARCH64. There is
no clang or riscv support.

There is one patch I haven't been able to submit. For Windows
hosted building, file util/nvidia/cbootimage/src/set.c needs
to fopen binary files using rb instead of r. This file
is part of a git 'submodule'. How do build and upload a patch
for this file?

Thanks,
Scott


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

Re: [coreboot] problem with: vendorcode/amd/agesa/fam15: Build as a static library

[Scott Duplichan]

Patrick Georgi [mailto:patr...@georgi-clan.de] wrote:

]Sent: Thursday, December 11, 2014 12:40 PM
]To: coreboot@coreboot.org
]Subject: Re: [coreboot] problem with: vendorcode/amd/agesa/fam15: Build as a 
static library
]
]Am 2014-12-10 07:27, schrieb Scott Duplichan:
] While trying to get abuild working from Windows I found a coreboot
] makefile problem. File src/vendorcode/amd/agesa/f15/Makefile.inc is
] be processed twice.
]
] What is the correct solution?
]Removing the subdirs-y += ../../../../$(AGESA_ROOT) line in the 
]mainboard's Makefile.inc

Thanks Patrick. That is perfect. I will try to submit patch soon with
this change and others needed to get abuild working on Windows.

Thanks,
Scott

]
]Patrick



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

[coreboot] problem with: vendorcode/amd/agesa/fam15: Build as a static library

[Scott Duplichan]

While trying to get abuild working from Windows I found a coreboot
makefile problem. File src/vendorcode/amd/agesa/f15/Makefile.inc is
be processed twice. While this doesn't break a Linux build, it does
break the Windows build. The Windows problem is because the ar
command line contains each object file twice, and the Windows 32KB
command line length is exceeded.

As a temporary work around, I bracket the contents if Makefile.inc with:

ifeq ($(F15_MAKE_INCLUDED),)
export F15_MAKE_INCLUDED=y
...
endif


What is the correct solution?

Thanks,
Scott



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

Re: [coreboot] cbfstool build issue in gcc 4.6.3

[Scott Duplichan]

Stefan Reinauer [mailto:stefan.reina...@coreboot.org] wrote:

]On 11/20/14 9:40 PM, Scott Duplichan wrote:
] The Gluglug [mailto:i...@gluglug.org.uk] wrote:
]
] ]-BEGIN PGP SIGNED MESSAGE-
] ]Hash: SHA1
] ]
] ]Hi,
] ]
] ]cbfs-mkstage.c: In function ‘is_phdr_ignored’:
] ]cbfs-mkstage.c:45:84: error: cast to pointer from integer of different
] ]size [-Werror=int-to-pointer-cast]
] ]
] ]The fix was made in http://review.coreboot.org/#/c/7545/ but some
] ]people were unhappy about the use of extra type casting.
] ]
] ]One possible solution is to simply upgrade GCC, which I will, but I
] ]would also like to get cbfstool to build again for this version of
] ]GCC. The patch in the gerrit link works, but is not accepted for
] ]upstream.
] ]
] ]Does anyone know a better way of doing it?
]
] What about: DEBUG(Ignoring program segment at %llx\n, ph_start);
]That will break 64bit compilers for the sake of fixing 32bit compilers. 
]Not the best either. I think the PRIx64 approach is better.

PRIx64 is certainly the most portable way. Too much uefi recently
is rotting my mind.

Thanks,
Scott


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

Re: [coreboot] cbfstool build issue in gcc 4.6.3

[Scott Duplichan]

The Gluglug [mailto:i...@gluglug.org.uk] wrote:

]-BEGIN PGP SIGNED MESSAGE-
]Hash: SHA1
]
]Hi,
]
]cbfs-mkstage.c: In function ‘is_phdr_ignored’:
]cbfs-mkstage.c:45:84: error: cast to pointer from integer of different
]size [-Werror=int-to-pointer-cast]
]
]The fix was made in http://review.coreboot.org/#/c/7545/ but some
]people were unhappy about the use of extra type casting.
]
]One possible solution is to simply upgrade GCC, which I will, but I
]would also like to get cbfstool to build again for this version of
]GCC. The patch in the gerrit link works, but is not accepted for
]upstream.
]
]Does anyone know a better way of doing it?

What about: DEBUG(Ignoring program segment at %llx\n, ph_start);

Thanks,
Scott

]Regards,
]Francis Rowe.
]-BEGIN PGP SIGNATURE-
]Version: GnuPG v1.4.11 (GNU/Linux)
]
]iQEcBAEBAgAGBQJUbsexAAoJEP9Ft0z50c+UGU4H/3nXZpc3OlaLNg+Otfv16Xw1
]Cu9lj59jqYZ4BKCWIl/ZFeZ2Dgpjgc2hJcYk+V5VcQwAWzAt/UquQJQLFBcR0gMd
]eZycL6z3iJS9vGh3wqpT0y1xnOXk+CckrU+3wUpGcwYuVRw2PnTllrhBDirTFObJ
]bOGuns8b8+wdRkuEc9kIyGgOqzSC2pLKNaPI9uYo2bAIz7J2O8IO0T6vLrfnYMqu
]ytV1fArz/CViF685KDB4IXbqHKlKmnVLwRWZw5mEtic0TGrcKElrHry3KgnK3Z4z
]eYgQ2SZ6AyA0fs7gjkC3JN9M7peWiKZ+q1DPugBnx8HBoDXIYs65QzDDFOE4yRw=
]=caB/
]-END PGP SIGNATURE-



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

Re: [coreboot] disabling bios usb stack

[Scott Duplichan]

ron minnich [mailto:rminn...@gmail.com] wrote:

]Thanks scott!
]
]So, what does an OS do to disable USB in the operating system? We have
]seen Linux do it, we're not quite sure just what
]place it gets done.
]
]ron

If I understand your question, I am not sure I know the answer. If you
boot linux with grub option 'nousb', or reboot Windows after disabling
usb controllers from device manager, what happens? I assume the operating
system just ignores USB controllers. It seems unlikely that the OS would
take some action to ensure that they are properly disabled. Does UEFI
disable USB controllers before handoff to the OS loader? I do not know.
Having the OS not load USB drivers should eliminate USB related interrupts,
but I know EHCI can generate memory accesses even when idle.

Thanks,
Scott


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

Re: [coreboot] disabling bios usb stack

[Scott Duplichan]

ron minnich [mailto:rminn...@gmail.com] wrote:

]This is really interesting information, thanks.
]
]This embedded USB stack problem actually impacts HPC applications.
]This type of periodic interference can cause big troubles when you
]have lots of nodes.
]
]Look for the case of the missing supercomputer performance for a
]classic paper. In that case, a 1/30 hz (i.e. lpd dropping out of
]select every 30 seconds on 2048 nodes) was worth a couple tens of
]millions of dollars of performance.
]
]I'm amazed that the embedded USB stack problems are WORSE, not better,
]than they were a few years back. The x86 world just keeps getting more
]backwards. I'm sorry to see the ARM V8 world trying to emulate it.
]
]ron

I have seen concern about BIOS SMI overhead from server customers running
certain applications. These customers do not want avoidable interruptions
of even a few uS. Some server BIOS enable a periodic SMI for various server
management uses. This never ending periodic SMI is not wanted by these
customers. But I thought all USB related SMI activity ends after a legacy
BIOS hands control to an operating system that supports USB. For pure
UEFI, I don't believe the USB uses SMI at all. So it would seem like
disabling USB in the operating system would be just as good as doing it
in BIOS. If an OS that predates USB is used, SMI will continue in order
to support legacy 60/64 emulation. In this case, the easiest solution 
might be to set the global SMI mask in the south bridge, assuming this
is the only source of SMI.
Thanks,
Scott

On Tue, Aug 26, 2014 at 3:14 PM, Антон Кочков anton.koch...@gmail.com wrote:
 Hello,

 Just checked some binaries - PEI USB driver is loading anyway, no
 checking for any setup option, so I guess it will be very hard even
 with the unpacking UEFI image and removing these drivers. Also in most
 UEFI systems big part of USB driver working in SMM mode, so it will be
 hard to patch this code on the fly.
 Best regards,
 Anton Kochkov.


 On Wed, Aug 27, 2014 at 1:23 AM, Carl-Daniel Hailfinger
 c-d.hailfinger.devel.2...@gmx.net wrote:
 Hi Ron,

 Am 26.08.2014 00:22 schrieb ron minnich:
 disabling the usb stack is the goal in this case.

 AFAIK it's called USB keyboard support, USB legacy support or
 something similar in most BIOSes. This internally maps a USB keyboard to
 a virtual PS/2 keyboard and sometimes has quite a few issues. If that's
 what your friend meant, disabling it should be straightforward in the
 BIOS menu.
 However, if your friend is a victim of EFI, I fear he is beyond help
 except for trying coreboot.

 Regards,
 Carl-Daniel

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

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


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

Re: [coreboot] why is firmware 32 bit as opposed to 64 bit

[Scott Duplichan]

Vladimir 'φ-coder/phcoder' Serbinenko [mailto:phco...@gmail.com] wrote


]On 10.08.2014 21:06, John de la Garza wrote:
] I understand that the calling functions in 32 bit C uses the stack and
] this is why coreboot needs to use cache as RAM.  Doesn't 64 bit C use
] registers to pass arguments to functions?  If this is the case why not
] run in 64 bit mode?
] 
] Also, even if cache as RAM is used and a stack is available, why not just
] build a 64 bit binary?  What are the advantages to using a 32 bit binary?
] 
]
]long mode (64-bit) needs paging table in RAM. So no 64-bit for preram
]binary. For rest it's theoretically possible but it's too much hassle
]for no benefit.

The page table requirement is certainly a negative for x64 mode.
Another is code size. Code grows by several percent when compiled
for x64 mode. Use of x32 ABI could reduce the code size penalty,
but page tables are still required.

Most UEFI uses 32-bit mode until RAM is ready, then x64 mode
after that. Unlike coreboot, UEFI doesn't prioritize code size
minimization. Minimum code size is needed for fast boot, because
the code must be read from the relatively slow flash chip before
it can execute. Coreboot does prioritize fast boot. Switching
coreboot to x64 mode would result in a measurable boot time
degradation I believe.

One advantage of x64 mode is easy use of DRAM structures larger
then 4GB. Boot firmware is unlikely to benefit from this. Another
benefit of x64 mode is use of additional registers. The additional
registers can lead to faster code. But boot firmware is usually I/O
bound, so it is unlikely the extra registers could lead to a
measurable boot time reduction.

Thanks,
Scott


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

Re: [coreboot] microcode updates

[Scott Duplichan]

ron minnich [mailto:rminn...@gmail.com]  wrote:

]you can  no longer update microcode after the kernel boots
](on modern Intel CPUs). It has to happen before you do Cache
]As Ram in many cases, or you'll get some pretty unpleasant 
]consequences.
]
]ron
]
][...]

While I am no expert on recent Intel processors, it appears
Intel still distributes patch packages for OS use (goo.gl/ffLdyq)
and Linux still applies them (goo.gl/oaBvdE).

Thanks,
Scott



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

Re: [coreboot] coreboot engineer needed

[Scott Duplichan]

A coreboot@coreboot.org subscriber wrote:

]Hi Scott,
]
]It appears they are looking for a full-time position. If they were 
]willing to outsource, I would be interested.

It might be useful to apply anyway. Others have pointed out
that most of the coreboot experts are located in Europe.
If a few engineers from remote or non-US locations responded,
it might get the hiring manager interested.

I point out this job offer because the recent Intel coreboot
openings are unique in an important aspect. Today, a BIOS
engineer who wants the security, pay and other benefits of
working for a major computer OEM must learn to be happy
living in the world of UEFI, including its rules, regulations,
mandates, laws, restrictions, enforcements, and coding standard.
Want to use features of C99? Sorry, Microsoft doesn't support
that. Want to use static functions? Sorry, those are banned.
Want to use a comma operator? Sorry, forbidden. Want to start
a local variable name with a lower case letter? Sorry, prohibited.
Want to write ugly code full of dangerous type casts, spaghetti
gotos, and countless global variables? You're in luck. Today, the
Intel coreboot openings are the only non-UEFI BIOS jobs that I know of.

Thanks,
Scott


]On 06/19/2014 08:11 PM, Scott Duplichan wrote:
] Scott Duplichan [mailto:sc...@notabs.org] wrote:
]
] ]Sent: Thursday, January 09, 2014 08:37 AM
] ]To: 'coreboot@coreboot.org'
] ]Subject: coreboot engineer needed
] ]
] ]
] ]https://intel.taleo.net/careersection/1/jobdetail.ftl?job=725464
] ]
] ]Thanks,
] ]Scott
]
] 
https://intel.taleo.net/careersection/1/jobdetail.ftl?]job=737461src=JB-12440
]
] Coreboot BIOS development for Chrome OS
]
] Thanks,
] Scott



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

Re: [coreboot] setting smbios values from the OS

[Scott Duplichan]

ron minnich [mailto:rminn...@gmail.com] wrote:

]realistically, though, it's hard for me to see how setting the
]serial # at firmware image build time scales. And setting it after
]boot makes no real sense either -- it's not really a serial number
]if you're changing it at that point. 

]But some way to customize the binary images with a serial number
]seems most workable, if you're going to put the serial number in
]the firmware image at all (which never made sense to me either
]--serial #s are supposed to be indelible, and firmware images are
]not indelible).
]
]ron

Putting the serial number in the same flash chip as the main
firmware is a cost reduction measure used with desktop and other
low cost boards. I have even seen a board where the MAC address
lives there. The only protection for those items is that the
flash utility given to the end user knows to skip that area.

The way I have seen the serial number programmed is at
manufacturing diagnostics time. The board is PXE booted to a
diagnostic image. The image runs a script that first erases
the entire flash chip. It then programs it with the OEM firmware
image. The OEM image contains a blank serial number. The script
then prompts for operator input. The operator pulls a barcoded
serial number label from a roll and attaches it to the board. The
operator then scans the label with a barcode reader. The script
uses the barcode data to find the serial number in a database.
The script then runs a special flash utility that reprograms only
the serial number portion of the flash chip.

If the end user flashes the firmware by any method other than the
supplied utility, the serial number will be lost. It can still be
read from the barcoded label though. 

Thanks,
Scott 






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

Re: [coreboot] coreboot engineer needed

[Scott Duplichan]

Scott Duplichan [mailto:sc...@notabs.org] wrote:

]Sent: Thursday, January 09, 2014 08:37 AM
]To: 'coreboot@coreboot.org'
]Subject: coreboot engineer needed
]
]
]https://intel.taleo.net/careersection/1/jobdetail.ftl?job=725464
]
]Thanks,
]Scott

https://intel.taleo.net/careersection/1/jobdetail.ftl?job=737461src=JB-12440

Coreboot BIOS development for Chrome OS

Thanks,
Scott


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

[coreboot] Building coreboot and SeaBIOS from Windows

[Scott Duplichan]

The coreboot build environment for Windows is once again working:
http://notabs.org/coreboot/windows-build.htm (release 013).

SeaBIOS also builds, but requires a change not yet in
SEABIOS_STABLE. Use SEABIOS_MASTER for now. Thanks to
Kevin for that change:
http://code.coreboot.org/p/seabios/source/commit/ec44fac1f69bd3d513204a6192623de511b11144/

Thanks,
Scott





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

Re: [coreboot] IMB-A180 based design question regarding interrupts

[Scott Duplichan]

Mark C. Mason [mailto:m...@edt.com] wrote:

]We are testing coreboot with our new IMB-A180 based AGESA design,
]and DMA interrupts are not functioning.  I am looking into the Coreboot
]Options, but is there a recipie for enabling legacy interrupts in AGESA?
]We configure in Linux at IRQ 17.
]
]Thanks in advance,
]
]Mark Mason
]Engineering Design Team

By legacy interrupts, do you mean the interrupt configuration
when PIC mode interrupt handling is in use, or do you mean
the routing of interrupts from a legacy device to an I/O
APIC interrupt number? You mention Linux so I think the latter.

It looks like agesa programs only APIC mode interrupt
routing, and not the PIC mode routing used by older
operating systems. The agesa programming is not configurable,
as far as I can tell (see FchInternalDeviceIrqForApicMode[]
in file HwAcpiLate.c).

Your own code reprogram this routing. See IOC00 Pci_Intr_Index
in the Kabini BKDG:
http://developer.amd.com/resources/documentation-articles/developer-guides-manuals/

Thanks,
Scott



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

Re: [coreboot] imb-a180 won't boot from single DIMM 0

[Scott Duplichan]

Mark C. Mason [mailto:m...@edt.com] wrote:

]Is there a straightforward way to get an IMB-A180 to boot with a single
]DIMM in slot 0?  It boots fine in slot 1.  I've looked through the code
]at length, and thought it configures the dimm, it fails in
]
]coreboot/src/vendorcode/amd/agesa/Proc/Mem/Main/KB/mmflowKB.c
]
]   //
]   // If there is no dimm on the system, do fatal exit
]   //
]   if (NBPtr[BSP_DIE].RefPtr-SysLimit == 0) {
] PutEventLog (AGESA_FATAL, MEM_ERROR_NO_DIMM_FOUND_ON_SYSTEM, 0, 0, 
]0, 0, (MemMainPtr-MemPtr-StdHeader));
] return AGESA_FATAL;
]   }
]
]Even though it has detected and configured the dimm in slot 0.
]Again, this does work with slot 1.
]
]Many thanks,
]
]Mark Mason
]Engineering Design Team

A few years ago the agesa code was changed to make
the DIMM population order rules a requirement rather
than a recommendation. This is a BKDG requirement.
Agesa excludes the out of place DIMM. If it is the
only DIMM in the system, then the error logic will
report no DIMM installed. This might be what you
are seeing. There may be an agesa warning for this
that isn't getting reported. The DIMM population
order rules are related to signal integrity and are
explained in the BKDG.
Thanks,
Scott



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

Re: [coreboot] Errors in Memtest86 with 4 or 8GB memory

[Scott Duplichan]

Krzysztof Pierwieniecki [mailto:kpierwienie...@teldat.com.pl] wrote:


]I have a problem on Intel DQ77KB board. I have two the same boards and 
]on every board Memtest86 reports a problem at 2990.8MB. That problem 
]occur only if I use 4 or 8GB memory. With 2GB memory everything is OK.
]
]What may be causing errors in Test2 Address test, own address, 
]Parallel  in Memtest86?
]http://www.memtest86.com/technical.htm
]
]Chris

The USB controller might be using memory reported as
free in the E820 map. The address 2990.8MB would be
around BAECh. The log file shows that SeaBIOS uses 
memory around there for USB. Yet the SeaBIOS E820 map
shows memory through BAEDCFFF as available RAM. I once
debugged a problem like this. Dumping the failing address
range with a DOS mode debugger showed a location that
was constantly incrementing. That location turned out to
be a periodic counter used by the USB controller. The
problem was E820 reporting the USB memory as free, just
like Wang Fei suggested.
Thanks,
Scott


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

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

[Scott Duplichan]

ron minnich [mailto:rminn...@gmail.com] wrote:

]On Tue, May 13, 2014 at 5:29 AM, Peter Stuge pe...@stuge.se wrote:
]
] That's an important question, but I believe the answer is no.
]
]That's all I wanted to know, to start.
]
]So why don't we just get that CL in and see where we go from there.
]
]Thanks all. And sorry if I was too hard on kolibrios. It's totally
]wonderful that they are building a from-the-bottom-up OS that gives
]people a close view of how things really work.
]
]ron

Thank you and everyone for all the ideas and suggestions.
Rudolf pointed out that coreboot already has an option for
setting up the PCI config space 3C register: CONFIG_PIRQ_ROUTE.
This initially looked like the proper way to enable the PIC
mode routing code. On the other hand, experiments suggest this
might not be the best way to do it.

Testing Ubuntu with the E350M1 OEM BIOS gives these results
for the south bridge SATA controller:

grub options: acpi=off noapic
debugger: clear SATA controller 3C register before Ubuntu boot.
result:
  ahci :00:11.0: can't find IRQ for PCI INT A; please try using pci=biosirq
  irq 10: nobody cared (try booting with the irqpoll option)
  Disabling IRQ #10
  ata4.00: qc timeout (cmd 0xa1)

grub options: acpi=off noapic
debugger: clear SATA controller PIC routing before Ubuntu boot.
result:
  SATA operation is extremely slow. Apparently the SATA
  ISR is called occasionally due to interrupt sharing.

In PIC mode with acpi=off, the OS can only look at the MPS
table or PIR table for interrupt info. These don't tell the
OS what interrupt BIOS has assigned. In addition, the tables
don't give enough info to allow the OS to program the
interrupt itself. So to make Ubuntu work in PIC mode using
MPS or PIR tables, both the 3C register and SB routing 
register must be setup by BIOS.

This leads to an argument that CONFIG_PIRQ_ROUTE shouldn't
exist. Instead, the PIC routing and 3C reporting should
be done any time the MPS or PIR tables are included.

Thanks,
Scott 







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

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

[Scott Duplichan]

Paul Menzel wrote:

]Am Dienstag, den 06.05.2014, 00:18 -0500 schrieb Scott Duplichan:
] Paul Menzel wrote:
]
] ]I try to get KolibriOS running on the ASRock E350M1 with coreboot and
] ]SeaBIOS payload. Keyboard and mouse do not work [1] probably because
] ]KolibriOS needs PIC mode.
] ]
] ]Was somebody successful in getting KolibriOS working on a board with
] ]coreboot?
] ]
] ]Is there an easy way to use PIC instead of APIC mode with coreboot and
] ]SeaBIOS or is APIC mode assumed everywhere?
]
][…]
]
] ][1] http://bugs.kolibrios.org/view.php?id=84
]
] The PS/2 keyboard mostly works with KolibriOS on my Asrock
] E350M1 with coreboot+SeaBIOS. Out of about 10 tests, it did
] fail once. In that case the SeaBIOS debug messages showed
] that SeaBIOS did not detect the PS/2 keyboard.
] 
] I don't know why the USB mouse doesn't work. It works with
] the OEM BIOS, but not coreboot+SeaBIOS.
]
]Do you have a picture the KolibriOS kernel messages? You can enable them
]in the KolibriOS kernel menu with the key `c` and then choose Yes/On.

L: /SYS/@DOCKY Param:
L: /SYS/SETUP Param: BOOT
L: /SYS/@ICON Param:
L: /SYS/@SS Param: assm
L: /SYS/TMPDISK Param: A0
trying to add disk
its size is not specified, 10% from free RAM will be used
new DiskSize: 319 MB
operation completed successfully
L: /SYS/SEARCHAP Param:
K : Attach Interrupt 0 Handler 80AB6B20
RTL8169: init OK!
Trying to contact DHCP server
No answer from DHCP server
Searchap: compare files success!
Searchap: mount directory: /cd2/1
L: AUTORUN.DAT processed
No answer from DHCP server
No answer from DHCP server
Link Local IP assigned: 169.254.205.31
Exiting

] If you want to see my build options (and rom image+boot log),
] it is here:
] http://notabs.org/coreboot/e350m1-kolibri.7z
]
]Thanks a lot for providing this archive. Unfortunately the PS/2 mouse
]still does not work with your coreboot + SeaBIOS image in the archive.
]
]Which KolibriOS version do you use? Did you build it yourself or do you
]use the distributed binaries? I use the image from May 1st.

I downloaded the 4 May 2014 LiveCD image and burnt it to CD-RW.

] I switched the SATA to IDE mode only to work around an
] AMD simnow problem. One line is added to agesa to work
] around another simnow problem. Other changes are hacks
] to get SeaBIOS to build from Windows. Building SeaBIOS
] from Windows is truly a painful experience. When I modify
] the makefile to work around a couple of problems with
] the Windows build environment, git gets upset.
]
]Interesting. Did you report that to the SeaBIOS developers?

I didn't mention it because I am probably the only one
who builds with Windows.

As for the mouse problem, I think it may be PIC interrupt
routing related. I see our PIR table is incomplete and also
the legacy interrupting route reporting registers in PCI
config space are not filled in. I will look at that tomorrow.

Thanks,
Scott


]Thanks,
]
]Paul


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

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

[Scott Duplichan]

Scott Duplichan [mailto:sc...@notabs.org] wrote:

[...]

]As for the mouse problem, I think it may be PIC interrupt
]routing related. I see our PIR table is incomplete and also
]the legacy interrupting route reporting registers in PCI
]config space are not filled in. I will look at that tomorrow.

I got the USB mouse working by setting up the PIC interrupt
routing and reporting. For now the changes are in mptable.c.
They may need to be relocated to a better place. The NIC
bus number is hard-coded at the moment. This needs fixing
if the NIC bus number can change.

KolibriOS reads PCI config offset 3C to find PIC interrupt
routing, so these must be filled in. The same values must
be programmed into the SB800 PIC mode interrupt routing
registers. In addition, a change to the legacy mode
edge-level control register setting is needed. An updated
archive is here:
http://notabs.org/coreboot/e350m1-kolibri-001.7z

An mptable.c patch is attached.

diff --git a/src/mainboard/asrock/e350m1/mptable.c 
b/src/mainboard/asrock/e350m1/mptable.c
index 6444be5..b6c5b76 100644
--- a/src/mainboard/asrock/e350m1/mptable.c
+++ b/src/mainboard/asrock/e350m1/mptable.c
@@ -35,6 +35,7 @@ extern u32 apicid_sb800;
 extern u32 bus_type[256];
 extern u32 sbdn_sb800;
 
+// SB800 interrupt routing register values: APIC mode
 u8 intr_data[] = {
   [0x00] = 0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17, /* INTA# - INTH# */
   [0x08] = 0x00,0x00,0x00,0x00,0x1F,0x1F,0x1F,0x1F, /* Misc-nil,0,1,2, INT 
from Serial irq */
@@ -45,6 +46,16 @@ u8 intr_data[] = {
   0x10,0x11,0x12,0x13
 };
 
+// SB800 interrupt routing register values: PIC mode
+u8 intr_data_pic[] = {
+0x0B, 0x0A, 0x0B, 0x0A, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x00
+0x00, 0xF1, 0x00, 0x00, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x08
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x10
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x18
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x20
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x28
+0x0B, 0x0A, 0x0B, 0x0A, 0x1F, 0x1F, 0x1F, 0x1F};  // 0x30
+
 static void *smp_write_config_table(void *v)
 {
   struct mp_config_table *mc;
@@ -75,6 +86,12 @@ static void *smp_write_config_table(void *v)
 outb(intr_data[byte], 0xC01);
   }
 
+  // progran the SB800 PIC mode interrupt routing register values
+  for (byte = 0x0; byte  sizeof(intr_data_pic); byte ++) {
+outb(byte, 0xC00);
+outb(intr_data_pic[byte], 0xC01);
+  }
+
   /* I/O Ints:TypePolarityTrigger Bus ID   IRQAPIC ID PIN# 
*/
 #define IO_LOCAL_INT(type, intr, apicid, pin) \
   smp_write_lintsrc(mc, (type), MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, 
bus_isa, (intr), (apicid), (pin));
@@ -149,6 +166,25 @@ static void *smp_write_config_table(void *v)
   IO_LOCAL_INT(mp_NMI, 0x0, MP_APIC_ALL, 0x1);
   /* There is no extension information... */
 
+  // program interrupt line registers for legacy OS use
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x01, 0)), 0x3C, 0x0B);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x01, 1)), 0x3C, 0x0A);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x04, 0)), 0x3C, 0x0B);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x11, 0)), 0x3C, 0x0A);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x12, 0)), 0x3C, 0x0B);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x12, 2)), 0x3C, 0x0A);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x13, 0)), 0x3C, 0x0B);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x13, 2)), 0x3C, 0x0A);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 1)), 0x3C, 0x0A);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 2)), 0x3C, 0x0B);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x14, 5)), 0x3C, 0x0B);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x16, 0)), 0x3C, 0x0B);
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x16, 2)), 0x3C, 0x0A);
+  pci_write_config32(dev_find_slot(3, PCI_DEVFN(0x00, 0)), 0x3C, 0x0B);
+
+  // program slave PIC edge-level control register
+  outb (0x0C, 0x4D1);
+
   /* Compute the checksums */
   return mptable_finalize(mc);
 }

Thanks,
Scott




legacy-interrupts.patch
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

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

[Scott Duplichan]

ron minnich [mailto:rminn...@gmail.com] wrote:

]So, how would these changes affect other payloads?
]
]ron

The patch adds programming and one reporting
mechanism for PIC mode PCI interrupt routing for
the ASRock E350M1 board only. Without the patch,
PIC mode PCI interrupt routing is not programmed
and not reported. There are several ways an OS can
find PIC mode interrupt routing for PCI devices:
1) $PIR table
2) ACPI
3) PCI config space interrupt line registers
This change adds reporting method 3. Reporting
methods 1 and 2 are incomplete or unimplemented
for this board.

This patch programs PIC mode PCI interrupt routing
to match the OEM BIOS. Without the patch, PIC mode
PCI interrupt routing is unprogrammed. The changes
affect an OS or other code that uses PCI interrupts
in PIC mode. APIC mode is unaffected.

From what I can remember, older mainstream operating
systems normally use the ACPI method to find PIC mode
interrupt routing. They might fall back to $PIR or 
even the config space line register method I suppose.
I see some coreboot boards support the ACPI method of
reporting (and modifying) PIC mode PCI interrupts.
However I don't see this this code in E350M1 project.
As a result, an OS such as Windows 2000 may or may not
see improvement with this patch. I didn't try it. Linux
still supports PIC mode PCI interrupt routing through
grub options. I did not test that either. It seems
interest in PIC mode interrupts has waned since
multicore processors have become popular. A limitation
of PIC mode interrupts is that all PCI interrupts are
handled by the BSP core and cannot be routed to AP cores.

I know of one application that uses PIC mode PCI 
interrupts and finds them from the config space line
register. It is the interrupt test portion of the
Broadcom b57diag utility.

For operating systems, Windows dropped PIC mode starting
with XP x64 edition if I remember correctly. XP 32-bit
defaults to APIC mode, but can be switched to PIC mode
during installation. After XP, all PIC mode is gone.
For linux, PIC mode is still supported, but the default
was switched to APIC mode several years ago. I believe 
there was a time with 32-bit Linux used PIC mode but
64-bit used APIC mode. This is from memory so I could
be a little off.

Thanks,
Scott



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

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

[Scott Duplichan]

ron minnich [mailto:rminn...@gmail.com] wrote:

]Thanks, that's a great explanation. Generally, we've tried to avoid
]too much hardware setup in coreboot; that's the job of the kernel.

The PIC mode interrupt routing configuration must be done by
BIOS because proprietary southbridge registers are used. The
register definitions are not even consistent across different
AMD southbridge models. An OEM BIOS does this configuration.

]I'm not really happy that we're doing all this PIC setup for one OS,
]written in assembly.

This is needed for all operating systems that support PIC mode.
For example, Ubuntu 13.10 with boot option acpi=off fails. With
the attached revised patch, it works.

]It's been quite some time since I've had to use PIC mode at all.
]
]Why can't the Kolibrios just use modern standards? And why all this
]effort for an OS written in assembly anyway?
]
]Unix v6 kernels were the same size as Kolibrios. They were written in
]C. That was 40 years ago. It's bizarre, to say the least, to be
]booting a kernel written in assembly from firmware written in C.
]
]Hence, I find it hard to believe that we want this patch. But I'm
]wrong a lot, so if I am here too, just let me know.

It is OK with me to take no action on the patch. The reason is
that the patch is here in the mailing list archives, and anyone
who really wants PIC mode will find it. The patch probably needs
sanitization and additional testing anyway.

]ron

Patch revisions:
1) With the current code, CONFIG_GENERATE_ACPI_TABLES=1 causes
the PCI interrupts to be omitted from the mptable. With the
revised patch, the mptable always includes PCI interrupts. This
solves the Ubuntu acpi=off problem of can't find IRQ for PCI
INT A; probably buggy MP table.
2) Add PIC mode PCI interrupt values for SATA and IDE devices.
Without this, Ubuntu setup cannot read the CD-ROM.
3) Use 00 for unused PIC mode routing entries rather than 1F.
This is for consistency with the APIC mode table.

Thanks,
Scott

diff --git a/src/mainboard/asrock/e350m1/mptable.c 
b/src/mainboard/asrock/e350m1/mptable.c
index 6444be5..f45385e 100644
--- a/src/mainboard/asrock/e350m1/mptable.c
+++ b/src/mainboard/asrock/e350m1/mptable.c
@@ -35,6 +35,7 @@ extern u32 apicid_sb800;
 extern u32 bus_type[256];
 extern u32 sbdn_sb800;
 
+// SB800 interrupt routing register values: APIC mode
 u8 intr_data[] = {
   [0x00] = 0x10,0x11,0x12,0x13,0x14,0x15,0x16,0x17, /* INTA# - INTH# */
   [0x08] = 0x00,0x00,0x00,0x00,0x1F,0x1F,0x1F,0x1F, /* Misc-nil,0,1,2, INT 
from Serial irq */
@@ -45,6 +46,20 @@ u8 intr_data[] = {
   0x10,0x11,0x12,0x13
 };
 
+// SB800 interrupt routing register values: PIC mode
+u8 intr_data_pic[] = {
+0x0B, 0x0A, 0x0B, 0x0A, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x00
+0x00, 0xF1, 0x00, 0x00, 0x1F, 0x1F, 0x1F, 0x1F,   // 0x08
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x00,   // 0x10
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,   // 0x18
+0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x1F, 0x00, 0x00,   // 0x20
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,   // 0x28
+0x0B, 0x0A, 0x0B, 0x0A, 0x0B, 0x0A, 0x0B, 0x00,   // 0x30
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,   // 0x38
+0x0A, 0x0A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,   // 0x40
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,   // 0x48
+0x0B, 0x0A, 0x0B, 0x0A};  // 0x50
+
 static void *smp_write_config_table(void *v)
 {
   struct mp_config_table *mc;
@@ -75,6 +90,12 @@ static void *smp_write_config_table(void *v)
 outb(intr_data[byte], 0xC01);
   }
 
+  // program the SB800 PIC mode interrupt routing register values
+  for (byte = 0x0; byte  sizeof(intr_data_pic); byte ++) {
+outb(byte, 0xC00);
+outb(intr_data_pic[byte], 0xC01);
+  }
+
   /* I/O Ints:TypePolarityTrigger Bus ID   IRQAPIC ID PIN# 
*/
 #define IO_LOCAL_INT(type, intr, apicid, pin) \
   smp_write_lintsrc(mc, (type), MP_IRQ_TRIGGER_EDGE | MP_IRQ_POLARITY_HIGH, 
bus_isa, (intr), (apicid), (pin));
@@ -84,12 +105,8 @@ static void *smp_write_config_table(void *v)
   /* PCI interrupts are level triggered, and are
* associated with a specific bus/device/function tuple.
*/
-#if !CONFIG_GENERATE_ACPI_TABLES
 #define PCI_INT(bus, dev, fn, pin) \
-smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, 
(bus), (((dev)2)|(fn)), apicid_sb800, (pin))
-#else
-#define PCI_INT(bus, dev, fn, pin)
-#endif
+  smp_write_intsrc(mc, mp_INT, MP_IRQ_TRIGGER_LEVEL|MP_IRQ_POLARITY_LOW, 
(bus), (((dev)2)|(fn)), apicid_sb800, (pin))
 
   /* APU Internal Graphic Device*/
   PCI_INT(0x0, 0x01, 0x0, intr_data[0x02]);
@@ -149,6 +166,25 @@ static void *smp_write_config_table(void *v)
   IO_LOCAL_INT(mp_NMI, 0x0, MP_APIC_ALL, 0x1);
   /* There is no extension information... */
 
+  // program interrupt line registers for legacy OS use
+  pci_write_config32(dev_find_slot(0, PCI_DEVFN(0x01, 0)), 0x3C, 0x0B);
+  

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

[Scott Duplichan]

Paul Menzel wrote:
 
]Dear coreboot folks,
]
]
]I try to get KolibriOS running on the ASRock E350M1 with coreboot and
]SeaBIOS payload. Keyboard and mouse do not work [1] probably because
]KolibriOS needs PIC mode.
]
]Was somebody successful in getting KolibriOS working on a board with
]coreboot?
]
]Is there an easy way to use PIC instead of APIC mode with coreboot and
]SeaBIOS or is APIC mode assumed everywhere?
]
]
]Thanks,
]
]Paul
]
]
][1] http://bugs.kolibrios.org/view.php?id=84

The PS/2 keyboard mostly works with KolibriOS on my Asrock
E350M1 with coreboot+SeaBIOS. Out of about 10 tests, it did
fail once. In that case the SeaBIOS debug messages showed
that SeaBIOS did not detect the PS/2 keyboard.

I don't know why the USB mouse doesn't work. It works with
the OEM BIOS, but not coreboot+SeaBIOS.

If you want to see my build options (and rom image+boot log),
it is here:
http://notabs.org/coreboot/e350m1-kolibri.7z

I switched the SATA to IDE mode only to work around an
AMD simnow problem. One line is added to agesa to work
around another simnow problem. Other changes are hacks
to get SeaBIOS to build from Windows. Building SeaBIOS
from Windows is truly a painful experience. When I modify
the makefile to work around a couple of problems with
the Windows build environment, git gets upset.

Thanks,
Scott



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

Re: [coreboot] AGESA (f15tn) AmdInitReset doing nasty things

[Scott Duplichan]

mrnuke [mailto:mr.nuke...@gmail.com] wrote:

]It's changing the ROM base (devfn 14.3, register 0x6c) from 0xffc0 to 0xff00. 
]The bootblock sets it up correctly, but AmdInitReset messes it up.
]
]Any ideas? AGESA is particularly annoying to grep.
]
]Alex

It is probably 102 of Hudson2LpcResetService.c:
  RwPci ((LPC_BUS_DEV_FUN  16) + FCH_LPC_REG6C, AccessWidth32, 0xFF00, 0, 
StdHeader);
Thanks,
Scott


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

Re: [coreboot] GSoC-2014 Coreboot project

[Scott Duplichan]

Allen Yan [mailto:lex...@gmail.com] wrote:

]Oh, sorry, incorrect address!
]http://www.google-]melange.com/gsoc/proposal/public/google/gsoc2014/jinyiyan/5629499534213120
]
]TianoCore as Coreboot payload
]JinyiYan
]
]Short description: The combination of coreboot + TianoCore
]is the most straightforward option to provide a complete,
]opensource UEFI environment.

This proposal should mention that only x86 systems will
be supported if that is the case.

To provide a complete, opensource x86 UEFI some items not
listed in this project proposal are needed:

1) UEFI support for writing to flash memory. The UEFI name is
Firmware Volume Block protocol. One module for Intel systems and
another module for AMD systems would probably cover most x86
motherboards. All current open source UEFI solutions use a 
substitute that either fails to capture OS writes to UEFI NVRAM
variables, or does not preserve these writes through a power down.
The most visible effect of the substitute firmware volume block
driver is loss of the NVRAM variable that points to the boot
device. When this variable is lost, Linux will no longer boot.
Windows can still boot due to an automatic repair mechanism.
In all cases, the boot order in a multiboot system will be lost.
The use of the substitute firmware volume block driver causes
other limitations such as such as loss of configuration settings.

2) USB OHCI support. Without this the USB keyboard on AMD systems
will not work until after the OS boots.

3) Another missing item is UEFI MP Services. This one might not
be essential. It is needed if UEFI code needs to launch the AP for
such things as gathering SMBIOS data or for setting the SMM base
address register. There is a discussion on the EDK2 Devel mailing
list about the possibility of an open source solution:
https://www.mail-archive.com/edk2-devel@lists.sourceforge.net/msg06354.html


]Based on coreboot-pkg, the project intends to implement
]some new features like UEFI CBFS driver and a GOP driver
]based on pre-initialized framebuffer.

How will the CBFS Driver be used?

Will the GOP driver support multiple video solutions?
If so, how? If I use a brand XYZ video card how will the
GOP driver find the details of the frame buffer? I know
it is possible because operating systems do it. But the
proposal should explain it for those of us who are not
graphics experts.

]Please complete the standard Google SoC application and project
]proposal. Prospective coreboot GSoC student should provide the
]following information as part of their application. If you are
]applying for a flashrom or SerialICE project use common sense
]when using the template below, this is part of the test. ;)
]
]Name:  Jinyi Yan
]Email: lex...@gmail.com
]IM/IRC/Skype/other contact:irc.freenode.net:
]   #coreboot, #flashrom nick: Jinyi-Yan
]Web Page / Blog / Microblog / Portfolio:
]Country/Timezone:China/UTC+08
]Normal working hours(UTC): 10:00~16:00
]School:University of Chinese Academy of Sciences
]Expected graduation date: 2015
]
]
]coreboot welcomes students from all backgrounds and levels
]of experience. To be seriously considered for coreboot GSoC,
]we recommend joining the mailing list and IRC channel.
]Introduce yourself and mention that you are a prospective
]GSoC student. Ask questions and discuss the project that
]you are considering. Community involvement is a key
]component of coreboot development. By the time you have
]submitted your application, you should have downloaded,
]built a and booted coreboot in QEMU, SimNow, or on real
]hardware. Please, email your serial output results to
]the mailing list.
]
]The following information will help coreboot match students
]with mentors and projects.
]
] 
]Please comment on your software and firmware experience.
]
]I used to be a mainboard BIOS engineer in ASUS Technology
]Suzhou Co., Ltd for about two years (2007.7~2009.2). When at
]AsusTek Suzhou, my work is mainly responsible for bios porting
]and fixing bug. There were four mainboards P5KPL-S, P5QL-E,
]P5QL-SE, P5QL. All based on Intel platform and AMI Legacy BIOS Core.
]In the second half year of 2008, I worked on pre-development
]of EFI-BIOS for ASUS mainboard. I wrote a Dual bootblock module
]and added NTFS support(read only) for AutoRecovery module using
]AMI Apito platform (based on EFI).
]
]The most important is that I still have plenty training
]materials(EFI training and hardware initialization,
]kinds of intel chipset datasheet before 2009) from the company.

If the intel chipset documents are not publically available
you should not list them in your proposal. The reason is that
companies sometimes ask engineers to destroy non-public documents
once they leave the company or finish the project.

]They can let me grasp the concepts that I‘ve forgot quickly and
]do proper choice.
]
] 
]Have you participated in the coreboot community before?
]
]No.
]
]Have you contributed to an open source project? Which one?
]What was your 

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

[Scott Duplichan]

陈军根 [mailto:c...@bolod.net]  wrote:

]Hello Rudolf:
]
]Because coreboot can't work in F2A85-MLE, I buy a new mainboard
]f2a85-M,and coreboot can run ok in my f2a85-m, also can boot
]ubuntu.But I find a strange question: when I plug my DIMM in
]DIMM_A1 or DIMM_B1, coreboot can't work, and get the error messages
]assertion Failed:file
]'src/vendorcode/amd/agesa/f15tn/proc/mem/main/mmexcludedimm.c',line 236.
]but when I plug my DIMM in DIMM_A2 or DIMM_B2, coreboot work well;
]Did coreboot only support DIMM_A2 or DIMM_B2 in F2A85-M?

From my reading of the F2A85-M manual, the preferred slot for
a single DIMM is DIMM_A2. So this coreboot behavior doesn't seem
bad. A few years ago, AMD changed the DIMM population order from
a recommendation to a requirement. It may be that Asus reversed
that change for their ROMs.

]I think this is also the reason why coreboot can't work in F2A85-MLE.
]Because F2A85-MLE only have DIMM_A1 and DIMM_B1.

You are probably correct. Because F2A85-MLE has only one DIMM
per channel, you need this change:

diff --git a/src/mainboard/asus/f2a85-m/buildOpts.c 
b/src/mainboard/asus/f2a85-m/buildOpts.c
index 0091cd9..73a0a8c 100644
--- a/src/mainboard/asus/f2a85-m/buildOpts.c
+++ b/src/mainboard/asus/f2a85-m/buildOpts.c
@@ -439,7 +439,7 @@ CONST PSO_ENTRY ROMDATA 
DefaultPlatformMemoryConfiguration[] = {
   //  Speicifes the HW RXEN training seed for a channel of a socket
   //
 
-  NUMBER_OF_DIMMS_SUPPORTED (ANY_SOCKET, ANY_CHANNEL, 2),
+  NUMBER_OF_DIMMS_SUPPORTED (ANY_SOCKET, ANY_CHANNEL, 1),
   NUMBER_OF_CHANNELS_SUPPORTED (ANY_SOCKET, 2),
 /*
   TODO: is this OK for DDR3 socket FM2?



For completeness, the F2A85-MLE code should also have this change:
diff --git a/src/mainboard/asus/f2a85-m/devicetree.cb 
b/src/mainboard/asus/f2a85-m/devicetree.cb
index 0014381..97316d6 100644
--- a/src/mainboard/asus/f2a85-m/devicetree.cb
+++ b/src/mainboard/asus/f2a85-m/devicetree.cb
@@ -122,7 +122,7 @@ chip northbridge/amd/agesa/family15tn/root_complex
 
register spdAddrLookup = 
{
-   { {0xA0, 0xA4}, {0xA2, 0xA6}, }, // socket 0 - 
Channel 0  1 - 8-bit SPD addresses
+   { {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
}

This should work, assuming F2A85-MLE uses SPD addresses A0 and A2.
If not, adjust as needed.
Thanks,
Scott
 
]thanks 
]陈军根
 
 
 
 


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

Re: [coreboot] F2A85-M coreboot not working

[Scott Duplichan]

Rostislav Lisovy [mailto:lis...@gmail.com] wrote:

]On Sun, 2014-03-02 at 00:00 -0600, Scott Duplichan wrote:
] This looks like a divide exception. Finding the source code
] for the failing divide might help narrow down the problem. I
] can't recreate your binary exactly so I can't find the failing
] instruction from the eip value. But based on register values,
] it looks like it is somewhere around line 334 of file
] amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GfxGmcInitTN.c
] You might be able to use the link map, disassembly, or debug
] prints to figure out the exact source line that is failing.
]
]I compiled the GDB support and connected to it from the other computer.
]The outcome of the debugging:
]
]_text () at src/arch/x86/lib/c_start.S:89
]warning: Source file is more recent than executable.
]89 callmain
](gdb) c
]Continuing.
]
]Program received signal SIGFPE, Arithmetic exception.
]0x0022fabf in GfxGmcInitializeSequencerTN (Gfx=0x1660) at
]src/vendorcode/amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GfxGmcInitTN.c:334
]warning: Source file is more recent than executable.
]334  scale_mp0 = (GfxLibGetMaxSclk (GnbLibGetHeader (Gfx)) * 100) / 
memps0_freq;
]
](gdb) p memps0_freq
]$1 = 0
]
](gdb) p Gfx
]$2 = (GFX_PLATFORM_CONFIG *) 0x1660
]
](gdb) l
]329  }
]330
]331  //scale_mp0 = sclk_max_freq / memps0_freq
]332  //scale_mp1 = sclk_max_freq / memps1_freq
]333  //Multiply it by 100 to avoid dealing with floating point values
]334  scale_mp0 = (GfxLibGetMaxSclk (GnbLibGetHeader (Gfx)) * 100) / 
memps0_freq;
]335  scale_mp1 = (GfxLibGetMaxSclk (GnbLibGetHeader (Gfx)) * 100) / 
memps1_freq;
]336
]337  GnbRegisterReadTN (TYPE_GMM , 0x2774 , ex1047.Value, 0, 
GnbLibGetHeader (Gfx));
]338  GnbRegisterReadTN (TYPE_GMM , 0x2778 , ex1048.Value, 0, 
GnbLibGetHeader (Gfx));
]
](gdb) p memps1_freq
]$5 = 333

It is good to see you have a debugger working. That confirms the problem
really is line 334. You dumped memps1_freq, but line 334 divides by
memps0_freq. Presumable memps0_freq is zero. If the failing instruction 
is div esi, then memps0_freq=0 is confirmed by your original email that
shows value 0 in the esi register.

Apparently something is going wrong with the code a few lines above
that initializes memps0_freq. You could step through that code and try
to understand the problem. You could also try forcing a non-zero value
such as 333 into memps0_freq to see how much farther execution gets.
Thanks,
Scott

]Regards;
]Rostislav Lisovy



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


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

Re: [coreboot] F2A85-M coreboot not working

[Scott Duplichan]

Rostislav Lisovy [mailto:lis...@gmail.com] wrote:

]Hello;
]I am trying to run coreboot on F2A85-M motherboard (without VGA support
]enabled). The CPU used is AMD Trinity A8-5600K, RAM is Kingston HyperX
]PnP 4GB (2x2GB) DDR3 1866
](http://www.kingston.com/datasheets/KHX1866C11D3P1K2_4G.pdf).
]
]I cloned the coreboot repository and ran 'make menuconfig'. The only
]options I set were motherboard vendor and type (RAM voltage is the
]default value of 1.5V). The desired payload is the default SeaBIOS. I
]have no interest in enabling VGA, thus I did not try to enable it.
]I used flashrom to flash the image. When I try to boot, execution fails
]with the following message (full log in the attachment):
]
]  Enabling resources...
]
]  Fam15 - domain_enable_resources: AmdInitMid.
]  agesawrapper_amdinitmid Unexpected Exception: 0 @ 10:0022fabf - Halting
]  Code: 0 eflags: 00010046
]  eax: 0002e630 ebx: 014d ecx: 0002 edx: 
]  edi: 100123e3 esi:  ebp: 1660 esp: 002bcd60

This looks like a divide exception. Finding the source code
for the failing divide might help narrow down the problem. I
can't recreate your binary exactly so I can't find the failing
instruction from the eip value. But based on register values,
it looks like it is somewhere around line 334 of file
amd/agesa/f15tn/Proc/GNB/Modules/GnbInitTN/GfxGmcInitTN.c
You might be able to use the link map, disassembly, or debug
prints to figure out the exact source line that is failing.
Thanks,
Scott 

]The number on my PCI POST card is 0x1.
]
]Unfortunately I have no other RAM modules to try. I tried to change the
]position from blue slots to black slots but then I got:
]
]  coreboot-4.0-5584-ge92155f-dirty Sat Mar  1 21:05:40 CET 2014 starting...
]  BSP Family_Model: 00610f01 
]  cpu_init_detectedx =  
]  agesawrapper_amdinitreset Fch OEM config in INIT RESET Done
]  Got past agesawrapper_amdinitearly
]  ASSERTION FAILED: file 
'src/vendorcode/amd/agesa/f15tn/Proc/Mem/Main/mmExcludeDimm.c',  line 236
]
]The command 'make crossgcc' also seems not to help at all.
]
]I will appreciate any ideas.
]
]Regards;
]Rostislav Lisovy



-- 
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

[Scott Duplichan]

HacKurx [mailto:hack...@gmail.com] wrote:

] David wrote:
] With just 1 stick in the A1 slot, please post a pastebin of the console
] output.
]
]Perfect! It is perfectly detailed, the cpu is not recognized:
]http://pastebin.com/2Lbew82b

you could try adding your cupid to the list in
src/cpu/amd/agesa/family15tn/model_15_init.c:

static struct cpu_device_id cpu_table[] = {
{ X86_VENDOR_AMD, 0x610f00 }, /* TN-A0 */
{ X86_VENDOR_AMD, 0x610f31 }, /* RL-A1 */
{ 0, 0 },
};
Thanks,
Scott


]Thanks, best regards,



-- 
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

[Scott Duplichan]

HacKurx [mailto:hack...@gmail.com] wrote:

]Thank you for adding this great feature that I hope will be added by
]default in Kconfig.
]Unfortunately, this option has no more help me to solve my problem
]with the richland architecture.

Your board is probably crashing at line 252 of file:
vendorcode/amd/agesa/f15tn/Proc/CPU/cpuFamilyTranslation.c

SubFamilyIdPtr[j] ((CONST CPU_LOGICAL_ID_XLAT **)CpuLogicalIdAndRevPtr, 
LogicalIdEntries, LogicalFamily, StdHeader);

The reason is that the loop is processing each element of table
F15LogicalIdTable until a match is found. But that table includes
a NULL terminator (line 1176 of file:
vendorcode/amd/agesa/f15tn/Include/ OptionFamily15hInstall.h)

This means that if no CPUID match is found, a NULL function pointer
will be called. That problem is an agesa bug that shows up only
when an unsupported cpu is found.

The cupid is not found because trinity support is included but 
richland support is needed. I do not know if forcing the trinity
code to run on richland will work, but you could try it. One way
to try it is to change the == to != on line 255 of file
vendorcode/amd/agesa/f15tn/Proc/CPU/cpuFamilyTranslation.c.

Thanks,
Scott



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

Re: [coreboot] High demand for CLI payload: Use GRUB 2?

[Scott Duplichan]

mrnuke [mailto:mr.nuke...@gmail.com] wrote:

]On Thursday, January 23, 2014 10:59:21 PM Paul Menzel wrote:
] Do you also know if GRUB 2 does not fulfill one of these requirements?
] 
]GRUB2 doesn't meet several requirements that vendors usually have:
]* must be crappily coded (ignoring the GNU coding standard here)
]* code must be unreadable to the casual trained observer
]* must be full of redundancy
]* must contain many superfluous functions
]* must be hard to get working (vendors want to add value, right?)
]* requires Visual Studio to compile

UEFI shell of course.
Thanks,
Scott

]I can't speak for older versions of GRUB2, but 2.02 beta fails to fulfill any 
]and all of the above requirements.
]
]Alex



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

[coreboot] coreboot engineer needed

[Scott Duplichan]

https://intel.taleo.net/careersection/1/jobdetail.ftl?job=725464

Thanks,
Scott


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

Re: [coreboot] coreboot engineer needed

[Scott Duplichan]

David Hubbard [mailto:david.c.hubbard+coreb...@gmail.com] wrote:

]Hi Scott,
]Without additional information about the following questions,
]the job offer misses some candidates. Still, in this economy,
]kudos for the offer.

I have never worked for Intel so I can only guess about
the job details. I suspect the creation of this position
is a consequence of coreboot now being the fastest growing
boot firmware used in the PC market:
http://www.theregister.co.uk/2013/07/11/chromebooks_fastest_growing_pc_market/
The listing's incorrect capitalization of coreboot shows that
coreboot is a new thing to Intel managers. Intel has been
pushing for UEFI as the standard x86 boot firmware since
1999, so the recent success of coreboot (through chromebook)
has probably taken some Intel managers by surprise. 

]1. What does coreboot engineer mean? An engineer who has
]experience with coreboot -- or an engineer who will be working
]openly, supporting the coreboot project, and contributing
]patches, source code, and documentation?

I can only guess about the job details. These job descriptions
often contain lots of cut and paste, and little proofreading.
At least this one lists Demonstrated C coding skills. The
nearly universal use of C/C++ in job advertisements is 
annoying (in my opinion, C and C++ are quite different languages).
It is also odd to see a requirement for 5 years of UEFI or 
coreboot experience. Probably some of both would be better,
given that the reference code must be packaged for both
UEFI and coreboot use.

]2. What legally binding signatures does the position require?
]For example, Intel has a standard NDA as well as several Trade
]Secret documents; please include an exhaustive list and highlight
]the agreements that will have a material affect on the engineer's
]efforts to improve http://www.coreboot.org/Binary_situation either
]during their free time after hours, or after they no longer work
]for Intel.
]3. Will the position require the engineer to intermittently work
]with Microsoft products, outside of compatibility tests? Will the
]position require the engineer to work on open source projects that
]are incompatible with the GPLv3, specifically the non-Tivoization
]clause? Will the position require the engineer to support UEFI
]Secure Boot?

I can't answer for Intel, but I really doubt any Microsoft OS
boot work is involved. The only Windows logo approved boot
method is UEFI. Intel already has a UEFI BIOS team to handle that.
Same for secure boot. I would be willing to bet that Intel wants
pure (UEFI free) coreboot here. Microsoft is the only company that
wants 'secure boot'. Google has their own security mechanisms that
seem to be getting the job done. Microsoft has UEFI.

Thanks,
Scott

]If you are not at liberty to discuss these kinds of details, it's fine.
]
]David
]
]On Thu, Jan 9, 2014 at 7:37 AM, Scott Duplichan sc...@notabs.org wrote:
]
]https://intel.taleo.net/careersection/1/jobdetail.ftl?job=725464
]
]Thanks,
]Scott





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

Re: [coreboot] a question about coreboot and Bochs emulator

[Scott Duplichan]

ron minnich [mailto:rminn...@gmail.com] wrote:

]A number of us used bochs years ago for coreboot debugging. IIRC it
]just worked when we tried it.
]
]ron

I remember in 2008 when a guy named Kevin proposed changing the
bochs bios from asm code to C code because the build environment
for the asm version was next to impossible to setup. Others were
skeptical about his proposal to use gcc for 16-bit x86 code
generation, but it worked out OK. Today that C coded BIOS is the
default coreboot payload. Though I have not used bochs for several
years, I bet SeaBIOS would still work without too much trouble.

But coreboot itself is a different story I imagine. Today, the 
DDR3 memory reference code used by AMD contains elaborate 
algorithms for receiver enable training, DQS read and write
position training, etc. I think it takes a significant amount
of memory controller emulation code to make the AMD DDR3
initialization pass. I imagine the situation is similar for
Intel memory reference code. Same for HT and QPI.

In 2004 I modified bochs enough to boot a production HP ProLiant
DL145 BIOS (http://notabs.org/bochs/). That took some work, but
the work mostly involved adding enough Opteron/AMD8111 PCI config
space emulation to make the AMI BIOS happy. Memory initialization
was relatively simple in those days. In 2004, bochs had no PCI
config space emulation at all as far as I remember.

AMD simnow has enough chipset and memory controller to boot an
unmodified coreboot. The biggest limitation of AMD simnow is
the public version doesn't support fusion and more recent 
processors.

Intel can boot unmodified images using Simics, according to
something I read a while back. But I don't think Intel has
a public version of Simics.

Thanks,
Scott

]On Thu, Jan 9, 2014 at 5:22 PM, behrouz khosravi bz.khosr...@gmail.com wrote:
] Hello every one. I have searched a lot on the Net to find my answer but
] I didn't got any helpful results so I decided to use the mailing list. my
] question is that has any body ported coreboot to Bochs emulator
] successfully.
] I know that Qemu or Simnow are available for emulating a platform but I like
] to test it Bochs.
] thanks



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

Re: [coreboot] EDK2 Duet (UEFI) payload for coreboot

[Scott Duplichan]

Scott Duplichan [mailto:sc...@notabs.org] wrote:

]The UEFI payload project I have been working on is usable now,
]though it has been tested on a single board only (ASRock E350M1).

I updated this payload project so that coreboot modifications are
no longer needed. Now the payload is added using an existing
cbfstool command:
build/cbfstool build/coreboot.rom add-flat-binary
-f ../edk2/build/images/EFILDR16 -n fallback/payload
-l 0x10 -e 0x102000

The coreboot and edk2 snapshots are updated and patches rebased.
http://notabs.org/coreboot/duet-payload/


]In a few days I will setup an AMD family 10h board and try it there.

A quick try did not get coreboot going on my RS780/SB700 family 10h
board, so I set that project aside for a while. Also, those boards
have only 1MB of flash, so the UEFI payload would have to slim down
by dropping integrated shell, network boot, etc.
Thanks,
Scott

]Though true flash-backed NVRAM support has not been added yet,
]it is quite usable with the emulated NVRAM substitute it uses.
]Probably the most visible effect of the emulated NVRAM is inability
]to maintain boot order when multiple operating systems are installed.
]The emulated NVRAM does allow the Windows 8 reboot to UEFI shell or
]UEFI setup to work.
]
]The payload has been tested with major UEFI capable operating systems
](Ubuntu 13.10, Windows 7, Windows 8.1) on real E350M1 hardware and
]it is working well.
]
]http://notabs.org/coreboot/duet-payload/
]
]Thanks,
]Scott




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


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

Re: [coreboot] Removing microcode updates from blobs

[Scott Duplichan]

mrnuke [mailto:mr.nuke...@gmail.com] wrote:

]Hi all,
]
]Following some recent discussions on IRC, we've see that some people
]just don't like us shipping microcode in the main repository. OK,
]microcode is a blob, so it belongs in blobs. Let's leave that at that.

De-blobing agesa is going to be a pain. I have seen these microcode
discussions here from time to time and never understood the concern.
There is no concern about the SMU binaries embedded in agesa, and
there is no concern about RD890 firmware either. Just microcode. I
understand the objection to lack of source code for something like
video option ROMS. With video option ROM source code, we could easily
modify the familiar x86 code to add customizations for improvements
such as boot time reduction. But the same is not true for microcode.
There is no reasonable expectation that the open source community 
could make meaningful improvements or bug fixes to a processor without
having the processor source code, internal docs, and access to the
processor designers. Even if I am wrong, there is still the problem
of the private encryption key needed to sign the patch. It is unlikely
Intel and AMD are going to reverse their policy of encrypting 
microcode patches. We choose to purchase processors without source
code then complain about lack of source code for their updates. I
understand the objection to putting binary data into source control.
It bloats the archive and does not produce meaningful diff output.
But the microcode size is fairly small when compared to a large
module like agesa. AMD tries to make agesa so that it can be used
without modification. That way updates can drop in easily. Pulling
out the microcode or other binary parts is going to defeat that. I
hope the idea of letting the agesa SMU, NB, and microcode stay where
they are will be considered.
Thanks,
Scott
 
]Kyösti and I are working on making all CPUs update microcode from CBFS.
]This is the first step in moving the microcode updates out of main. Our
]branches are already up on gerrit:
]
]Infrastructure (ready for review):
]http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+topic:microcod]e-cbfs/infrastructure,n,z
]
]Intel branch (ready for review):
]http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+topic:microcod]e-cbfs,n,z
]
]AMD branch (ready for review/needslove):
]http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+topic:microcod]e-amd,n,z
]
]I've also started integrating the microcode updates for Intel CPUs in
]blobs. The branch is here (ready for review):
]http://review.coreboot.org/#/q/status:open+project:blobs+branch:master+topic:microcode-]deblob,n,z
]
]Once ALL that is done, we can start removing those updates from master
](needslove):
]http://review.coreboot.org/#/q/status:open+project:coreboot+branch:master+topic:microcod]e-deblob,n,z

]This last branch is a WIP, but we should be able to have it build via
]Jenkins once all the other Intel stuff is done.
]
]And once ALL that is done, we'll be able to update Kconfig such that
]microcode is only included automatically when the blobs repository is
]enabled. This separation of blobs versus free code is only logical, and
]the end result is more options for the user.
]
]Reviews and testers highly appreciated. Let's get this done once and for
]all. Remember, this is a multi-step process with changes that are, sadly
]not trivial to keep track of.
]
]Alex



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

[coreboot] EDK2 Duet (UEFI) payload for coreboot

[Scott Duplichan]

The UEFI payload project I have been working on is usable now,
though it has been tested on a single board only (ASRock E350M1).
In a few days I will setup an AMD family 10h board and try it there.

Though true flash-backed NVRAM support has not been added yet,
it is quite usable with the emulated NVRAM substitute it uses.
Probably the most visible effect of the emulated NVRAM is inability
to maintain boot order when multiple operating systems are installed.
The emulated NVRAM does allow the Windows 8 reboot to UEFI shell or
UEFI setup to work.

The payload has been tested with major UEFI capable operating systems
(Ubuntu 13.10, Windows 7, Windows 8.1) on real E350M1 hardware and
it is working well.

http://notabs.org/coreboot/duet-payload/

Thanks,
Scott




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

Re: [coreboot] EDK2 Duet (UEFI) payload for coreboot

[Scott Duplichan]

]Patrick Georgi wrote:
]
]Am Freitag, den 06.12.2013, 10:04 -0600 schrieb Scott Duplichan:
] The payload has been tested with major UEFI capable operating systems
] (Ubuntu 13.10, Windows 7, Windows 8.1) on real E350M1 hardware and
] it is working well.
] 
] http://notabs.org/coreboot/duet-payload/
]Do you mind if I port this to corebootPkg?

Hello Patrick,

Sure. Use this code in any way that is useful to the coreboot project.

Thanks,
Scott

]Patrick


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

Re: [coreboot] DUET freeze problem

[Scott Duplichan]

Anthony Ross wrote:

]Hello There,
]
]There has been no response to my last mentioned problem
](Seabios floppy mechanism) DUET freeze. So also could
]anyone look up the code to execute DUET as a coreboot payload.
]
]Regards... 
]
]Neo. 

Hello,

The attachment you sent on 11/06/2013 shows that your serial
port logging is working well. If you are not seeing the debug
messages from updatememorymap (), then it is possible execution
is hanging before that code is able to execute. That code is
part of BdsDxe.efi. That module is entered when dxemain.c
executes gBds-Entry (gBds). You could put some debug prints
in that area to see what is happening.

The existing UEFI coreboot payload project is here:
https://github.com/pgeorgi/edk2/tree/coreboot-pkg
The UEFI coreboot payload project that I am working on won't
be ready for a long time.

Thanks,
Scott


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

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Scott Duplichan]

Patrick Georgi wrote:

]Am 2013-11-06 14:55, schrieb Scott Duplichan:
] ]We had that 4 years ago or so. Want me to look up the code?
] 
] Yes, I would be interested to see how others approach it,
] though I have the payload support working now.
]I'll take a look, but it can take some days.

No need to dig it up. 

] 1) Hack in a change to make it use the proper I/O port when
] reading the ACPI power management timer. The ideal solution
] is to get the ACPI PM timer address from the ACPI tables,
] which is what Duet does.
]I started work on FixedAtBuild Pcds that teach the various table 
]managers in UEFI to inherit existing tables (SMBIOS, ACPI). That way we 
]could pass the coreboot tables into UEFI, making the payload even more 
]independent.

Sounds good.

]The change might also be useful for DUET, but I don't know if upstream 
]is actually still interested in it.
]
] 2) Change PCI device and function numbers hard-coded in
] bdsplatform.h from 440BX values to AMD SB800 values. Not
] sure if this is essential for shell boot.
] 3) Disable PCI ARI support to eliminate some EDK2 code
] crashes. Not sure if the cause of the problem is an EDK2
] problem or a simnow model problem.
] 4) Work around a crash in SmbiosDxe.c. I didn't investigate
] the cause.
] 5) Expand the temporary identity mapped page tables. I
] believe they map up to 1GB, and I am using more.
] 6) Big changes to make it build on Windows using Microsoft
] tools. It is really unfortunate that as of 2013, Microsoft
] doesn't support C99. I used fasm in place of Microsoft's
] assembler because it can assemble a module containing both
] 32-bit and 64-bit code.
]Any chance you could publish these somewhere?

OK, I put it here:
http://notabs.org/coreboot/e350m1-edk2corebootpkg.7z

The original and modified projects are included for diffing.

I added NOOPT to the dsc file for easier debug.

The size adjustments to the fdf file are to prevent a
build fail when the NOOPT target is built.

Changes to the C code are work-arounds for Microsoft's
lack of C99 support.

corebootPkg\Sec\X64\SecEntry.asm is a port of SecEntry.asm
for use in the Windows build environment. I used the fasm
assembler to minimize changes. Unfortunately the Microsoft
linker won't accept relocations between 32 and 64 bit code
due to pointer truncation concern. I couldn't find a link
solution, so I had to change the code to position independent.
I didn't try to port the asm support for PCDs and replaced
them with hard coded constants.

] might even be possible to extract the native UEFI GOP video driver
] from an OEM UEFI ROM for reuse. But I believe in the case of my
] ASRock E350M1 the OEM UEFI ROM has no GOP driver, only legacy.
]Another alternative would be graphics init in coreboot, setting up a 
]frame buffer. UEFI could parse out the cbtables to figure out the 
]position and layout of the framebuffer in a primitive GOP driver.
]
]Unfortunately my time for UEFI work is rather limited these days.
]
] The biggest work is going to be support for the large NVRAM
] area needed by EDK2 UEFI. A generic solution is not possible.
]Not totally generic, but I guess we could carve out some space by adding 
]a CBFS file (with proper alignment) whose content is managed as nv 
]variable storage (similar to how the MRC stuff on both intel and AMD 
]works now).
]For security, I'd also propose doing the actual flash access from SMM in 
]coreboot code (which can reuse the existing flash drivers) - but maybe 
]that's something for later.
]
] I will start with support for AMD systems.
]Great!
]
]
]Regards,
]Patrick



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

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Scott Duplichan]

Patrick Georgi wrote:

]Am 2013-11-06 00:28, schrieb Scott Duplichan:
] I am working on a project to allow Duet to run as a
] coreboot payload, and to fix the major Duet problems.
]We had that 4 years ago or so. Want me to look up the code?

Yes, I would be interested to see how others approach it,
though I have the payload support working now.

] It will also continue to support bootable image form.
] It may take me a few weeks to reach the goal of booting
] operating systems in UEFI mode on real hardware though.
]corebootPkg boots the Fedora 19 Live DVD on QEmu.
]](http://www.coreboot.org/~patrick/coreboot/2013-10-29-coreboot%2btianocore%2bcsm-qemu-]]i440fx.rom)
]Could you try on real hardware? I'm away from mine for the next couple 
]of days.

I did get this going on ASRock E350M1, at least on simnow.
The biggest problem is that parts are taken from the OVMF
project, which is hard-coded for Intel 440BX chipset in
some aspects. I got it to boot the shell with these changes:

1) Hack in a change to make it use the proper I/O port when
reading the ACPI power management timer. The ideal solution
is to get the ACPI PM timer address from the ACPI tables,
which is what Duet does.
2) Change PCI device and function numbers hard-coded in
bdsplatform.h from 440BX values to AMD SB800 values. Not
sure if this is essential for shell boot.
3) Disable PCI ARI support to eliminate some EDK2 code
crashes. Not sure if the cause of the problem is an EDK2
problem or a simnow model problem.
4) Work around a crash in SmbiosDxe.c. I didn't investigate
the cause.
5) Expand the temporary identity mapped page tables. I
believe they map up to 1GB, and I am using more.
6) Big changes to make it build on Windows using Microsoft
tools. It is really unfortunate that as of 2013, Microsoft
doesn't support C99. I used fasm in place of Microsoft's
assembler because it can assemble a module containing both
32-bit and 64-bit code.

These changes are enough to get the shell on the serial
console. Exiting the shell runs into trouble though.

]edk2 source with (some) documentation can be found at
]https://github.com/pgeorgi/edk2/tree/coreboot-pkg
]
]The image above was built with the GCC47 toolchain, the 64bit issues it 
]had are now fixed.
]
]Like Duet, the resulting payload should be portable across boards since 
]coreboot does the initialization part.
]CSM is useful to initialize video if you only have a PCBIOS style 
]VGABIOS (eg. on QEmu).

I am hoping to avoid use of full CSM. corebootPkg/Csm/CsmSupportLib
has a lot of hard-coding for Intel 440BX. The Duet project uses
an INT 10h wrapper called BiosVideoThunkDxe which can make legacy
video usable. UEFI has native support for most other devices. It
might even be possible to extract the native UEFI GOP video driver
from an OEM UEFI ROM for reuse. But I believe in the case of my
ASRock E350M1 the OEM UEFI ROM has no GOP driver, only legacy.

The biggest work is going to be support for the large NVRAM
area needed by EDK2 UEFI. A generic solution is not possible.
I will start with support for AMD systems.

Thanks,
Scott


]Patrick




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

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Scott Duplichan]

Anthony Ross wrote:

]Dear Folks
]
]Thanks for the suggestions. Well this is how I debug 
]
]qemu-system-x86_64 -no-kvm -net none -bios build/coreboot.rom
] -s -global isa-serial.iobase=0x3f8 -serial file:/new/serial8.log
] -monitor stdio
]
] (Don' t consider the 8)
]
]
]Please correct me if Im mistaken
]
]By the way by freeze I meant is that the DUET BIOS page gets displayed but it 
does not ]allow to select anything. If I use the down
arrow key there is no effect...So still ]facing the same problem.
]
]
]Any suggestions...

UEFI is not easy to debug. I do see that both PS/2
and USB keyboard support module load messages in your log file:

Loading driver at 0x000173D5000 EntryPoint=0x000173D52C0 UsbKbDxe.efi
Loading driver at 0x000173C7000 EntryPoint=0x000173C72C0 Ps2KeyboardDxe.efi

Though bdsdxe loads...
Loading driver at 0x00017428000 EntryPoint=0x000174282C0 BdsDxe.efi
... I do not see its debug messages.

You could would step through the code of PlatformBdsInit
to see why the messages from UpdateMemoryMap() are not displayed.
Thanks,
Scott
]
]
]Neo...
]
]
](Attached serial log) 
]
]
]
]
]On Wed, Nov 6, 2013 at 4:58 AM, Scott Duplichan spambuc...@notabs.org wrote:
]Anthony Ross wrote:
]
]]Hello Coreboot Folks,
]]
]]Well Thanks for the suggestions. It seems that  DUET boots but now a major 
problem has ]]cropped up. It freezes at the main
]DUET-BIOS page not allowing to perform any further ]operations, like booting a 
HDD image ]or fingering around the EFI BIOS options.
]Similarly ]If I had the .lzma to the cbfs file name I face the same problem 
like earlier ]so having ]it as myfloppy.img makes it
take
]effect.
]]
]]
]]Any further Ideas about these problems.
]]
]]
]]Regards..
]]
]]
]]Neo 
]For your freeze problem, how are you debugging? The usual way
]is to enable and capture debug messages written to a serial
]port. I believe the standard Duet settings make it write
]debugging messages to a serial port at 3F8 (115200,8,N,1).
]Because halt for assert is enabled by default on Duet, an
]assert is the most likely reason for a freeze. The assert
]will log details to the serial port.
]
]If your hardware doesn't have a serial port, you can use
]an emulator such as simnow or qemu. A good thing about
]Duet is that it is generic and in theory can run on
]different systems without porting. If I remember correctly,
]the current Duet project can boot to the UEFI shell and
]menu system on AMD simnow using the Solo board model.
]
]I am working on a project to allow Duet to run as a
]coreboot payload, and to fix the major Duet problems.
]It will also continue to support bootable image form.
]It may take me a few weeks to reach the goal of booting
]operating systems in UEFI mode on real hardware though.
]
]Thanks,
]Scott
]
]On Sat, Oct 26, 2013 at 8:01 PM, Kevin O'Connor ke...@koconnor.net wrote:
]On Thu, Oct 24, 2013 at 12:17:33AM -0500, Scott Duplichan wrote:
] Scott Duplichan wrote:
]
] ..snip..
]
] ]I have no experience with making SeaBIOS boot an embedded floppy
] ]image. I may be able to give this a try, but I would have to first overcome
] ]Windows build problems that have crept into both SeaBIOS and coreboot.
]
] I tested the SeaBIOS virtual floppy boot with EDK2 Duet and it worked
] for me. I tested with the ASRock e350M1 project. Here is the cbfstool
] output:
]Thanks for confirming.
]
] scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build
] $ cbfstool.exe coreboot.rom print
] coreboot.rom: zd kB, bootblocksize 4096, romsize 1008, offset 0x40
] alignment: 0 bytes
]
] Name                           Offset     Type         Size
] cmos_layout.bin                0x0        cmos_layout  1776
] pci1002,9802.rom               0x740      optionrom    57856
] fallback/romstage              0xe980     stage        345432
] fallback/coreboot_ram          0x62f40    stage        203312
] fallback/payload               0x949c0    payload      53738
] config                         0xa1c00    raw          3831
] (empty)                        0xa2b40    null         3526744
]
] scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build
] $ cbfstool.exe coreboot.rom add -f /d/duetfloppy.img -n 
floppyimg/duetfloppy.img -t ]raw
]FYI, it's also possible to add an lzma compressed image (make sure the
]cbfs filename ends in .lzma then).
]
]-Kevin



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

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Scott Duplichan]

Anthony Ross wrote:

]Hello Coreboot Folks,
]
]Well Thanks for the suggestions. It seems that  DUET boots but now a major 
problem has ]cropped up. It freezes at the main
DUET-BIOS page not allowing to perform any further ]operations, like booting a 
HDD image or fingering around the EFI BIOS options.
Similarly ]If I had the .lzma to the cbfs file name I face the same problem 
like earlier so having ]it as myfloppy.img makes it take
effect.
]
]
]Any further Ideas about these problems.
]
]
]Regards..
]
]
]Neo 

For your freeze problem, how are you debugging? The usual way
is to enable and capture debug messages written to a serial
port. I believe the standard Duet settings make it write
debugging messages to a serial port at 3F8 (115200,8,N,1).
Because halt for assert is enabled by default on Duet, an 
assert is the most likely reason for a freeze. The assert
will log details to the serial port.

If your hardware doesn't have a serial port, you can use
an emulator such as simnow or qemu. A good thing about
Duet is that it is generic and in theory can run on 
different systems without porting. If I remember correctly,
the current Duet project can boot to the UEFI shell and
menu system on AMD simnow using the Solo board model.

I am working on a project to allow Duet to run as a
coreboot payload, and to fix the major Duet problems.
It will also continue to support bootable image form.
It may take me a few weeks to reach the goal of booting
operating systems in UEFI mode on real hardware though.

Thanks,
Scott

On Sat, Oct 26, 2013 at 8:01 PM, Kevin O'Connor ke...@koconnor.net wrote:
On Thu, Oct 24, 2013 at 12:17:33AM -0500, Scott Duplichan wrote:
 Scott Duplichan wrote:

 ..snip..

 ]I have no experience with making SeaBIOS boot an embedded floppy
 ]image. I may be able to give this a try, but I would have to first overcome
 ]Windows build problems that have crept into both SeaBIOS and coreboot.

 I tested the SeaBIOS virtual floppy boot with EDK2 Duet and it worked
 for me. I tested with the ASRock e350M1 project. Here is the cbfstool
 output:
Thanks for confirming.

 scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build
 $ cbfstool.exe coreboot.rom print
 coreboot.rom: zd kB, bootblocksize 4096, romsize 1008, offset 0x40
 alignment: 0 bytes

 Name                           Offset     Type         Size
 cmos_layout.bin                0x0        cmos_layout  1776
 pci1002,9802.rom               0x740      optionrom    57856
 fallback/romstage              0xe980     stage        345432
 fallback/coreboot_ram          0x62f40    stage        203312
 fallback/payload               0x949c0    payload      53738
 config                         0xa1c00    raw          3831
 (empty)                        0xa2b40    null         3526744

 scott@p67-2600k /D/coreboot/win-build-env-011/coreboot/build
 $ cbfstool.exe coreboot.rom add -f /d/duetfloppy.img -n 
 floppyimg/duetfloppy.img -t raw
FYI, it's also possible to add an lzma compressed image (make sure the
cbfs filename ends in .lzma then).

-Kevin



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

Re: [coreboot] Help required to boot DUET (Seabios floppy mechanism)

[Scott Duplichan]

Anthony Ross wrote:

]Thanks for the heartiest reply. Well I have gone through the pros  cons of 
DUET  haven' t faced any hurdles thus ]successfully
building it. Similarly getting to the EDK2 project I have successfully built 
OVMF 32  64 with secure boot ]configuration,
integrating them with seabios as csm and initializing them in QEMU-kvm. I have 
also successfully built  ]booted  the Coreboot Pkg
IA32 encapsulating it in the coreboot.rom and booting it under QEMU-kvm except 
for the X64 ]architectures I faced certain toolchain
errors.
]
]So if the Coreboot Pkg can boot so should DUET. I know there are both 
different but any how they both follow the same ]basis of the
UEFI platform. I say this because the Coreboot Pkg (coreboot.rom) during its 
boot up shows signs of errors  ]debugging messages are
worth noting but DUET (coreboot.rom) seems just absent.It also does not 
indicate any low ]memory problems in real mode, frankly
speaking the coreboot.rom just boots as if it was built with just a seabios 
]payload. Yes one thing can be noted when I had earlier
booted DUET directly under QEMU it indicated something as ]'executing code out 
of memory' and it aborted there.Secondly taking again
into concern the Coreboot Pkg it follows lzma ]compression and also DUET so any 
issue about that?   what about QEMU does it require
any changes as for DUET

It is good to hear you are  you are building successfully. Here is an 
alternative
method of booting the EDK2 Duet project. It uses the publically available AMD
simnow in place of qemu. Simnow has the benefit of booting unmodified BIOS
and other code. It boots the same BIOS image that is used on the real hardware.
You can use simnow to ensure you have a working image. Then you can try it on
real hardware. Simnow can be downloaded from here:
http://developer.amd.com/tools-and-sdks/cpu-development/simnow-simulator/

I tested using the simnow model for an old AMD reference board named Solo.
The limited virtual address space of the processor used in the Solo model
avoids a memory overwrite bug in the Duet code. The limited DRAM of the
Solo model avoids pointer truncation problems in the Duet code.

Here is how I tested:
1) get EDK2 SVN version 14796 from one of the public servers.
2) build the Duet project and use the output to make a bootable hard disk image.
3) boot the hard disk image using the simnow solo model.

The simulation will stop with a red screen register dump. This is due
to a Duet bug where initialization of the 8254 timer while it is already
running causes a spurious interrupt. Use the built-in debugger to
continue out of the exception handler's hang loop. The simulation
will continue and boot the UEFI shell. If you exit the shell, the UEFI
menu system will run.

Here it the bootable hard disk image and a Windows batch file
for starting simnow. Some screen shots are also included.
http://notabs.org/edk2-duet/

Once you have this much working, you could try real hardware or
a different simnow model. This will expose some problems that 
need to be fixed in order to run on systems with larger memory
and on processors with larger virtual address space. 

I have no experience with making SeaBIOS boot an embedded floppy
image. I may be able to give this a try, but I would have to first overcome 
Windows build problems that have crept into both SeaBIOS and coreboot.

Thanks,
Scott





              

On Wed, Oct 23, 2013 at 1:00 AM, Scott Duplichan spambuc...@notabs.org wrote:
Neo wrote:

]Hello
]
]  There has been no response to my thread [Help required to initialize
]coreboot as Seabios (floppy mechanism for DUET) payload] since a long
]time.I have eagerly waited but no solutions have turned up.
]  If Im mistaken in any way or the other please let know.
]
]Regards
]
]Neo.
Hello,

If this is really something you want I may be able to help. Be aware that
Duet
is not an active EDK2 project. Duet has many problems that you must solve
before it is usable. The Duet concept is sound, and is a good match for
coreboot.
But it is not in general a usable project as it exists in the public EDK2
archive.

Building Duet should be easy, relative to other EDK2 projects. Can you
successfully
build other EDK2 projects? From EFI's beginning in 1999 to recently, the
only
supported build toolset was Microsoft. Recently gnu build tool support was
added.
But because Duet is not an active project, it may not build easily with gnu
tools.
In addition, EDK2 does not properly support any Windows port of the gnu
tools.
So try building with Microsoft tools for a reference point. But be aware
that EDK2
actually uses a hard-coded absolute path to the Microsoft tools. So unless
your
Microsoft build tools are installed in the same location as theirs, you will
have to
modify Basetools\Conf\ tools_def.template.

Once Duet builds, there are some basic bugs to fix. There is a memory
overlap
problem for example. Duet cannot work with more than 4GB of RAM if I
remember correctly

Re: [coreboot] Trying to support Attro G5G100-P board

[Scott Duplichan]

Christoph Grenz wrote:

]Hello,
]
]I'm currently experimenting with an Attro G5G100-P industrial board.
]
]According to the documentation the chipset is an Intel i915GM with 
]an Intel 82801FBM southbridge (which flashrom shows as ICH6-M).
]Inteltool only shows:
]   Northbridge: 8086:2590 (unknown)
]   Southbridge: 8086:2641 (unknown)
]
]Is the chipset supported (or could it be supported by modifying existing 
]code)?
]
]The main superio is a W83627HG-AW, which is already supported.
]The board seems to have a second superio which manages the four RS232
ports.
]I couldn't yet identify this chip.
]The config mode init sequence is 0x67,0x67 at 0x2e
]and the config mode registers 20-26 contain 02 08 03 19 34 01 00.
]
]Does anybody know something about this second superio chip? I couldn't find

]anything about this chip and as I don't know how it may look like, I can't 
]even locate it on the board.

This looks like Fintek F81216. Apparently superiotool tries only 87h and
77h for Fintek enter config mode, but 67h is needed for this part when
strapped for base address 2Eh.

]Thanks,
]
]Christoph


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

Re: [coreboot] Please advise: (new toolkit) crossgcc fails on ubuntu 32/64 bit fresh installs

[Scott Duplichan]

Mark Mc wrote:

...
] Is there any way to exclude crossgcc for compiling for armv7?
...

Try launching buildgcc directly with no arguments. i386-elf is the default
target.
Lines 5 and 10 of util/crossgcc/Makefile are where the ARM builds are
triggered.

Thanks,
Scott



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

Re: [coreboot] Building AMD Persimmon in MinGW

[Scott Duplichan]

]2013/5/6 Wim Vervoorn wvervo...@eltan.com:
] Hello,
]
]
]
] I am trying to build CoreBoot from Windows using MingGW.
]
]
]
] After downloading the latest version of the complete package to enable 
] this it is possible to build this without problem.
]
]
]
] As this package contains an old version of the tree I updated this to 
] the latest one. After doing this it's not possible to build the 
] Persimmon tree any longer.
]
]
]
] In the latest CoreBoot version the Persimmon tree uses the 
] nvramtool.exe to generate option_table.h. When this is started I get 
] a nvramtool.exe has stopped working message is anyone familiar with 
] that? Is there a solution for this so I can get the tree building with
the latest version as well?
]
]My guess is that nvramtool won't work on any Windows build since Windows
most likely blocks CMOS ](nvram) access.
]Most developers are using Linux; if you are in dire need of a persimmon
coreboot.rom: please say so (I or ]someone else can send you one off-list).

I looked at this problem a while back and found the same thing as you.
Because Windows
blocks direct hardware access attempts by applications, nvramtool fails.
Routing I/O access
through a driver was easy until Microsoft came up with their signed driver
requirement.

The question in my mind is why should the coreboot build process need to
access
the cmos of the build machine? I assume the answer is that it does not, and
accessing
the cmos of the build machine is an unintentional side effect of the way
nvramtool works.

Thanks,
Scott

] Best regards,
]
] Wim Vervoorn



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

Re: [coreboot] ASRock E350M1 video option ROM?

[Scott Duplichan]

Andrew Goodbody wrote:


]
] b) When the board arrives...
] 1) Boot MSDOS and start DOS debug
] 2) At the - prompt, enter these commands:
]-n vga.bin
]-rbx
]-1
]-w
] 3) The option rom is vga.bin in the current directory.
]
] Thanks,
] Scott
]
]a) is good.
]b) is just going to get you 64KB of unintialised data. There is nothing 
]in those instructions to access the video BIOS AFAICT.
]
]Andrew

Oops, make that:
-n vga.bin
-rbx
-1
-w c000:0
-q

Thanks,
Scott



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

Re: [coreboot] Trying to port abit A-S78H

[Scott Duplichan]

Prakash Punnoor wrote:


]BTW, could you explain what happens after soft_reset? Will coreboot run
]again from start?

Yes, the CF9 soft reset starts execution at the reset vector
same as a cold boot. 

] At least the following die(...) statement (romstage.c 
]cache_as_ram_main) suggests that program flow should NOT get there. So, if 
]coreboots runs again from start, why doesn't it enable port 80 again like
]it did initially?

I am not sure. But the important function is sb7xx_51xx_pci_port80(),
called from line 90 of romstage.c. It looks like that function does
everything needed to enable PCI port 80. You could try calling the
function unconditionally and see what happens.

Thanks,
Scott

]Thanks,
]
]Prakash


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

Re: [coreboot] How to make System Restart after Power Fail working onSB800?

[Scott Duplichan]

mopz0506 wrote:

]Hi,
]
]My mainboard is ASRock E350M1, it's sourthbridge is AMD SB800.
]
]I want the machine to restart once I connect the power cable to
]it, without press the POWER button on the front panel.
]...

I worked on a similar problem a wile back, though I don't
remember if it was with ASRock E350M1 or something else.
Anyway, I finally came to the conclusion that my board used
the SIO for this function, and not the SB800. I think I used the
OEM BIOS and compared SIO registers with both settings. It might
be logical device A, CR E4h bits 5 and 6, though I don't have
the exact datasheet.

Thanks,
Scott


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

Re: [coreboot] [SeaBIOS] usb boot issue

[Scott Duplichan]

Kevin O'Connor wrote:

]On Thu, Oct 13, 2011 at 03:56:48PM +0200, Wolfgang Kamp - datakamp wrote:
] 
] Hi,
] 
] is there any solution for the usb boot issue of the AMD SB800 Persimmon
]platform
] with SeaBIOS 1.6.3 and actual Coreboot version?
]
]I'm unfamiliar with the issue.  Can you post the SeaBIOS debug output
]along with a description of the issue you are seeing?

This might be a coreboot problem and not a SeaBIOS problem. See:
http://www.mail-archive.com/coreboot@coreboot.org/msg31922.html

Wolfgang could try reverting the suspect coreboot patch and see
if it solves the problem. The change was a NIC fix I believe.
I think Marc had proposed an alternative NIC fix that could be
tried if the existing one really is causing the usb problem.

]-Kevin


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

Re: [coreboot] DL145 G1 with dual dualcore CPU using coreboot ?

[Scott Duplichan]

Peter Stuge wrote:

] // write to AMD 8131 Link Command Register BUID field (bits 16-20)
] // with value 2 so that the 8111 can be accessed:
] -epcid 0 0 0 c0 00420008 // bus 0, dev 0, fun 0, reg 0xc0
]
]Is it safe to blindly write this word in
]src/northbridge/amd/amdfam10/bootblock.c ? I think this is what is
]missing.

I am not sure if that is a good enough way or not. It has been
a while since I worked with that generation chipset. This way
also works with simnow:

dev = PCI_DEV(0, 0, 0);
byte = pci_io_read_config8(dev, 0xc2);
byte |= 2; /* set BUID in 8131 Link Command Register */
pci_io_write_config8(dev, 0xc2, byte);

] // write to AMD 8111 Rom Decode Control Register and set bit 7
] // to enable LPC memory decoding of the top 4MB of 4GB space:
] -epcib 0 1 0 43 80 // bus 0, dev 1, fun 0, reg 0x43
]
]This is already done in src/southbridge/amd/amd8111/bootblock.c for
]device id 1022:7468 - is this the correct device for that board?

Oh yes, you are correct. That code runs very early, just a few
instructions after reset. Adding only the above AMD8131 write
lets it find and program the 8111 rom decode. The weird thing
is that in simnow, it runs all the way through then loops in
cbfs. If I remove this line:
byte |= (1  6); /* Enable 0xFFB0-0xFFBF (1MB). */
, then it continues. I suspect this is a simnow problem, because
the FFB0 range decode is needed for programming some LPC
flash chip models.

Thanks,
Scott


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

Re: [coreboot] DL145 G1 with dual dualcore CPU using coreboot ?

[Scott Duplichan]

Patrick Georgi wrote:

]Am Freitag, 23. September 2011 01:45:09 schrieb Oskar Enoksson:
] As for the dead behaviour in recent versions I bisected my way down
] to commit 1f7d3c5672ec90f8d71907b1a07c8a87fa461047 (svn 6124). That
] commit adds TINY_BOOTBLOCK support  to AMD-8111 southbridge. I
] understand that this commit splits up things into a romstage and
] coreboot_ram. But what is going wrong, and what should I do? All
] hints appreciated.
]Try a smaller image size (and write it into flash top-aligned). If 
]things work then, the bootblock doesn't correctly set up ROM mapping 
]correctly.

Hello Patrick,

That is a good point about rom mapping. According to the 8111 document,
only the top 64KB is decoded by default. Simnow confirms this, and
won't boot the DL145 G1coreboot image. Dumping the start of the 512KB
image shows it is not decoded:

-d fff8
FFF8-FF FF FF FF FF FF FF FF   FF FF FF FF FF FF FF FF

If I manually issue these PCI config writes while execution is still
in the top 64KB, the entire 512KB is decoded and simnow will boot
the coreboot image:

// write to AMD 8131 Link Command Register BUID field (bits 16-20)
// with value 2 so that the 8111 can be accessed:
-epcid 0 0 0 c0 00420008 // bus 0, dev 0, fun 0, reg 0xc0

// write to AMD 8111 Rom Decode Control Register and set bit 7
// to enable LPC memory decoding of the top 4MB of 4GB space:
-epcib 0 1 0 43 80 // bus 0, dev 1, fun 0, reg 0x43

-d fff8
FFF8-4C 41 52 43 48 49 56 45   00 00 06 F0 00 00 01 AA
LARCHIVE

A couple of PCI config writes similar to these should get it going.

Thanks,
Scott


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

Re: [coreboot] E350M1 does not POST

[Scott Duplichan]

Marshall Buschman wrote:

...

]Hello Kerry:
]
]I have tested your patch set, and it does make the E350M1 boot.
]The bad news is there is now a delay of approximately 5 minutes and 20
]seconds before any serial output is displayed.
]
]The coreboot log is available at
]http://www.lucidmachines.com/coreboot/kerrypatches20110907.txt
]
]Please let me know if I can assist further.
]
]Thank you!
]-Marshall Buschman

The problem of early serial output causing a large boot delay is not new. It
is caused by serial port logging before the SB800 LPC clock is configured,
and/or serial port logging before the SIO baud rate is setup. The original
LPC clock fix was in romstage.c, then later moved to sb800 bootblock.c,
function enable_clocks(). Marshall's log file is missing the following early
serial output, which suggests a problem with the needed early SB800 LPC
clock programming, or SIO baud rate programming:

POST: 0x30
SB800 - Cfg.c - sb800_cimx_config - Start.
SB800 - Cfg.c - sb800_cimx_config - End.
POST: 0x31

I am not in a position to try this on real hardware, but I did do a quick
simnow test. It looks like function enable_clocks() is correctly executing
before the first serial output. But the above lines of early serial output
are logged before the SIO baud rate is programmed. Here is some discussion
of this problem:

http://patchwork.coreboot.org/patch/3178/

That old patch should overcome the problem for the above post code logging.
But the new SB800 logging in sb800_cimx_config() probably needs removing
also.

Thanks,
Scott


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

Re: [coreboot] ASRock E350M1 demo image needed!

[Scott Duplichan]

Carl-Daniel Hailfinger wrote:

]Hi Scott,
]
]a big THANK YOU for that image. I'm booting a openSUSE 11.4 (64bit) from
]a SATA DVD drive and that works just fine.
]
]Things I noticed:
]- NIC doesn't even show up in lspci

I attempted to fix the missing NIC problem a while back. It is due to
improper PCIe configuration. While the fix worked, there is some evidence it
is responsible for a new legacy USB boot fail problem.

]- Linux complains about missing info for HD Audio

I am not familiar with this problem. It is likely the interrupt routing is
not reported correctly though.

]- Linux complains about ACPI weirdnesses
]- Serial port shows no messages, but the serial port works under Linux
]just fine

The serial port logging is turned off because I was using that image for
fast boot testing. Boot from hardware reset to DOS prompt using an SSD drive
takes 600 or 700 ms as I remember. You could use the patch to recreate the
source code and then enable logging.

I believe with this image, the IDE interface is hidden and only the AHCI
interface at device 11h is visible. This was done because Windows boot is
slowed greatly by an IDE interface unless all drive positions are populated.
So be sure to enable AHCI when building SeaBIOS.

]Regards,
]Carl-Daniel

Am 17.08.2011 01:08 schrieb Scott Duplichan:
 Carl-Daniel Hailfinger wrote:

 ]does anyone have a working ASRock E350M1 coreboot image with SeaBIOS?
 ]I hope to demo that board this weekend at the FrOSCon conference.

 Here is one from LinuxTag:
 http://notabs.org/coreboot/peter/asrock-e350m1-003
 Probably NIC doesn't work, but I think this one does work with USB boot.
   

-- 
http://www.hailfinger.org/


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

Re: [coreboot] [RFC] Universal panic-room serial console, for x86 BIOS bootblock

[Scott Duplichan]

Pete Batard wrote:

]Also, if it's not too much to ask and if the code works without 
]FORCE_PANIC, I wouldn't mind finding out where it breaks if not using 
]the 48 MHz init (using forced base/type/ldn).
]
]I have now committed your patch to svn. Will still need to figure out 
]what the best approach might be with regards to 48 MHz SIO init.

Hello Pete,

I do not have that board setup at the moment so I cannot try it without
FORCE_PANIC. It seems like a baud rate change could substitute for the LPC
clock frequency programming, but so far that does not work as expected.

I have an AMD SB900 board with Nuvoton NCT6776F. To make the serial port
work on this board, two pieces of non-generic code are needed.

1) SIO com1 pins default to GPIO and must switched to serial port use:
// logical device 2 (UART A) defaults to base 3f8, irq 4, enabled
// all that is needed for early serial is to switch some dual function
// pins from gpio use (default) to serial port use. Clearing cr2a bit 7
// does this.
u8 reg8;
pnp_enter_ext_func_mode(dev);
reg8 = pnp_read_config(dev, 0x2a);
reg8 = ~(1  7);
pnp_write_config(dev, 0x2a, reg8);
pnp_exit_ext_func_mode(dev);

2) LPC clock frequency programming and enable:
static void sb900_clocks(void)
{
  u8 reg8;
  u32 reg32;
  volatile u32 *acpi_mmio28 = (void *) (0xFED8 + 0xE00 + 0x28);
  volatile u32 *acpi_mmio40 = (void *) (0xFED8 + 0xE00 + 0x40);

  // Program AcpiMmioEn to enable MMIO access to ClkDrvSth2, MiscClkCntrl
registers
  outb(0x24, 0xCD6);
  reg8 = inb(0xCD7);
  reg8 |= 1;
  reg8 = ~(1  1);
  outb(reg8, 0xCD7);

  // Program ClkDrvSth2 OSCOUT1_CLK_sel for 48 MHz (default is 14 MHz)
  reg32 = *acpi_mmio28;
  reg32 = ~(7  16);
  reg32 |= 2  16;
  *acpi_mmio28 = reg32;

  // Program MiscClkCntrl OSCOUT1_Clk_OutputEn to zero to enable LPC clock
  reg32 = *acpi_mmio40;
  reg32 = ~(1  2);  // Auxiliary Clock1, OSCOUT1 clock output enable
  *acpi_mmio40 = reg32;
}

Thanks,
Scott


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

Re: [coreboot] [RFC] Universal panic-room serial console, for x86 BIOS bootblock

[Scott Duplichan]

Pete Batard wrote:


]Hi Scott,
]
]With my apologies for the delay, I have just pushed an updated version 
]of ubrx to svn. It includes SB8x0 48 MHz Clk1 init, the ability to 
]provide of SIO base, type and UART LDN, as well as additional DIAG codes 
]to help with the troubleshooting.
]
]If you want to give it a try again, you can fetch it from:
]   svn checkout http://akeo.googlecode.com/svn/ubrx ubrx
]or just update if you already checked out.

Hello Pete,

Thanks for the clock code. It works on asrock e350m1 with the attached
patch.

Thanks,
Scott



asrock-e350m1.patch
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] Universal panic-room serial console, for x86 BIOS bootblock

[Scott Duplichan]

Pete Batard wrote:

]...
]Right now, I am especially interested in tests being conducted on AMD 
]hardware to confirm that the AMD LCP/SouthBridge init works. Again, you 
]should be able to test UBRX even if your platform is not supported by 
]coreboot, provided of course that you can reflash your BIOS through 
]external means afterwards (SPI, parallel programmer, etc.).

Hello Pete,

This is an important subject because recovery is one of the few major
features of a commercial BIOS that coreboot+SeaBIOS lacks. I tried the
sample on ASRock E350M1 and it did not work. One reason is needed LPC
clock initialization (http://permalink.gmane.org/gmane.linux.bios/67229).
Another problem is the one mentioned in the release notes about cases
where the serial port pins default to gpio use and must be configured
for serial port use. I believe this will be the situation with Nuvoton
NCT6776F.

 I spent a few minutes debugging with AMD simnow but was unable to get
it to work there. Maybe some additional port 80 codes that mark 
algorithm milestones would simplify debug.

Thanks,
Scott


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

[coreboot] [PATCH] move AMD SB800 early clock setup code to common file

[Scott Duplichan]

The attached patch moves the AMD SB800 early clock setup code that is
needed for early serial port operation from mainboard/romstage.c to
sb800/bootblock.c. This prevents code duplication and simplifies porting.

Signed-off-by: Scott Duplichan sc...@notabs.org



sb800-bblk.patch
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ASRock e350m1 problems

[Scott Duplichan]

Tadas Slotkus wrote:


] Just to completely rule out the bad SPD idea, can you please dump the
] SPD content when you boot with the production BIOS? i2cdump output
] (ASCII) or raw output from sysfs would be great. Then we can plug it
] into bc and confirm that the checksum is correct. This would also be a
] good way to confirm that the SPD addresses are correct in Coreboot,
] and rule out the possibility that ASRock changed SPD addressing
] between board revisions...
]
]Attaching /sys/bus/i2c/drivers/eeprom/0-0050/eeprom as hex file
]+ i2cdump output

Hello Tadas,

Thanks for the data. I think DIMM SPD check bytes are OK. This SPD has
bit zero of byte zero set, which means the crc covers the first 117 bytes
instead of the first 126 bytes. The old simnow I have seems to not handle
this case.

The original log file you sent also suggests no SPD check byte problem.
A check byte fail creates a error record like this:

EventLog:  EventClass = 5, EventInfo = 4011200.
  Param1 = 0, Param2 = 0.
  Param3 = 0, Param4 = 0.
In addition, your experiment with disabling the check byte confirmation 
did not let it boot.

It seems like it might not be able to read SPD at all. It is possible
your DIMM has SMBus signaling difficulty when run at 400 KHz. You could
try running the SMBus at the default frequency (93750 KHz) by removing
the last statement in function setupFch in file dimmSpd.c:

static void setupFch (int ioBase)
   {
   writePmReg (0x2D, ioBase  8);
   writePmReg (0x2C, ioBase | 1);
   writePmReg (0x29, 0x80);
   writePmReg (0x28, 0x61);
   __outbyte (ioBase + 0x0E, 6600 / 40 / 4); // set SMBus clock to
400 KHz
   }

If that doesn't solve the problem, I would add some code to log each SPD
byte as it is read.

Thanks,
Scott



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

Re: [coreboot] ASRock e350m1 problems

[Scott Duplichan]

Tadas Slotkus wrote:


]Hi,
]
]just compiled coreboot for e350m1, flashed original flashchip and got
]this (log attached) everytime I power on or reset my system. Any hints?

Hello Tadas,

AMD.h shows EventClass = 2 corresponds to AGESA_BOUNDS_CHK, a warning
that does not prevent booting. This is related to memory allocation, as
Frank pointed out.

Your log file stops with:
EventLog:  EventClass = 7, EventInfo = 4011c00.

EventClass = 7 is an unrecoverable error, according to amd.h. Searching
the source code for 4011c00 finds:
#define MEM_ERROR_NO_DIMM_FOUND_ON_SYSTEM 0x04011C00 /// No DIMMs have been
found

I assume you have DIMMs installed, and the production BIOS confirms they
are good. Though I believe the SPD addressing is correct for both slots,
testing both single DIMM configurations is worthwhile.

If the DIMMs work with the production BIOS but not with your BIOS, it is 
possible that you are using low cost modules that do not have a valid 
SPD checksum. The coreboot project is configured to validate the SPD
checksum, while the Asrock production BIOS is configured to ignore the
SPD checksum. To test your coreboot using the DIMM SPD checksum ignore
option, change BLDCFG_IGNORE_SPD_CHECKSUM in buildopts.c and try it that
way.

Thanks,
Scott


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

Re: [coreboot] [RFC] use of SMM with SSE/MMX...

[Scott Duplichan]

Stefan Reinauer wrote:

]On 7/2/11 2:08 PM, Rudolf Marek wrote:
] Hi,
]
] Yes even 486 would be good fit! (It has more closer aligns etc). As 
] Stefan mentioned, some CPU might not have SSE enabled failing to 
] execute coreboot. Maybe this is a bit broader problem.
]
] Thanks
] Rudolf
]
]Note that this problem does not happen with the reference toolchain that 
]is i386-elf.

The asrock e350m1 project ends up with some mmx and xmm register usage,
at least as I build it. Some is forced in by the memory initialization
code. Examples are the asm code in function _mm_stream_si128_fs2() and
in file cache_as_ram.inc. In other cases, it appears the compiler
chooses these registers on its own. For the AMD reference code, this is
not surprising due to the use of compiler flags -march=k8-sse3 and
-mtune=k8-sse3. However, there are cases in common coreboot code where
xmm register accesses are generated, such as in coreboot_table.c.

]I agree, we should add CFLAGS to not compile coreboot or at least the 
]SMM handler with MMX/SSE/... instructions.
]There is no big gain in doing so anyways.

If the smm code is stand-alone and does not call library functions, then
using separate compile flags for it should be easy.

]Stefan



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

Re: [coreboot] looking for coreboot snapshots

[Scott Duplichan]

Patrick Georgi wrote:

]Am Donnerstag, 23. Juni 2011 03:20:05, Cristian Măgherușan-Stanciu 
]schrieb:
] SetEnvIf Request_URI \.gz$ no-gzip
]I had to disable it unconditionally for all of gitweb (REQUEST_URI 
]matches the request url without the query string), but it looks okay 
]for me now.
]
]Thanks,
]Patrick

Hello Patrick,

7-zip is happy now. Thanks for making the change, and thanks to Cristi and 
Thomas for figuring out details.

Thanks,
Scott




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

Re: [coreboot] looking for coreboot snapshots

[Scott Duplichan]

Stefan Tauner wrote:

] Hello,
] 
] Is there a way to download an archived snapshot of recent coreboot source
] code?
]
]gitweb can create snapshots on the fly.
]i am not sure if the gitweb integration is completed so YMMV.
]http://review.coreboot.org/gitweb?p=coreboot.git;a=summary

This is working well, but the filename confuses 7-zip. For example,
coreboot-3352b29.tar.gz would be more accurately named
coreboot-3352b29.tar.gz.gz I believe. Does anyone know how to update the
filename, or better yet remove the redundant gzip pass?

Thanks,
Scott


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

Re: [coreboot] [PATCH] asrock e350m1: configure sb800 gpp ports to support onboard pcie nic

[Scott Duplichan]

Marc Jones wrote:

]Hi Scott,
]
]On Fri, Jun 17, 2011 at 10:26 PM, Scott Duplichan sc...@notabs.org wrote:
] The attached patch allows the asrock e350m1 onboard nic to work.
] 1) Update the asrock e350m1 devicetree.cb to match the hardware.
] 2) Change the way the sb800 cimx wrapper code works. The original
] cimx code calls sb800 cimx function sbBeforePciInit() once. When
] ported to coreboot, the gpp component of this function was called
] once for each gpp port, as the gpp port's enable/disable state
] became known. A 05/15/2011 change makes the early gpp code run
] only once, triggered by processing the 4th gpp port. This method
] is not general enough because the 4th gpp port is not enabled on
] all boards. With the current change, the early gpp code runs when
] the first gpp port is processed. If any gpp ports are enabled, the
] first must be enabled. Tested with Win7 and linux on asrock e350m1.
] This change will also affect amd inagua, and has not been tested
] on that board.
]
] Signed-off-by: Scott Duplichan sc...@notabs.org
]
]-  sb_config-PORTCONFIG[0].PortCfg.PortPresent = dev-enabled;
]-  return;
]-  case (0x15  3) | 1: /* 0:15:1 PCIe PortB */
]-  sb_config-PORTCONFIG[1].PortCfg.PortPresent = dev-enabled;
]-  return;
]-  case (0x15  3) | 2: /* 0:15:2 PCIe PortC */
]-  sb_config-PORTCONFIG[2].PortCfg.PortPresent = dev-enabled;
]-  return;
]-  case (0x15  3) | 3: /* 0:15:3 PCIe PortD */
]-  sb_config-PORTCONFIG[3].PortCfg.PortPresent = dev-enabled;
]+  {
]+  device_t device;
]+  for (device = dev; device; device = device-next) {
]+  if (dev-path.type != DEVICE_PATH_PCI) continue;
]+  if ((device-path.pci.devfn  ~7) !=
PCI_DEVFN(0x15,0)) ]break;
]+  sb_config-PORTCONFIG[device-path.pci.devfn 
]3].PortCfg.PortPresent = device-enabled;
]+  }
]
]The allocator is going to loop through and call this function for each
]device in the devicetree.cb. Is there a reason to change this to a
]loop here? It looks like the real fix is moving the SB_BEFORE_PCI_INIT
]call to the last device, and to not run for each device. Did I miss
]something more subtle in this patch?
]
]Marc

Hello Marc,

I wanted to call the standard cimx entry point only once, the way it is done
in the reference BIOS. This is difficult to do with coreboot, because all
the portPresent values need to be known before making the call. All of the
dev-enable values are not available in parallel from coreboot. The previous
code captured the dev-enable values for functions 0, 1, and 2 in the local
sb_config struct, then returned. When function 3 was processed all 4 values
were ready. I think that is similar to what you suggest. The difference is
that the prevoius code called only the sbPcieGppEarlyInit part of
SB_BEFORE_PCI_INIT.

I think your suggestion works for boards that use the sb800 option for 4 x1
ports, as asrock e350m1 does. But what about a board that uses one of the
other sb800 pcie options such as single x4 port? My concern was that
functions 1, 2, and 3 might not even be visible. Even if they are visible,
the person writing devicetree might not choose to include them since they
are not present in a booted system. Because function 0 is visible in all
cases, I thought that is the best place to trigger the cimx call. Because
function 0 is processed first, getting the dev-enable values is not so
easy. The new code scans the devicetree.cb nodes following device 0x15
function 0. Scanning stops on the first pci node not for device 0x15, so
the loop will run a maximum of 3 times. That lets the code gather the needed
dev-enable values.

Thanks,
Scott


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

Re: [coreboot] Wiki update/wiki access request: E350M1 sound supportverified

[Scott Duplichan]

Marshall Buschman wrote:

]Hello:
]
]The built-in sound on the ASRock E350M1 works properly.
]Could someone please update the wiki page accordingly?
]
]Also, a wiki account would be nice if possible.

Hello Marshall,

I did the wiki update.

http://www.coreboot.org/index.php?title=ASRock_E350M1action=historysubmitd
iff=10828oldid=10826

Thanks,
Scott


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

Re: [coreboot] ASRock E350M1: Boot delay with debug enabled, system RAM reported incorrectly in Linux

[Scott Duplichan]

Marshall Buschman wrote:

]Hello:
]
]With Scott's work on PCIe support for the E350M1, the NIC and USB3 are 
]now working -- Thanks Scott!

Thanks for testing it on both the boards. Good to hear it works.

]The remaining problems that I know of are:
]
]1) Enabling coreboot serial debugging slows system boot dramatically: 5min+
]Someone mentioned in IRC that this is because we are attempting to write 
]to the serial device before it is ready, which causes some kind of 
]timeout/backoff/retry sequence. How can I help with this?

That is weird. The log file you sent is 38819 bytes. I would expect the
boot time penalty to be not much more than the I/O time of 38819 bytes /
(11520 bytes/second) = 3.37 seconds. I did a test with loglevel 8. It logged
45745 bytes and the boot time from cold reset to DOS prompt was 5.56
seconds. When I watch the serial output, it spews text nearly continuously.
There is no hardware or software handshaking for the writes, so nothing
should slow it down.  

]2) System RAM is reported incorrectly. In linux, free -m reports 480mb 
]of total RAM -- the full total is 4gb.

I see, I had tested only a small memory configuration so far. It looks
like any size greater than 4GB will fail. Try the attached patch.

Thanks,
Scott



4gbfix-001.patch
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ASRock E350M1: Boot delay with debug enabled, system RAM reported incorrectly in Linux

[Scott Duplichan]

Marshall Buschman wrote:

]Nevermind, it works - Apparently there are disadvantages to doing things 
]that require thought in the very early hours of the morning. :|
]Thanks!

Hello Marshall,

Thanks for the update. I tested Win7 with this change and 4GB and found
it is not happy. Win7 makes a BSOD. Windbg with checked build reports:

-
84126053: Store(TOM1=0x,MM1B)=0x
8412605c: ShiftLeft(0x1000,0x4,Local0)=0x1
84126065:
Subtract(Local0=0x1,TOM1=0x,Local0)=0x5556
8412606c: Store(Local0=0x5556,MM1L)=0x5556
84126072: Return(CRES=Buffer(0x42){

0x47,0x01,0xf8,0x0c,0xf8,0x0c,0x01,0x08,0x88,0x0d,0x00,0x01,0x0c,0x03

0x00,0x00,0x00,0x00,0xf7,0x0c,0x00,0x00,0xf8,0x0c,0x88,0x0d,0x00,0x01

0x0c,0x03,0x00,0x00,0x00,0x0d,0xff,0xff,0x00,0x00,0x00,0xf3,0x86,0x09

0x00,0x00,0x00,0x00,0x0a,0x00,0x00,0x00,0x02,0x00,0x86,0x09,0x00,0x00
0xaa,0xaa,0xaa,0xaa,0x56,0x55,0x55,0x55,0x79,0x00})
84126077: }ACPI: E820 Entry 3 (type 4503599627370497)
(c7fee000-7) overlaps
ACPI: PCI  Entry -1431655766 Min: Max:5556
Length:1 Align:0
ACPI:
ACPI: FATAL BIOS ERROR - Need new BIOS to fix PCI problems
-

Unfortunately the Win7 code that prints e820 message has an error where
the argument and format string do not match. One is long and the other
is long long. That is why the numbers are garbage. The real problem is
that the asl code for \_SB.PCI0._CRS is using uninitialized variable
TOM1. The default value of  from from line 267 of
family14/ssdt.asl is being used.

Somehow the OS does need to know where the PCI hole can safely start.
It can't start immediately after the end of low ram because of uma.
\_SB.PCI0._CRS is one way to pass this information. This method requires
passing data from coreboot to asl, which is a pain. I wonder if just
reserving the uma range in the e820 map is sufficient? I will try to
do some experiments tonight.

If you can send me a binary or otherwise let me recreate the serial
logging problem, I will take a look.

Thanks,
Scott




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

Re: [coreboot] ASRock E350M1: Boot delay with debug enabled, system RAM reported incorrectly in Linux

[Scott Duplichan]

Peter Stuge wrote:


] If you can send me a binary or otherwise let me recreate the serial
] logging problem, I will take a look.
]
]http://stuge.se/stuge_e350m1_47b3fb_4mb.bin

Hello Peter,

Thanks. This shows the problem on my board. I have not been in
the habit of enabling kconfig option console_post, and that is why
I did not see the problem at first. I noticed the post code logging
in Marshall's log file, but forgot to try adding that to mine. The 
problem is caused when code logs to the serial port before it is
initialized. This happens with the first two post calls to post_code().
Apparently the baud rate defaults to some really slow value, causing
the those 24 characters to take a long time to transmit. The attached
patch is one way to fix the problem. It looks like this problem 
potentially affects several other coreboot projects.

Thanks,
Scott


slowserialfix.patch
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot support: difference between ASRock E350M1 and ASRock E350M1/USB3

[Scott Duplichan]

Marshall Buschman wrote:

]I own both boards - both do work, BUT there are still bugs:
]USB3 and built-in NIC do not work on either by default.
]Memory is only reported as roughly 512mb at this point.
]
]You're welcome to help. :)

Hello Marshall,

Thanks for reporting these problems. Incorrect memory size
should be easy to fix. Can you send an e820 listing for a 
problem memory configuration?

I started looking at the NIC problem. The first thing wrong
is that its bridge is not enabled in devicetree.cb. The bridge
is at device 0x15, function 1. Also, the correct pcie lane option
needs to be selected with: register gpp_configuration = 4.
Once that is fixed, it doesn't work because its sb800_enable()
code is not running early enough. This a message such as:
sb800_enable() PCI: Static device PCI: 00:15.1 not found,
disabling it. As a result, no bus number is assigned. I manually
assigned a bus number and was able to see the NIC, so the PCIe
link is trained and working. I will try to complete the debug
during the next couple of days.

Thanks,
Scott


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

[coreboot] [PATCH] asrock e350m1: configure sb800 gpp ports to support onboard pcie nic

[Scott Duplichan]

The attached patch allows the asrock e350m1 onboard nic to work.
1) Update the asrock e350m1 devicetree.cb to match the hardware.
2) Change the way the sb800 cimx wrapper code works. The original
cimx code calls sb800 cimx function sbBeforePciInit() once. When
ported to coreboot, the gpp component of this function was called
once for each gpp port, as the gpp port's enable/disable state
became known. A 05/15/2011 change makes the early gpp code run 
only once, triggered by processing the 4th gpp port. This method
is not general enough because the 4th gpp port is not enabled on
all boards. With the current change, the early gpp code runs when
the first gpp port is processed. If any gpp ports are enabled, the
first must be enabled. Tested with Win7 and linux on asrock e350m1.
This change will also affect amd inagua, and has not been tested
on that board.

Signed-off-by: Scott Duplichan sc...@notabs.org



nic-001.patch
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] looking for coreboot snapshots

[Scott Duplichan]

Stefan Tauner wrote:

] Hello,
] 
] Is there a way to download an archived snapshot of recent coreboot source
] code?
]
]gitweb can create snapshots on the fly.
]i am not sure if the gitweb integration is completed so YMMV.
]http://review.coreboot.org/gitweb?p=coreboot.git;a=summary

Hello Stefan,

Thanks, this is perfect.

Thanks,
Scott



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

[coreboot] looking for coreboot snapshots

[Scott Duplichan]

Hello,

Is there a way to download an archived snapshot of recent coreboot source
code?

Thanks,
Scott


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

Re: [coreboot] Builduing coreboot for Gigabyte GA-890GPA-UD3H always fails with this message (using Fedora 15 x86_64 and the Option SeaBios as loader)

[Scott Duplichan]

Omar-Mohammad Ataya wrote:

]HOSTCC util/romcc/romcc (this may take a while)
]/home/omar/coreboot/util/romcc/romcc.c: In Funktion »raw_next_token«:
]/home/omar/coreboot/util/romcc/romcc.c:4083:7: Warnung: Variable »wchar«
]gesetzt, aber nicht verwendet [-Wunused-but-set-variable]

Hello Omar,

From the error messages, it looks like you are using gcc 4.6.0, and
possibly the wrong binutils. The current coreboot code is most often
compiled using gcc 4.5.2. The best way to ensure no build tool
related problems is build a cross compile tool set using
coreboot/util/crossgcc/buildgcc.

Thanks,
Scott


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

Re: [coreboot] [PATCH] ASRock E350M1 update

[Scott Duplichan]

Marshall Buschman wrote:

]Marc:
]
]After taking a quick look through the git log, it looks like we've 
]probably applied all of the patches you mentioned to me besides these:
]
]Move SB800 clock init earlier to fix problem where initial serial port 
]output is garbled.
]Skip memory clear for boot time reduction. Memory clear is not required 
]for non-ECC boards.
]
]I'd confirm manually, but I don't know where to find the actual patches.
]
]Thanks!
]-Marshall

Hello Marshall and Marc,

Thanks for committing these patches. The two mentioned above are
items 17-early-serial-fix.patch and skip-memclr.patch from 
this set:
http://permalink.gmane.org/gmane.linux.bios/66598

Thanks,
Scott


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

Re: [coreboot] [PATCH 01/16] Port persimmon r6572 to e350m1:I/O APIC ID

[Scott Duplichan]

Peter Stuge wrote:

]All are either
]
]Acked-by: Peter Stuge pe...@stuge.se
]
]or
]
]Acked-by: Marshall Buschman mbusch...@lucidmachines.com
]
]per IRC. Committed as r6621 to r6636.
]
]Many thanks to Scott for these fixes to amd/persimmon, and to
]Marshall for working on getting them over to asrock/e350m1, which
]should now be functionally equivalent to amd/persimmon, as has also
]been tested by Marshall.
]
]
]//Peter

Thank you Peter and Marshall. I will keep my e350m1 board around
for future testing and experiments.

Thanks,
Scott


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

Re: [coreboot] [commit] r6625 - trunk/src/mainboard/asrock/e350m1

[Scott Duplichan]

Stefan Reinauer wrote:

] +  // early enable of SPI 33 MHz fast mode read
] +  if (boot_cpu())
] +{
] +volatile u32 *spiBase = (void *) 0xa000;
] +u32 save;
] +__outdword (0xcf8, 0x8000a3a0);
]
]what's the reason to not use pci_read_config32() here?

Hello Stefan,

It was due to a quick copy/paste from some old code.
I will send a patch to update it.

Thanks,
Scott


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

[coreboot] [PATCH] AMD F14 persimmon and e350m1: use standard pci config functions

[Scott Duplichan]

AMD F14 persimmon and e350m1: replace inline cf8/cfc pci config
access with pci_read_config and pci_write_config function calls.

Signed-off-by: Scott Duplichan sc...@notabs.org

Index: src/mainboard/amd/persimmon/romstage.c
===
--- src/mainboard/amd/persimmon/romstage.c  (revision 6637)
+++ src/mainboard/amd/persimmon/romstage.c  (working copy)
@@ -73,21 +73,20 @@
   // early enable of PrefetchEnSPIFromHost
   if (boot_cpu())
 {
-__outdword (0xcf8, 0x8000a3b8);
-__outdword (0xcfc, __indword (0xcfc) | 1  24);
+device_t dev = PCI_DEV(0, 0x14, 3);
+pci_write_config8(dev, 0xbb, pci_read_config8(dev, 0xbb) | 1);
 }
 
   // early enable of SPI 33 MHz fast mode read
   if (boot_cpu())
 {
 volatile u32 *spiBase = (void *) 0xa000;
-u32 save;
-__outdword (0xcf8, 0x8000a3a0);
-save = __indword (0xcfc);
-__outdword (0xcfc, (u32) spiBase | 2); // set temp MMIO base
+device_t dev = PCI_DEV(0, 0x14, 3);
+u32 save = pci_read_config32(dev, 0xa0);
+pci_write_config32(dev, 0xa0, (u32)spiBase | 2); // set temp MMIO base
 spiBase [3] = (spiBase [3]  ~(3  14)) | (1  14);
 spiBase [0] |= 1  18; // fast read enable
-__outdword (0xcfc, save); // clear temp base
+pci_write_config32(dev, 0xa0, save);
 }
 
   if (!cpu_init_detectedx  boot_cpu()) {
Index: src/mainboard/asrock/e350m1/romstage.c
===
--- src/mainboard/asrock/e350m1/romstage.c  (revision 6637)
+++ src/mainboard/asrock/e350m1/romstage.c  (working copy)
@@ -58,21 +58,20 @@
   // early enable of PrefetchEnSPIFromHost
   if (boot_cpu())
 {
-__outdword (0xcf8, 0x8000a3b8);
-__outdword (0xcfc, __indword (0xcfc) | 1  24);
+device_t dev = PCI_DEV(0, 0x14, 3);
+pci_write_config8(dev, 0xbb, pci_read_config8(dev, 0xbb) | 1);
 }
 
   // early enable of SPI 33 MHz fast mode read
   if (boot_cpu())
 {
 volatile u32 *spiBase = (void *) 0xa000;
-u32 save;
-__outdword (0xcf8, 0x8000a3a0);
-save = __indword (0xcfc);
-__outdword (0xcfc, (u32) spiBase | 2); // set temp MMIO base
+device_t dev = PCI_DEV(0, 0x14, 3);
+u32 save = pci_read_config32(dev, 0xa0);
+pci_write_config32(dev, 0xa0, (u32)spiBase | 2); // set temp MMIO base
 spiBase [3] = (spiBase [3]  ~(3  14)) | (1  14);
 spiBase [0] |= 1  18; // fast read enable
-__outdword (0xcfc, save); // clear temp base
+pci_write_config32(dev, 0xa0, save);
 }
 
   if (!cpu_init_detectedx  boot_cpu()) {


pci-config-access.patch
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [commit] r6627 - trunk/src/mainboard/asrock/e350m1

[Scott Duplichan]

Stefan Reinauer wrote:

]Also, enabling Prefetch and 33MHz fast read mode should possibly go in the
]southbridge's bootblock.c so the first cbfs scan does not run with the
]slow settings.

Hello Stefan,

You are probably right. In fact these settings are applied fairly early
even without the patch:
tracker.coreboot.org/trac/coreboot/browser/trunk/src/vendorcode/amd/cimx/
sb800/SBPOR.c#L67 (prefetch)
tracker.coreboot.org/trac/coreboot/browser/trunk/src/vendorcode/amd/cimx/
sb800/SBPOR.c#L249 (spi speed)

The patch applies the settings even earlier for boot time reduction. The
gain is small:

---e350m1 DOS AHCI SSD boot time in ms---
early prefetch   offon offon 
early 33 mhz offoffon on 
 ------------
 686682736679

Together the changes save 7 ms. The question is, where do we draw the line
on boot time reduction? I worked in a group a while back where a manager
said, every millisecond counts. This was due to a desire to make a
customer's board boot more quickly than a board from a competitor. Certainly
no user can notice a boot time difference of a few ms. The difference is
easy to measure though, and in some cases a few ms is enough to affect who
calls their board fastest. On the other hand, coreboot+seabios is already
several thousand ms faster than UEFI, so maybe saving 7 ms is not worth the
somewhat out of place code.

Thanks,
Scott





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

Re: [coreboot] [commit] r6626 - trunk/src/mainboard/asrock/e350m1

[Scott Duplichan]

Stefan Reinauer wrote:

] +  // all cores: set pstate 0 (1600 MHz) early to save a few ms of boot
]time
] + __writemsr (0xc0010062, 0);
] +
]
]why not use writemsr instead of __writemsr?

Hello Stefan,

The wrmsr function is certainly OK. I am in the habit us using the
Intel/MS functions because they are built into the Microsoft compiler
and therefore portable between all UEFI vendor code bases and any
other code that uses the MS complier. But portability with UEFI is
not the reason I still sometimes use these function types. Truthfully,
the coreboot wrmsr function seems awkward to me. With the Intel/MS
__writemsr function, any 64-bit value can be written with a single
statement. Coreboot code using wrmsr is often taking 4 statements to
do the same thing. While there is probably little difference in
generated code, using the coreboot wrmsr function does require more
source code typing. I also find it less readable. For example,

// set bit 46 of NB_CFG_MSR using wrmsr function:
msr_t msr;
msr = rdmsr(NB_CFG_MSR);
msr.hi |= (1  (46 - 32));
wrmsr(NB_CFG_MSR, msr);

// Making msr_t a union that adds a uint64_t would allow:
msr_t msr;
msr = rdmsr(NB_CFG_MSR);
msr.all |= 1  46;
wrmsr(NB_CFG_MSR, msr);

// The Intel/MS style uint64_t prototypes allow:
__writemsr (__readmsr (NB_CFG_MSR) | 1  46);

A question I have wanted to ask for a while is why coreboot
doesn't use 64 bit integers in situations like this?

Thanks,
Scott


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

Re: [coreboot] Coreboot issues with ASRock E350m1

[Scott Duplichan]

Marshall Buschman wrote:

]Hello:
]
]I was instructed to send mail to you by Carebear from #coreboot.
]I have some issues to report based on the Golden Image I received from 
]him, which was created for the ASRock E350M1.
]
]After booting, my Linux kernel panics like this:
]http://www.lucidmachines.com/coreboot/panic-lm-patched-2.6.39.txt


]CareBear told me to enable ACPI (and try it with the vanilla kernel), 
]and it no longer panics, but he did note the following quirks:
]
][ 0.137098] Extended Config Space enabled on 0 nodes

The recent patch set may resolve the above problem:
http://permalink.gmane.org/gmane.linux.bios/66598

][ 0.178984] ACPI: (supports S0 S5)

I think this is expected because more work is needed in order to
support additional power states.

][ 0.289970] Unable to assume _OSC PCIe control. Disabling ASPM
][ 0.310267] ACPI: PCI Interrupt Link INTA (IRQs 3 4 5 7 10 11 12 15) *0, 
]disabled.
]This last error is repeated for INTB to INTH

Probably work is needed on the interrupt routing. I did not check it.

]Other issues:
]* Network card is not recognized at all (works fine with stock BIOS)

We are probably missing some PCIe board support.

]* Total system RAM is reported as 480 Megabytes, actual system ram is 
]4096mbytes.

ASRock E350M1 Testing to date has used only 2GB, so it is possible
memory above 4GB will not be reported properly. On the other hand,
all usable memory below 4GB should be reported. I think the patch
set will at least get the memory below 4GB reporting properly.

Thanks,
Scott


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

Re: [coreboot] Build coreboot with grub/grub2 payload

[Scott Duplichan]

C.L. wrote:

]Hello, all
]I found that grub could be used as a coreboot payload at coreboot
]website, but no more detail messages.
]Can anyone give me some advices?
]I alse found there were great resource at http://grub.enbug.org, but I
]can not open it, the other people around me
]can not open it either, maybe, its address had changed. Can anyone open it?
]
]BRs,
]
]C.L.


Hello C.L.,

Here is a partial work around for accessing http://grub.enbug.org:
http://web.archive.org/web/20090215055224/http://grub.enbug.org/

Thanks,
Scott


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

Re: [coreboot] [commit] r6608 - trunk/src/southbridge/nvidia/ck804

[Scott Duplichan]

Stefan Reinauer wrote:

] +  .align 4
] Shouldn't this be .align 16 then?
] The as(1) info page says it's in bits on x86.
]
]  Jonathan Kollasch
]
]Oh does it? This used to be only the case for i386 + a.out. It seems at 
]least the coreboot reference compiler assumes those are bytes.

It's easy enough to check. I changed the value from 4 to 5:

romstrap.inc:24: Error: alignment not a power of 2

Thanks,
Scott




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

Re: [coreboot] [patch] ck804 mmconf

[Scott Duplichan]

Stefan Reinauer wrote:

] Why would the resource allocator have to worry about posted vs
] non-posted PCI transactions?
] How else will the northbridge be told to make the region non-posted?
]Why would it have to? Not sure I understand your concern. Your patch 
]does not address that issue at all.

This subject came up recently:
http://www.coreboot.org/pipermail/coreboot/2010-October/061288.html

AMD processors have 8 mmio base/limit register pairs. Each pair
defines an address range as posted mmio or as non-posted mmio.
Somehow posted and non-posted ranges have to be allocated so
that they can be consolidated into a total of 8 or fewer ranges.
Then the mmio base/limit registers can be programmed to cover
the ranges.

Thanks,
ScottD


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

Re: [coreboot] [commit] r6584 - trunk/src/mainboard/amd/persimmon

[Scott Duplichan]

Mark Marshall wrote:

] +__outdword (0xcf8, 0x8000a3b8);
] +__outdword (0xcfc, __indword (0xcfc) | 0  24);
]
]Isn't this a no-op (or'ing 0 into the read value and writing it back)?
]
]MM


Hello Mark,

Thanks for point this out. You are certainly correct. This
was left over from a test of its effectiveness and not restored.
I repeated the test with the corrected code and it cuts boot
time by 4 ms. Revision 6601 corrects it.

Still needed is a change to replace these in line code sequences
with calls to existing PCI config functions.

Thanks,
Scott


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

Re: [coreboot] [PATCH] workaround for An unexpected error (805262864) occurred at line 1768 of d:\xpclient\base\boot\setup\arcdisp.c

[Scott Duplichan]

Marc Jones wrote:

 The attached patch works around a Windows XP or Server 2003 setup
 failure where an error message such as:
 An unexpected error (805262864) occurred at line 1768 of
 d:\xpclient\base\boot\setup\arcdisp.c
 The value 805262864 varies, and is the physical address, in decimal,
 of one of the ACPI tables.

 Tested on Persimmon. Others abuild tested only.
 Signed-off-by: Scott Duplichan sc...@notabs.org


]It looks like src/mainboard/amd/mahogany/acpi_tables.c has a double
]paste issue. Fix that and it looks good.
]
]Acked-by: Marc Jones marcj...@gmail.com
]
]
]Marc

Hello Marc,

Thanks for finding the double paste problem in mahogany.
This change is revision 6600.

Thanks,
Scott


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

[coreboot] [PATCH] workaround for An unexpected error (805262864) occurred at line 1768 of d:\xpclient\base\boot\setup\arcdisp.c

[Scott Duplichan]

The attached patch works around a Windows XP or Server 2003 setup
failure where an error message such as:
An unexpected error (805262864) occurred at line 1768 of
d:\xpclient\base\boot\setup\arcdisp.c
The value 805262864 varies, and is the physical address, in decimal,
of one of the ACPI tables.

Tested on Persimmon. Others abuild tested only.
Signed-off-by: Scott Duplichan sc...@notabs.org

Detailed explanation: The error message is displayed when a 1024 dword
page table array used by setupldr runs out of space. This table is used
for mapping various physical addresses, such as those of ACPI tables
(a separate table identity maps the lower 16MB used by setupldr code
and data). Setupldr only looks at ACPI tables (FACP) to determine make
and model of the system. The make and model of the system is needed when
setupldr scans the good/bad bios lists contained in txtsetup.sif. The
good/bad bios lists are used to bypass installation of the ACPI enabled
kernel on certain systems known to have ACPI problems. The code loop
that scans the lists creates a new mapping each time it reads an ACPI
table, and never frees mappings. The code uses FACP OEM ID to determine
the system model. The code sequentially reads tables listed in the RSDT
array until the FACP is found. Each read consumes one page table entry.
If more that 4 tables precede the FACP in the RSDT array, the 1024
entry page table array will run out of space before the good/bad bios
list processing completes. BIOS can work around this Windows XP/Server
2003 limitation by placing the FACP early in the RSDT array.

Thanks,
Scott





xp-workaround.patch
Description: Binary data
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options?

[Scott Duplichan]

Idwer Vollering wtote:


]Have you though of using an USB flash drive, to install Windows from?
]http://www.windowsvalley.com/install-windows-2000-xp-2003-using-usb-]storag
e-device-pen-drive/

Hello Idwer,

Thanks for the suggestion and information. That could be useful in 
situations where no CD drive is available. I think it does not directly
solve the AHCI driver problem though. The Windows XP F6 driver mechanism
seems to be completely hard-coded for floppy drive only (tradition or USB).
For example, BIOS can make a USB flash drive appear as floppy drive A: to
DOS. The Windows XP F6 method is happy with this for the early access
where BIOS calls are used to read drive A:. But later in the setup process,
execution switches to native mode drivers for floppy access, at which time
only a real floppy or a limited number of models of USB floppy will work.
Somehow an AHCI driver has to get loaded in order for Windows XP setup to
find the hard disk. Probably nliteos could be used in combination with
the tool you mention though.

Thanks,
Scott


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

Re: [coreboot] Kconfig vs. devicetree vs. CMOS policy for options?

[Scott Duplichan]

Anders Jenbo wrote:

]You could use http://driverpacks.net/ to incorporate the AHCI driveres 
]on your cd.

Hello Anders,

Thanks for the suggestion. I did find that site the other day. At first
it looked like what I needed. But when I went to choose a download, I
I could find x64 packs only for Vista/7. I use the x64 edition of XP
or Server 2003.

Thanks,
Scott



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

Re: [coreboot] AMD Persimmon update

[Scott Duplichan]

Marc Jones wrote:

]Hi Scott,
]
]I'm acking and committing all except the LTO patch, which should wait
]for the crossgcc changes for gcc4.6. i only made a minor tweak to the
]AHCI patch to add a #define for the PCI DID.

Thanks Marc. I noticed the PCI ID also, how embarrassing! I will test
everything and try to make some of the changes suggested by Peter and
Stefan. After that, I need to do the same for asrock e350m1.

Thanks,
Scott


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

Re: [coreboot] [commit] r6584 - trunk/src/mainboard/amd/persimmon

[Scott Duplichan]

Peter Stuge wrote:

] +__outdword (0xcf8, 0x8000a3b8);
] +__outdword (0xcfc, __indword (0xcfc) | 0  24);
] +}
]
]PCI function? And maybe this, as well as the 33MHz setup, is good to
]have in the chipset code, as opposed to duplicated per mainboard?

Hello Peter,

I will try improve this and some of the others, hopefully this week.
Yes, the code above looks odd, so I should at least explain why. This
and the other newly added early settings indeed duplicate settings made
later. The justification is/was 'early as possible' for boot time
reduction. With another change or two, both persimmon and asrock e350m1
boot to DOS time drop to 600 ms.

Maybe a bigger question is why the unusual pci config write coding?
Certainly a function call is just as good (and I will submit a change).
The code is a quick and dirty way to paste in a pci config write and
have it work for amd agesa as well as for all phases of UEFI. I used to
get frustrated over how complicated UEFI makes something as simple as a
write to base pci config space. A single function call? More like a
couple dozen lines of code: Call the OpenProtocol function pointer from
a global structure, passing half a dozen items including the GUID for PCI
protocol. Check for errors then call the write() member of the structure
it returns. Of course integer constants are often passed by address, so
separate allocation is needed for those. Check for and handle any error
returned by the write function, then call another function to close the
protocol. The code sequence above was my silent protest over this ordeal,
and it ended up in coreboot. I/O functions named like __outdword are 
supported by the Microsoft compilers used for UEFI, and can even be used
with no prototype.

Thanks,
Scott



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