Hi all,
Has anybody been able to boot Bayley Bay CRB with the latest coreboot source
from the git tree? We have a Bayley Bay CRB (E3827, B3). With coreboot
Baytrail fsp support pulled from about two weeks ago and some help from
Martin, I was able to see coreboot booting and fsp loaded, but was having
issues with SeaBIOS. I pulled latest source tree this morning and found out
it does not boot any more on my board. Port 80 stuck at code 0x43, no
console output.
Here are my steps:
1. Build coreboot toolchain.
2. Build coreboot.rom using fsp and microcode from BAY_TRAIL_FSP_KIT
downloaded from Intel fsp site.
3. Flash coreboot.rom to top 2M of the 8M flash.
I was getting the usage information here and there from the discussion
threads and perhaps I missed something? It would be great if somebody could
post the detailed procedure.
Thanks!
Wen
Dave,
Dave Frodin wrote:
> An engineer here suggests you set BLDCFG_MEMORY_ALL_CLOCKS_ON TRUE
> in the mainboard buildOpts.c file.
Can you please provide more information.
I think it is incredibly embarrassing that coreboot has code which
requires manually messing with #defines depending on something so
fundamentally dynamic as memory configuration.
What is that about, really?
//Peter
We are testing coreboot with our new IMB-A180 based AGESA design,
and DMA interrupts are not functioning. I am looking into the Coreboot
Options, but is there a recipie for enabling legacy interrupts in AGESA?
We configure in Linux at IRQ 17.
Thanks in advance,
Mark Mason
Engineering Design Team
We have a board that is failing to boot, and we think there is a memory
problem on the board. I have a trace (od -t x4 dump) of the POST codes:
0000000 01 10 10 a0 a1 a1 30 31 34 37 c0 b1 c1 38 39 c4
0000020 71 72 75 76 77 78 79 7b 7a 7c 90 91 91 58 5a 01
0000040 10 10 a0 a1 a1 34 37 c0 c1 38 39 c4 7d 7e 58 5a
0000060 58 58 5b 5b 5c 5d 5e 92 94 95 c5 40 01 0a 46 42
0000100 c6 44 96 97 98 03 02 3e 3f 47 48 49 3d 08 00 00
0000120 40 41 10 50 43 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6
0000140 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6
0000160 d7 d6 d7 d6 d7 d6 d7 41
Using the Sage SmartProbe to perform source-level debugging,
we find that the process is stuck in an infinite loop in this code:
while (CurrNodeOffset != 0) {
CurrNodePtr = (BIOS_BUFFER_NODE *) (BiosHeapBaseAddr +
CurrNodeOffset);
if (CurrNodePtr->BufferHandle == AllocParams->BufferHandle) {
return AGESA_BOUNDS_CHK;
}
CurrNodeOffset = CurrNodePtr->NextNodeOffset;
/* If BufferHandle has not been allocated on the heap,
CurrNodePtr here points
to the end of the allocated nodes list.
*/
}
with CurrNodeOffset == -1 (0xffffffff). The code is from around line 103 in
coreboot/src/northbridge/amd/agesa/family16kb/fam16kb_callouts.c
I plan to continue the source-level debugging to try and track this down,
but as I am new to Coreboot, any guidance you may have to offer would be
much appreciated.
Mark Mason
Engineering Design Team
Paul,
Which commit is the known good commit, and has been regressed?
Thanks,
Wen
Dear Wen,
Am Mittwoch, den 18.06.2014, 13:54 -0400 schrieb Wen Wang:
> Has anybody been able to boot Bayley Bay CRB with the latest coreboot
source
> from the git tree? We have a Bayley Bay CRB (E3827, B3). With coreboot
> Baytrail fsp support pulled from about two weeks ago and some help
> from Martin, I was able to see coreboot booting and fsp loaded, but
> was having issues with SeaBIOS. I pulled latest source tree this
> morning and found out it does not boot any more on my board. Port 80
> stuck at code 0x43, no console output.
could you please bisect the commit [1], which introduced the regression?
[?]
Thanks,
Paul
*******
Hi all,
I have two B3 stepping E3815 processors, one is reporting a PCI device id of 0x0f00 ( as expected ) but another is reporting 0x0000. I can work round that in the BAYTRAIL_FSP CoreBoot build but cannot install Linux, and I'm guessing that having a wonky device id may be involved. Has anyone else seen this and know the work around? I can't see anything about it on the Intel IBL.
Cheers,
Mike.
On 06/13/2014 09:40 AM, Marc Jones wrote:
> Rafael,
>
> i don't think that you can update them once the OS loads. The OS would
> have already made decisions based on the settings.
>
> Marc
>
>
> On Tue, Jun 10, 2014 at 7:41 PM, Rafael Vanoni
> <rafael.vanoni(a)pluribusnetworks.com> wrote:
>> Hi folks, first time posting here. I was wondering if it would be possible
>> to modify smbios values once a system is up and running. Has anyone ever
>> looked into that? If not, any pointers on how to implement this would be
>> greatly appreciated. I'm fairly new to coreboot but would like to look into
>> this.
>>
>> This is with coreboot + seabios, btw.
>>
>> Thanks,
>> Rafael
>>
>>
Hi Marc,
That's true, but my intention is to modify more 'informational' fields
like version, sn, etc. Nothing that would break the OS.
Thanks,
Rafael
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
The fact that my M4A785T-M got unusable with master
pushed me to retest that patch:
23:58 < PaulePanter> GNUtoo-irssi: git fetch
http://review.coreboot.org/coreboot refs/changes/41/4541/1 && git
checkout FETCH_HEAD
So instead of doing a checkout, I did a cherry-pick of the patch on top
of master, and I've attached the log.
I don't remember what happened but we probably deadlocked each other.
What probably happened is that you wrote a mail to the mailing list,
which I didn't respond to because I responded trough IRC.
I probably didn't even see the thread because with my mali setup, the
coreboot mails are now automatically in a coreboot folder, and since I
don't work on it right now, I probably didn't look it up.
M4A785T-M status:
- -----------------
Here is the difference of status since I touched it last time(probably
about one year ago). The new status of the M4A785T-M is on top of a
patched old master.
* The mmconf issues are still there on master
* Ram init got very unstable lately, lately I have freeze once booted,
and before I had difficult boot (sometimes it reseted during the
boot).
* 4G of RAM doesn't work, most probably because of the unstable RAM
init, because it has the same reboot symptom, but way more frequently.
* The sound card now works!
Denis.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBAgAGBQJTm33EAAoJENWQk6o21VqZ0w4P/0usTXDzu0nnmx6th1BakwHX
w3WdudpmYgbIRV5hC9mbax+X0tV3aKcMrbBYVLdgUxCmrLNUr55nxuX+Kku5loIA
5YvCTMtmX4oKLS5FWiP9cMMCNY5mkUAeQT/bNWgqScxizBc1fD2KvLUyB35rP56t
6G7A+4GmmEYYTwk83dJDK4nn8zRvRKkqSuFd4Dt7Ha4OWSI1h/N5PodYILhtNR7C
U62mTYJ7J1n6iD09GDMBuBvo8pBnZ2T8r1QbCc4tw5M+JPRtJQ7CYrBm/tRoDVdT
DgZOpRygnnUVT3VDfoWsKvdU0JtSIxvI0WENYujw439+7nfACeMOV6X9EACPu7Zu
+gF0pN0jsnGxcd7A6wvq+gZ8ojljheKvFRVCYz1M9irezN4iPfuBRI0voMTBTjVP
do0n2hacbqXKznkWXS8OSF032LLF/mONOfG8GFZjXt0a6Esgkfye30UHq1eX4jLp
8cek7XvdC5TnX940zcNPhY4fLySDtYCU4awEnphU27w9JfJsAQWr1snTavFILE+z
J2B7UJ9oRq0i1Sq1Gz6MurqgeGuhXzoPYPRaTbgQTqxKG1IXSQvW8P/yknCX6YJe
eQGjIkRMZoQ9OwvVfNYZ5l2TZvL2XstImXzDzwT/QbVwsibRRErjAHXepj7v/jd3
WPeI3uOQ5r3/JHk/5/e0
=sEXG
-----END PGP SIGNATURE-----