Hello,
Recently I have decided to give a try to coreboot for first time and
flashed my ThinkPad T420, but a few weeks ago I have swapped the USB
controller on the back, next to the battery, with a FireWire/USB controller
(40GAB5809-G200) from another T420. Nothing special, since some models have
been shipped like this. The controller is no longer accessible on my laptop.
It seems like it may have been detected as an "SD Host Controller" or not
detected at all. I will probably have to remove the chip and compare the
output of lspci and lshw. If nothing has changed, I will probably have to
return the stock BIOS and compare the results again. I have also tried to
load some of the firewire kernel modules manually with modprobe.
The operating systems I have tested so far are Arch Linux and Xubuntu. I am
willing to provide more useful information, boot into a fresh Windows
install, flash the chip again or whatever else. Correct me if I am wrong,
but if I go back to the stock BIOS, the next time I flash, I will have to
disassemble the laptop again and otherwise I must be fine with flashing
internally, right?
Thanks
I have attached all the log files releated to the dmidecode ectool
inteltool etc. Can you read those out and tell me if it is possible to port
coreboot to my netbook? If it is then how hard will it be?
Hi everybody,
it's that time of year again: we should look into cutting a
release. Not because there's anything noteworthy that we should bring
out (although there certainly is), but because we have a 6-monthly
cadence of giving our tree a new number and pushing out tarballs and
press releases.
I plan to do the release on or shortly after May 11, and
this announcement is in accordance to the process detailed on
https://doc.coreboot.org/releases/checklist.html, so we're at the
"~2 weeks prior to release" point right now.
As such, there are a number of things I ask of you (all of you
subscribed to the list, but since you're reading this mail, yes,
I mean you, personally!):
1. If you have anything big that you want to get in before the release,
it's on you to maintain the changes responsibly and responsively so
that it all works out in time. I'll gladly help coordinate things
but I'm not interested in last-minute heroics, so get in touch with
me ASAP.
2. Please try to postpone riskier refactorings and the like until after
the release (unless they're ready to land in the next few days), so
that people have a solid foundation to test their hardware on. Which
gets us to the next point:
3. Please test your coreboot-supported gear if you can, report and/or
fix issues, and upload fresh reports to the board-status repo. While
we have no quality requirement for releases - they're _really_ only
about giving the tree a new number, a release is a good opportunity
to verify that what we have in the tree is still functional, with
only limited work required to pin-point new issues (bisections since
4.11 should take 12 steps or less at this time).
4. Please check the preliminary release notes in
Documentation/releases/coreboot-4.12-relnotes.md and add whatever
happened since 4.11 that you think is noteworthy. If in doubt, push
a change to gerrit and see what your fellow developers think about it.
Thanks,
Patrick Georgi
--
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
Dear coreboot community,
What are the requirements for working PCIe hotplug support on
Intel-based platforms using FSP 2.0?
I see there are FSP configuration options for PCIe root ports hotplug,
but setting the bit alone and enabling PCIe hotplug in coreboot is
sufficient?
Typically there should be an ACPI code or SMI handler to train the link
when the device is detected in the slot if I am not mistaken.
Anyone with PCIe hotplug experience could advise and clarify my doubts?
Thanks in advance.
--
Michał Żygowski
Firmware Engineer
https://3mdeb.com | @3mdeb_com
Dear coreboot folks,
Despite ever increasing flash ROM chip sizes, small images are still
desired for faster boot times, faster flash times, and more space for
payloads, which is sometimes needed for adding several payloads
(including GRUB/TianoCore) or Linux payloads.
Jacob Garber did great work to achieve this goal by enabling Link Time
Optimization (LTO) for coreboot [1] and libpayload [2]. While doing
this, he also found and fixed several bugs in the code base.
Currently, it fails for AMD AGESA boards due handling of illegal globals.
> Yes, this is a current limitation of LTO right now. Because the
> object files are all lumped together into a single unit, all
> information about where the symbols came from is lost, so
> EXCLUDE_FILE is unable of excluding the AGESA objects from the
> illegal_globals check. Tracing where a symbol came from has been
> implemented in LLVM [0], but I'm not sure if it's on the roadmap for
> GCC. For now it's probably best to disable LTO when compiling AGESA.
>
> [0]: https://llvm.org/devmtg/2017-10/slides/LTOLinkerScriptsEdlerVonKoch.pdf
If somebody has a solution for that, that’d be great.
It’d be great, if more people could test this, on your boards, and
report back.
I propose, to submit the change-sets before the next release, and to
enable LTO for libpayload by default, and to disable it for coreboot by
default.
Big thanks again to Jacob for doing this. (My attempt doing this for
GRUB failed. ;-))
Kind regards,
Paul
[1]: https://review.coreboot.org/c/coreboot/+/38989
[2]: https://review.coreboot.org/c/coreboot/+/38291
Hello,
As a GSoC candidate, I have been digging for some time within coreboot
repos, building stuff, booting different OSes with different payloads
and different tweaks, and so on.
I have applied to two coreboot projects:
1) "Fully support building coreboot with the Clang compiler",
2) "Port GRUB2 to RISC-V".
As an ENS master student intending to pursue in the academic field, I
chose :
- coreboot organization because, very briefly, I believe in open
hardware/firmware and am very interested in system development and
computer security, especially in the intersection of both ;
- these 2 possible projects because, again very briefly, I am highly
interested since a few years in both the LLVM toolchain and the RISC-V
architecture.
I already worked on research projects related to all of this during
research internships, and think of this GSoC as an opportunity to learn
more while contributing to one of the open source projects I am the most
interested in.
- Due to COVID-19 outbreak and corresponding countermeasures in France,
I do not have access currently to all of the hardware normally at my
disposal. Even if I have enough resources to work remotely in a
reasonable manner, I try to optimize my setup, and think about using
ccache (when useful) and distcc (when possible).
Thankfully, I have access to some of my school resources that should
allow me to work efficiently, a few mid-range workstations.
The first topic would probably be more resource-intensive. I already
have some experience with ccache.
Do you have any additional advice? It could really be useful (and
interesting)?
- I also tried to build coreboot toolchain targets on different Linux
distributions, and I have some trouble on Arch Linux with the clang
target. I managed to bisect it to an issue between gcc 9.2.0-4 and gcc
9.3.0-1. I did not find anything about this previously, is there
something I am missing and I should be aware of, before I go further?
Please find attached the error message, due to a narrowing conversion.
It is quite late to get in touch with the developers team, but I had to
cope with issues related to COVID-19. I am very sorry about that, but
now that it is done, I am ready for this GSoC.
Best regards,
Antonin Reitz
Hi everybody,
There's some fine work by Jan on Gerrit on the issue of adding unit testing
infrastructure to our tree and I'd like to see it merged soon.
So far, most feedback was by Google folks so this is a heads up for
everybody (and especially those not at Google) to take a look and offer
your input.
The design doc, build infra and demonstration test cases can be found at
https://review.coreboot.org/39893 and the commits that are based on it.
I aim for inclusion near the end of the week unless there's feedback
showing weaknesses in the plan or implementation.
Thanks,
Patrick
Hallo Alexander,
danke!
Ich werde das austesten.
Viele Grüße
Wolfgang
-----Ursprüngliche Nachricht-----
Von: Alexander 'lynxis' Couzens [mailto:lynxis@fe80.eu]
Gesendet: Montag, 27. April 2020 12:52
An: Wolfgang Kamp - datakamp <wmkamp(a)datakamp.de>
Betreff: Re: [coreboot] CBFS pointer problem with SeaBios and Apollo Lake platform
Hallo Wolfgang,
hier ist ein alter HACK/Patch von mir, als ich Probleme mit dem Seabios hatte. Ist schon etwas länger her, eventuell hilft der dir.
e.g.
CONFIG_CBFS_LOCATION=0xffc23038
Schönen Gruß,
lynxis / Alexander
On Thu, 23 Apr 2020 08:15:42 +0000
Wolfgang Kamp - datakamp <wmkamp(a)datakamp.de> wrote:
> Hello,
>
> Am I correct that the problem still exists that SeaBios can't find the
> CBFS in apl platform?
>
> Kind regards,
> Wolfgang Kamp
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)fe80.eu
gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604
Hello,
I found out that the panel backlight enable function in libgfxinit for Broxton platform (Intel x5-E3940) will not work for me.
The Backlight Enabling Sequence Description in the Intel document Doc Ref # IHD-OS-BXT-Vol 7-05.17 says:
1. Set frequency and duty cycle in BLC_PWM_FREQ Frequency and BLC_PWM_DUTY Duty Cycle.
2. Enable PWM output and set polarity in BLC_PWM_CTL PWM Enable and PWM Polarity.
It is also necessary to set Bit 2 in the PP_CONTROL register to "1" to enable Backlight Power.
In "hw-gfx-gma-panel.adb" in the function Backlight_On only BXT_BLC_PWM_CTL_ENABLE will be set and PP_CONTROL setting is excluded through the If statement.
Also I can't find any call of the Set_Backlight function and I'm missing the setting of the PWM frequency divider in this function. Most panels will work with 200Hz PWM.
Can anyone help?
Kind regards,
Wolfgang Kamp
