Hello Zvika,
> How can it find [VBIOS] in the vendor's bin file ?
It really depends on the type of vendor's BIOS because they could be
packed differently. For example, if your vendor's BIOS is Inside then
you can use Inside H2OEZE utility (sadly its' Windows-only and not
available officially, but you could find it if really want). But
please keep in mind that your vendor's BIOS might be patching that
VBIOS during booting, if that is indeed so - then a "clean" unpatched
VBIOS extracted with this method, either will not work at all or work
with errors. So it is always recommended to extract VBIOS from a
running system, just in case. Usually these instructions are working -
https://www.coreboot.org/VGA_support#How_to_retrieve_a_good_video_bios
, see "Retrieval via Linux kernel" part. But if that's not working at
your system and you've tried everything else, here is a great
alternative method -
https://mail.coreboot.org/pipermail/coreboot/2017-July/084660.html
Best regards,
Mike Banon
On Tue, Nov 6, 2018 at 10:18 PM Zvi Vered <veredz72(a)gmail.com> wrote:
>
> Hello,
>
> Currently I'm replacing the BIOS in the vendor's bin file with coreboot.bin
> Can coreboot use Vendor's VBIOS instead of the serial console ?
> How can it find it in the vendor's bin file ?
>
> Thank you,
> Zvika
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
Hi coreboot fellows,
I have always been confused that we have the option to use FSP's
TempRamInit (CAR setup) even when a native coreboot implementation is
available. Now, what I'm really concerned about is the low quality of
the code in coreboot surrounding it. There are often Kconfig prompts
that don't add up, and about every related, merged commit I've been
looking at today seemed somehow flawed.
So if we can't keep the quality we are used to when trying to maintain
two (or even more) CAR options, why not focus on a single one? After
all, coreboot is a firmware framework, not an FSP testing framework.
Here's just one weird example of what I was confronted with today:
default USE_CANNONLAKE_CAR_NEM_ENHANCED if
MAINBOARD_HAS_CHROMEOS
I don't understand it, but somehow feel offended. Does that mean I have
to work with ChromeOS now to get reasonable defaults?
Nico
Ok, there is no spd on the board. Four memory chips are soldered on the board (Micron DDR3L 4х512MB 1333Mhz). I understand that I need to set the correct memory parameters in the fsp configurator. Even if it works, replacing the memory chips may lead to a stop working of the coreboot.rom. It is necessary to change the parameters of the fsp again and rebuild coreboot.rom.
How does the proprietary BIOS (TianoCore) work in case of replacing the memory chips on board?
Are there universal parameters for this memory types and what should I take note for when configuring FSP?
From: R S
Sent: Tuesday, November 06, 2018 8:30 PM
To: alexfeinman(a)hotmail.com
Cc: coreboot(a)coreboot.org ; alexey_bau(a)mail.ru
Subject: Re: [coreboot] How to get correct memory params for FSP
Faint memories... are you the ISO recorder author from 15 years ago?
On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman <alexfeinman(a)hotmail.com> wrote:
The two major issues with bringing up the memory subsystem on a new board are SPD parameters and DQ/DQS layout
Specifically, if you look at the apollolake rvp subtree, you can see a whole bunch of parameters being set in romstage.c. Some of it is fairly straightforward. Swizzling tables are not and require you to be able to read schematic (and have access to it in the first place)
Obviously, the problem could be elsewhere. I would start with enabling MRC debug and perhaps posting the MRC output
------------------------------------------------------------------------------
From: coreboot <coreboot-bounces(a)coreboot.org> on behalf of Alexey Borovikov via coreboot <coreboot(a)coreboot.org>
Sent: Saturday, November 3, 2018 5:38 AM
To: coreboot(a)coreboot.org
Subject: [coreboot] How to get correct memory params for FSP
Hi.
I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP for the Baytrail family. The result - postcode is 0x2A. From the descriptions on the Internet, I understand that the problem is in the incorrect memory parameters.
Question: are there any utilities or methods that will help to get the correct memory parameters when working a regular BIOS from Linux or Windows systems?
Many thanks!
--
coreboot mailing list: coreboot(a)coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
--
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign
Hello,
Currently I'm replacing the BIOS in the vendor's bin file with coreboot.bin
Can coreboot use Vendor's VBIOS instead of the serial console ?
How can it find it in the vendor's bin file ?
Thank you,
Zvika
Thanks for it after all those years.
// end being off-topic
On Tue, Nov 6, 2018 at 12:45 PM Alex Feinman <alexfeinman(a)hotmail.com>
wrote:
> Guilty as charged :)
>
> ------------------------------
> *From:* R S <rene.shuster(a)bcsemail.org>
> *Sent:* Tuesday, November 6, 2018 9:30 AM
> *To:* alexfeinman(a)hotmail.com
> *Cc:* coreboot(a)coreboot.org; alexey_bau(a)mail.ru
> *Subject:* Re: [coreboot] How to get correct memory params for FSP
>
> Faint memories... are you the ISO recorder author from 15 years ago?
>
> On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman <alexfeinman(a)hotmail.com>
> wrote:
>
> The two major issues with bringing up the memory subsystem on a new board
> are SPD parameters and DQ/DQS layout
> Specifically, if you look at the apollolake rvp subtree, you can see a
> whole bunch of parameters being set in romstage.c. Some of it is fairly
> straightforward. Swizzling tables are not and require you to be able to
> read schematic (and have access to it in the first place)
> Obviously, the problem could be elsewhere. I would start with enabling MRC
> debug and perhaps posting the MRC output
>
> ------------------------------
> *From:* coreboot <coreboot-bounces(a)coreboot.org> on behalf of Alexey
> Borovikov via coreboot <coreboot(a)coreboot.org>
> *Sent:* Saturday, November 3, 2018 5:38 AM
> *To:* coreboot(a)coreboot.org
> *Subject:* [coreboot] How to get correct memory params for FSP
>
> Hi.
> I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP
> for the Baytrail family. The result - postcode is 0x2A. From the
> descriptions on the Internet, I understand that the problem is in the
> incorrect memory parameters.
> Question: are there any utilities or methods that will help to get the
> correct memory parameters when working a regular BIOS from Linux or Windows
> systems?
> Many thanks!
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
>
> --
> Tech III * AppControl * Endpoint Protection * Server Maintenance
> Buncombe County Schools Technology Department Network Group
> ComicSans Awareness Campaign <http://comicsanscriminal.com>
>
--
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign <http://comicsanscriminal.com>
Guilty as charged :)
________________________________
From: R S <rene.shuster(a)bcsemail.org>
Sent: Tuesday, November 6, 2018 9:30 AM
To: alexfeinman(a)hotmail.com
Cc: coreboot(a)coreboot.org; alexey_bau(a)mail.ru
Subject: Re: [coreboot] How to get correct memory params for FSP
Faint memories... are you the ISO recorder author from 15 years ago?
On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman <alexfeinman(a)hotmail.com<mailto:alexfeinman@hotmail.com>> wrote:
The two major issues with bringing up the memory subsystem on a new board are SPD parameters and DQ/DQS layout
Specifically, if you look at the apollolake rvp subtree, you can see a whole bunch of parameters being set in romstage.c. Some of it is fairly straightforward. Swizzling tables are not and require you to be able to read schematic (and have access to it in the first place)
Obviously, the problem could be elsewhere. I would start with enabling MRC debug and perhaps posting the MRC output
________________________________
From: coreboot <coreboot-bounces(a)coreboot.org<mailto:coreboot-bounces@coreboot.org>> on behalf of Alexey Borovikov via coreboot <coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>>
Sent: Saturday, November 3, 2018 5:38 AM
To: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>
Subject: [coreboot] How to get correct memory params for FSP
Hi.
I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP for the Baytrail family. The result - postcode is 0x2A. From the descriptions on the Internet, I understand that the problem is in the incorrect memory parameters.
Question: are there any utilities or methods that will help to get the correct memory parameters when working a regular BIOS from Linux or Windows systems?
Many thanks!
--
coreboot mailing list: coreboot(a)coreboot.org<mailto:coreboot@coreboot.org>
https://mail.coreboot.org/mailman/listinfo/coreboot
--
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign<http://comicsanscriminal.com>
Faint memories... are you the ISO recorder author from 15 years ago?
On Tue, Nov 6, 2018 at 12:23 PM Alex Feinman <alexfeinman(a)hotmail.com>
wrote:
> The two major issues with bringing up the memory subsystem on a new board
> are SPD parameters and DQ/DQS layout
> Specifically, if you look at the apollolake rvp subtree, you can see a
> whole bunch of parameters being set in romstage.c. Some of it is fairly
> straightforward. Swizzling tables are not and require you to be able to
> read schematic (and have access to it in the first place)
> Obviously, the problem could be elsewhere. I would start with enabling MRC
> debug and perhaps posting the MRC output
>
> ------------------------------
> *From:* coreboot <coreboot-bounces(a)coreboot.org> on behalf of Alexey
> Borovikov via coreboot <coreboot(a)coreboot.org>
> *Sent:* Saturday, November 3, 2018 5:38 AM
> *To:* coreboot(a)coreboot.org
> *Subject:* [coreboot] How to get correct memory params for FSP
>
> Hi.
> I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP
> for the Baytrail family. The result - postcode is 0x2A. From the
> descriptions on the Internet, I understand that the problem is in the
> incorrect memory parameters.
> Question: are there any utilities or methods that will help to get the
> correct memory parameters when working a regular BIOS from Linux or Windows
> systems?
> Many thanks!
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
--
Tech III * AppControl * Endpoint Protection * Server Maintenance
Buncombe County Schools Technology Department Network Group
ComicSans Awareness Campaign <http://comicsanscriminal.com>
Hi.
I port the Coreboot to a board with an SOC Intel Atom E3845 and use FSP for the Baytrail family. The result - postcode is 0x2A. From the descriptions on the Internet, I understand that the problem is in the incorrect memory parameters.
Question: are there any utilities or methods that will help to get the correct memory parameters when working a regular BIOS from Linux or Windows systems?
Many thanks!
yanvasilij yan wrote:
> I have two Intel Atom E3800 based boards. The first one is older version,
> which woks properly,
..
> The second one is modernized version, we added 89HPES5T5 PCIe I/O
> expansion switch. And WGI210IT based Ethernet ports are connected
> to switch.
So the good news is that your log clearly shows the PCIe switch
working correctly and both NICs behind reachable by software.
> Further we rebuild a bit a power up circuit of the E3800 SOC.
This is quite possibly the root cause, but I wouldn't exclude any
other possibilities.
> Launching stops when starts payload loading. The launch log of this board
> see in attached “not_working_board_log.txt”.
The log is very clear about why: (down near the end)
--8<--
SELF segment doesn't target RAM: 0x00800000, 4259840 bytes
-->8--
Looking at the coreboot table a little further up, we see:
--8<--
Writing coreboot table at 0x3add3000
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000e00000-0000000000e39fff: RAMSTAGE
2. 000000003ad9e000-000000003adfffff: CONFIGURATION TABLES
3. 00000000feb00000-00000000fec00fff: RESERVED
4. 00000000fed01000-00000000fed01fff: RESERVED
5. 00000000fed03000-00000000fed03fff: RESERVED
6. 00000000fed05000-00000000fed05fff: RESERVED
7. 00000000fed08000-00000000fed08fff: RESERVED
8. 00000000fed0c000-00000000fed0ffff: RESERVED
9. 00000000fed1c000-00000000fed1cfff: RESERVED
10. 00000000fef00000-00000000feffffff: RESERVED
-->8--
Compare that with your working board:
--8<--
Writing coreboot table at 0x3add3000
0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES
1. 0000000000001000-000000000009ffff: RAM
2. 00000000000a0000-00000000000fffff: RESERVED
3. 0000000000100000-0000000000dfffff: RAM
4. 0000000000e00000-0000000000e39fff: RAMSTAGE
5. 0000000000e3a000-000000003ad9dfff: RAM
6. 000000003ad9e000-000000003adfffff: CONFIGURATION TABLES
7. 000000003ae00000-000000003fffffff: RESERVED
8. 00000000e0000000-00000000efffffff: RESERVED
9. 00000000feb00000-00000000fec00fff: RESERVED
10. 00000000fed01000-00000000fed01fff: RESERVED
11. 00000000fed03000-00000000fed03fff: RESERVED
12. 00000000fed05000-00000000fed05fff: RESERVED
13. 00000000fed08000-00000000fed08fff: RESERVED
14. 00000000fed0c000-00000000fed0ffff: RESERVED
15. 00000000fed1c000-00000000fed1cfff: RESERVED
16. 00000000fee00000-00000000fee00fff: RESERVED
17. 00000000fef00000-00000000feffffff: RESERVED
-->8--
The new board ends up with no RAM regions in the coreboot table.
That results in the payload loader not finding RAM where the payload is
to be loaded, so boot stops.
Why are there no RAM regions? I don't know.
Looking near the beginning of the log about FSP memory init:
--8<--
Memory Down Data Existed : Enabled
- Speed (0: 800, 1: 1066, 2: 1333, 3: 1600): 1
- Type (0: DDR3, 1: DDR3L) : 1
- DIMM0 : Enabled
- DIMM1 : Disabled
- Width : x16
- Density : 2Gbit
- BudWidth : 64bit
- Rank # : 1
- tCL : 0B
- tRPtRCD : 0B
- tWR : 0C
- tWTR : 06
- tRRD : 06
- tRTP : 06
- tFAW : 14
Using 1066 MHz DDR3 settings.
1 GB Minnowboard Max detected.
romstage_main_continue status: 0 hob_list_ptr: 3ae20000
FSP Status: 0x0
PM1_STS = 0x1 PM1_CNT = 0x0 GEN_PMCON1 = 0x1001808
romstage_main_continue: prev_sleep_state = S0
Baytrail Chip Variant: Bay Trail-I (ISG/embedded)
MRC v0.102
1 channels of DDR3 @ 1066MHz
-->8--
It appears OK - but do check that those numbers actually match the
DRAM chips assembled on the board. Are DRAM parts identical between
old and new?
Were there *any* hardware changes between SoC and RAM?
That's worth checking, but..
> nico_h in the IRC chat noticed that in non-working board appears a starnge
> device with vid/did PCI: 00:00.0 [8086/0000].
The 0000 is a HUGE red sign, screaming to be thoroughly investigated.
This also hints that the power up changes may be the problem.
It's VERY unlikely that Intel has suddenly released a variant of this
particular SoC with PCI DID=0000 when it used to be DID=0f00. In fact
it's really unlikely that 0000 would be used in correct operation at all.
Very likely on the other hand is that the SoC isn't being powered on
correctly, and so it ends up in some half-initialized state, with the
memory controller not working, and while some part of coreboot seems
to notice (because no RAM regions in coreboot table) clearly that
isn't causing a fatal error, which I think is a bug. Oh well.
If you go through every single powerup hardware change together with
a hardware engineer, starting with the previous circuit and manually
applying one change at a time, maybe you can find one or even more
changes causing that device ID symptom. It depends on how many changes
you have there, but with a good hardware engineer you could perhaps go
through them all in a couple days, which would be really fast results
for a problem like this.
Maybe even simpler, hack this into some early part of the code, maybe
even console_init() works, if pci_early is available there.
while (1)
if (0x0f00 == pci_read_config32(PCI_DEV(0,0,0), PCI_VENDORID))
printk(BIOS_INFO, "PASS\n");
else
printk(BIOS_INFO, "FAIL: want 0f00 is %04x\n", pci_read_config32(PCI_DEV(0,0,0), PCI_VENDORID));
Then hardware engineering can do analysis on their own. But make sure
to confirm that your test is reliable, using the hardware you have
(old and new) before you give a flash image to them.
Oh, and test on multiple new boards, a single unit in a new batch isn't
representative. New PCB; potentially the process has to be tuned. I don't
know how early in bringup you are.
Good luck and have fun! :)
//Peter
