coreboot April 2013

coreboot@coreboot.org

42 participants
125 discussions

Not able to post +1/-1 for Gerrit code reviews
by Bruce Griffith 22 Apr '13

22 Apr '13

I am no longer able to post comments as +1 and -1 in Gerrit code reviews. Is there something that I messed up in my user preferences? I am user "kepler2". BG

2 1

GSoC student application period opens today, 22.04.2013
by Marc Jones 22 Apr '13

22 Apr '13

Just a reminder that the student application period goes from 22.04.2013 to 03.05.2013. Please visit the wiki for more information: http://www.coreboot.org/GSoC Marc -- http://se-eng.com

1 0

Trac reminder: list of new ticket(s)
by coreboot tracker 22 Apr '13

22 Apr '13

1 0

[RFC] Improving early debugging as GSoC project
by Kyösti Mälkki 22 Apr '13

22 Apr '13

Hi! I have previously expressed my interest on GSoC. During the summer 2013, I would like to attack some of the early debugging problems I have seen people often come across when starting a port of a new mainboard for coreboot. My proposal includes ideas taken from "coreboot panic room" and "SerialICE" project ideas, as well as early cbmem. I have identified some old patches that should go upstream first, so there would be a combination of new development, maintenance, as well as integration of some new features to older boards. This is not a sorted list by effort estimation or importance, just some topics I could work on to improve the debugging environment one has to cope with when porting for a new mainboard. 1. User of SerialICE usually has the goal to port a board to coreboot. By building serialice.rom as a romstage instead of separate flash image, one can re-use the coreboot tree structure and the early superio setup sources. First step of any new port would then be to commit a mainboard directory with SerialICE and console debugging capabilities. 2. SerialICE with EHCI debug is currently a quick hack for one board. Integrate it properly for all boards. Motivation for this is that serial ports are not always available and also my DIY EHCI debug dongle could use more testing. 3. SerialICE has the capability to capture any PCI/IO/MEM accesses during the early boot stages from the target-host communication link, while running vendor bios in QEmu. Implement similar sniffer functionality when coreboot goes through ramstage and log all the accesses in cbmem. While this would not help raminit problems, it could help solve problems where PCI subsystem has incorrect initialization sequences. I found it hard to understand how walking the devicetree really works reading the source alone as Agesa wrappers are pretty difficult to master. 4. SerialICE communication could use a more efficient protocol, especially with the 8 byte packet length restriction of EHCI debug. Could one multiplex coreboot console and SerialICE and GDB in some fashion here? 5. One of the main tasks I would like to accomplish is to be able to reprogram flash even when some stage of boot process has prevented from entering OS. I do not have the latest status of FILO developments or Flashrom as payload, I believe there is some working code for some selected hardware already. It appears the GSoC 2011 project of panic room and running flashrom in cache-as-ram environment did not produce a suitable generic solution for upstream. Should this be investigated further? 6. What is the status of debug console support in different payloads? I quess superio based UARTs in IO space are the only ones generally supported, while MMIO UARTs and EHCI debug ports may have existing patches out there somewhere? For now, I would much appreciate comments if some of the topics above are just "bad idea, don't", and/or if some ideas are already implemented but not merged upstream, and/or if you have active development that would void my work or vice-versa. Regards, Kyösti

2 1

Re: [coreboot] [i915] Screen corruptions
by Denis 'GNUtoo' Carikli 22 Apr '13

22 Apr '13

On Sun, 14 Apr 2013 22:04:19 -0700 ron minnich <rminnich(a)gmail.com> wrote: > What we do on ARM (see google/snow) for now is reserve a big chunk of > memory in the coreboot tables for graphics. You could set the gtt to > point to that. I've seen the framebuffer address for google/snow,I've also seen it passing its address to various functions. But I failed to find where it creates such tables and passes them in arm. However I've investigated more and I found that: [...] Root Device assign_resources, bus 0 link: 0 pci_tolm: 0xd0000000 Base of stolen memory: 0xcf800000 Top of Low Used DRAM: 0xd0000000 IGD decoded, subtracting 8M UMA Available memory: 3399680K (3320M) Adding PCIe config bar [...] Note that TSEG not valid(address=0, len=0) for that platform(Lenovo X60). Removing SMM removes the corruption in coreboot, but not in the payload. The BAR holding the framebuffer(which is at 0xd0020000) is here(from lspci): Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M] Also before running videotest in grub, all the tables(coreboot,ACPI etc...) are there, but after, all the tables are gone. Thanks a lot to phcoder/Vladimir Serbinenko because he wrote a coreboot framebuffer driver for grub. Thanks to that I've done some test: 1) run lscoreboot or lsmmap or any command that list or uses the tables. => it works 2) run videotest => it works in qemu,fails on the X60. 3) the tables are gone on the X60. Denis.

1 0

Re: [coreboot] ASRock E350M1: How to set RAM voltages under coreboot?
by Rudolf Marek 21 Apr '13

21 Apr '13

> In the long term, would it be possible to do this stuff from the OS, > not some bios setup screen? Or is it too late by the time the OS is > booted? On the SiS 630 we controlled overclocking parameters via a > user mode command once Linux had booted, but that was long ago ... do > the new chips make this easier, or harder? Yes sounds like good idea (to have it in nvram) but only as option. My DDR3 memory does not work well on 1.5V (it has to have 1.65V) from the start. Thanks Rudolf > > ron >

2 1

Re: [coreboot] ASRock E350M1: How to set RAM voltages under coreboot?
by Patrick Georgi 20 Apr '13

20 Apr '13

Am 20.04.2013 19:20, schrieb ron minnich: > In the long term, would it be possible to do this stuff from the OS, > not some bios setup screen? Or is it too late by the time the OS is > booted? On the SiS 630 we controlled overclocking parameters via a > user mode command once Linux had booted, but that was long ago ... do > the new chips make this easier, or harder? Even if it has no immediate effect, exposing such options over nvram (and so they can be modified from the OS using nvramtool) is the right thing to do. We'll have to reconsider once there's actual hardware without old-style nvram (SMM emulated nvram backed by flash? ;-) ) Patrick

1 0

ASRock E350M1: How to set RAM voltages under coreboot?
by Paul Menzel 20 Apr '13

20 Apr '13

Dear coreboot folks, currently the ASRock E350M1 has the following code copied from AMD Inagua for setting voltages. $ nl -ba src/mainboard/amd/inagua/BiosCallOuts.c […] 487 /* Call the host environment interface to provide a user hook opportunity. */ 488 AGESA_STATUS BiosHookBeforeDramInit(UINT32 Func, UINT32 Data, VOID * ConfigPtr) 489 { 490 AGESA_STATUS Status; 491 UINTN FcnData; 492 MEM_DATA_STRUCT *MemData; 493 UINT32 AcpiMmioAddr; 494 UINT32 GpioMmioAddr; 495 UINT8 Data8; 496 UINT16 Data16; 497 UINT8 TempData8; 498 499 FcnData = Data; 500 MemData = ConfigPtr; 501 502 Status = AGESA_SUCCESS; 503 /* Get SB MMIO Base (AcpiMmioAddr) */ 504 WriteIo8(0xCD6, 0x27); 505 Data8 = ReadIo8(0xCD7); 506 Data16 = Data8 << 8; 507 WriteIo8(0xCD6, 0x26); 508 Data8 = ReadIo8(0xCD7); 509 Data16 |= Data8; 510 AcpiMmioAddr = (UINT32) Data16 << 16; 511 GpioMmioAddr = AcpiMmioAddr + GPIO_BASE; 512 513 Data8 = Read64Mem8(GpioMmioAddr + SB_GPIO_REG178); 514 Data8 &= ~BIT5; 515 TempData8 = Read64Mem8(GpioMmioAddr + SB_GPIO_REG178); 516 TempData8 &= 0x03; 517 TempData8 |= Data8; 518 Write64Mem8(GpioMmioAddr + SB_GPIO_REG178, TempData8); 519 520 Data8 |= BIT2 + BIT3; 521 Data8 &= ~BIT4; 522 TempData8 = Read64Mem8(GpioMmioAddr + SB_GPIO_REG178); 523 TempData8 &= 0x23; 524 TempData8 |= Data8; 525 Write64Mem8(GpioMmioAddr + SB_GPIO_REG178, TempData8); 526 527 Data8 = Read64Mem8(GpioMmioAddr + SB_GPIO_REG179); 528 Data8 &= ~BIT5; 529 TempData8 = Read64Mem8(GpioMmioAddr + SB_GPIO_REG179); 530 TempData8 &= 0x03; 531 TempData8 |= Data8; 532 Write64Mem8(GpioMmioAddr + SB_GPIO_REG179, TempData8); 533 534 Data8 |= BIT2 + BIT3; 535 Data8 &= ~BIT4; 536 TempData8 = Read64Mem8(GpioMmioAddr + SB_GPIO_REG179); 537 TempData8 &= 0x23; 538 TempData8 |= Data8; 539 Write64Mem8(GpioMmioAddr + SB_GPIO_REG179, TempData8); 540 541 switch (MemData->ParameterListPtr->DDR3Voltage) { 542 case VOLT1_35: 543 Data8 = Read64Mem8(GpioMmioAddr + SB_GPIO_REG178); 544 Data8 &= ~(UINT8) BIT6; 545 Write64Mem8(GpioMmioAddr + SB_GPIO_REG178, Data8); 546 Data8 = Read64Mem8(GpioMmioAddr + SB_GPIO_REG179); 547 Data8 |= (UINT8) BIT6; 548 Write64Mem8(GpioMmioAddr + SB_GPIO_REG179, Data8); 549 break; 550 case VOLT1_25: 551 Data8 = Read64Mem8(GpioMmioAddr + SB_GPIO_REG178); 552 Data8 &= ~(UINT8) BIT6; 553 Write64Mem8(GpioMmioAddr + SB_GPIO_REG178, Data8); 554 Data8 = Read64Mem8(GpioMmioAddr + SB_GPIO_REG179); 555 Data8 &= ~(UINT8) BIT6; 556 Write64Mem8(GpioMmioAddr + SB_GPIO_REG179, Data8); 557 break; 558 case VOLT1_5: 559 default: 560 Data8 = Read64Mem8(GpioMmioAddr + SB_GPIO_REG178); 561 Data8 |= (UINT8) BIT6; 562 Write64Mem8(GpioMmioAddr + SB_GPIO_REG178, Data8); 563 Data8 = Read64Mem8(GpioMmioAddr + SB_GPIO_REG179); 564 Data8 &= ~(UINT8) BIT6; 565 Write64Mem8(GpioMmioAddr + SB_GPIO_REG179, Data8); 566 } 567 return Status; 568 } […] The attached screenshot from Alvaro shows, that the vendor BIOS of the ASRock E350M1 [1] offers even more options for the voltages. Especially the AUTO options sounds nice. First I have to say, that I have not tried yet to change the voltage on my ASRock E350M1, so I have no idea if the code from AMD Inagua works or not. Secondly I have no idea how to check under the operating system, what the voltage is. So how would I find out what to do on the ASRock E350M1 without having any schematics? a) Disassemble the vendor BIOS binary? b) Use SerialICE and look at the differences when changing the option in the vendor BIOS menu? Thanks, Paul [1] http://www.asrock.com/mb/overview.asp?cat=Download&os=BIOS&Model=E350M1

3 2

question about asrock E350M1
by Iurie 20 Apr '13

20 Apr '13

this mboard: http://www.asrock.com/mb/overview.asp?cat=Specifications&Model=E350M1 has Chipset - AMD A50M Chipset but here http://www.coreboot.org/Supported_Motherboards#Mini-ITX_.2F_Micro-ITX_.2F_N… i have : ASRock E350M1 OK... AMD Fam14h AMD® SB800 Winbond™ W83627HF that is, the Chipset - AMD A50M is not referenced as the southbridge and instead i have SB800. regarding the super IO, some folks suggested me that it is the same as the southbrige, that is the same chip, AMD A50M. but i wold like to know you opinion. for example the ASRock E350M1, has the Winbond™ W83627HF as the super IO i thank you in advance for the answer best regards

1 0

Re: [coreboot] git clone coreboot : Error: RPC failed; result=22, HTTP code = 502
by Aaron Durbin 19 Apr '13

19 Apr '13

On Fri, Apr 19, 2013 at 4:36 AM, Pradish M P, ERS, HCLTech <pradishmp(a)hcl.com> wrote: > Hi Paul > > Sorry for the earlier logs, please find attached the latest logs > And here the output of df -h command > > pradish@pradish-VirtualBox:~$ df -h > Filesystem Size Used Avail Use% Mounted on > /dev/sda1 32G 15G 16G 48% / > udev 242M 4.0K 242M 1% /dev > tmpfs 100M 760K 99M 1% /run > none 5.0M 0 5.0M 0% /run/lock > none 249M 168K 249M 1% /run/shm > share 60G 34G 27G 57% /media/sf_share > /dev/sr0 53M 53M 0 100% /media/VBOXADDITIONS_4.2.4_81684 > Fwiw, it seems like your virtual box instance might be acting funny. [pid 3363] connect(4, {sa_family=AF_INET, sin_port=htons(8080), sin_addr=inet_addr("10.97.32.19")}, 16) = -1 EINPROGRESS (Operation now in progress) <-- snip --> [pid 3363] getpeername(4, {sa_family=AF_INET, sin_port=htons(8080), sin_addr=inet_addr("10.97.32.19")}, [16]) = 0 [pid 3363] getsockname(4, {sa_family=AF_INET, sin_port=htons(53159), sin_addr=inet_addr("10.119.71.112")}, [16]) = 0 I'm not sure if I can trust those addresses as those are returned from the respective syscalls, but they definitely don't match with review.coreboot.org's ip address: $ dig +short review.coreboot.org coreboot.org. 80.81.252.130 Can you get to other network addresses from your virtual box instance? There might be some intermittent issues w/ virtual box's proxies, etc. I'd just periodically try to re-clone. -Aaron > From: Paul Menzel [mailto:paulepanter@users.sourceforge.net] > Sent: Friday, April 19, 2013 2:31 PM > To: Pradish M P, ERS, HCLTech > Cc: coreboot(a)coreboot.org > Subject: Re: [coreboot] git clone coreboot : Error: RPC failed; result=22, HTTP code = 502 > > Dear Pradish, > > > Am Freitag, den 19.04.2013, 08:27 +0000 schrieb Pradish M P, ERS, HCLTech: >> Dear Ron/Coreboot folks >> >> I have run the command under strace -f , and I have attached the log >> Let me know if any of you have any suggestions. > > Why did you press Ctrl + z? Everything seemed to work until you stopped the process. Have you *retried* running the command as suggested by Björn? > > Please do the following again. > > $ df -h # see if you have enough space > $ git clone http://review.coreboot.org/p/coreboot > > > Thanks, > > Paul > > > ::DISCLAIMER:: > ---------------------------------------------------------------------------------------------------------------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. > E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, > lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents > (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. > Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the > views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, > distribution and / or publication of this message without the prior written consent of authorized representative of > HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. > Before opening any email and/or attachments, please check them for viruses and other defects. > > ---------------------------------------------------------------------------------------------------------------------------------------------------- > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
13
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 April 2013