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
coreboot's memtest86+ payload is buggy compared to memtest86+ floppy
(which could be downloaded from memtest.org and added to CBFS to be
accessible as SeaBIOS menu entry). at AMD Lenovo G505S and maybe some
other coreboot laptops, the USB devices like keyboard are not working
at coreboot's memtest86+ while working fine at all the other payloads
using "libpayload" (i.e. coreinfo or tint) - so it's not a libpayload
problem - and also the same USB keyboards are working at memtest86+
floppy. So it is obvious something is broken at 86+ payload source
code.
Also, with LZMA compression 86+ floppy occupies much less space than
86+ payload. So, aside from academic/research purposes, I do not see
any advantages of 86+ payload compared to 86+ floppy - only
disadvantages: larger size and troubled USB. I've seriously considered
submitting a patch which replaces coreboot's memtest86+ payload with a
floppy (download, compare its' checksum and then insert to CBFS), but
then I thought that maybe someone could need 86+ payload as a coding
example.
If you would like to try out a floppy (e.g. because something else -
like 2GB support - could be also broken at 86+ payload, while working
fine at 86+ floppy booted through SeaBIOS) , here are the
instructions:
1) Download the latest 5.01 version of memtest86+ from memtest86.org :
wget https://www.memtest.org/download/5.01/memtest86+-5.01.floppy.zip
2) Calculate its' sha256 :
sha256sum ./memtest86+-5.01.floppy.zip
should be
2a2d4c1234c9130e1da5fea941ccfbaa343739d5b3302b5f3f9b24077868f8ee
./memtest86+-5.01.floppy.zip
3) If sha256 is correct, unzip ./memtest86+-5.01.floppy.zip . You'll
get a "floppy" directory with these files: ls ./floppy/
dd.exe install64.bat install.bat memtestp.bin rawrite.exe README.txt
You only need memtestp.bin , sha256 of which is "
ddd4a2ba44c312aa4f2c7506a388cc2ca7f1caec60c3c6d80ed8a9f0b43d529c "
4) Size of memtestp.bin file is 150024 bytes. To be understood by
SeaBIOS, it needs to be expanded to 1474560 bytes (by zeroes), which
could be done with this command:
dd if=/dev/zero of=./memtestp.bin bs=1 count=1 seek=1474559 conv=notrunc
sha256 of expanded memtestp.bin file will be "
364535abd0d105da9396df6015e480c4d4c52b07dcc4e1d4756bde8ef87a30f1 "
5) Now it could be added to the compiled coreboot.rom with this command:
./build/cbfstool ./build/coreboot.rom add -f ./floppy/memtestp.bin -n
floppyimg/memtestp.lzma -t raw -c lzma
If done everything correctly, it will be available at SeaBIOS boot
menu as Ramdisk [memtestp]
Best regards,
Mike Banon
On Mon, Nov 5, 2018 at 3:51 PM Krystian Hebel <krystian.hebel(a)3mdeb.com> wrote:
>
>
>
> On 11/05/18 13:32, Paul Menzel wrote:
>
> > Thank you for the patch. If it’s the common problem, then it was > fixed in “coreboot’s” MemTest86+ [1]. Can you reproduce the problem > with that version?
> Yes, it is the version on which I tested. It worked OK before [1], because when no
> coreboot tables were found MemTest86+ resorted to e820.
>
> It was reproduced on PC Engines apu3 (2 GB version) and apu1, the latter requires SPD fix [2].
> 4 GB versions of apu doesn't seem to be affected.
>
> [1]: https://review.coreboot.org/cgit/memtest86plus.git/commit/?id=0704ab381a7...
>
> [2]: https://review.coreboot.org/c/memtest86plus/+/29372
>
> Regards,
>
> Krystian
>
>
> _______________________________________________
> SeaBIOS mailing list
> SeaBIOS(a)seabios.org
> https://mail.coreboot.org/mailman/listinfo/seabios
