coreboot May 2015

coreboot@coreboot.org

46 participants
117 discussions

ASUS KFSN4-DRE Automated Test Failure
by Raptor Engineering Automated Coreboot Test Stand 08 May '15

08 May '15

The ASUS KFSN4-DRE fails verification as of commit b11be321a895aa70adeaa8cb92fcfcd5dcbd748c The following tests failed: CBMEM_OBJECT_TABLE_TRUNCATED Commits since last successful test: b11be32 build system: use platform specific ar(1) for libverstage 7aafe53 timestamp: fix incremental linking error for !HAVE_MONOTONIC_TIMER 1d7b9de kbuild: Use wildcard for driver subdirectories 2e38cc5 MAINTAINERS: Add lint scripts b2aee6f vboot2: Replace hard coded 'fallback' prefix with Kconfig variable <39 commits skipped> 2436bda cpu: get rid of socket source code 99cc1aa Mediawiki editing warning e9b7e25 util/xcompile/xcompile: Allow to override `HOSTCC` variable 939dc84 crossgcc: Re-download the archive if it is incomplete 6548ae9 cbfstool/Makefile*: Use `LDFLAGS` instead of `LINKFLAGS` See attached log for details This message was automatically generated from Raptor Engineering's ASUS KFSN4-DRE test stand Raptor Engineering offers coreboot consulting services! Please visit https://www.raptorengineeringinc.com for more information Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineeringinc.com> regarding any issues stemming from this notification

1 0

coreboot debugging with qemu-x86
by Saket Sinha 08 May '15

08 May '15

Hi, I am trying to debug coreboot with qemu-x86 with the following command - qemu-system-x86 -L . -bios coreboot.rom -nographic I am getting output something like this - http://pastebin.com/Ae2X5sPe (Also pasted below) EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000633 ESI=00000000 EDI=00000000 EBP=00000000 ESP=00000000 EIP=0000fff0 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0000 00000000 0000ffff 00009300 CS =f000 ffff0000 0000ffff 00009b00 SS =0000 00000000 0000ffff 00009300 DS =0000 00000000 0000ffff 00009300 FS =0000 00000000 0000ffff 00009300 GS =0000 00000000 0000ffff 00009300 LDT=0000 00000000 0000ffff 00008200 TR =0000 00000000 0000ffff 00008b00 GDT= 00000000 0000ffff IDT= 00000000 0000ffff CR0=60000010 CR2=00000000 CR3=00000000 CR4=00000000 DR0=00000000 DR1=00000000 DR2=00000000 DR3=00000000 DR6=ffff0ff0 DR7=00000400 I have build coreboot.rom with the following option in .config - Payload ---> Add a payload ---> FILO ; Payload ---> FILO version ---> HEAD Kindly let me know if I am missing something here. Regards, Saket Sinha

1 0

Re: [coreboot] u-boot as coreboot payload on qemu-x86
by Saket Sinha 08 May '15

08 May '15

Hi Ajay, The issue was that qemu-x86 did not support u-boot. Resolved it by picking up latest commits. Regards, Saket Sinha On Wed, May 6, 2015 at 11:26 AM, Ajoy Das <dasajoy80(a)gmail.com> wrote: > what is the difficulty u r facing ? > > yes it is suppose to work > > Thanks > Ajoy > > On Tue, May 5, 2015 at 7:39 PM, Saket Sinha <saket.sinha89(a)gmail.com> wrote: >> >> Hi, >> >> I am trying to run u-boot as a coreboot payload on qemu-x86.Currently >> facing some difficulty in the process. >> >> Has anyone tried running u-boot as a coreboot payload on qemu-x86 before? >> >> Regards, >> Saket Sinha >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot > >

1 0

Re: [coreboot] AGESA PI for Olivehill+
by Wolfgang Kamp - datakamp 08 May '15

08 May '15

Hello Kyösti, hello Wim, with AGESA source there is a file buildOpts.c in the mainboard directory. In this file you can overwrite seed values and they will be passed to AGESA build. With binary Pi this file is absent. How is it possible to pass values to binary PI? My AMD support comes from Aschheim-Dornach, Germany. Regards, Wolfgang

1 0

Re: [coreboot] AGESA PI for Olivehill+
by Kyösti Mälkki 08 May '15

08 May '15

On to, 2015-05-07 at 13:19 +0000, Wolfgang Kamp - datakamp wrote: > Hi Bruce, > > is it right that the AGESA Pi binary for AMD Olivehill+ board is not usable for custom board implementations of FT3B GSOC? > For example, if we use memory down design in star topology, AGESA will fail to initialize DDR3. > > Regards, > Wolfgang > I assume you have left out SPD eeproms from BOM, so have you already created and double-checked the SPD files? We have some boards in the tree doing that already. I hope to upstream DB-FT3b-LC board sources to coreboot.org, possibly next week. That may or may not help You further. Do you have PI build with raminit logging enabled? Regards, Kyösti

2 1

Re: [coreboot] [poll] device_t
by ron minnich 08 May '15

08 May '15

Oh, yeah, the history of device_t is as old as coreboot v2. It came in ca. 2002 and was part of what made romcc work. It's not a recent or ill-considered change, to say the least. ron

1 0

Re: [coreboot] [poll] device_t
by ron minnich 08 May '15

08 May '15

On Thu, May 7, 2015 at 1:42 PM Patrick Georgi <pgeorgi(a)google.com> wrote: > > > > One of these days... > > well, that's kind of key ... one of these days. Once we came to that happy time it might make sense to make this change, but until then, I think we have to wait. Now I know how to vote. ron

1 0

Re: [coreboot] Problem with USB keyboard
by David Imhoff 07 May '15

07 May '15

On 2015-05-07 11:25, Anteja Vuk-Maček wrote: > Hi, > I'm begin with coreboot and seaBIOS. I have the problem with USB > keyboard and mouse. When I boot the firmware my keyboard and mouse > don't work. > > I use : coreboot, payload seaBios, MinnowMax board > Problem: What I need to do for correct a firmware? > > Best regards, > > _Anteja _ What version of Coreboot are you using? Version number should look something like 4.0-9612-g7aafe53. What version of the Intel FSP are you using(Gold3?)? I'm running GIT commit d93bd263b66d83fff4e22826e465aae8fac326df + the patch from the following review: http://review.coreboot.org/#/c/10100/2/src/drivers/intel/fsp1_0/fsp_util.c With my Apple USB keyboard connected to the USB 3.0 port I can enter the SeaBIOS boot menu and make a selection from there without a problem. That is on a dual core Minnowboard Max. Best regards, David

1 0

Re: [coreboot] [poll] device_t
by Stefan Reinauer 07 May '15

07 May '15

* ron minnich <rminnich(a)gmail.com> [150507 21:35]: > one counter-question: is romcc ever going away, or at least is the usage > gong to change such that no code would ever use the uint32 version of > device_t? > > > If it's *never* going away then I think the change makes no sense. If romcc is > going away, then I would favor the change. With our current bootblock concept, it is never going away on x86 (for bootblock usage) Stefan

2 1

[poll] device_t
by Stefan Reinauer 07 May '15

07 May '15

Since Edward started hijacking patches on gerrit to push his agenda of getting rid of device_t without prior discussion, I would like to start a poll on how people think about this, and maybe find reasons for why it might be a good idea. Edward wrote: > The issue of 'device_t' has many heads. The primary issue I have here > is that these patches introduce many more 'device_t' instances that > make the job of sorting out which 'device_t' are 'uint32_t' and which > are 'struct device *' significantly harder as this sort of thing > progresses. > If the author would just use 'struct device *' and there is (for some > wrapped reasoning) a consensus to only use 'device_t' then it is trivial > to go do 's/struct device * /device_t /g'. > There is actually no reason needed here to use a opaque type which was > invented to solve a particular issue however has now spilled over to > becoming rampant though the tree. The reality here is that device_t was a concept used ever since coreboot v2 (LinuxBIOS v2 from 2003 actually) existed. It is indeed the use of struct device that has accidently spilled over. The reason this was done was to use the same driver code in romstage and ramstage. While this can be achieved by other means, no doubt, I don't think that this churn on the code base is particularly useful. Before we continue on this path I would like to see a reason for not using device_t or why the difference between the type has to be sorted out. The whole idea is that it does not matter, and the code does not have to know. Check out the poll at https://doodle.com/vvqtyhdxr9yhvqci Stefan

2 1

← Newer
1
...
5
6
7
8
9
10
11
12
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 May 2015