Re: [coreboot] setting smbios values from the OS
Rafael Vanoni wrote: Please explain why you want to modify these values at run time? Like I said in a previous post, I'd like to set fields like version, serial number on a per system basis. That's not the why, that's the what. Indeed you already wrote what you want. I'm asking *why* you want it, because what you ask for doesn't make sense, so either I don't understand your situation (not at all unlikely) or there might be a better approach to get what you want (also possible). This is partially an experiment, fwiw. Again, why modify the values at run time? Why isn't setting these values at build time enough? Kind regards //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] latest baytrail fsp on CRB
As Mike mentioned earlier, you need the TXE ( located in top 6MB ) from BYT-I_SEC_DUAL_BOOT_PV_GOLD. The TXE from the BIOS’s you mentioned don’t work with coreboot. I ran into the same issue as you. Alternatively you can erase the top 6MB to start in non-descriptor mode. I don’t think this matters much for coreboot’s startup process, but could be wrong. Gerald On 19 Jun 2014, at 23:08, Wen Wang wen.w...@adiengineering.com wrote: I went back to the commit (Martin’s commit d75800c7f2476bee243cc22255acb54d6676d4bc back in late May) that seems work for a few people on the list. I also thought it was working better for me too as I was observing coreboot and fsp booting until it failed at SeaBIOS. It turned out I had a pilot error flashing the image. I thought I flashed the top 2M of the flash, but my script accidentally erased the bottom 6M. Surprisingly it booted quite far. Anyhow, after I corrected my script today (flashing only the top 2M, leaving rest from BIOS). Nothing happens, port 80 remains 0, no console output. Here is cbfstool print, my config file is attached to an earlier post, [wenwang@localhost coreboot]$ build/cbfstool build/coreboot.rom print coreboot.rom: 2048 kB, bootblocksize 1024, romsize 2097152, offset 0x0 alignment: 64 bytes Name Offset Type Size cmos_layout.bin0x0cmos_layout 1132 pci8086,0f31.rom 0x4c0 optionrom65536 fallback/romstage 0x10500stage27029 fallback/ramstage 0x16f00stage58966 fallback/payload 0x255c0payload 59949 config 0x34040raw 4239 (empty)0x35100null 896728 cpu_microcode_blob.bin 0x11 microcode52224 (empty)0x11cc40 null 209752 mrc.cache 0x14ffc0 (unknown)65536 (empty)0x16 null 393112 fsp.bin0x1bffc0 (unknown)229376 (empty)0x1f8000 null 31640 Could it be my BIOS issue? I tried both 64 and 32-bit BIOS from 540469_540469_BYT_l_66_41_ReleasePackage and 543844_543844_BYTI_080_011_ReleasePackage. None of them works with my coreboot build. . Can somebody please share the working BIOS version? Thanks, Wen From: Mike Hibbett [mailto:mhibb...@ircona.com] Sent: Wednesday, June 18, 2014 4:58 PM To: Wen Wang; Mike Hibbett; coreboot@coreboot.org Subject: Re: [coreboot] latest baytrail fsp on CRB Use the one that came with your board, or get the latest From the IBL. I forget the document number but the file is called byt-i_sec_dual_boot_pv_gold Mike Sent with AquaMail for Android http://www.aqua-mail.com On 18 June 2014 21:15:51 Wen Wang wen.w...@adiengineering.com wrote: .config file attached. Also what should I do for flash descriptor? Thanks, Wen From: Mike Hibbett [mailto:mhibb...@ircona.com] Sent: Wednesday, June 18, 2014 2:29 PM To: Wen Wang; coreboot@coreboot.org Subject: Re: [coreboot] latest baytrail fsp on CRB Can you post your coreboot .config file? I'm booting bayley bay with a b3 e3815. Mike Sent with AquaMail for Android http://www.aqua-mail.com On 18 June 2014 19:13:49 Wen Wang wen.w...@adiengineering.com wrote: 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] latest baytrail fsp on CRB
PCI ids will be different. Plus some devices may be disabled. On Jun 20, 2014 5:21 PM, Gerald Otter gerald.ot...@gmail.com wrote: As Mike mentioned earlier, you need the TXE ( located in top 6MB ) from BYT-I_SEC_DUAL_BOOT_PV_GOLD. The TXE from the BIOS’s you mentioned don’t work with coreboot. I ran into the same issue as you. Alternatively you can erase the top 6MB to start in non-descriptor mode. I don’t think this matters much for coreboot’s startup process, but could be wrong. Gerald On 19 Jun 2014, at 23:08, Wen Wang wen.w...@adiengineering.com wrote: I went back to the commit (Martin’s commit d75800c7f2476bee243cc22255acb54d6676d4bc back in late May) that seems work for a few people on the list. I also thought it was working better for me too as I was observing coreboot and fsp booting until it failed at SeaBIOS. It turned out I had a pilot error flashing the image. I thought I flashed the top 2M of the flash, but my script accidentally erased the bottom 6M. Surprisingly it booted quite far. Anyhow, after I corrected my script today (flashing only the top 2M, leaving rest from BIOS). Nothing happens, port 80 remains 0, no console output. Here is cbfstool print, my config file is attached to an earlier post, [wenwang@localhost coreboot]$ build/cbfstool build/coreboot.rom print coreboot.rom: 2048 kB, bootblocksize 1024, romsize 2097152, offset 0x0 alignment: 64 bytes Name Offset Type Size cmos_layout.bin0x0cmos_layout 1132 pci8086,0f31.rom 0x4c0 optionrom65536 fallback/romstage 0x10500stage27029 fallback/ramstage 0x16f00stage58966 fallback/payload 0x255c0payload 59949 config 0x34040raw 4239 (empty)0x35100null 896728 cpu_microcode_blob.bin 0x11 microcode52224 (empty)0x11cc40 null 209752 mrc.cache 0x14ffc0 (unknown)65536 (empty)0x16 null 393112 fsp.bin0x1bffc0 (unknown)229376 (empty)0x1f8000 null 31640 Could it be my BIOS issue? I tried both 64 and 32-bit BIOS from 540469_540469_BYT_l_66_41_ReleasePackage and 543844_543844_BYTI_080_011_ReleasePackage. None of them works with my coreboot build. . Can somebody please share the working BIOS version? Thanks, Wen *From:* Mike Hibbett [mailto:mhibb...@ircona.com mhibb...@ircona.com] *Sent:* Wednesday, June 18, 2014 4:58 PM *To:* Wen Wang; Mike Hibbett; coreboot@coreboot.org *Subject:* Re: [coreboot] latest baytrail fsp on CRB Use the one that came with your board, or get the latest From the IBL. I forget the document number but the file is called byt-i_sec_dual_boot_pv_gold Mike Sent with AquaMail for Android http://www.aqua-mail.com On 18 June 2014 21:15:51 Wen Wang wen.w...@adiengineering.com wrote: .config file attached. Also what should I do for flash descriptor? Thanks, Wen *From:* Mike Hibbett [mailto:mhibb...@ircona.com mhibb...@ircona.com] *Sent:* Wednesday, June 18, 2014 2:29 PM *To:* Wen Wang; coreboot@coreboot.org *Subject:* Re: [coreboot] latest baytrail fsp on CRB Can you post your coreboot .config file? I'm booting bayley bay with a b3 e3815. Mike Sent with AquaMail for Android http://www.aqua-mail.com On 18 June 2014 19:13:49 Wen Wang wen.w...@adiengineering.com wrote: 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] latest baytrail fsp on CRB
PCI ids will be different Oh - what do you mean by the Sean? I am still trying to understand why for two identical CPUID/Stepping E3815s, with the same 8BM flash image, I get different PCI device ids for the Soc Transaction Router ( rather than 0f00 ) and Video ( 0031 rather than 0f00 ). Is this related? I’ve asked Intel Premier Support but heard nothing back yet. Still puzzled :o) Mike. From: coreboot [mailto:coreboot-boun...@coreboot.org] On Behalf Of Sean McNeil Sent: 20 June 2014 11:26 To: Gerald Otter Cc: Wen Wang; coreboot Subject: Re: [coreboot] latest baytrail fsp on CRB PCI ids will be different. Plus some devices may be disabled. On Jun 20, 2014 5:21 PM, Gerald Otter gerald.ot...@gmail.commailto:gerald.ot...@gmail.com wrote: As Mike mentioned earlier, you need the TXE ( located in top 6MB ) from BYT-I_SEC_DUAL_BOOT_PV_GOLD. The TXE from the BIOS’s you mentioned don’t work with coreboot. I ran into the same issue as you. Alternatively you can erase the top 6MB to start in non-descriptor mode. I don’t think this matters much for coreboot’s startup process, but could be wrong. Gerald On 19 Jun 2014, at 23:08, Wen Wang wen.w...@adiengineering.commailto:wen.w...@adiengineering.com wrote: I went back to the commit (Martin’s commit d75800c7f2476bee243cc22255acb54d6676d4bc back in late May) that seems work for a few people on the list. I also thought it was working better for me too as I was observing coreboot and fsp booting until it failed at SeaBIOS. It turned out I had a pilot error flashing the image. I thought I flashed the top 2M of the flash, but my script accidentally erased the bottom 6M. Surprisingly it booted quite far. Anyhow, after I corrected my script today (flashing only the top 2M, leaving rest from BIOS). Nothing happens, port 80 remains 0, no console output. Here is cbfstool print, my config file is attached to an earlier post, [wenwang@localhost coreboot]$ build/cbfstool build/coreboot.rom print coreboot.rom: 2048 kB, bootblocksize 1024, romsize 2097152, offset 0x0 alignment: 64 bytes Name Offset Type Size cmos_layout.bin0x0cmos_layout 1132 pci8086,0f31.rom 0x4c0 optionrom65536 fallback/romstage 0x10500stage27029 fallback/ramstage 0x16f00stage58966 fallback/payload 0x255c0payload 59949 config 0x34040raw 4239 (empty)0x35100null 896728 cpu_microcode_blob.bin 0x11 microcode52224 (empty)0x11cc40 null 209752 mrc.cache 0x14ffc0 (unknown)65536 (empty)0x16 null 393112 fsp.bin0x1bffc0 (unknown)229376 (empty)0x1f8000 null 31640 Could it be my BIOS issue? I tried both 64 and 32-bit BIOS from 540469_540469_BYT_l_66_41_ReleasePackage and 543844_543844_BYTI_080_011_ReleasePackage. None of them works with my coreboot build. . Can somebody please share the working BIOS version? Thanks, Wen From: Mike Hibbett [mailto:mhibb...@ircona.com] Sent: Wednesday, June 18, 2014 4:58 PM To: Wen Wang; Mike Hibbett; coreboot@coreboot.orgmailto:coreboot@coreboot.org Subject: Re: [coreboot] latest baytrail fsp on CRB Use the one that came with your board, or get the latest From the IBL. I forget the document number but the file is called byt-i_sec_dual_boot_pv_gold Mike Sent with AquaMail for Android http://www.aqua-mail.comhttp://www.aqua-mail.com/ On 18 June 2014 21:15:51 Wen Wang wen.w...@adiengineering.commailto:wen.w...@adiengineering.com wrote: .config file attached. Also what should I do for flash descriptor? Thanks, Wen From: Mike Hibbett [mailto:mhibb...@ircona.com] Sent: Wednesday, June 18, 2014 2:29 PM To: Wen Wang; coreboot@coreboot.orgmailto:coreboot@coreboot.org Subject: Re: [coreboot] latest baytrail fsp on CRB Can you post your coreboot .config file? I'm booting bayley bay with a b3 e3815. Mike Sent with AquaMail for Android http://www.aqua-mail.comhttp://www.aqua-mail.com/ On 18 June 2014 19:13:49 Wen Wang wen.w...@adiengineering.commailto:wen.w...@adiengineering.com wrote: 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
Re: [coreboot] IMB-A180 based design question regarding POST codes during boot failure
Dave, I was ready to boot your
suggestion and the hardware guys said:
"We know there's no clock", then soon after had it booting
normally.
Good call. This was indeed a debugging session, not a coreboot
issue.
A bit of history. Our design uses a single DIMM, and we got that
running
from earlier posts on this list. Agesa requires that specific
DIMMs
be populated when there are empty DIMM slots, and so the config
files devicetree.cb and buildOpts.c require two changes to allow
a single DIMM to boot.
We also had to find the correct VGA device id from the Series G
SOC
range of 9830-D, but that's done as well. Our 210 parts use 9835
and our 420 parts use 9831. Coreboot comes with 9830, and our
stock IMB-A180 use 9834. It would be nice if this value could be
polled in Coreboot.
Lastly, we found that our legacy DMA interrupts were not working
with
Coreboot. We switched to MSI interrupts and now everyone is
happy.
Thanks for your help!
Mark Mason
Engineering Design Team
I was getting ready to try your suggestions
Mark,
Can you describe your memory SODIMM config?
Are you loading both SODIMMs?
An engineer here suggests you set
BLDCFG_MEMORY_ALL_CLOCKS_ON TRUE
in the mainboard buildOpts.c file.
Thanks,
Dave
On Thu, Jun 19, 2014 at 12:37 PM, Mark
C. Mason m...@edt.com
wrote:
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:
000 01 10 10 a0 a1 a1 30 31 34 37 c0 b1 c1 38 39 c4
020 71 72 75 76 77 78 79 7b 7a 7c 90 91 91 58 5a 01
040 10 10 a0 a1 a1 34 37 c0 c1 38 39 c4 7d 7e 58 5a
060 58 58 5b 5b 5c 5d 5e 92 94 95 c5 40 01 0a 46 42
100 c6 44 96 97 98 03 02 3e 3f 47 48 49 3d 08 00 00
120 40 41 10 50 43 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6
140 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6 d7 d6
160 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 (0x). 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
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] latest baytrail fsp on CRB
hi, i did some experiments with the baytrail fsp coreboot and first of all i like to say thanks for all the good code! everything looks much better than the last time i tried to do anything with coreboot. for the problems - maybe there is something wrong with reading the ids. i found that on my platform it seems like fsp is change mmio base address. so pci reads will not work there after and read all ff. maybe there should be a check which reads back mmio and does some debug log. a example for access to the base address is in setup_mmconfig regards, 2014-06-20 12:33 GMT+02:00 Mike Hibbett mhibb...@ircona.com: PCI ids will be different Oh - what do you mean by the Sean? I am still trying to understand why for two identical CPUID/Stepping E3815s, with the same 8BM flash image, I get different PCI device ids for the Soc Transaction Router ( rather than 0f00 ) and Video ( 0031 rather than 0f00 ). Is this related? I’ve asked Intel Premier Support but heard nothing back yet. Still puzzled :o) Mike. *From:* coreboot [mailto:coreboot-boun...@coreboot.org] *On Behalf Of *Sean McNeil *Sent:* 20 June 2014 11:26 *To:* Gerald Otter *Cc:* Wen Wang; coreboot *Subject:* Re: [coreboot] latest baytrail fsp on CRB PCI ids will be different. Plus some devices may be disabled. On Jun 20, 2014 5:21 PM, Gerald Otter gerald.ot...@gmail.com wrote: As Mike mentioned earlier, you need the TXE ( located in top 6MB ) from BYT-I_SEC_DUAL_BOOT_PV_GOLD. The TXE from the BIOS’s you mentioned don’t work with coreboot. I ran into the same issue as you. Alternatively you can erase the top 6MB to start in non-descriptor mode. I don’t think this matters much for coreboot’s startup process, but could be wrong. Gerald On 19 Jun 2014, at 23:08, Wen Wang wen.w...@adiengineering.com wrote: I went back to the commit (Martin’s commit d75800c7f2476bee243cc22255acb54d6676d4bc back in late May) that seems work for a few people on the list. I also thought it was working better for me too as I was observing coreboot and fsp booting until it failed at SeaBIOS. It turned out I had a pilot error flashing the image. I thought I flashed the top 2M of the flash, but my script accidentally erased the bottom 6M. Surprisingly it booted quite far. Anyhow, after I corrected my script today (flashing only the top 2M, leaving rest from BIOS). Nothing happens, port 80 remains 0, no console output. Here is cbfstool print, my config file is attached to an earlier post, [wenwang@localhost coreboot]$ build/cbfstool build/coreboot.rom print coreboot.rom: 2048 kB, bootblocksize 1024, romsize 2097152, offset 0x0 alignment: 64 bytes Name Offset Type Size cmos_layout.bin0x0cmos_layout 1132 pci8086,0f31.rom 0x4c0 optionrom65536 fallback/romstage 0x10500stage27029 fallback/ramstage 0x16f00stage58966 fallback/payload 0x255c0payload 59949 config 0x34040raw 4239 (empty)0x35100null 896728 cpu_microcode_blob.bin 0x11 microcode52224 (empty)0x11cc40 null 209752 mrc.cache 0x14ffc0 (unknown)65536 (empty)0x16 null 393112 fsp.bin0x1bffc0 (unknown)229376 (empty)0x1f8000 null 31640 Could it be my BIOS issue? I tried both 64 and 32-bit BIOS from 540469_540469_BYT_l_66_41_ReleasePackage and 543844_543844_BYTI_080_011_ReleasePackage. None of them works with my coreboot build. . Can somebody please share the working BIOS version? Thanks, Wen *From:* Mike Hibbett [mailto:mhibb...@ircona.com mhibb...@ircona.com] *Sent:* Wednesday, June 18, 2014 4:58 PM *To:* Wen Wang; Mike Hibbett; coreboot@coreboot.org *Subject:* Re: [coreboot] latest baytrail fsp on CRB Use the one that came with your board, or get the latest From the IBL. I forget the document number but the file is called byt-i_sec_dual_boot_pv_gold Mike Sent with AquaMail for Android http://www.aqua-mail.com On 18 June 2014 21:15:51 Wen Wang wen.w...@adiengineering.com wrote: .config file attached. Also what should I do for flash descriptor? Thanks, Wen *From:* Mike Hibbett [mailto:mhibb...@ircona.com mhibb...@ircona.com] *Sent:* Wednesday, June 18, 2014 2:29 PM *To:* Wen Wang; coreboot@coreboot.org *Subject:* Re: [coreboot] latest baytrail fsp on CRB Can you post your coreboot .config file? I'm booting bayley bay with a b3 e3815. Mike Sent with AquaMail for Android http://www.aqua-mail.com On 18 June 2014 19:13:49 Wen Wang wen.w...@adiengineering.com wrote: Hi all, Has anybody been able to boot Bayley Bay CRB with the latest coreboot
Re: [coreboot] setting smbios values from the OS
On 06/20/2014 01:25 AM, Peter Stuge wrote: Rafael Vanoni wrote: Please explain why you want to modify these values at run time? Like I said in a previous post, I'd like to set fields like version, serial number on a per system basis. That's not the why, that's the what. Indeed you already wrote what you want. I'm asking *why* you want it, because what you ask for doesn't make sense, so either I don't understand your situation (not at all unlikely) or there might be a better approach to get what you want (also possible). This is partially an experiment, fwiw. Again, why modify the values at run time? Why isn't setting these values at build time enough? Kind regards //Peter Take serial number, for example. I'd like each different system that I build to have its own serial number, and building coreboot for every serial number doesn't scale. Thanks, Rafael -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] setting smbios values from the OS
Am 20.06.2014 22:01, schrieb Rafael Vanoni: Take serial number, for example. I'd like each different system that I build to have its own serial number, and building coreboot for every serial number doesn't scale. We have an .id section just below the 16bit entry point - that can (easily) be extended to host more fields, and our smbios table generator could fetch a number from there, overriding a compile time default. To start, see src/arch/x86/lib/id.inc. It's really two tables: one containing the offsets, one containing the data (strings are 0-terminated). Both tables need to be prepended with new fields, since we're in a top-aligned world here. Patches accepted :-) Patrick signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] setting smbios values from the OS
On 20.06.2014 20:08, Patrick Georgi wrote: Am 20.06.2014 22:01, schrieb Rafael Vanoni: Take serial number, for example. I'd like each different system that I build to have its own serial number, and building coreboot for every serial number doesn't scale. We have an .id section just below the 16bit entry point - that can (easily) be extended to host more fields, and our smbios table generator could fetch a number from there, overriding a compile time default. To start, see src/arch/x86/lib/id.inc. It's really two tables: one containing the offsets, one containing the data (strings are 0-terminated). Both tables need to be prepended with new fields, since we're in a top-aligned world here. I think it's more sound to have a CBFS plain-text file with serial numbers and other runtime configs. There is a fair number of board and chipset-specific config that should be modifiable without recompilation but are probably inappropriate for CMOS for various reasons as CMOS size shortage or the need for persistance even across RTC power well failure [aka bad clock battery] (think MAC address). having fixed indexes doesn't scale. Patches accepted :-) Patrick signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] setting smbios values from the OS
Am 20.06.2014 22:40, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: (think MAC address). I guess PC technology is finally beyond requiring those at fixed magic offsets. Some of our chipsets still need it that way. having fixed indexes doesn't scale. Neither do text files. Patrick signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] setting smbios values from the OS
realistically, though, it's hard for me to see how setting the serial # at firmware image build time scales. And setting it after boot makes no real sense either -- it's not really a serial number if you're changing it at that point. But some way to customize the binary images with a serial number seems most workable, if you're going to put the serial number in the firmware image at all (which never made sense to me either --serial #s are supposed to be indelible, and firmware images are not indelible). ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] setting smbios values from the OS
On 20.06.2014 20:43, Patrick Georgi wrote: Am 20.06.2014 22:40, schrieb Vladimir 'φ-coder/phcoder' Serbinenko: (think MAC address). I guess PC technology is finally beyond requiring those at fixed magic offsets. Some of our chipsets still need it that way. having fixed indexes doesn't scale. Neither do text files. I disagree. If you have a file named e.g. config.txt with a syntax like: southbridge/ibexpeak/thermal_correction: 0x1222 one value per line, it perfectly scales. Patrick signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] latest baytrail fsp on CRB
If we figure out why we see the device id of 0x for the SOC
transaction router, I'd really like to understand that. I had initially
thought it was a B0 vs B3 issue, but I've heard from people that it
happens on the B3 silicon as well.
Currently if the device id comes up as 0, the northcluster code won't
get run, and the memory tables won't get generated correctly. A
fix/hack/workaround for this is to add this code to northcluster.c:
static const struct pci_driver nc_driver_b0 __pci_driver = {
.ops = nc_ops,
.vendor = PCI_VENDOR_ID_INTEL,
.device = 0x, // for the B0 Supersku chips
};
This code was written when we thought it was a B0 vs B3 issue, thus the
names and comment.
Martin
On 06/20/2014 04:33 AM, Mike Hibbett wrote:
PCI ids will be different
Oh - what do you mean by the Sean?
I am still trying to understand why for two identical CPUID/Stepping
E3815s, with the same 8BM flash image, I get different PCI device ids
for the Soc Transaction Router ( rather than 0f00 ) and Video (
0031 rather than 0f00 ). Is this related?
I’ve asked Intel Premier Support but heard nothing back yet. Still
puzzled :o)
Mike.
*From:*coreboot [mailto:coreboot-boun...@coreboot.org] *On Behalf Of
*Sean McNeil
*Sent:* 20 June 2014 11:26
*To:* Gerald Otter
*Cc:* Wen Wang; coreboot
*Subject:* Re: [coreboot] latest baytrail fsp on CRB
PCI ids will be different. Plus some devices may be disabled.
On Jun 20, 2014 5:21 PM, Gerald Otter gerald.ot...@gmail.com
mailto:gerald.ot...@gmail.com wrote:
As Mike mentioned earlier, you need the TXE ( located in top 6MB )
from BYT-I_SEC_DUAL_BOOT_PV_GOLD.
The TXE from the BIOS’s you mentioned don’t work with coreboot. I ran
into the same issue as you.
Alternatively you can erase the top 6MB to start in non-descriptor
mode. I don’t think this matters much for coreboot’s startup process,
but could be wrong.
Gerald
On 19 Jun 2014, at 23:08, Wen Wang wen.w...@adiengineering.com
mailto:wen.w...@adiengineering.com wrote:
I went back to the commit (Martin’s commit
d75800c7f2476bee243cc22255acb54d6676d4bc back in late May) that seems
work for a few people on the list. I also thought it was working
better for me too as I was observing coreboot and fsp booting until it
failed at SeaBIOS. It turned out I had a pilot error flashing the
image. I thought I flashed the top 2M of the flash, but my script
accidentally erased the bottom 6M. Surprisingly it booted quite far.
Anyhow, after I corrected my script today (flashing only the top 2M,
leaving rest from BIOS). Nothing happens, port 80 remains 0, no
console output. Here is cbfstool print, my config file is attached to
an earlier post,
[wenwang@localhost coreboot]$ build/cbfstool build/coreboot.rom print
coreboot.rom: 2048 kB, bootblocksize 1024, romsize 2097152, offset 0x0
alignment: 64 bytes
Name Offset Type Size
cmos_layout.bin 0x0 cmos_layout 1132
pci8086,0f31.rom 0x4c0 optionrom 65536
fallback/romstage 0x10500 stage 27029
fallback/ramstage 0x16f00 stage 58966
fallback/payload 0x255c0 payload 59949
config 0x34040 raw 4239
(empty) 0x35100 null 896728
cpu_microcode_blob.bin 0x11 microcode 52224
(empty) 0x11cc40 null 209752
mrc.cache 0x14ffc0 (unknown) 65536
(empty) 0x16 null 393112
fsp.bin 0x1bffc0 (unknown) 229376
(empty) 0x1f8000 null 31640
Could it be my BIOS issue? I tried both 64 and 32-bit BIOS from
540469_540469_BYT_l_66_41_ReleasePackage and
543844_543844_BYTI_080_011_ReleasePackage. None of them works with my
coreboot build. . Can somebody please share the working BIOS version?
Thanks,
Wen
*From:*Mike Hibbett [mailto:mhibb...@ircona.com]
*Sent:* Wednesday, June 18, 2014 4:58 PM
*To:* Wen Wang; Mike Hibbett; coreboot@coreboot.org
mailto:coreboot@coreboot.org
*Subject:* Re: [coreboot] latest baytrail fsp on CRB
Use the one that came with your board, or get the latest From the IBL.
I forget the document number but the file is called
byt-i_sec_dual_boot_pv_gold
Mike
Sent with AquaMail for Android
http://www.aqua-mail.com http://www.aqua-mail.com/
On 18 June 2014 21:15:51 Wen Wang wen.w...@adiengineering.com
mailto:wen.w...@adiengineering.com wrote:
.config file attached.
Also what should I do for flash descriptor?
Thanks,
Wen
*From:*Mike Hibbett [mailto:mhibb...@ircona.com]
*Sent:* Wednesday, June 18, 2014 2:29 PM
*To:* Wen Wang; coreboot@coreboot.org mailto:coreboot@coreboot.org
*Subject:* Re: [coreboot] latest baytrail fsp on CRB
Can you post your coreboot .config file?
I'm booting bayley bay with a b3 e3815.
Mike
Sent with AquaMail for Android
http://www.aqua-mail.com http://www.aqua-mail.com/
On 18 June 2014 19:13:49 Wen Wang wen.w...@adiengineering.com
mailto:wen.w...@adiengineering.com wrote:
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,
Re: [coreboot] latest baytrail fsp on CRB
Hi, I'm getting ready to push some code that better aligns things between the Kconfig option and the FSP for the MMIO configuration area. It shouldn't be a problem after that. Martin On 06/20/2014 01:17 PM, Karl-Heinz Nirschl wrote: hi, i did some experiments with the baytrail fsp coreboot and first of all i like to say thanks for all the good code! everything looks much better than the last time i tried to do anything with coreboot. for the problems - maybe there is something wrong with reading the ids. i found that on my platform it seems like fsp is change mmio base address. so pci reads will not work there after and read all ff. maybe there should be a check which reads back mmio and does some debug log. a example for access to the base address is in setup_mmconfig regards, 2014-06-20 12:33 GMT+02:00 Mike Hibbett mhibb...@ircona.com mailto:mhibb...@ircona.com: PCI ids will be different Oh - what do you mean by the Sean? I am still trying to understand why for two identical CPUID/Stepping E3815s, with the same 8BM flash image, I get different PCI device ids for the Soc Transaction Router ( rather than 0f00 ) and Video ( 0031 rather than 0f00 ). Is this related? I’ve asked Intel Premier Support but heard nothing back yet. Still puzzled :o) Mike. *From:*coreboot [mailto:coreboot-boun...@coreboot.org mailto:coreboot-boun...@coreboot.org] *On Behalf Of *Sean McNeil *Sent:* 20 June 2014 11:26 *To:* Gerald Otter *Cc:* Wen Wang; coreboot *Subject:* Re: [coreboot] latest baytrail fsp on CRB PCI ids will be different. Plus some devices may be disabled. On Jun 20, 2014 5:21 PM, Gerald Otter gerald.ot...@gmail.com mailto:gerald.ot...@gmail.com wrote: As Mike mentioned earlier, you need the TXE ( located in top 6MB ) from BYT-I_SEC_DUAL_BOOT_PV_GOLD. The TXE from the BIOS’s you mentioned don’t work with coreboot. I ran into the same issue as you. Alternatively you can erase the top 6MB to start in non-descriptor mode. I don’t think this matters much for coreboot’s startup process, but could be wrong. Gerald On 19 Jun 2014, at 23:08, Wen Wang wen.w...@adiengineering.com mailto:wen.w...@adiengineering.com wrote: I went back to the commit (Martin’s commit d75800c7f2476bee243cc22255acb54d6676d4bc back in late May) that seems work for a few people on the list. I also thought it was working better for me too as I was observing coreboot and fsp booting until it failed at SeaBIOS. It turned out I had a pilot error flashing the image. I thought I flashed the top 2M of the flash, but my script accidentally erased the bottom 6M. Surprisingly it booted quite far. Anyhow, after I corrected my script today (flashing only the top 2M, leaving rest from BIOS). Nothing happens, port 80 remains 0, no console output. Here is cbfstool print, my config file is attached to an earlier post, [wenwang@localhost coreboot]$ build/cbfstool build/coreboot.rom print coreboot.rom: 2048 kB, bootblocksize 1024, romsize 2097152, offset 0x0 alignment: 64 bytes Name Offset Type Size cmos_layout.bin 0x0 cmos_layout 1132 pci8086,0f31.rom 0x4c0 optionrom 65536 fallback/romstage 0x10500 stage 27029 fallback/ramstage 0x16f00 stage 58966 fallback/payload 0x255c0 payload 59949 config 0x34040 raw 4239 (empty) 0x35100 null 896728 cpu_microcode_blob.bin 0x11 microcode 52224 (empty) 0x11cc40 null 209752 mrc.cache 0x14ffc0 (unknown) 65536 (empty) 0x16 null 393112 fsp.bin 0x1bffc0 (unknown) 229376 (empty) 0x1f8000 null 31640 Could it be my BIOS issue? I tried both 64 and 32-bit BIOS from 540469_540469_BYT_l_66_41_ReleasePackage and 543844_543844_BYTI_080_011_ReleasePackage. None of them works with my coreboot build. . Can somebody please share the working BIOS version? Thanks, Wen *From:*Mike Hibbett [mailto:mhibb...@ircona.com] *Sent:* Wednesday, June 18, 2014 4:58 PM *To:* Wen Wang; Mike Hibbett; coreboot@coreboot.org mailto:coreboot@coreboot.org *Subject:* Re: [coreboot] latest baytrail fsp on CRB Use the one that came with your board, or get the latest From the IBL. I forget the document number but the file is called byt-i_sec_dual_boot_pv_gold Mike Sent with AquaMail for Android http://www.aqua-mail.com http://www.aqua-mail.com/ On 18 June 2014 21:15:51 Wen Wang wen.w...@adiengineering.com mailto:wen.w...@adiengineering.com wrote: .config file attached. Also what should I do for flash descriptor? Thanks, Wen *From:*Mike Hibbett [mailto:mhibb...@ircona.com] *Sent:* Wednesday, June 18, 2014 2:29 PM *To:* Wen Wang; coreboot@coreboot.org mailto:coreboot@coreboot.org *Subject:* Re: [coreboot] latest
[coreboot] Migrating to a free BIOS
Dear Sir I would like to migrate my PC to a free BIOS. Do I have to replace the motherboard, please? Thanks Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] setting smbios values from the OS
ron minnich [mailto:rminn...@gmail.com] wrote: ]realistically, though, it's hard for me to see how setting the ]serial # at firmware image build time scales. And setting it after ]boot makes no real sense either -- it's not really a serial number ]if you're changing it at that point. ]But some way to customize the binary images with a serial number ]seems most workable, if you're going to put the serial number in ]the firmware image at all (which never made sense to me either ]--serial #s are supposed to be indelible, and firmware images are ]not indelible). ] ]ron Putting the serial number in the same flash chip as the main firmware is a cost reduction measure used with desktop and other low cost boards. I have even seen a board where the MAC address lives there. The only protection for those items is that the flash utility given to the end user knows to skip that area. The way I have seen the serial number programmed is at manufacturing diagnostics time. The board is PXE booted to a diagnostic image. The image runs a script that first erases the entire flash chip. It then programs it with the OEM firmware image. The OEM image contains a blank serial number. The script then prompts for operator input. The operator pulls a barcoded serial number label from a roll and attaches it to the board. The operator then scans the label with a barcode reader. The script uses the barcode data to find the serial number in a database. The script then runs a special flash utility that reprograms only the serial number portion of the flash chip. If the end user flashes the firmware by any method other than the supplied utility, the serial number will be lost. It can still be read from the barcoded label though. Thanks, Scott -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
