Re: [coreboot] Update on G505S (dGPU init success)

[Mike Banon]

Dear HJK,

My sincere huge congratulations to you for your incredible
breakthrough! :-) As you could see from
http://mail.coreboot.org/pipermail/coreboot/2018-November/087679.html
- I got stuck after loading both iGPU and dGPU OpROMs at kernel panic
and thought its' only because of a broken PCI config. But after
reading your good experience, it seems there were some other problems
as well which you've successfully solved. Please could you clarify
some details :
1)
> I modified the IO address & the PCI device ID in APU GPU VBIOS file (even 
> though IO address change to 0x3000 might not required).
> I modified the IO address in the dGPU VBIOS files to the actual CB - linux 
> kernel provided (0x1000) address
1a) Please confirm that you've modified the IO addresses as following:
APU iGPU (integrated GPU) = 0x3000
dGPU (discrete GPU) = 0x1000
1b) Why these exact "IO address" values? How you came up with them,
and why not any different addresses?
1c) At what address offsets (in relation to the beginnings of VBIOS
files) these "IO address" values are situated?
1d) To what value you've changed the PCI device ID in APU iGPU VBIOS,
and why this change is necessary?
2)
> I had to add my SPI chip driver for EN25QH32=0x7016 to CB
Why it was needed? My G505S also has this EN25QH32 chip and I never
had to add any SPI chip drivers - this chip always "just worked" at
coreboot. If this is indeed required (e.g. for the successful graphics
initialization), where to get this SPI chip driver and how to add it?
3)
> I enabled pci 00:02.0 for dGPU in devicetree.cb → according to the CB logs 
> this causes pci resource allocation problems
Do you still have any part of this log, for the reference? I don't
remember any resource allocation problems in 8 level CB logs
4)
> I modified pci_device.c, function pci_dev_init to only enable pci_rom_probe 
> and pci_rom load for the dGPU pci device (no oprom exec needed for 
> PCI_CLASS_DISPLAY_OTHER)
Why OpROM exec is not needed for dGPU device? And what would happen if
I will execute it there? (would it break the things, or just no
difference)
5)
> I modified pci_rom.c, so the VBIOS of the dGPU is copied to 0xd from CBFS 
> (..check_initialized..)
Why this specific 0xd address has been selected? Or it has been
automatically chosen by coreboot when it wanted to load this OpROM to
dGPU ?
6)
> and pci_rom_write_acpi_tables only run for PCI_CLASS_DEVICE_OTHER → dGPU 
> (ACPI VFCT fill is done from the previously prepared 
> 0xd=PCI_RAM_IMAGE_START address)
Why this should be done for dGPU only? (not for APU iGPU or any other devices)

7) I would like to refine your "hacks" and commit them to coreboot,
while giving a full credit to you of course. But, if I would start
doing it from scratch according to your instructions, there is always
a chance that I'd misunderstand or forget something (or you forgot to
mention some small but important technicality) and as result my
attempt to reproduce your success could be problematic. It would be
ideal if you could share:
A*) your successful coreboot.rom (I'd like to check its' PCI state out
of curiosity)
B*) your coreboot's .config file for the reference purposes
C*) upload your whole coreboot directory to some convenient place,
either to GitHub or just archive it as .tar.gz (maybe as a multipart
archive if it ends up too big) and upload it to some hosting website;
or maybe even create a .torrent out of it and host it temporarily -
whatever is most convenient to you.

Hopefully you could share this stuff and I will be able to reproduce
your results, initially "AS-IS" - but then I will try my best to
refine it to the acceptable code quality (so that it could be
officially accepted to coreboot) while checking from time to time if
it is still working after my gradual changes. Hope to hear any news
from you soon

Best regards,
Mike Banon
On Sat, Nov 3, 2018 at 8:42 PM Hans Jürgen Kitter
 wrote:
>
>  Hi All,
>
> I thought that I share with the G505S+Coreboot (+QubesOS) users that I 
> finally managed to enable and use the dGPUs on the G505S boards.  When 
> mentioning boards, I mean, that both variants  with its respective VBIOSes: 
> dGPU=1002,6663 (ATI HD 8570M, Sun-Pro) and the dGPU=1002,6665 (ATI R5 M230, 
> Jet-Pro) are working under Ubuntu Linux or Qubes 4.0 (no Windows testing was 
> done or planned).
> DRI_PRIME=1 seem to work, I use the radeon driver for the APU GPU (A10-5750m) 
> and amdgpu for the dGPU. I'm currently investigating how to get the most out 
> of this setup in Qubes (HW accel 2D in AppVMs).
>
> Problem statement: the dGPU was not initiated correctly and was not enabled 
> by the radeon or amdgpu kernel module, VFCT header was corrupt/truncated 
> (effectively was not corrupt, but only VFCT for the APU/iGPU was present). 
> Trying to init the dGPU device through Oprom initialization failed all my 
> attempts (radeon :04:00.0: Invalid PCI ROM header signature: expecting 
> 0xaa55, got 0x). This was true whether using

Re: [coreboot] Update on G505S (dGPU init success)

[awokd via coreboot]

Hans Jürgen Kitter:

  Hi All,

I thought that I share with the G505S+Coreboot (+QubesOS) users that I
finally managed to enable and use the dGPUs on the G505S boards.
Nice hacking! I know Mike Banon was working with some others on this 
too, hopefully you were able to compare notes. Any benefits to G505s 
owners who don't have the secondary GPU?


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Status Update of F2A85M

[Mike Banon]

Have you tried any Linux distributions other than Debian? Because
Debian's packages and Linux kernel - are relatively ancient, and maybe
the problems you're having - have been fixed in the recent kernel
versions (although they could have broken something else there ;) .
Please try a very modern Linux distribution, like Antergos
(newbie-friendly Arch Linux with GUI), Artix Linux (friendly Arch
without systemd), or maybe a fully updated Void Linux (really clean
and ultra fast Linux, also no systemd). Maybe some of your current
problems wouldn't exist there, it might be a good idea to try ;)
On Sat, Nov 3, 2018 at 2:37 AM Kinky Nekoboi
 wrote:
>
> i have tried it, microcode is now updated, but this does not help with
> linux not wants to boot with iommu enabled
>
>
> Am 02.11.2018 um 21:29 schrieb Mike Banon:
> > For our Richland 15h family AMD CPUs (and for 16h also) , this
> > microcode update procedure - accessible from coreboot's configuration
> > "menuconfig" menu - is broken, I've observed this 0K problem too. You
> > should leave this "Include CPU microcode in CBFS" option as "Do not
> > include microcode updates" and just run a script from this wiki -
> > http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#AMD_microcode_updates
> > - it will patch the AMD microcodes hardcoded inside .c source code
> > files as the arrays of hex values. After you'll patch your coreboot,
> > rebuild it and install to your motherboard, your microcode's patch
> > level should change from 0x0600110f to 0x0600111f (0f->1f)
> >
> > Best regards,
> > Mike Banon
> > On Fri, Nov 2, 2018 at 10:51 PM kinky_nekoboi
> >  wrote:
> >> I tried only the one included in current master tree.
> >>
> >> But CBFS reports me an 0KB blob as an output ... so that its mostlikele
> >> the reason it halts after boot (maybe updating an not working microcode
> >> to the cpu than ?)
> >>
> >> i have microcodes enabled per linux kernel update
> >> dmesg | grep microcode:
> >> [3.794585] microcode: CPU0: patch_level=0x0600110f
> >> [3.794588] microcode: CPU1: patch_level=0x0600110f
> >> [3.794595] microcode: CPU2: patch_level=0x0600110f
> >> [3.794602] microcode: CPU3: patch_level=0x0600110f
> >> [3.794653] microcode: Microcode Update Driver: v2.2.
> >>
> >> Am 02.11.2018 um 17:12 schrieb Mike Banon:
> >>> Which microcode gives you a brick? Have you tried those new 2018
> >>> microcodes (not merged yet to coreboot) for 15h generation -
> >>> https://review.coreboot.org/c/coreboot/+/28273 ? If not, here is a
> >>> quick & secure way to get them -
> >>> http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#AMD_microcode_updates
> >>> (although this script is at "Lenovo G505S hacking" page, the same
> >>> microcodes should work for desktop Richland CPUs as well) . By the
> >>> way, it could help you to get your hardware virtualization (IOMMU)
> >>> working
> >>> On Fri, Nov 2, 2018 at 7:06 PM kinky_nekoboi
> >>>  wrote:
>  Hi Mike, i hope i can help u i am just a User of coreboot and noo 
>  skilled coreboot hacker yet lol.
>  The A10-6800K should work as its the same CPU core/ gen.
>  do not include microcode it makes the rom a brick mode.
>  U have to add a VGA bios if u are using the Internal GPU.
>  i am using a F2A85M rev 1.1 (not pro and not LE, they are quite rare)
> 
>  Am 2. November 2018 17:01:24 MEZ schrieb Mike Banon :
> > Nice report. Do you think A10-6800K CPU would have worked at this
> > motherboard? Or only A8-6600K is supported? Also, what hardware
> > revision of this motherboard do you have? (there were F2A85M / --//--
> > PRO and some other revisions, so I'm a bit confused) . I am seriously
> > considering doing a similar build, but would like to get the fastest
> > available CPU you could install there
> > On Fri, Nov 2, 2018 at 4:29 AM kinky_nekoboi
> >  wrote:
> >>  something like that happens if u connect anything to a USB2 Port
> >>
> >>  [ 2600.001601] usb 7-1: new full-speed USB device number 3 using 
> >> ohci-pci
> >>  [ 2600.001612] ohci-pci :00:12.0: dma_direct_map_page: overflow 
> >> 0x0001c52c2ea8+8 of device mask 
> >>  [ 2600.001619] ohci-pci :00:12.0: dma_direct_map_page: overflow 
> >> 0x0001c52c2ea8+8 of device mask 
> >>  [ 2600.001624] ohci-pci :00:12.0: dma_direct_map_page: overflow 
> >> 0x0001c52c2ea8+8 of device mask 
> >>  [ 2600.185864] usb 7-1: device descriptor read/64, error -11
> >>  [ 2600.293659] ohci-pci :00:12.0: dma_direct_map_page: overflow 
> >> 0x0001c52c2ea8+8 of device mask 
> >>  [ 2600.293669] ohci-pci :00:12.0: dma_direct_map_page: overflow 
> >> 0x0001c52c2ea8+8 of device mask 
> >>  [ 2600.293674] ohci-pci :00:12.0: dma_direct_map_page: overflow 
> >> 0x0001c52c2ea8+8 of device mask 
> >>  [ 2600.477668] usb 7-1: device descriptor re

Re: [coreboot] Schematics and PCB design for ASMB4 (Was: There are ASMB5's on fleabay right now for $30/ea (firmware storage module required for OpenBMC on the KGPE-D16/KCMA-D8))

[Daniel Gröber]

On Sat, Nov 03, 2018 at 01:28:06PM -0500, Timothy Pearson wrote:
> Very nice work!  I too had been intending to work on this at some
> nebulous date in the future, great to see it actually done and boards
> ordered!

I did it as soon as I got a KGPE-D16 which included the module as a
surprise :). I had been trying to get just the module for my KCMA-D8
for a while too.

Since it was unobtainium at the time I figured I'd just do it quickly
so I can copy it for myself. It really just took an afternoon or so to
do the physical probing and component identification.

> Quick question -- how are you handling MAC allocation?  Each module
> comes with the MAC address on a sticker; the mainboard itself doesn't
> have a MAC allocated to the BMC port until the module is installed.

Full disclosure: I haven't actually looked at the software side of the
BMC yet, so I wouldn't mind some pointers to what coreboot patches are
required these days etc.

Generally speaking it's always possible to just allocate "locally
administered" MAC addresses either randomly on first boot-up or by
having the user do it at flash time so it's not really a big deal IMO.

I hadn't intended to pre-flash these modules since it's just another
SPI flash for which coreboot user are likely to already have a
programmer anyways. If enough people are interested in it I could look
into that though.

--Daniel


signature.asc
Description: PGP signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Schematics and PCB design for ASMB4 (Was: There are ASMB5's on fleabay right now for $30/ea (firmware storage module required for OpenBMC on the KGPE-D16/KCMA-D8))

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 11/03/2018 12:20 AM, Andrew Luke Nesbit wrote:
> Dear Daniel,
> 
> Please see my comments inline...
> 
> On 03/11/2018 04:32, Daniel Gröber wrote:
>> On Sat, Nov 03, 2018 at 12:10:25AM +0100, Angel Pons wrote:
>>> Is it me, or is that thing a SPI flash chip on a PCB plus a few
>>> transistors? It seems like copying the PCB design is rather doable, or am I
>>> missing something?
>>
>> Indeed, very doable, but tedious work ;)
>>
>> Here you go:
>>
>> https://github.com/DanielG/asmb4
>> https://oshpark.com/shared_projects/jZLoDQ3Y
> 
> This is fantastic, thank you!!
> 
> I've been intending to do something very similar to this.

Very nice work!  I too had been intending to work on this at some
nebulous date in the future, great to see it actually done and boards
ordered!

Quick question -- how are you handling MAC allocation?  Each module
comes with the MAC address on a sticker; the mainboard itself doesn't
have a MAC allocated to the BMC port until the module is installed.

In any case, we'll probably be switching away from the proprietary
modules for future work; great to see KiCad used here as well.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCAAGBQJb3eivAAoJEK+E3vEXDOFbSGEIAKMS1f5b4zGxxH0SHYCT/sKH
gs/a5908kBWyvbbBHj+Eksj8ZBJNNLSz49RchF1m2younm8PZ1hsf0rO3ys/xrpx
NNHD7QeYFAYvsLC04tTzXKkiw1l5XgGro9SHIvweKBHPQCBtiO19l94OVXGm7nEW
YdIGCbCLf9Q9eIN76AonT+vOe1iYAfnzCrNT9urPevPyzZ6b7oD69d8YJ9HoIgHF
VaevvPqzrohbYK2UZXYfm82Exl6KUfMAx4h86HlQ/nkD8mnNKs79uS00NqITQwew
FSOSloccGvJVbCUmNn0bICOfh24+IW/XUVhl8XDR8IW6SH1UX1u+f8+oHNjVMoQ=
=Ni0y
-END PGP SIGNATURE-

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Update on G505S (dGPU init success)

[Hans Jürgen Kitter]

 Hi All,

I thought that I share with the G505S+Coreboot (+QubesOS) users that I
finally managed to enable and use the dGPUs on the G505S boards.  When
mentioning boards, I mean, that both variants  with its respective VBIOSes:
dGPU=1002,6663 (ATI HD 8570M, Sun-Pro) and the dGPU=1002,6665 (ATI R5 M230,
Jet-Pro) are working under Ubuntu Linux or Qubes 4.0 (no Windows testing
was done or planned).
DRI_PRIME=1 seem to work, I use the radeon driver for the APU GPU
(A10-5750m) and amdgpu for the dGPU. I'm currently investigating how to get
the most out of this setup in Qubes (HW accel 2D in AppVMs).

Problem statement: the dGPU was not initiated correctly and was not enabled
by the radeon or amdgpu kernel module, VFCT header was corrupt/truncated
(effectively was not corrupt, but only VFCT for the APU/iGPU was present).
Trying to init the dGPU device through Oprom initialization failed all my
attempts (radeon :04:00.0: Invalid PCI ROM header signature: expecting
0xaa55, got 0x). This was true whether using Coreboot+GRUB or using
Coreboot+Seabios, regardless of kernel version 4.x.

Solution in short: Modify Coreboot, that the VFCT table is only created for
the dGPU so it can be used by either the radeon or amdgpu KMS driver.

Solution in more details:

   - CB 4.8 latest, with SB latest 1.11.2 as payload
   - I modified the IO address & the PCI device ID in APU GPU VBIOS file
   (even though IO address change to 0x3000 might not required).
   - I modified the IO address in the dGPU VBIOS files to the actual CB -
   linux kernel provided (0x1000) address
   - both prepared VBIOSes were put into CBFS
   - Coreboot config: std. g505s build, but both run oprom & load oprom was
   enabled (native mode), also display was set to FB, 1024x768 16.8M color
   8:8:8, legacy VGA → this provides console output even if eg. GRUB is the
   payload).
   - main payload Seabios (compiled as elf separately)
   - I had to add my SPI chip driver for EN25QH32=0x7016 to CB
   - I used version 0600111F AMD Fam 15h microcode (even though this was
   later recalled by AMD to n-1 version 06001119).  Nevertheless, Spectre V2
   RSB and IBPB mitigations are thus enabled.
   - I enabled pci 00:02.0 for dGPU in devicetree.cb → according to the CB
   logs this causes pci resource allocation problems, because the 256M address
   window of the dGPU conficts with the APU GPU VRAM UMA memory window
   (originally 512M).  Solution (not really professional, but I gave up
   understanding the whole AGESA and CB PCI allocation mechanism): I decreased
   the UMA size in buildopts.c to 256M (0x1000) and patched amd_mtrr.c,
   function setup_bsp_ramtop, to bring TOM down by 256M. So now the APU GPU
   has an 256M PCI address window @0xd000 and the dGPU has also 256M from
   0xe000 without eventual resource conflict (there's an initial
   allocation warning for pci:00:01.0 in linux log though).
   - I modified pci_device.c, function pci_dev_init to only enable
   pci_rom_probe and pci_rom load for the dGPU pci device (no oprom exec
   needed for PCI_CLASS_DISPLAY_OTHER).
   - I modified pci_rom.c,
  - so the VBIOS of the dGPU is copied to 0xd from CBFS
  (..check_initialized..)
  - and pci_rom_write_acpi_tables only run for PCI_CLASS_DEVICE_OTHER →
  dGPU (ACPI VFCT fill is done from the previously prepared
  0xd=PCI_RAM_IMAGE_START address)

Remark1: there could be one ACPI VFCT table containing both VBIOSes
present, but the APU GPU VBIOS is fully working via Oprom exec only.
Remark2: in the stock v3 bios additional ACPI tables are present (SSDT,
DSDT) which contain VGA related methods and descriptions therefore, the
VFCT table itself (in EFI mode) is a lot smaller ca. 20K (vs. 65k).  These
additional ACPI extentions allow eg. the vga_switcheroo to work under
Ubuntu in stock BIOS.  WIth CB currently only offloading (DRI...) seems to
work.  And as I checked I will need to understand the whole ACPI concept
before I can migrate the relevant ACPI tables from the stock BIOS to CB for
the switching to work.  Also, it seems, that TurboCore (PowerNow?) is not
currently enabled entirely in CB --> also implemented via ACPI tables in
stock BIOS.
Well, I’m not a coding expert (just a G505S enthusiast), this is the reason
I didn’t include patches. My goal was to describe a working solution, and
someone with proper coding skills and the possibility to submit official
patches for CB can get this committed.

BR,
HJK
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] How to get correct memory params for FSP

[Alexey Borovikov via coreboot]

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@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [LinuxBoot] FOSDEM 2019 deadline today

[Paul Kocialkowski]

Hi,

Le vendredi 02 novembre 2018 à 22:59 +0100, Carl-Daniel Hailfinger a
écrit :
> In that case, I'd also like to point you to the deadline for submitting
> main track talks which is tomorrow(!).
> https://fosdem.org/2019/news/2018-08-10-call-for-participation/
> Having a coreboot/LinuxBoot talk there would be awesome. Ron/David,
> could you submit something or do you have someone in mind who can do that?
> 
> There's also lightning talks, deadline is a bit later.

I just submitted the CFP for the hardware enablement devroom at FOSDEM.
Submissions related to coreboot and associated projects can definitely
be in the scope of the devroom, so feel free to submit talks!

Our submission deadline is December 1st, so there is still some time
ahead.

Cheers,

Paul

> OK, I'm submitting a request for a stand. I need a backup contact for
> the stand. Who is willing to do that? AFAICS we can still change the
> backup contact later if life happens.
> 
> Regards,
> Carl-Daniel
> 
> On 02.11.2018 20:48, David Hendricks wrote:
> > 
> > On Fri, Nov 2, 2018 at 9:15 AM 'Ron Minnich' via linuxboot
> > mailto:linuxb...@googlegroups.com>> wrote:
> > 
> > I"m leaning to yes, by which I mean if you do it, I'll show up.
> > 
> > I can't believe I said that.
> > On Fri, Nov 2, 2018 at 7:20 AM Carl-Daniel Hailfinger
> >  > > wrote:
> > >
> > > Hi!
> > >
> > > FOSDEM next year will be on 2 & 3 February 2019.
> > > The deadline for applying for a stand is today.
> > > Do we want a coreboot/flashrom/LinuxBoot stand/booth?
> > 
> > 
> > Same as what Ron said. I think someone from FB can be there to talk
> > about coreboot/LinuxBoot stuff and perhaps bring some hardware to demo.
> > 
> > 
> 
> 


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] FOSDEM 2019 Hardware Enablement Devroom Call for Participation

[Paul Kocialkowski]

Hi,

The Hardware Enablement devroom is back for a second year at FOSDEM!
It will take place on Sunday 3 February 2019.

# Call for Participation

We are opening the call for participation to our devroom, with the
deadline for talk proposals set to Saturday 1 December 2018.

# Devroom Scope

This devroom covers topics related to hardware support and enablement
with free software. It includes the following topics:
* peripheral/controller firmwares
* boot software
* kernel drivers and hardware interfaces
* hardware-related adaptation in operating systems
* tools for firmware flashing
* tools for low-level development

Despite this large scope, the focus of the devroom is set on
highlighting the technical aspects of the hardware and its enablement
in free projects, rather than the specific applications and use cases
that benefit from it. We also want to avoid purely commercial vague
talks with marketing content, which leave little place to technical
aspects.

This year, we are looking to particularly highlighting free software
outside of the operating system boundaries, especially with boot
software as well as controller and peripheral firmwares.

# Talk Format

Since no Embedded devroom is taking place this year (and our devroom
also covers embedded devices), we are expecting a significant number of
submissions.

In order to cover as much ground as we can, a new talk will be
scheduled every half-hour, so accepted talks will follow this format:

 20 minutes for the talk
+ 5 minutes for questions
+ 5 minutes for speaker setup

We ask speakers to be present in the room before their talk so that
speaker setup can go smoothly.

# Submission

Talks that fit in our devroom's scope can be submitted to the FOSDEM
Pentabarf interface at https://penta.fosdem.org/submission/FOSDEM19

We encourage reusing accounts from previous years instead of creating
new ones:
* lost password: https://penta.fosdem.org/user/forgot_password
* new Account: https://penta.fosdem.org/user/new_account/FOSDEM19

Here are a few guidelines when submitting a talk:
* select the Hardware Enablement devroom as track
* include an abstract for every submission and optionally a full
  description
* make sure your contact details are up to date

# Video

Talks will be streamed live during the event and recorded. They will be
available under a Creative Commons Attribution (BY) license later.

# Contact

For more information or questions about the devroom and this CFP, feel
free to email hardware-devroom-manager at fosdem.org

We're looking forward to lots of interesting proposals and hoping to
see you all in Brussels at the event!

Cheers,

Paul for the Hardware Enablement devroom


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] How to get correct memory params for FSP

[Alexey Borovikov]

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@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot