petecb via coreboot wrote:
> Does anyone know whether there is a specific coreboot/cmos option I
> could be missing or if it is a Qubes configuration issue?
Narrow the problem down by booting any common Linux distribution
(the install media is fine) and as root suspending with
echo mem > /sys/power/state
..and see if resume works there. If yes coreboot is not neccessarily
off the hook, but xen/Qubes is at least involved.
//Peter
petecb via coreboot wrote:
> Well the good news is that I have now got this board to work with
> Coreboot v4.6 with the CMOS options and SeaBIOS! :-)
>
> The bad news is that this obviously means a bug has crept in on the
> way up to 4.8
The best news is that you can track that down, since you have both a
working (good) and a failing (bad) test case.
Please clone the git repo and use git bisect to find the first bad commit.
This would clearly be a really valuable contribution to the project,
because it is not so unlikely that more boards are affected.
Thanks
//Peter
Hi
I have been playing around with the AMD fam10 codebase as of late.
It is quite different from Intel hardware is that AMD hardware starts up
other AP cores whereas on Intel hardware typically only the BSP runs code.
As far as I can tell the AP's are started early on. They then start
running from the reset vector. The code then updates their microcode
and sets a 'reasonable' TOP_MEM MTRR such that when starting the APs
later on during the ramstage, it won't result in any problems given that the
stack will be in that 'reasonable' range (below CONFIG_RAMTOP). After that,
they are put to rest and the BSP will be doing the rest of the things
during the romstage (raminit for instance).
Now the cbmem_top depends on the value the BSP set's in TOP_MEM, but
unless the AP's have their own TOP_MEM (not shared MTRR) synced with the
BSP. This syncing only happens during the AP init.
To implement relocatable ramstage this syncing needs to happen earlier,
preferable during the romstage...
At the moment with relocatable ramstage enabled it hangs when starting
the APs as it puts their stack somewhere in CBMEM well above the
'reasonable' default value of TOP_MEM which is CONFIG_RAMTOP.
Now my questions:
- Is this analysis correct?
- If so, how to sync TOP_MEM in romstage (is there already an example of
an implementation somewhere?), is there an easy way to run code on
all AP's during the romstage?
- Are workarounds possible/better? like figuring out TOP_MEM saving it
nvram and resetting and programming that value on AP's
Kind regards
Arthur Heymans
On 12/07/2018 02:14 PM, petecb via coreboot wrote:
>
> Hi Taiidan,
>
> Thanks for your message.
>
>
>> I am using v4.6 on my system FYI (no reason for me to update) and the
>> only options I have changed are the ones I told you about before...all I
>> can figure is perhaps I have a different version of the SP5100 that
>> doesn't have the erratum or something to that effect.
>
> Is it possible for me to build v4.6 in case something has changed since then that causes my issues? When I look at the branches available on git there is no 4.6 available.
Get it from the coreboot website + check signature.
>
>>
>> FYI I saw you select build nvramcui as a secondary payload so you can
>> mess with cmos options without recompiling as long as next time you shut
>> off "Load default configuration values into CMOS on each boot"
>>
>> Since your menuconfig options look fine...shot in the dark but try using
>> grub instead of SeaBIOS as I use grub.
>>
>
> I will try building it with Grub. There is an option to include a GRUB2 runtime config file into ROM image. Should I select this? If so, what options should be in this file?
I would set it to load your disk .cfg file otherwise you would have to
do so via configfile (ahci0,msdos1)/grub2/grub.cfg or what not when it
boots to the rescue shell.
>
> Kind regards,
>
> Pete
>
>
Please keep replies on the list - I will notice them - and like I said I
won't give up until it works :D
I wish you had OpenBMC installed so that I could access your system
remotely and try stuff myself (via VPN and a router IP whitelist for
security ofc)
Did your D16 come with an ASMB4 or ASMB5 module? if so I recommend
installing OpenBMC and its coreboot patches - note that coreboot needs
patching for them to play nice together since for some stupid reason the
required patches have not been upstreamed so you would need to cherry-pick.
I am using v4.6 on my system FYI (no reason for me to update) and the
only options I have changed are the ones I told you about before...all I
can figure is perhaps I have a different version of the SP5100 that
doesn't have the erratum or something to that effect.
FYI I saw you select build nvramcui as a secondary payload so you can
mess with cmos options without recompiling as long as next time you shut
off "Load default configuration values into CMOS on each boot"
Since your menuconfig options look fine...shot in the dark but try using
grub instead of SeaBIOS as I use grub.
Hello,
I was trying to upgrade my Kontron 986LCD-M setup to AMD Radeon RX460
and I've found the vendor BIOS lack support for the video BIOS (RX460
requires UEFI). This incompatibility leads to x16 PCIe slot disable and
no graphics in linux at all.
I was able to re-enable the PCIe slot until now when I tried to upgrade
to 2+2 GiB DDR2 modules (little more MB and dual channel). The RAM space
is shared with PCI space and limited by 32bit so the top part of RAM is
eaten by the regions of PCI devices. Problem is when vendor BIOS
disables the card's slot it doesn't leave a hole for my GPU and it sets
the TOLUD register (top of used RAM). This causes kernel to crash in GPU
initialization.
There is probably no way to fix TOLUD (and ACPI tables, SMI and other
stuff) or force vendor's BIOS to reserve region for GPU, so I'm
considering to switch to coreboot.
My question is: does anybody know advanced information about TPM and SPI
connectors? In the Kontron 986LCD-M datasheet (sections 4.16 and 4.17)
there are only pin names and caption "unsupported". I understand these
signals are likely buses from chipset, but it would be nice to know more
details. Namely if the default LPC flash chip needs to be disconnected
when using these busses and which pins of the chipset are connected to
SPI pins BOOT0 and BOOT1 (I suppose they are LPC/SPI/PCI priority?).
Thanks for any help.
Petr Cvek
Hi Kkonstantin,
just by any chance, do you tried to use baytrail and _not_ fsp_baytrail?
best,
lynxis
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604
Hi
I'm trying to implement a few features on x86 platforms to improve
coreboot. Currently I'm focusing on unifying the bootflow of x86
platforms a little better. An important aspect of that is to make sure
program boundaries within stages are respected, which is mostly an issue
when romstage destroys the stack+environment in which it is running.
Currently many platforms work around it by having code to fetch the
global variables which are either still in the CAR (before CAR tear
down) or somewhere relocated in cbmem after cbmem has been set up.
A better solution is to have CAR being torn down in a separate stage,
which means that romstage can always access global variables where the
linker initially puts them. We call this stage postcar stage.
I have an implementation ready for the following platforms:
* CPU_AMD_MODEL_10XXX or in mainboard terms:
amd/serengeti_cheetah_fam10
asus/kfsn4-dre
hp/dl165_g6_fam10
msi/ms9652_fam10
supermicro/h8dmr_fam10
supermicro/h8qme_fam10
tyan/s2912_fam10
amd/mahogany_fam10
gigabyte/ma78gm
iei/kino-780am2-fam10
jetway/pa78vm5
amd/tilapia_fam10
asus/m4a78-em
asus/m4a785-m
asus/m4a785t-m
asus/m5a88-v
gigabyte/ma785gm
gigabyte/ma785gmt
avalue/eax-785e
amd/bimini_fam10
advansus/a785e-i
asus/kcma-d8
supermicro/h8scm_fam10
asus/kgpe-d16
It would be great if the following patches could be tested (i.e. does it
still boot):
https://review.coreboot.org/c/coreboot/+/30063/2https://review.coreboot.org/c/coreboot/+/30064/2
preferably on a board on which ACPI S3 resume is implemented (select HAVE_ACPI_RESUME).
* NORTHBRIDGE_VIA_VX900 on the VIA EPIA-M850 board
https://review.coreboot.org/c/coreboot/+/30057/1https://review.coreboot.org/c/coreboot/+/30058/3
The only remaining targets that need to be addressed before the special
logic for CAR globals can be dropped are FSP1.0 platforms and geode_lx.
geode_lx still has to implement EARLY_CBMEM (requirement for 4.7 and 4.9 is
coming soon)...
Kind regards
Arthur Heymans
Hi everybody,
as Martin is swamped by other work, I'm taking over as the release manager
for 4.9.
Based on our schedule, we should have released 4.9 in October or early
November, but since those passed, I'll plan to release 4.9 two weeks from
now, on December 20th.
If you want, consider it an early Christmas present :-)
(Why early? I'd appreciate some last minute testing of the commit I'll pick
for the release, and it might be easier to drum up support for that when
family functions aren't interfering.)
The release after that will go back to our April/October schedule, so the
4.10 window will be rather short. Due to that, there will be no
deprecations announced in 4.9.
Arthur's proposals sparked some discussion that started activity to keep
some affected chipsets alive, and depending on how that unfolds, we can
reconsider those deprecations for the 4.10 release notes, to happen after
4.11 in late 2019.
Regarding release notes: I set up an etherpad copy of the release notes we
have so far at https://piratenpad.de/p/S8slYOeag. I'll collect the changes
of the last 8 months there, and I appreciate any help: if you made coreboot
do something new since 4.8, feel free to tell the world about it in the
upcoming release notes.
I chose this method over the usual gerrit workflow we use for documentation
because the latter doesn't scale so well when lots of changes happen close
to each other: git produces too many merge conflicts in such a case.
As part of the release process I'll push the release notes into the tree.
While we have no quality criterion for releases, we all like to be able to
point to releases as functional on our preferred hardware. Therefore,
please test the hardware you have with recent master, and maybe schedule
some time on the 19th or 20th to re-test master then, and report (or better
yet, fix) any issues you encounter.
While testing, consider adding to the board-status repository, too :-)
I guess every release needs a bit of hyperbole, so let me end this
announcement with a call to make this the best coreboot release ever!
Regards,
Patrick
--
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft:
Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
