Hi all,
Does anyone have experience with using the CK804 PCIe PME# signal? I
have a board here that is receiving PME from the power button but I
cannot seem to get it to receive PME from the PCIe PME# signal.
Dumping the CK804 configuration space and the SYS/ANACTL LPC
configuration spaces with the "Wake on PCIe" option enabled then
disabled in the proprietary BIOS didn't reveal anything interesting.
Thanks!
--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com
Hello!
I'm trying to run Coreboot on Lenovo G505s and have a problem:
- backlight of LCD is not turn on. But on the external LCD (by CRT
connector) is all good.
Could you help me with a solution to this problem?
Hello,
Has anybody tried to launch GRUB2 by SeaBIOS as a payload (not grub2 on
MBR)? I am hoping to see grub2 on SeaBIOS boot menu.
I followed the coreboot wiki page to compile grub2:
git clone git://git.savannah.gnu.org/grub.git grub
cd grub
./autogen.sh
./configure --with-platform=coreboot
make
At this point it is not clear to me how to create grub2.elf and what the
role of memdisk is. I would appreciate it if somebody could clarify the
steps.
Thanks!
Wen
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I found this patch on http://review.coreboot.org/#/c/7975/ but I was
surprised to see a lack of testers. Is there someone out there with
this machine that would still be willing to test it?
Regards,
Francis Rowe.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJUwquyAAoJEP9Ft0z50c+Uk+kH/i6EYfGSRVO5dgyJAYgBnQYz
mIPDhgd3mcXdeqcKAFQvubZ9j9/rDeMxM+SrmJWybIE8WtrwoxkO6vFxl6JivzYp
gH1bMgl9YVSZZZxvvZmHJzyBFa2VocApSztPfC9PkIdvEDfH4CnHGkO6ulGfVVKC
ESr6+ZP8jK3uN6dtLJqX0NcEhuxw7ZRt5nUtIWxpuwjSaavxYfuFhw6NCWfsI6ay
nzSWSP6P7jG5WSacVAvxqQfraMcSuPu0q3y+kIhVxspOqKpWmwsasGtgZu777zy6
thGgtHbJPhYULLfZcizWIwJ1MAXGzB8XVz6VVaV0DoYPh3WEIBkviDg89iDC7MY=
=GwaO
-----END PGP SIGNATURE-----
Hello,
I'm trying to load Memtest86+ on the Mohon Peak reference board from
CBFS and it fails.
My primary payload is SeaBIOS. Memtest is added using cbfstool, so the
layout of my ROM file is as follows:
$ ./build/cbfstool build/coreboot.rom print
coreboot.rom: 8192 kB, bootblocksize 1024, romsize 8388608, offset 0x600000
alignment: 64 bytes, architecture: x86
Name Offset Type Size
cmos_layout.bin 0x600000 cmos_layout 1352
fallback/romstage 0x600580 stage 26616
fallback/ramstage 0x606dc0 stage 60446
fallback/payload 0x615a40 payload 55799
config 0x623480 raw 4323
revision 0x6245c0 raw 714
img/Memtest86+ 0x6248c0 payload 225028
(empty) 0x65b800 null 1001368
mrc.cache 0x74ffc0 (unknown) 65536
cpu_microcode_blob.bin 0x760000 microcode 83968
(empty) 0x774840 null 46936
fsp.bin 0x77ffc0 (unknown) 372736
(empty) 0x7db000 null 150424
I've tried versions 4.20 and 5.01. Memtest86+ v4.20 just hangs, here is
output of SeaBIOS trying to load it:
Trying CBFS
Booting from CBFS...
Run img/Memtest86+
Segment 41544144 194420@0xffe24920 -> 194420@0x00000000
No compression
And then nothing. Memtest86+ v5.01 goes a bit further, SeaBIOS finds its
entry point:
Trying CBFS
Booting from CBFS...
Run img/Memtest86+
Segment 41544144 224972@0xffe24920 -> 224972@0x00000000
No compression
Calling addr 0x00010000
But after this the board reboots.
I also tried to load Memtest from HDD using Grub and v4.20 seems to work
fine, while v5.01 causing reboot just like in case with CBFS.
And I also tried to add Memtest as a primary payload without SeaBIOS.
Again, v5.01 causes reboot. And v4.20 cannot find linuxbios tables.
Viktor
Hi Sevan,
Well for this problem, I would like to see someone who is designated to help. I
thought we had someone, but it looks like there is none.
Thanks
Rudolf
On Mon Jan 19 2015 at 7:52:45 PM Carl-Daniel Hailfinger <
c-d.hailfinger.devel.2006(a)gmx.net> wrote:
> Hi Marc,
>
> On 19.01.2015 01:49, Marc Jones wrote:
> > On Sat Jan 17 2015 at 8:12:20 PM Carl-Daniel Hailfinger wrote:
> >> Hi Marc,
> >>
> >> thanks for writing this up.
> >>
> >> On 16.01.2015 19:15, Marc Jones wrote:
> >>> A coreboot code of conduct has been posted on the wiki.
> >>> - http://www.coreboot.org/Code_of_Conduct
> >>>
> >>> I have written a blog post about why we have a code of conduct.
> >>> - http://blogs.coreboot.org/blog/2015/01/16/coreboot-code-of-
> conduct/
> >>>
> >>> Feel free to give feedback on the policy and how else we can contribute
> >>> to a welcoming and collaborative environment.
> >> Given that the Code of Conduct has been announced publicly in a blog
> >> post, the feedback is probably expected to be public as well. Apologies
> >> if that is not the case.
> >>
> >> The current wording suggests that anyone can be expelled from the
> >> community permanently without warning for either perceived harrassment
> >> or for strongly enforcing the code of conduct. This is probably not the
> >> intention.
> > Open discussion is acceptable.
>
> Adding that sentence to the CoC would be helpful.
>
>
> >> Furthermore, the second paragraph of "Unacceptable Behaviour" is either
> >> redundant or woefully incomplete. If you really think the word
> >> "harassing" from the first paragraph needs to be defined, you should
> >> define the other words from the first paragraph "intimidating",
> >> "abusive", "discriminatory", "derogatory" and "demeaning" as well. I
> >> suggest deleting that second paragraph.
> > I'll disagree. Harassment is the most common problem in online
> communities
>
> Real citation needed, not just some sentiment. For example, quite a few
> feminist blogs point to intimidating and derogatory speech/actions as
> the primary hurdles against female participation in online communities.
>
>
This was based on discussions at the GSOC summit as I mentioned in my blog
post. Several community leaders and more experience policy makers lead the
discussion.
> > and warrants the paragraph about those unacceptable behaviors.
>
> If harassment is the most common problem, that definitely warrants
> listing harassment first (which is not the case in the current CoC).
>
>
> > Defining
> > every other term would not make this policy any more robust.
>
> Is the term "harassment" so unclear it warrants explanation? I thought
> there was universal agreement that harassment is bad, but having to
> define harassment implies that there is no such universal agreement (you
> can't agree on something undefined).
> I argue that creating our own homegrown definition of harassment (or
> copying someone else's homegrown definition) makes this policy less
> robust because this current homegrown definition is woefully incomplete.
>
>
>
Your point has been noted and we will examine how a change would improve
the policy. Thanks for your contribution. I admit that this is not an area
we are experts in, but we tried to choose a reference policy that was
recognized a good a positive representation of our community. Please
forward any expert recommendation or examples from other communities that
improves the coreboot community policy, interactions, increase diversity
within this community.
> >> Please define "community organizers". Did you mean "arbitration team"?
> >> Or is it the community members present at an event?
> > It isn't not meant to be specific to an arbitration team. These members
> may
> > not be present in all cases and organizers of events and online
> communities
> > should uphold the good standards of the community.
>
> Thanks for clarifying. The CoC would benefit from adding this
> clarification.
>
>
> >> How can we deploy this against people not part of our community? If
> >> they're not part of the community in the first place, it is by
> >> definition impossible to exclude them from our community and the Code of
> >> Conduct in its current form does not apply. If, on the other hand, we
> >> define everyone on the mailing list, everyone on IRC and everyone
> >> visiting our booths at various conferences and trade shows as being part
> >> of our community, we're going to overshoot the mark. I don't want to be
> >> guilty by association just because some troll on IRC joins all channels,
> >> spews some random offensive crap and disappears.
> > It applies to everyone that participates in coreboot communication,
> online,
> > at an event or in a conference booth. People that are not up to this
> > standard of behavior are not welcome in our community and they should be
> > asked to leave. If a troll joins and spams the channel, clearly ask them
> to
> > leave. If they don't leave report them to a channel or IRCOP. If there
> is a
> > question of the policy or of a behavior, please contact an organizer or
> > someone from the arbitration team.
>
> Great, thanks for the explanation and guideline!
>
>
> Regards,
> Carl-Daniel
>
>
ron minnich [mailto:rminnich@gmail.com] wrote:
]Sent: Sunday, August 10, 2014 06:34 PM
]To: Marc Jones
]Cc: Scott Duplichan; coreboot
]Subject: Re: [coreboot] why is firmware 32 bit as opposed to 64 bit
]
]I understand the arguments.
]
]It's worth remembering that coreboot has to date run on 5 different
]architectures. 4 of those used paging. The x86 has always been the
]outlier. Lack of paging has costs not discussed much. Rmodules would
]be a lot simpler if we had paging. We could make the code space
]readonly, which we should be doing anyway. We would have less fighting
]with the granularity and alignment restrictions of MTRRs. We could
]catch NULL pointers in hardware. These are clear benefits. And they
]all apply to the ramstage as well as other stages.
]
]As to 64 bit ramstage, I see lots of benefits for my use cases, but I
]may be the only one.
]
]In any event, this is all stuff that can be measured, and I propose to
]implement and measure it. Then we can see. I'm not convinced that a
]few percent either way on code size is a showstopper.
Certainly true about code size. Until coreboot starts using gcc link
time optimization, any talk of code size is out of place. By the way,
gcc link time optimization is finally working well. I got it working
with UEFI for x86, ARM, and AARCH64 (though boot testing on real
hardware was limited to x86). Gcc link time optimization should be
simpler to enable on coreboot than UEFI. This is because coreboot
doesn't replace libgcc.a like UEFI does. Here some notes on using
gcc link time optimization with UEFI: http://notabs.org/uefi/gcc-lto.htm.
I abandoned the idea of submitting a UEFI patch due to lack of interest.
Another reason to convert coreboot x86 to 64-bit mode is to avoid
negative comparisons to UEFI by those who don't know better. UEFI x86
uses 32-bit code for the first part of execution and then 64-bit for
the remainder. Some might say "x86 UEFI is 64-bit, why not coreboot?"
A big negative of using 64-bit execution is lack of source code needed
for recompile. What's the chance of getting Intel to support 64-bit
binaries for reference code? Zero, unless the UEFI guys decide to move
reference code execution to 64 bit mode.
I wanted to do an experimental proof of concept port of x86 coreboot to
64 bit mode. I was hoping to switch to 64-bit mode immediately. Running
romstage before the x64 switch is too much like UEFI, in that a whole
lot of execution runs in 32-bit mode.
I chose ASRock E350M1 for the experiment because I have the board and
the reference code is built from source. I did the conversion and got
it working on simnow. But it failed on real hardware. It turns out the
processor (and possibly all AMD processors) can't handle rom-based page
tables. I tried presetting dirty and accessed bits, along with every
MTRR cache setting. Nothing worked. It is possible Intel processors can
use rom based page tables. But I have not bothered to test that because
of lack of needed Intel reference code source.
Someone with some clout needs to request a solution from Intel and AMD.
While 32-bit mode includes built-in identity mapped paging, x64 mode
does not. Why did AMD leave this feature out of the original x64 design?
I imagine rom developers at the time (1999 or 2000) didn't object to its
omission. If AMD and Intel would add this feature, both UEFI and coreboot
could switch to 64-bit mode right out of the reset vector.
I almost scrapped the experiment after finding rom based page tables
couldn't be used. But I did try the next best thing, cache as ram page
tables. This works and the board boots all the way to SeaBIOS. So cache
as ram initialization runs in 32-bit mode as before, but agesa, cimx, and
everything until payload launch runs in x64 mode.
I put the experimental conversion here: http://notabs.org/coreboot/e350m1-x64.7z.
This is not a patch or submission. It is a proof of concept experiment only.
Only ASRock E350M1 builds. Because I am not good with makefiles, I hard-coded
the changes rather than make a 32/64 selection option. I took a lot of short-
cuts because the experiment is only intended to see if anything unexpected
would be encountered. Only features I needed are ported. I did not port
option rom execution for example. There are some inconsistent line endings.
Here is a summary of changes:
Switch compiler code generation from 32-bit to 64-bit. Switch asm code too,
except for cache as ram. Yes, I have some .intel_syntax in there. I have to
write it that way then convert afterwards.
Change GDB_DEBUG flag from -O0 to -Og to support source level debugging
without such a drastic code size increase.
Switch back to 32-bit mode for payload execution.
Add x64 code segment to GDTs and do some 64-bit changes. I skipped the
IDT to save time because it is not essential for this board.
Fix definitions like intptr_t and UINT32 to give the sizes needed for
x64 compile.
flag_is_changeable_p was not ported because it is not needed for this
test.
Fix integer overflow problem in rom_media.c. Not sure if I got it right,
but it is good enough for this test.
Work around some section alignment related problems. I did not use a good
solution because I was in a hurry.
There are a couple of small changes to simplify simnow testing. Those
changes are marked and are not needed when booting on real hardware.
A very few changes were needed in order to get the GDB_DEBUG (-Og) build
to compile. Both the normal and GDB_DEBUG builds boot on real hardware.
A hack was made to agesa ExecuteFinalHltInstruction so that the cache
as ram page tables do not disappear before shadowed to RAM.
Made the AMD NMI handler compatible with -Og debug build.
Increased cache as ram for AP cores from 4 to 8 KB to make room for
cache as ram page tables.
There are lots of 64-bit pointer truncations left. Some work would be
needed in order to run the code about 4GB.
I used 2GB pages to minimize cache as ram usage. Those are left in
place for the whole boot, but could easily be replaced once ram is
initialized.
Builds were done with Windows 7 and win-build-env-015.7z from:
http://sourceforge.net/projects/coreboot-tools-for-windows/
It will most likely build on linux without change.
The archive contains the git files. Hopefully this will make
it easier to diff. The archive also contains the build directory.
Thanks,
Scott
]ron
]
]--
All,
I have been working on porting Coreboot to a new CK804-based K10
mainboard; it warm boots but will not cold boot due to IRQ/MSI
configuration issues.
While tracing the IRQ problem I noticed that the CK804 PCI function
numbers change from the proprietary BIOS to Coreboot:
Proprietary:
-[0000:00]-+-00.0 NVIDIA Corporation CK804 Memory Controller [10de:005e]
+-01.0 NVIDIA Corporation CK804 ISA Bridge [10de:0051]
+-01.1 NVIDIA Corporation CK804 SMBus [10de:0052]
...etc...
Coreboot:
-[0000:00]-+-01.0 NVIDIA Corporation CK804 Memory Controller [10de:005e]
+-02.0 NVIDIA Corporation CK804 ISA Bridge [10de:0051]
+-02.1 NVIDIA Corporation CK804 SMBus [10de:0052]
This, in turn, causes Linux to not detect the CK804 root bridge.
Has anyone else seen this with the CK804 chipset? Is there a magic
register somewhere that configures the CK804 to use the "correct" PCI
function numbers?
The only pertinent quirk of this mainboard is that Asus put the CK804 on
HT link 1, not 0 or 2 as is more common.
Thanks!
--
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645
http://www.raptorengineeringinc.com
Hi all,
Who is the current AMD technical contact? I would like to know whom to ask for
the help with the S3 CAR issue of fam15h.
The CAR teardown routine has wbinvd instead of invd and memory is currupted with
CAR contents during resume from suspend. Replacing WBINVD with INVD does not
work, coreboot will crash during cold boot (perhaps due to unconsistent L2 state).
Thanks
Rudolf
