coreboot February 2015

coreboot@coreboot.org

45 participants
93 discussions

Re: [coreboot] memtest86 reading 0k memory
by Timothy Pearson 06 Feb '15

06 Feb '15

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 0xa0000, 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! -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

2 5

Plans for upcoming Broadwell Thinkpads
by Stefan Tauner 06 Feb '15

06 Feb '15

I should probably not post about any Thinkpads till I get to test the T410s port... but anyway has anybody considered a port for the incoming Broadwell Thinkpads - especially the T450s? It would definitely be a plus to know that there will be others hacking at it as well before buying ;) -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

1 0

Re: [coreboot] memtest86 reading 0k memory
by Timothy Pearson 05 Feb '15

05 Feb '15

On 02/05/2015 12:59 PM, Aaron Durbin wrote: > On Thu, Feb 5, 2015 at 12:48 PM, Timothy Pearson > <tpearson(a)raptorengineeringinc.com> wrote: >> On 02/05/2015 12:38 PM, Jonathan A. Kollasch wrote: >>> >>> That's a pretty old memtest86+. Also, memtest86+ prefers >>> linuxbios/coreboot memory map to e820. This becomes a problem >>> when SeaBIOS sets up a USB controller to DMA to e820-reserved >>> memory that wasn't reserved by coreboot. >>> >>> Try a modern memtest86+ with the coreboot table probe patched out. >>> >>> Jonathan Kollasch >> >> >> Yep, that was it. Didn't catch the obsolete version number. >> >> I'm trying to figure out the point of memtest86 reading the coreboot tables. >> It doesn't help that the coreboot tables / e820 map are apparently wrong; >> memtest86+ almost immediately started stepping on the lower MMIO regions >> (e.g. 0xb800) rendering the display mostly useless. Interestingly Linux >> doesn't seem to have any problems; I'll need to investigate further. >> > > Your e820 looks fine to me. memtest86 should just be testing the > usable regions. Since b800 isn't in there, the only issue that could > arise is it using that physical address as a mmio bar. However, that'd > be an OS level thing, and I wouldn't expect the memtest86 doing any > such things. It sounds more like it does a merge of some sort with > e820 and its notion of valid memory instead relying on e820 proper. > Thanks for the information. The e820 map is comparable to the one generated from the proprietary BIOS so I agree it is likely correct. That leaves the coreboot tables themselves and/or memtest86's interpretation of them. BTW it looks I am not the only one to have run into this: http://www.coreboot.org/pipermail/coreboot/2010-December/062245.html At this point I'm not sure if the bug is in coreboot, SeaBIOS, or memtest86. -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 http://www.raptorengineeringinc.com

2 1

Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project
by Scott Duplichan 05 Feb '15

05 Feb '15

Yang, York [mailto:york.yang@intel.com] wrote: ]Sent: Wednesday, February 04, 2015 01:22 PM ]To: Patrick Georgi ]Cc: coreboot(a)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.927000000 -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.662000000 -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)(0x100000000), + (EFI_PHYSICAL_ADDRESS)(0x100000000ll), HighMemorySize ); } diff -rupN original/CorebootModulePkg/Include/Coreboot.h modified/CorebootModulePkg/Include/Coreboot.h --- original/CorebootModulePkg/Include/Coreboot.h 2014-06-17 21:15:25.814000000 -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.958000000 -0500 +++ modified/CorebootModulePkg/Include/Library/CbParseLib.h 2015-02-04 15:40:00.544565300 -0600 @@ -63,7 +63,7 @@ CbParseCbMemTable ( **/ RETURN_STATUS CbParseAcpiTable ( - IN VOID** pMemTable, + IN VOID* pMemTable, IN UINT32* pMemTableSize ); diff -rupN original/CorebootModulePkg/Library/CbParseLib/CbParseLib.c modified/CorebootModulePkg/Library/CbParseLib/CbParseLib.c --- original/CorebootModulePkg/Library/CbParseLib/CbParseLib.c 2014-06-24 03:04:34.021000000 -0500 +++ modified/CorebootModulePkg/Library/CbParseLib/CbParseLib.c 2015-02-04 16:32:34.355304700 -0600 @@ -31,16 +31,6 @@ static UINT64 cb_unpack64(struct cbuint6 return (((UINT64) val.hi) << 32) | val.lo; } -static const char *cb_mb_vendor_string(const struct cb_mainboard *cbm) -{ - return (char *)(cbm->strings + cbm->vendor_idx); -} - -static const char *cb_mb_part_string(const struct cb_mainboard *cbm) -{ - return (char *)(cbm->strings + cbm->part_number_idx); -} - VOID * FindCbTag ( IN VOID *Start, @@ -245,11 +235,11 @@ CbParseCbMemTable ( **/ RETURN_STATUS CbParseAcpiTable ( - IN VOID** pMemTable, + IN VOID* pMemTable, IN UINT32* pMemTableSize ) { - return CbParseCbMemTable (SIGNATURE_32 ('I', 'P', 'C', 'A'), pMemTable, pMemTableSize); + return CbParseCbMemTable (SIGNATURE_32 ('I', 'P', 'C', 'A'), (void **)pMemTable, pMemTableSize); } /** diff -rupN original/CorebootModulePkg/SecCore/Ia32/SecEntry.S modified/CorebootModulePkg/SecCore/Ia32/SecEntry.S --- original/CorebootModulePkg/SecCore/Ia32/SecEntry.S 2014-06-17 21:15:26.064000000 -0500 +++ modified/CorebootModulePkg/SecCore/Ia32/SecEntry.S 2015-02-04 16:43:17.249033900 -0600 @@ -46,7 +46,7 @@ ASM_PFX(_ModuleEntryPoint): # # Construct the temporary memory at 0x80000, length 0x10000 # - movl ($BASE_512KB + $SIZE_64KB), %esp + movl $(BASE_512KB + SIZE_64KB), %esp # # Pass BFV into the PEI Core diff -rupN original/CorebootPayloadPkg/CorebootPayloadPkg.fdf modified/CorebootPayloadPkg/CorebootPayloadPkg.fdf --- original/CorebootPayloadPkg/CorebootPayloadPkg.fdf 2014-06-29 21:53:30.992000000 -0500 +++ modified/CorebootPayloadPkg/CorebootPayloadPkg.fdf 2015-02-04 18:13:08.571703300 -0600 @@ -17,15 +17,15 @@ ################################################################################ [FD.UefiPayload] BaseAddress = 0x800000|gUefiCorebootModulePkgTokenSpaceGuid.PcdPayloadFdMemBase -Size = 0x400000|gUefiCorebootModulePkgTokenSpaceGuid.PcdPayloadFdMemSize +Size = 0x402000|gUefiCorebootModulePkgTokenSpaceGuid.PcdPayloadFdMemSize ErasePolarity = 1 BlockSize = 0x1000 -NumBlocks = 0x400 +NumBlocks = 0x402 -0x00000000|0x020000 +0x00000000|0x022000 FV = PEIFV -0x00020000|0x3E0000 +0x00022000|0x3E0000 FV = DXEFV ################################################################################ diff -rupN original/CorebootPayloadPkg/SerialDxe/SerialIo.c modified/CorebootPayloadPkg/SerialDxe/SerialIo.c --- original/CorebootPayloadPkg/SerialDxe/SerialIo.c 2014-06-17 21:15:26.224000000 -0500 +++ modified/CorebootPayloadPkg/SerialDxe/SerialIo.c 2015-02-04 16:59:42.921165200 -0600 @@ -37,18 +37,18 @@ typedef struct { SIMPLE_TEXT_OUT_DEVICE_PATH mDevicePath = { { - { HARDWARE_DEVICE_PATH, HW_VENDOR_DP, sizeof (VENDOR_DEVICE_PATH), 0}, + { HARDWARE_DEVICE_PATH, HW_VENDOR_DP, { sizeof (VENDOR_DEVICE_PATH), 0} }, EFI_SERIAL_IO_PROTOCOL_GUID // Use the drivers GUID }, { - { MESSAGING_DEVICE_PATH, MSG_UART_DP, sizeof (UART_DEVICE_PATH), 0}, + { MESSAGING_DEVICE_PATH, MSG_UART_DP, { sizeof (UART_DEVICE_PATH), 0} }, 0, // Reserved FixedPcdGet64 (PcdUartDefaultBaudRate), // BaudRate FixedPcdGet8 (PcdUartDefaultDataBits), // DataBits FixedPcdGet8 (PcdUartDefaultParity), // Parity (N) FixedPcdGet8 (PcdUartDefaultStopBits) // StopBits }, - { END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE, sizeof (EFI_DEVICE_PATH_PROTOCOL), 0} + { END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE, { sizeof (EFI_DEVICE_PATH_PROTOCOL), 0 } } }; EFI_HANDLE gHandle = NULL; --- build-commands.txt --- build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t DDK3790 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t DDK3790 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t DDK3790 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t DDK3790 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t VS2005x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t VS2005x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t VS2005x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t VS2005x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t VS2008x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t VS2008x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t VS2008x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t VS2008x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t VS2010x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t VS2010x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t VS2010x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t VS2010x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t VS2012x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t VS2012x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t VS2012x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t VS2012x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t VS2013x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t VS2013x86 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t VS2013x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t VS2013x86 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t GCC44 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t GCC44 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t GCC44 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t GCC44 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t GCC45 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t GCC45 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t GCC45 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t GCC45 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t GCC46 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t GCC46 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t GCC46 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t GCC46 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t GCC47 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t GCC47 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t GCC47 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t GCC47 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t GCC48 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t GCC48 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t GCC48 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t GCC48 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b DEBUG -t GCC49 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgIA32.dsc -b RELEASE -t GCC49 -n 0 -a IA32 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b DEBUG -t GCC49 -n 0 -a IA32 -a X64 build.exe -p D:\edk2build\edk2\CorebootPayloadPkg\CorebootPayloadPkgX64.dsc -b RELEASE -t GCC49 -n 0 -a IA32 -a X64 -------------------------- Thanks, Scott ]-----Original Message----- ]From: Patrick Georgi [mailto:patrick@georgi-clan.de] ]Sent: Wednesday, February 04, 2015 11:55 AM ]To: Yang, York ]Cc: coreboot(a)coreboot.org ]Subject: Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board ]project ] ]Am 2015-02-04 19:27, schrieb Yang, York: ]> I was told that to build an UEFI payload need to get two components ]> from different sites, sounds I got some information out-of-date. I ]> will try getting the corebootPkg and then build a payload myself. ]corebootPkg is very likely a different project from yours. There are several attempts ]to make Tianocore into a payload. ] ]The thing is, if you want to make it easier on MinnowMax users, you (or anyone else) ]could open an account on github, fork the Tianocore repository there ](https://github.com/tianocore/edk2) ]and integrate the stuff from firmware.intel.com/develop. ] ]After that, users of that payload version can just pull the entire code with a single ]git clone, too. And participate in the development through github's pull request ]feature and issue tracker. ](Of course, if you want to do this, all this may require some sign-off by your team) ] ]But since that's possible (and really easy, too), there's no need to burden ]coreboot.org with more binaries. ] ]> Understood your point that entire coreboot code must contain source ]> code only. I will share this with inside our team. ]We compromise here and there, but that's not some thing we want to encourage - it is ]really just a compromise, and it's risky to try to push its boundaries. ] ] ]Patrick ]--

1 0

AMD Mahogany Fam10 not booting
by Scott Duplichan 04 Feb '15

04 Feb '15

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 &= 0xFFFFFFFF; if (moving == 0) { if (value != 0) { printk(BIOS_DEBUG, "%s register %02lx(%08lx), " Thanks, Scott

5 6

Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project
by Patrick Georgi 04 Feb '15

04 Feb '15

Am 2015-02-04 19:27, schrieb Yang, York: > I was told that to build an UEFI payload need to get two components > from different sites, sounds I got some information out-of-date. I > will try getting the corebootPkg and then build a payload myself. corebootPkg is very likely a different project from yours. There are several attempts to make Tianocore into a payload. The thing is, if you want to make it easier on MinnowMax users, you (or anyone else) could open an account on github, fork the Tianocore repository there (https://github.com/tianocore/edk2) and integrate the stuff from firmware.intel.com/develop. After that, users of that payload version can just pull the entire code with a single git clone, too. And participate in the development through github's pull request feature and issue tracker. (Of course, if you want to do this, all this may require some sign-off by your team) But since that's possible (and really easy, too), there's no need to burden coreboot.org with more binaries. > Understood your point that entire coreboot code must contain source > code only. I will share this with inside our team. We compromise here and there, but that's not some thing we want to encourage - it is really just a compromise, and it's risky to try to push its boundaries. Patrick

2 1

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 04 Feb '15

04 Feb '15

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 11 new defect(s) introduced to coreboot found with Coverity Scan. 10 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 11 of 11 defect(s) ** CID 1268177: Out-of-bounds access (ARRAY_VS_SINGLETON) /src/cpu/x86/car.c: 137 in do_car_migrate_hooks() ** CID 1268176: Unchecked return value (CHECKED_RETURN) /src/lib/hardwaremain.c: 470 in main() ** CID 1268175: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 215 in pstates_algorithm() ** CID 1268174: Same on both sides (CONSTANT_EXPRESSION_RESULT) /src/mainboard/asus/kfsn4-dre/romstage.c: 234 in cache_as_ram_main() ** CID 1268173: Out-of-bounds read (OVERRUN) /src/northbridge/intel/i440bx/raminit.c: 612 in spd_enable_refresh() ** CID 1268172: Out-of-bounds access (OVERRUN) /src/northbridge/intel/e7505/debug.c: 99 in dump_spd_registers() /src/northbridge/intel/e7505/debug.c: 117 in dump_spd_registers() ** CID 1268171: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 82 in pstates_algorithm() ** CID 1268170: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 215 in pstates_algorithm() ** CID 1268169: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 83 in pstates_algorithm() ** CID 1268168: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 208 in pstates_algorithm() ** CID 1268167: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 81 in pstates_algorithm() ________________________________________________________________________________________________________ *** CID 1268177: Out-of-bounds access (ARRAY_VS_SINGLETON) /src/cpu/x86/car.c: 137 in do_car_migrate_hooks() 131 { 132 car_migration_func_t *migrate_func; 133 /* Call all the migration functions. */ 134 migrate_func = &_car_migrate_start; 135 while (*migrate_func != NULL) { 136 (*migrate_func)(); >>> CID 1268177: Out-of-bounds access (ARRAY_VS_SINGLETON) >>> Using "migrate_func" as an array. This might corrupt or misinterpret adjacent memory locations. 137 migrate_func++; 138 } 139 } 140 141 void car_migrate_variables(void) 142 { ________________________________________________________________________________________________________ *** CID 1268176: Unchecked return value (CHECKED_RETURN) /src/lib/hardwaremain.c: 470 in main() 464 coreboot_version, coreboot_extra_version, coreboot_build); 465 466 post_code(POST_CONSOLE_BOOT_MSG); 467 468 /* Handoff sleep type from romstage. */ 469 #if CONFIG_HAVE_ACPI_RESUME >>> CID 1268176: Unchecked return value (CHECKED_RETURN) >>> Calling "acpi_is_wakeup" without checking return value (as is done elsewhere 4 out of 5 times). 470 acpi_is_wakeup(); 471 #endif 472 473 exception_init(); 474 threads_initialize(); 475 ________________________________________________________________________________________________________ *** CID 1268175: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 215 in pstates_algorithm() 209 210 /* Calculate transition latency */ 211 dtemp = pci_read_config32(dev_find_slot(0, PCI_DEVFN(0x18, 3)), 0xD4); 212 power_step_up = (dtemp & 0xf000000) >> 24; 213 power_step_down = (dtemp & 0xf00000) >> 20; 214 dtemp = pci_read_config32(dev_find_slot(0, PCI_DEVFN(0x18, 3)), 0xA0); >>> CID 1268175: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) >>> "pll_lock_time & 0x3800" is always 0 regardless of the values of its operands. This occurs as a value. 215 pll_lock_time = (pll_lock_time & 0x3800) >> 11; 216 if (all_enabled_cores_have_same_cpufid) 217 core_latency = ((12 * power_step_down) + power_step_up) / 1000; 218 else 219 core_latency = (12 * (power_step_down + power_step_up) / 1000) 220 + pll_lock_time; ________________________________________________________________________________________________________ *** CID 1268174: Same on both sides (CONSTANT_EXPRESSION_RESULT) /src/mainboard/asus/kfsn4-dre/romstage.c: 234 in cache_as_ram_main() 228 229 post_code(0x32); 230 231 winbond_enable_serial(SERIAL_DEV, CONFIG_TTYS0_BASE); 232 console_init(); 233 >>> CID 1268174: Same on both sides (CONSTANT_EXPRESSION_RESULT) >>> "2 != 2" is always false regardless of the values of its operands because those operands are identical. This occurs as the logical operand of if. 234 if (CONFIG_MAX_PHYSICAL_CPUS != 2) 235 printk(BIOS_WARNING, "CONFIG_MAX_PHYSICAL_CPUS is %d, but this is a dual socket board!\n", CONFIG_MAX_PHYSICAL_CPUS); 236 237 /* Halt if there was a built in self test failure */ 238 report_bist_failure(bist); 239 ________________________________________________________________________________________________________ *** CID 1268173: Out-of-bounds read (OVERRUN) /src/northbridge/intel/i440bx/raminit.c: 612 in spd_enable_refresh() 606 reg = pci_read_config8(NB, DRAMC); 607 608 for (i = 0; i < DIMM_SOCKETS; i++) { 609 value = spd_read_byte(DIMM0 + i, SPD_REFRESH); 610 if (value < 0) 611 continue; >>> CID 1268173: Out-of-bounds read (OVERRUN) >>> Overrunning array "refresh_rate_map" of 6 4-byte elements at element index 127 (byte offset 508) using index "value & 0x7f" (which evaluates to 127). 612 reg = (reg & 0xf8) | refresh_rate_map[(value & 0x7f)]; 613 614 PRINT_DEBUG(" Enabling refresh (DRAMC = 0x%02x) for DIMM %02x\n", reg, i); 615 } 616 617 pci_write_config8(NB, DRAMC, reg); ________________________________________________________________________________________________________ *** CID 1268172: Out-of-bounds access (OVERRUN) /src/northbridge/intel/e7505/debug.c: 99 in dump_spd_registers() 93 for(i = 0; i < 4; i++) { 94 unsigned device; 95 device = ctrl->channel0[i]; 96 if (device) { 97 int j; 98 printk(BIOS_DEBUG, "dimm: %02x.0: %02x", i, device); >>> CID 1268172: Out-of-bounds access (OVERRUN) >>> Checking "j < 128" implies that "j" has the value which may be up to 127 on the true branch. 99 for(j = 0; j < 128; j++) { 100 int status; 101 unsigned char byte; 102 if ((j & 0xf) == 0) 103 printk(BIOS_DEBUG, "\n%02x: ", j); 104 status = spd_read_byte(device, j); /src/northbridge/intel/e7505/debug.c: 117 in dump_spd_registers() 111 printk(BIOS_DEBUG, "\n"); 112 } 113 device = ctrl->channel1[i]; 114 if (device) { 115 int j; 116 printk(BIOS_DEBUG, "dimm: %02x.1: %02x", i, device); >>> CID 1268172: Out-of-bounds access (OVERRUN) >>> Checking "j < 128" implies that "j" has the value which may be up to 127 on the true branch. 117 for(j = 0; j < 128; j++) { 118 int status; 119 unsigned char byte; 120 if ((j & 0xf) == 0) 121 printk(BIOS_DEBUG, "\n%02x: ", j); 122 status = spd_read_byte(device, j); ________________________________________________________________________________________________________ *** CID 1268171: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 82 in pstates_algorithm() 76 u32 *v; 77 struct cpuid_result cpuid1; 78 79 u16 Pstate_feq[10]; 80 u32 Pstate_power[10]; 81 u32 Pstate_latency[10]; >>> CID 1268171: Uninitialized scalar variable (UNINIT) >>> Declaring variable "Pstate_control" without initializer. 82 u32 Pstate_control[10]; 83 u32 Pstate_status[10]; 84 u8 Pstate_num; 85 u8 cmp_cap; 86 u8 index; 87 msr_t msr; ________________________________________________________________________________________________________ *** CID 1268170: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 215 in pstates_algorithm() 209 210 /* Calculate transition latency */ 211 dtemp = pci_read_config32(dev_find_slot(0, PCI_DEVFN(0x18, 3)), 0xD4); 212 power_step_up = (dtemp & 0xf000000) >> 24; 213 power_step_down = (dtemp & 0xf00000) >> 20; 214 dtemp = pci_read_config32(dev_find_slot(0, PCI_DEVFN(0x18, 3)), 0xA0); >>> CID 1268170: Uninitialized scalar variable (UNINIT) >>> Using uninitialized value "pll_lock_time". 215 pll_lock_time = (pll_lock_time & 0x3800) >> 11; 216 if (all_enabled_cores_have_same_cpufid) 217 core_latency = ((12 * power_step_down) + power_step_up) / 1000; 218 else 219 core_latency = (12 * (power_step_down + power_step_up) / 1000) 220 + pll_lock_time; ________________________________________________________________________________________________________ *** CID 1268169: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 83 in pstates_algorithm() 77 struct cpuid_result cpuid1; 78 79 u16 Pstate_feq[10]; 80 u32 Pstate_power[10]; 81 u32 Pstate_latency[10]; 82 u32 Pstate_control[10]; >>> CID 1268169: Uninitialized scalar variable (UNINIT) >>> Declaring variable "Pstate_status" without initializer. 83 u32 Pstate_status[10]; 84 u8 Pstate_num; 85 u8 cmp_cap; 86 u8 index; 87 msr_t msr; 88 ________________________________________________________________________________________________________ *** CID 1268168: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 208 in pstates_algorithm() 202 expanded_cpuidv = 100; 203 break; 204 case 0x3: 205 expanded_cpuidv = 1000; 206 break; 207 } >>> CID 1268168: Uninitialized scalar variable (UNINIT) >>> Using uninitialized value "expanded_cpuidv". 208 core_power = (core_voltage * cpuidd) / (expanded_cpuidv * 10); 209 210 /* Calculate transition latency */ 211 dtemp = pci_read_config32(dev_find_slot(0, PCI_DEVFN(0x18, 3)), 0xD4); 212 power_step_up = (dtemp & 0xf000000) >> 24; 213 power_step_down = (dtemp & 0xf00000) >> 20; ________________________________________________________________________________________________________ *** CID 1268167: Uninitialized scalar variable (UNINIT) /src/cpu/amd/model_10xxx/powernow_acpi.c: 81 in pstates_algorithm() 75 u8 processor_brand[49]; 76 u32 *v; 77 struct cpuid_result cpuid1; 78 79 u16 Pstate_feq[10]; 80 u32 Pstate_power[10]; >>> CID 1268167: Uninitialized scalar variable (UNINIT) >>> Declaring variable "Pstate_latency" without initializer. 81 u32 Pstate_latency[10]; 82 u32 Pstate_control[10]; 83 u32 Pstate_status[10]; 84 u8 Pstate_num; 85 u8 cmp_cap; 86 u8 index; ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/1016?tab=overview To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://scan.coverity.com/subscriptions/edit?email=coreboot%40coreboot.org&… .

1 0

Re: [coreboot] Can I upstream an UEFI payload binary for MinnowMax board project
by Patrick Georgi 04 Feb '15

04 Feb '15

Am 2015-02-04 01:18, schrieb Yang, York: > Can I upstream an UEFI payload binary for MinnowMax board project? No. We don't ship payload binaries, and there's no reason to start doing that. coreboot is an Open Source project. > The reason is we want to reduce the effort that coreboot user spends to > build one. > UEFI payload contains two component, 1) is EDK2 infrastructure in > tianocore.org, and 2) coreboot library and package in > firmware.intel.com/develop. User need to download them separately, and > put them together, and build it. I like to think that the corebootPkg sources are rather easy to obtain: $ git clone https://github.com/pgeorgi/edk2 So the reason that your UEFI payload's sources are harder to assemble must be a problem within that project and its processes, not something that's fundamental to Tianocore based payloads. For example, I can't imagine a single good reason why that firmware site ships Open Source code in an encrypted zip file. > It could be improved in the future, but for now it takes time. Then take the time. What incentive is left to improve things in the future if users can simply be diverted to those binaries? Patrick

2 1

What are the intricacies?, what's the finese for operating the Neal Peacock PengPod1000 tablets' Buttons!?...
by Don Warner Saklad 04 Feb '15

04 Feb '15

What are the intricacies?, what's the finese for operating the Neal Peacock PengPod1000 tablets' Buttons!?... What Button presses, what sequence of Button presses, what length of holding Button presses can be tried to get the Neal Peacock PengPod1000 to work from the included SD Card? Tried holding presses for different lengths of time, tried repeating presses, tried getting the Neal Peacock PengPod 1000 to work from the included SD Card starting with the power on and also starting with the power off and using the PowerButton, ResetButton, RockerButtonVolumeUp/VolumeDown The instructions didn't work... "To boot into Linux you must have either a Linux SD card or a device flashed with Linux. To boot from the Linux SD, starting in Android, insert the card (it will show as 'damaged") and reset the device. The screen should be blank for 15-30 seconds then boot into Linux." "There is an open root terminal on virtual console 1, use ctrl, alt, F1 to access it if needed." About tablet Model number BC1077 Build number crane_bc1077-eng 4.0.4 IMM76D 20121108 test-keys Android on Flash dual boot capable Micro SD 32GB 10-inch case with keyboard N500 Tablet PC CPU Allwinner A10 1.5GHz 560MHzDSP "PengPod 32GB Linux Bootable Micro SD Card for PengPod1000 TM and C 2013 Peacock imports LLC. All rights reserved. PengPod and the Pengpod logo are trademarks of Peacock Imports LLC, 5415 Lake Howell Rd. #317, Winter Park FL 32792 USA"

1 0

Can I upstream an UEFI payload binary for MinnowMax board project
by Yang, York 04 Feb '15

04 Feb '15

Hello, Can I upstream an UEFI payload binary for MinnowMax board project? The reason is we want to reduce the effort that coreboot user spends to build one. UEFI payload contains two component, 1) is EDK2 infrastructure in tianocore.org, and 2) coreboot library and package in firmware.intel.com/develop. User need to download them separately, and put them together, and build it. It could be improved in the future, but for now it takes time. If upstream a binary is accepted, is any rule and guidance that I should follow up? Thanks, York

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot February 2015