coreboot February 2011

coreboot@coreboot.org

52 participants
283 discussions

build service results for r6401
by repository service 28 Feb '11

28 Feb '11

Dear coreboot readers! This is the automatic build system of coreboot. The developer "mjones" checked in revision 6401 to the coreboot repository. This caused the following changes: Change Log: Improving BKDG implementation of P-states, CPU and northbridge frequency and voltage handling for Fam 10 in SVI mode. Factor out some common expressions. Add an error message when coreboots hangs waiting for a pstate that never comes (it happened to me), and throw some paranoia at it for good mesure. If I understood BKDG fam10 CPUs never need a software initiated vid transition, because the hardware knows what to do when you just request a Pstate change if the cpu is properly configured. In fact unifying a little what PVI and SVI do was better for my board (SVI). So I drop transitionVid, which I didn't understand either (why did it have a case for PVI if it is never called for PVI ? Why did the PVI case distinguigh cpu or nb when PVI is theoretically single voltage plane ? ). Signed-off-by: Xavi Drudis Ferran <xdrudis(a)tinet.cat> Acked-by: Marc Jones <marcj303(a)gmail.com> Build Log: Compilation of amd:bimini_fam10 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=6401&device=bimini_fam10&v… Compilation of amd:tilapia_fam10 has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=6401&device=tilapia_fam10&… Compilation of gigabyte:ma785gmt has been broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=6401&device=ma785gmt&vendo… If something broke during this checkin please be a pain in mjones's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

build service results for r6406
by repository service 28 Feb '11

28 Feb '11

Dear coreboot readers! This is the automatic build system of coreboot. The developer "mjones" checked in revision 6406 to the coreboot repository. This caused the following changes: Change Log: Improving BKDG implementation of P-states, CPU and northbridge frequency and voltage handling for Fam 10 in SVI mode. Well, I understand it better like this, but maybe it's only me, part of the changes are paranoic, and the only effective change is for a factor depending on mobile or not that I can't test. Signed-off-by: Xavi Drudis Ferran <xdrudis(a)tinet.cat> Acked-by: Marc Jones <marcj303(a)gmail.com> Build Log: Compilation of amd:bimini_fam10 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=6406&device=bimini_fam10&v… Compilation of amd:tilapia_fam10 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=6406&device=tilapia_fam10&… Compilation of gigabyte:ma785gmt is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=6406&device=ma785gmt&vendo… If something broke during this checkin please be a pain in mjones's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

Trac reminder: list of new ticket(s)
by coreboot tracker 28 Feb '11

28 Feb '11

1 0

Re: [coreboot] Microcode CPU writeup
by Xavi Drudis Ferran 28 Feb '11

28 Feb '11

On Mon 28/02/11 08:16 , Rudolf Marek <r.marek(a)assembler.cz> wrote: > Hi all, > > Would someone be interrested if I write something about microcoded CPUs > controllers? Like the classic uCode ROM + ALU + Regs + IO unit? > > Thanks, > Rudolf > I'd read it. I remember a little from college but I'm not very up to date. But maybe the list is already tired of my long mails on microcode ?

2 1

CBSTOOL
by ali hagigat 28 Feb '11

28 Feb '11

I wonder if anybody can explain the function of CBFSTOOL commands: create, add-stage and locate in details, examples are below: $(CBFSTOOL) $@ create $(CONFIG_COREBOOT_ROMSIZE_KB)K $(obj)/coreboot.bootblock $(CBFSTOOL) $@ add-stage $(obj)/romstage.elf $(CONFIG_CBFS_PREFIX)/romstage x 0x$(shell cat $(obj)/location.txt) $(CBFSTOOL) $(obj)/coreboot.pre1 locate $(obj)/romstage.bin $(CONFIG_CBFS_PREFIX)/romstage $(CONFIG_XIP_ROM_SIZE) > $(obj)/location.txt Regards

3 2

Re: [coreboot] [PATCH] Fam10 FIDVID in SVI 25/25
by Xavi Drudis Ferran 28 Feb '11

28 Feb '11

On Mon 28/02/11 05:01 , Marc Jones <marcj303(a)gmail.com> wrote: > On Wed, Feb 16, 2011 at 11:46 PM, xdrudis wrote: > > see patch > > > > Oops no patch attached. > > Marc > Never mind. It was just moving the coreDelay function where it was used. You already did it. :) Sorry to have forgot the attachment. I tested each patch with my board and only after the 24 I did an abuild and saw that some of the boards called coreDelay but didn't use fidvid.c . Then I made the 25th patch to solve it instead of fixing the original patch, fearing that the line numbers would be wrong in the other patches and all that. That wasn't very proper. But then I forgot to even attach the 25th patch. :( Thank you very much, Marc, for fixing, reviewing and commiting all this.

1 0

build service results for r6404
by repository service 28 Feb '11

28 Feb '11

Dear coreboot readers! This is the automatic build system of coreboot. The developer "mjones" checked in revision 6404 to the coreboot repository. This caused the following changes: Change Log: Improving BKDG implementation of P-states, CPU and northbridge frequency and voltage handling for Fam 10 in SVI mode. Add to init_fidvid_stage2 some step mentioned in BKDG 2.4.2.7 that was missing . Some lines are dead code now, but may handy if one day we support revison E CPUs. Signed-off-by: Xavi Drudis Ferran <xdrudis(a)tinet.cat> Acked-by: Marc Jones <marcj303(a)gmail.com> Build Log: Compilation of amd:bimini_fam10 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=6404&device=bimini_fam10&v… Compilation of amd:tilapia_fam10 is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=6404&device=tilapia_fam10&… Compilation of gigabyte:ma785gmt is still broken See the error log at http://qa.coreboot.org/log_buildbrd.php?revision=6404&device=ma785gmt&vendo… If something broke during this checkin please be a pain in mjones's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

build service results for r6408
by repository service 28 Feb '11

28 Feb '11

Dear coreboot readers! This is the automatic build system of coreboot. The developer "mjones" checked in revision 6408 to the coreboot repository. This caused the following changes: Change Log: Improving BKDG implementation of P-states, CPU and northbridge frequency and voltage handling for Fam 10 in SVI mode. In fact I changed coreDelay before deleting the code in fidvid that called it. But there're still a couple of calls from src/northbridge/amd/amdmct/wrappers/mcti_d.c Since the comment encouraged fixing something, I parametrized it with the delay time in microseconds and paranoically tried to avoid an overflow at pathological moments. Signed-off-by: Xavi Drudis Ferran <xdrudis(a)tinet.cat> Acked-by: Marc Jones <marcj303(a)gmail.com> Build Log: Compilation of amd:bimini_fam10 has been fixed Compilation of amd:tilapia_fam10 has been fixed Compilation of gigabyte:ma785gmt has been fixed If something broke during this checkin please be a pain in mjones's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

Re: [coreboot] about Intel calpella board(I3+QM57)
by Peter Stuge 28 Feb '11

28 Feb '11

Hello, zxy__1127 wrote: > I have worked on this board two weeks,now it can print from serial > port, This is a very important first step! Good news. > and stop at ddr3 initialling in file romstage.c. > I found it difficult to deal with it. I can understand that. Memory initialization is the most complex task in coreboot, and require many details to be exactly right, including e.g. the sequence of steps and timing between steps. > Is there anyone working on it? My guess is no. However, since you have the serial port working, you could try to use SerialICE (see http://serialice.org/ ) to get a better understanding of the operations done by the factory BIOS. This can help to create the code needed in coreboot to bring up a board. //Peter

2 1

Fam10 FIDVID in SVI : disabling microcode update
by Xavi Drudis Ferran 28 Feb '11

28 Feb '11

Hello. I finally splitted my changes into some 25 small patches (some 8-10 quite trivial refactorings, but I hesitate to use "trivial" in signing off) . I compiled each for my board and tested it , and I hoped to find which of them fixed my fidvid issues. I have to add some commit comments and I hope to send them tonight or tomorrow evening. But after applying all of them it still didn't work. So I looked again and discovered in my previous tests I had commented the calls to update_microcode(...) . In the test of the smaller patches I had mistakenly commented only the call for the BSP but not for the APs. I tried with both calls commented and it works, then I thought, "ok, it must work with both uncommented, having diferent microcode versions in different cores is just weird". But with the calls uncommented it won't work (it hangs in ram initialization, like without most of the patches, or with microcode updated only in some cores, and then it depends, sometines it works). So in order for my board to pass fidvid and ram init I have to disable microcode updating. I haven't tried any new microcode in Agesa code submitted this last sunday, because, after all, it does not have source, so for all I care I'll be happier if it works without it. I guess the reason could be either of: - coreboot is applying the wrong microcode version, and some logic selecting the microcode can be fixed - the version of the microcode itself is faulty, and may be fixed in a later version (maybe already under /vendorcode/...) - the way to update the microcode does not work in my CPU But I don't feel like fixing any. Yet I don't think I should send a patch just commenting those calls to update_microcode, should I ? Should I send a patch making a Kconfig option to not upgrade microcode for fam10? Is there any interest in that ? Should I just send the patches for fidvid and keep the update_microcode commented for myself only, even if this still does not fix the issues for my setup, so that someone else may investigate what's wrong with the microcode ? Are my patches moot because fam10 fidvid is going to be replaced with something from Agesa ? Finally, I've never used abuild, but taking into account I'm touching src/cpu/amd/model_10xxx/fidvid.c src/cpu/amd/model_10xxx/defaults.h src/cpu/amd/model_10xxx/init_cpus.c src/northbridge/amd/amdmct/wrappers/mcti_d.c src/northbridge/amd/amdmct/amddefs.h src/northbridge/amd/amdfam10/Kconfig src/northbridge/amd/amdfam10/raminit_amdmct.c src/northbridge/amd/amdht/AsPsDefs.h should I try to abuild before sending my patches ? thanks.

7 57

← Newer
1
2
3
4
5
6
7
...
29
Older →

Jump to page:

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 2011