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