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
Issue #314 has been updated by Felix Singer.
Status changed from Response Needed to Closed (locked)
@akjuxr3, you are doing very strong accusations against the project and the administrators of this service without providing any proof. Since I am administrating this service, I am taking this very serious and I really don't like getting wrong accusations.
Not anything from what you are saying is true. The coreboot project tries to be inclusive as much as possible and people, me including, didn't know what to say or what to think while reading this. People are working hard and using their spare time, while having a day job, to give you the best possible experience. When we have to deal with things like this, then it's not just annoying or frustrating but it hurts, which might discourage people from spending their time on the project.
Patrick already explained the reason for that. We have to deal with spam accounts, rather some form of bots creating accounts, and this prevents them to flood this ticket system with spam. I'm trying to find ways to get rid of that, but there are not many options. So I do think this is a valid and reasonable solution so that the ticket system stays usable.
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.
I'm going to close this ticket.
----------------------------------------
Other #314: Please disable 'administrator approval' on ticket.coreboot.orghttps://ticket.coreboot.org/issues/314#change-1415
* 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