Hey Denis, My reply got out of control here. Apologies for the length, feel free to ignore the top and just skip to my replies. :)
The points you bring up are definitely valid, but coreboot isn't Linux. We don't have the same infrastructure, or investment from companies. coreboot has no "full time" contributors as such. We have a number of contributors from various companies who need to get their products shipped, but they all have varying amounts of time to spend on the project. It's a tiny tiny fraction of what Linux gets.
I don't mean to say that coreboot is a small project - we're not. In the past year, we've gotten contributions from over 350 different people. Most of these contributions are from people who work on coreboot as a job. Those aren't the people who keep the project alive though. There are really just a couple of dozen people at any given time who actually do the work on the coreboot project outside of the individual patches they're assigned to do for their jobs.
Unfortunately, that's simply not enough people to maintain all of the platforms and chips in the tree the way things are currently. We could do something like add a requirement that each platform added needs to donate two (or choose an arbitrary number) boards to the coreboot project that we install somewhere and test on a (daily/weekly/monthly) basis to make sure that they're working.
Currently we don't have the funds or a place to do that. It also puts a burden on an individual who wants to add a board to the coreboot tree. It creates problems for companies that use coreboot for an embedded system that isn't easy to test.
Looking forward:
coreboot just got our first "large" donation from Google to support the build servers for the next year. Until now, the build servers have mainly been running from my house. We've reached the point where the project can no longer run as a hobby-project on a hobby-project budget.
If we're going to actually be more than a hobby-project going forward, I think we're going to need to expand our scope and make changes to the way we do things. This is going to require making changes to better define how things like code deprecation is handled.
I think you're right that we need some way to guarantee that boards added to coreboot aren't going to be dropped again in a short period of time, but that requires investment from companies using coreboot to make sure that it happens. When a chip is added to coreboot, how long is a company expected to maintain that chip in the coreboot repository? If we make it too short, nobody wants to develop mainboards for it. If we make that time too long, chip vendors aren't going to want to add their chips to the tree. I'm not sure how to balance that.
Jan 3, 2023, 17:17 by GNUtoo(a)cyberdimension.org:
> On Tue, 3 Jan 2023 18:38:02 +0100 (CET)
> Martin Roth <gaumless(a)tutanota.com> wrote:
>
>> Hi Denis,
>> - Responses inline
>>
> Hi,
>
> Thanks for the answers.
>
>> Jan 2, 2023, 17:16 by GNUtoo(a)cyberdimension.org:
>>
>> > Hi,
>> >
>> > The MAINTAINERS file has the following:
>> >
>> >> PC ENGINES ALL MAINBOARDS
>> >> M: Piotr Król <piotr.krol(a)3mdeb.com>
>> >> M: Michał Żygowski <michal.zygowski(a)3mdeb.com>
>> >> S: Supported
>> >> F: src/mainboard/pcengines/
>> >>
>> >
>> > But the commit f9decbb0c720662d8e71fe221aef55b7ecf76196 ("mb/*/*:
>> > Remove AMD family14 boards") actually removed the apu1
>> > (src/mainboard/pcengines/).
>> >
>> > Is there some policy somewhere that describes what kind of support
>> > to expect from maintained boards?
>> Yes, It's in the maintainers file itself:
>>
>> Supported: Someone is continuously paid to look after
>> this and a reaction to review requests can be expected
>> within a few days, a month at most.
>>
> [...]
>
>> Because the maintainers may not notice the patches, it's always
>> suggested to reach out to the maintainers directly for reviews.
>>
> As I understand that file tells only about patch review delays and not
> what kind of patches are acceptable or not or who is supposed to do the
> work of converting a board to the newer APIs. I'm mostly interested in
> two last aspects.
>
> For instance as a Linux contributor, I can send a patch to add a
> computer (like a smartphone for instance) or contribute fixes and new
> support to existing drivers, and usually the code gets maintained
> somehow automatically:
> - New patches are required not to break existing code, so they have to
> take care to either keep the compatibility with the old code or
> update it along the way.
>
> Though older code doesn't necessarily benefit from new features (for
> instance, for ARM, if nobody converts old C board code to the
> devicetree, it will still works if people compile support for that
> ARM computer, but the resulting kernel will only be able to boot on
> that computer).
>
> The code quality requirements is usually very high in order to reduce
> the amount of time required to maintain the code.
>
> - If I'd contribute a driver instead, I may end up being its maintainer
> somehow, so I'd have to review patches. Who will maintain the driver
> might also be part of the discussion when upstream will decide or not
> to accept the patch for the new driver.
>
> - Users can test the code and report bugs. If the bugs are reported
> during patch review, the burden to fix the bug is on the person who
> sent the patch.
>
> Since there are different policies in Coreboot, I'm trying to
> understand if it's possible to somehow find ways to get the same kind
> of assurances than with Linux so that specific mainboards will not be
> removed, and if so how to do it, how much resources it requires, etc.
>
We don't currently have any way to make this assurance. It depends on a number of things. Imagine that there's a mainboard maintainer, but no chipset maintainer. If the chipset isn't being maintained and is being removed from ToT because it's not supported and has become problematic, it's not like the mainboard can stay independently.
As far as the resources needed, that's difficult for me to say. It depends on the chipset and the changes that are needed.
Remember that the boards that are removed from ToT are not gone. We've created branches, and the boards that have been removed from ToT can be maintained on those branches. We have builders set up to test patches pushed to those branches for that reason. Those boards may not get all of the latest features automatically, but do they really need all of the latest features? Does the KGPE-D16 need an eSPI driver? No - it doesn't support eSPI.
Because coreboot is a firmware project, it's very different than something that's pure software and can be tested easily. If people want to keep the chipsets and boards on ToT, we need to have people actually working to keep them there. There are a very few people at coreboot doing a LOT of work to keep the project running. We can't do everything for every board on our own. We need other volunteers who own the boards to test them, submit bugs and patches, and help with the project. Without that, coreboot has no way of even knowing if a board is actually working.
> If I look at Linux, in the worst case scenario I can look at the number
> of maintainers for a given driver and expect that the maintainers will
> at worse, work full time on reviewing patches, so that can be roughly
> calculated.
>
> There is also information on how to setup automatic test infrastructure
> (for instance with LAVA) so the resources needed for that can also be
> predicted somehow.
>
> Here this interest me because I'm trying to evaluate if it makes sense
> for me and other interested people to contribute big changes to
> Coreboot, for instance by adding back a mainboard like the Asus
> KGPE-D16. If we do a lot of work and that this work is removed right
> after, it's not worth it, so it's best to check beforehand than to have
> some drama if the huge work is removed.
>
> The issue with Coreboot is that I'm unsure if I can do the same kind of
> calculation than with Linux: The APU1 was removed despite the fact that
> the mainboard was "supported".
>
As mentioned in the scenario above, the mainboard was marked as being supported, but the chipset was not. Unless someone is willing to step up as the supporter of the chipset, I don't know what to tell you. We can't really keep the mainboard without the chipset. I don't know if there's something similar in the linux hierarchy to look at, but if there is, I'd be interested in knowing how it's handled there.
> So this is why I'm trying to understand how much work it is to convert
> boards and for that understanding how deprecation are decided could
> give me hints of the amount of work to expect in the worst case.
>
>> The usual reason is progress: Infrastructure module X has been
>> replaced byinfrastructure module X+1. Removing X helps keep the
>> sources manageableand likely opens opportunities to improve the
>> codebase even more.
>>
> Here I am wondering precisely how the deprecation of module X is
> decided. For instance can anyone convert some code in Rust and expect
> everybody else to learn Rust and rewrite everything in Rust?
>
> Is it up to maintainers of each module to decide when to deprecate
> module X in favor of module X+1?
>
This is typically suggested on the mailing list, beaten to a pulp, then discussed in the coreboot leadership meeting for a decision
> If so what are usually the factors taken into account? I assume that if
> there is too much change to do (like completely rewriting Coreboot in
> Rust), I assume that they won't be able to force a change like that on
> the rest of the Coreboot contributors. If that's the case it gives some
> indication of the amount of work required to convert to newer modules.
>
> It also brings the question of what is taken into account when deciding
> to deprecate module X. For instance is the maintainability of each
> "modules" the only concern, or are the amount of supported mainboards
> and end users a concern too?
>
> Is the amount of work needed to convert from module X to module X+1
> taken into account? And is there usually some documentation that
> explains how to do the conversion? Or are do people need to find out by
> looking at the release notes and other boards being converted?
>
We don't currently have a written policy about it.
>> > Is there also a policy that explains when boards are removed? Or
>> > what to do to prevent boards from being removed?
>> >
>> We do have that policy, though it could probably be written a bit
>> more plainly.
>>
>> Here's the search in the coreboot documentation.
>> https://doc.coreboot.org/search.html?q=deprecation&check_keywords=yes&area=…
>>
>> Here's the template for the release notes:
>>
>> Deprecation notices are part of release notes to act as a warning: at
>> somepoint in the future some part of coreboot gets removed. That
>> point must beat least 6 months after the release of the notice and it
>> must be right aftersome release: That is, the specified release must
>> still contain the part inquestion while one git commit later it might
>> be removed.
>>
> That is good: at least we have a way to find that out.
>
>> > For instance u-boot warns when building that a boards needs to be
>> > adjusted to the newer driver model. So just by building u-boot you
>> > know in advance what needs to be fixed and for when.
>> >
>> > I've looked in the Coreboot documentation but I didn't find any
>> > information about that.
>> >
>>
>> Someone could definitely add something to put up a notice when doing
>> the build, but that doesn't exist right now. If it's not something
>> that you're interested in doing, you could file a bug if you think it
>> should be added.`
>>
> I'm not sure I'm the right person to do that, and if so how I could do
> it. I could probably propose a patch to the documentation though, if
> it's the right place to do it.
>
> For the code, it's probably best if it's done in the commit that
> deprecates something. For instance for CONFIG_LEGACY_SMP_INIT, we could
> add the following to the Makefile in the top directory:
>
> ifneq ($(CONFIG_LEGACY_SMP_INIT),)
> @echo "+----------------------- /!\ WARNING /!\ ---------------------+"
> @echo "| CONFIG_LEGACY_SMP_INIT is deprecated. |"
> @echo "| It will be removed in Coreboot release 4.18 (November 2022).|"
> @echo "| Please migrate your mainboard to CONFIG_PARALLEL_MP, |"
> @echo "| or it will be removed right after the Coreboot 4.18 release.|"
> @echo "| See the Coreboot release notes[1] for more details. |"
> @echo "| [1]Documentation/releases/coreboot-4.16-relnotes.md |"
> @echo "+-------------------------------------------------------------+"
> endif
>
> If we add that at the end of the Makefile, to have it show up at the
> end of the build. We could also add a deprecation target if needed.
> This way if we do that and that we use a similar format for all
> deprecations, people building Coreboot will most likely see it.
>
> This way users will not have to read all the release notes at each
> releases to catch that kind of issues, and if distributions start
> packaging coreboot or other projects based on Coreboot, then they would
> see that too.
>
I'm all in favor of that. I'll add it to the discussion of the coreboot leadership meeting on the 11th.
Martin
Issue #464 has been reported by Alex Perez.
----------------------------------------
Support #464: Writes to AM29LV040B with -p satasii work properly
https://ticket.coreboot.org/issues/464
* Author: Alex Perez
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-02-22
----------------------------------------
When flashing the AM29LV040B with -p satasii (attached to a PCI SATA card) using the latest git checkout, writes work fine. Write Protect does NOT work. I've also reported this via e-mail to flashrom(a)flashrom.org, as per the command-line recommendation.
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #327 has been updated by Jason Stewart.
Know this thread is a bit old, but just wanted to add that this change fixed this issue for me. Just wanted to add some data points regarding my hardware and in hopes that it helps someone else in the future:
Sandy Bridge Lenovo W520 + I7 3840QM + Quadro 2000m. No VGA roms were used.
----------------------------------------
Bug #327: MBOX3, OperationRegion (OPRG, SystemMemory, ASLS, 0x2000) causes windows uefi tianocore BSOD ACPI_BIOS_ERROR
https://ticket.coreboot.org/issues/327#change-1434
* Author: xinhua wang
* Status: New
* Priority: Normal
* Start date: 2021-12-30
----------------------------------------
https://review.coreboot.org/c/coreboot/+/27711/7/src/drivers/intel/gma/acpi…
this line .. OperationRegion (OPRG, SystemMemory, ASLS, 0x2000)
the 0x2000 will cause BSOD ACPI_BIOS_ERROR when booting installer, os, etc
When set to 0x1000 windows UEFI tianocore mode boots fine
---Files--------------------------------
dmesg.txt (76.9 KB)
results.log (204 KB)
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #463 has been reported by Felix Niederwanger.
----------------------------------------
Bug #463: nvramtool: coreboot table not found on Starbook Mark VI
https://ticket.coreboot.org/issues/463
* Author: Felix Niederwanger
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-02-18
----------------------------------------
The `nvramtool` on my Starbook Mark VI reports that it can't find the coreboot table:
```
# nvramtool -d
nvramtool: coreboot table not found. coreboot does not appear to
be installed on this system. Scanning for the table produced the
following results:
0 valid signatures were found with bad header checksums.
0 valid headers were found with bad table checksums.
```
I compiled the `nvramtool` freshly on my Laptop using the documentation from
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #455 has been reported by shen Liu.
----------------------------------------
Bug #455: superiotool recognizes the wrong chip and doesn't work.
https://ticket.coreboot.org/issues/455
* Author: shen Liu
* Status: New
* Priority: Normal
* Category: userspace utilities
* Target version: master
* Start date: 2023-02-07
* Affected versions: master
* Needs backport to: none
* Related links: More discussion:
https://www.reddit.com/r/coreboot/comments/10ud7tk/is_b85me45_ms7817_suppor…https://wiki.archlinux.org/title/Debuginfod
* Affected hardware: MSI B85M-E45
* Affected OS: Manjaro Linux 22.0.2 (Kernel ver:6.1.9-1)
----------------------------------------
``` shell
sudo ./superiotool
Found Aspeed AST2400 (id=0x00) at 0x4e
sudo ./superiotool
superiotool r4.19-306-g12ec7901b7
No Super I/O found
```
Does superiotool provide debug symbols?
Without debug symbols I can't use gdb to provide more useful information.
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #461 has been reported by akjuxr3 akjuxr3.
----------------------------------------
Feature #461: Replacing Haswell mrc.bin blob with free software
https://ticket.coreboot.org/issues/461
* Author: akjuxr3 akjuxr3
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-02-16
* Related links: https://review.coreboot.org/c/coreboot/+/52659
----------------------------------------
Currently in case of the ability to run as less amount of closed source software as possible and still have Microcode updates the reduced Intel ME with disabled bit in IFD and the lga1155 or the mobile versions of those cpus are the only option for x86_64 out there.
The next cpu generation (Haswell) inside for example T440p and W541 require the binary blob mrc.bin
Are there any plans of replacing the Haswell mrc.bin with free software? Or have the x86_64 platform be given up when the goal is to run just free software and the people should move to aarch64 or risc-v?
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #314 has been updated by akjuxr3 akjuxr3.
> To be very clear: For the future, I am asking you to think twice before you do such accusations and to write your requests in a polite manner. I do not want to read wrong accusations again, especially when there is not a single proof given.
Please define 'polite'. I have not used useless(providing no information) and just emotional words like *hole or any other known slang-wording. The text i wrote is as rational as possible.
You write 'wrong accusations'. Could you get in more detail with that? I would really like to know what is wrong. Thats why i use coreboot and free software. I like to 'be able' to get the whole picture at any time. I have the ability and thus the freedom to learn and read the sourcecode and get logfiles. If i have the knowledge and understanding to be able to understand that all is only related on my capabilities i am free to expand by training. When free access to knowledge (books, tutorials, ...) is combined with open source, its then up to the people to use this freedom. I know that this is a privileged point in the recent world, because if you have to deal the whole day to get food to survive or build up your home again after its gone because of some bombing in a war. I hope and would like to see every single human get the ability to get to this privileged point to have the time to deal with open knowledge instead of surviving.
But with the registration-procedure there is no sourcecode and a fully and transparent(i am able to read logfiles, prove everything, ...) system approving the registration. Thats why i wrote that in 2021 and wait since then.
I would like to know what the 'wrong accusations' are. I love to understand and fix things where i am wrong. I thus split now the accusations in numbers to be as exact as possible to be able to look at everything as rational as possible.
1. I got approved by hand after days waiting. <- this is what i experienced. Is this a wrong accusation?
2. Quote: Have the IP-address used for registration been tracked? <- this was a question that is still unanswered. Its based on a idea what could have been used for the manual approval. Is my idea IP addresses are been used for manual approval a wrong accusation?
3. Quote: Have the used email-address been tracked? <- this was a question that is still unanswered. Its based on a idea what could have been used for the manual approval. Is my idea email-addresses are been used for manual approval a wrong accusation?
3.1 Quote: E-mail-address-discrimination is illegal in many countries and this is completely breaking the freedom of choice! <- This is a legal (net neutrality laws) part of countries. Or is this a 'wrong accusation' you mentioned?
4. Quote: Username? <- this was a question that is still unanswered. Its based on a idea what could have been used for the manual approval. Is the idea usernames are been used for manual approval a wrong accusation?
4.1 Quote: Choosing (user)names is up to the user and making decision based on what names are 'allowed' to enter a platform is the most racist thing possible. <- This is also part of many laws in many countries. Telling a human that the human have the 'wrong name' is in general against many laws. Or is this part of a 'wrong accusation' you mentioned?
I hope i would get the ability to understand how this 'administrator approval' is done because i like in general to understand everything and also to have the ability to understand everything.
@ Paul Menzel:
> do you know of a solution to prevent the creation of spam accounts?
Thanks for the productive question. In general i try to first understand everything before i post a idea to something. Thats why i would still like to know what have been done to make this manual administration approval. But here is a answer in before:
Prevent spam? No, this is impossible in capitalism. As long as there is a financial benefit of spam, there would always be spam.
There should be no prevention. Prevention of anything that affect other people abilities is blocking freedom. Spam should be dealt with as off-topic. If i would ask in this ticket-instance how i could fix my vacuum cleaner (a model that have no firmware - something that have to be told this days) should be handled the same as some capitalistic offer of some pills for peoples private life.
There are two common ways implemented by many websites for many years to handle the spam-situation.
1. Let the people register and post without any blockage. If the thing(s) that have been posted was some pills offer or something like this, it gets deleted. In general its easy for administators by selecting the username, delete everything from the user and then delete the registration that is made for posting spam. This solution represent in general the laws in all countries. At first you can (have the ability) to do anything you are capable of. And if a thing you did is not allowed, this thing gets reverted and you get punished if possible/required. Simple example: You want to use your right of free speech. You print stickers and stick them at the train windows. In general this stickers get removed because this is not how you are allowed to represent your right of free speech.
2. A second common implementation on websites is to let people post on the website what they want to post but its unlisted until the written post get approved. This is not in common with the laws in many free countries (it would be completely wrong in a democratic country if your words you want to say and your banners you want to show would have to be approved from the government first).
But this is somewhat a not that great but ok'ish implementation on the internet.
To compare what is recently implemented on this site (to my understanding, i still have no answers to the questions i asked in year 2021):
3. A person (and not what the person want to say, there is nothing the person have written to base the approval-decision on) is been checked. The decision if the person is allowed to fill up a bug for coreboot is done by checking the identity of the person (name), the area the person is from (IP-address) and the service the person is using (email address).
This is by far the worst implementation possible. To give abilities (free speech) to people based on where they are from or what name they have is so bad, there is not a single more worse implementation of a system possible. There are history examples in Europe about 75 years ago. There decisions was made based on what name a human had and where the human was from.
If the decision is made on the entered email address, this is still terrible. Net neutrality is a extremely important thing. There should never ever be made a decision based on if some other person like the e-mail provider that is been used for registration or not. Such decision break for example completely the federated, open idea e-mail is based on.
----------------------------------------
Other #314: Please disable 'administrator approval' on ticket.coreboot.orghttps://ticket.coreboot.org/issues/314#change-1422
* Author: akjuxr3 akjuxr3
* Status: Closed (locked)
* Priority: Normal
* Category: infrastructure
* Start date: 2021-07-30
----------------------------------------
Please disable this 'administrator approval' on ticket.coreboot.org. It feels like discrimination. Before i have written the first word on ticket.coreboot.org i have to be approved by someone by hand without this person knowing anything from me. I had to wait several days for this approval. Its completely unclear what is been tracked. Have the IP-address used for registration been tracked? Have the used email-address been tracked? E-mail-address-discrimination is illegal in many countries and this is completely breaking the freedom of choice! Username? Choosing (user)names is up to the user and making decision based on what names are 'allowed' to enter a platform is the most racist thing possible.
Conclusion: This 'administrator approval' is sort of discrimination i have not seen for years on free projects! There is no data available at the registration process that could or should be used to decide who is allowed to report a bug in the coreboot project. Please disable this discrimination that is stopping people for days or even forever to report a coreboot issue.
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #456 has been reported by Thierry Laurion.
----------------------------------------
Bug #456: coreboot 4.19 tarballs are unusable
https://ticket.coreboot.org/issues/456
* Author: Thierry Laurion
* Status: New
* Priority: High
* Category: infrastructure
* Target version: 4.19
* Start date: 2023-02-08
* Affected versions: 4.19, master
* Needs backport to: 4.19, master
----------------------------------------
As reported on #coreboot channel, coreboot 4.19 tarballs contain invalid timestamps (year 1901) for all contained files.
Reproducility of issue:
wget https://www.coreboot.org/releases/coreboot-4.19.tar.xz
user@heads-tests:/tmp/test$ ls -al coreboot-4.19.tar.xz
-rw-r--r-- 1 user user 56908588 Jan 26 21:46 coreboot-4.19.tar.xz
user@heads-tests:/tmp/test$ tar Jxvf coreboot-4.19.tar.xz
coreboot-4.19/
coreboot-4.19/.checkpatch.conf
tar: coreboot-4.19/.checkpatch.conf: implausibly old time stamp -9223372036854775808
coreboot-4.19/.clang-format
tar: coreboot-4.19/.clang-format: implausibly old time stamp -9223372036854775808
coreboot-4.19/.coreboot-version
tar: coreboot-4.19/.coreboot-version: implausibly old time stamp -9223372036854775808
coreboot-4.19/.crossgcc-version
tar: coreboot-4.19/.crossgcc-version: implausibly old time stamp -9223372036854775808
coreboot-4.19/.editorconfig
tar: coreboot-4.19/.editorconfig: implausibly old time stamp -9223372036854775808
Cause:
@icon investigated and said "d05ea79e40c4 util/release/build-release: Fix style issues
at least that change to the tstamp variable looks very suspicious"
flx suggested to recreate the archive: "I think 4.19-2 would be better. There are no changes to coreboot or anything. It also doesn't need a new git tag"
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account
Issue #445 has been updated by Masc Masc.
I would like to add a latest update. I have been having the wifi card problem intermittently and I decided to change it.
I purchased another Atheros AR5B95 and so far the problem seems resolved (I have been testing it for a few days and the issue seems gone), supporting the idea in Martin Roth's post.
----------------------------------------
Bug #445: Thinkpad X200 wifi issue
https://ticket.coreboot.org/issues/445#change-1418
* Author: Masc Masc
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2023-01-06
* Affected versions: 4.18
----------------------------------------
Compiled coreboot latest revision from source and built a coreboot rom image for X200 with SeaBIOS (also tried with Grub as a payload). The laptop beeps and the power LED flashes at startup and the wifi card does not work (cannot enable wifi in OS).
The operating system is Debian Bullseye and the wifi card is an Atheros AR5B95. The OS boots normally, but no wifi is available. The wifi card has been tested and works fine with latest stable libreboot release.
---Files--------------------------------
config (18.1 KB)
cbmem.txt (42.4 KB)
dmesg.txt (62.8 KB)
lspci_nn_libreboot.txt (2.42 KB)
lspci_tv_libreboot.txt (1.47 KB)
lspci_vvvxx_libreboot.txt (31.1 KB)
lspci_nn_coreboot.txt (2.42 KB)
lspci_tv_coreboot.txt (1.48 KB)
lspci_vvvxx_coreboot.txt (31.6 KB)
--
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: https://ticket.coreboot.org/my/account