Am Montag, den 12.12.2016, 14:50 +0100 schrieb Elena ``of Valhalla'':
> On 2016-12-12 at 13:18:42 +0100, Łukasz Dobrowolski wrote:
> > On 12/12/2016 03:27 AM, Taiidan(a)gmx.com wrote:
> > > (...) considering that the average linux sysadmin makes over
> > > $100K per year the community could have easily funded the
> > > project.
> > In Germany, US, France... Not in Poland, Ukraine... many hackers there.
> Indeed. In my country 20k EUR per year is a good pay, but even with a
> pay of 60k EUR|$ a year, that would mean paying the whole earnings of a
> month for something that is still at the crowdfunding stage and may just
> disappear into nothing.
> If you consider that people have to, well, live with that money, that
> would mean multiple months of savings / disposable income.
> If somebody has a family, that probably goes in the range of expenses
> that have to be negotiated with the other family members.
> All of this necessarily reduces the number of people who can even think
> about partecipating in that crowdfunding, not to say actually decide to
> put down their money for it.
Unfortunately, I don’t agree. There was the option to support the
project with less money. People can pledge $10, $250, or $500. In my
opinion, everybody interested in user-controlled hardware would be able
to spend at least $10. But it looks like there are well below 300
people interested in that. That is very sad to see, that people are not
willing to support to kick-start such a project to maybe profit in the
future from cheaper devices.
In my opinion, people are ignorant about the locked-down hardware issue
and some don’t care.
On the other hand, I also think, that maybe marketing was probably not
as successful as for other projects.
At least I didn’t see a lot of marketing support from the FSF, FSFE,
and EFF. The media also didn’t help very much.
PS: Wikipedia is also asking for donations right now. Despite the bad
things about Wikipedia, I guess most of us use it daily and want it to
remain maintained and free of advertisement.
never mind, pilot error, I did not realize it was a linux partition, not
On Tue, Dec 13, 2016 at 3:20 PM ron minnich <rminnich(a)gmail.com> wrote:
> we have a kgpe-d16 with seabios as the payload and would like to usb boot.
> We have two sticks which work fine on other systems.
> seabios is not seeing the usb sticks. Anyone have configuration or other
> hints about what I might be doing wrong?
we have a kgpe-d16 with seabios as the payload and would like to usb boot.
We have two sticks which work fine on other systems.
seabios is not seeing the usb sticks. Anyone have configuration or other
hints about what I might be doing wrong?
On Tue, Dec 06, 2016 at 02:40:46AM +0800, Pok Gu wrote:
>Thanks all. I value all your concerns on freedom (not opensource) and
>security and the feeling of having control.
>Let's say down to earth. I just wondering are there any other cool things
>(e.g., unlocking features) we can get. Because it seems the reason that
>other projects (e.g., OpenWRT) is so popular is it unlock many features
>along with the freedom/security once a router flash it.
Yes, you get rid of the PCI whitelist allowing you to use any wifi
module (being supported by free drivers). You may also install more RAM
depending on both board and RAM type.
Please correct me if I'm wrong.
On Mon, Dec 12, 2016 at 03:08:53PM -0600, Aaron Durbin via coreboot wrote:
> What about the SSDT? With the patch I think the device is in the SSDT
> -- not DSDT.
Whups, forgot to include it. There is far less change:
--- ./no-tpm/SSDT.dsl 2016-12-12 17:23:51.314355365 -0500
+++ ./yes-tpm/SSDT.dsl 2016-12-12 17:24:08.694610389 -0500
@@ -5,13 +5,13 @@
* Disassembling to symbolic ASL+ operators
- * Disassembly of SSDT, Mon Dec 12 17:23:51 2016
+ * Disassembly of SSDT, Mon Dec 12 17:24:08 2016
* Original Table Header:
* Signature "SSDT"
* Length 0x0000170D (5901)
* Revision 0x02
- * Checksum 0xB4
+ * Checksum 0x83
* OEM ID "CORE "
* OEM Table ID "COREBOOT"
* OEM Revision 0x0000002A (42)
@@ -73,7 +73,7 @@
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
- 0xBFEED000, // Address Base
+ 0xBFEF0000, // Address Base
0x00008000, // Address Length
My x230's TPM has gone missing somewhere between 4.5 and the current head.
CONFIG_LPC_TPM is still set, but neither coreboot nor the Linux payload
detects it. Bisecting will take a while since it requires reflashing;
does anyone know where it might have gone?
I think it would be interesting to have such functionality in userspace.
On Mon, Dec 12, 2016 at 8:04 AM Michal Widlok <michalwd1979(a)gmail.com>
> Dear Members,
> I looking for a way to set battery charge thresholds on T400 with
> coreboot. I know that tp_smapi are not supported, but I found an
> interesting thread (it's for X220, but I hope that my would be
> The post says:
> "tp smapi depends on lot of SMM/SMI code. So tp-smapi kernel module
> asked the Lenovo BIOS to tell the EC to do something. coreboot don't
> want to support SMM/SMI APIs, because they are quite dangerous.
> But there is another way to get those features back.
> We know how to enable it, but we haven't yet create a way to control
> this by the user.
> One thing could be a userspace tool executed as root or we add another
> CMOS configuration for it. Any idea?"
> Is that mean that EC in lenovo laptops is "known" enough to control
> it, but coreboot is not ready to implement this functionality? An if
> it is known the is there any literature/posts available that says how
> to control it with ectool or something?
> If there are any test needed to be done to help about this subject,
> then I can do them on my laptop. Hardware flashing is possible also.
> Very best regards,
> Michael Widlok
> coreboot mailing list: coreboot(a)coreboot.org
The Linux 4.7 kernel payload crashes early in the boot process
with CoreBoot 4.4. I traced it to these instructions that are
finding a safe spot to decompress the rest of the kernel and
patched around it with a hard coded location:
diff -u --recursive /home/hudson/build/clean/linux-4.7/arch/x86/boot/compressed/head_64.S ./linux-4.7/arch/x86/boot/compressed/head_64.S
--- /home/hudson/build/clean/linux-4.7/arch/x86/boot/compressed/head_64.S 2016-07-24 15:23:50.000000000 -0400
+++ ./linux-4.7/arch/x86/boot/compressed/head_64.S 2016-08-05 12:07:11.399854225 -0400
@@ -340,9 +357,15 @@
/* Target address to relocate to for decompression */
movl BP_init_size(%rsi), %ebx
subl $_end, %ebx
addq %rbp, %rbx
+ // coreboot does not populate the init_size boot param?
+ // fake it with a hard coded value
+ movl $0x97b000, %ebx
/* Set up the stack */
leaq boot_stack_end(%rbx), %rsp
It seems that the Linux kernel bzImage is supposed to set this value,
rather than coreboot, so my comment is likely incorrect.
Dumping linux-4.7/arch/x86/boot/header.o, it looks like init_siez
is supposed to be 0xcf5000, so I wonder if %rsi is pointing to the
In 4.6.4 the computed address was hardcoded:
movl $LOAD_PHYSICAL_ADDR, %ebx
/* Target address to relocate to for decompression */
addl $z_extract_offset, %ebx
3e: bb 00 00 00 01 mov $0x1000000,%ebx
43: 81 c3 00 00 00 00 add $0x0,%ebx
I looking for a way to set battery charge thresholds on T400 with
coreboot. I know that tp_smapi are not supported, but I found an
interesting thread (it's for X220, but I hope that my would be
The post says:
"tp smapi depends on lot of SMM/SMI code. So tp-smapi kernel module
asked the Lenovo BIOS to tell the EC to do something. coreboot don't
want to support SMM/SMI APIs, because they are quite dangerous.
But there is another way to get those features back.
We know how to enable it, but we haven't yet create a way to control
this by the user.
One thing could be a userspace tool executed as root or we add another
CMOS configuration for it. Any idea?"
Is that mean that EC in lenovo laptops is "known" enough to control
it, but coreboot is not ready to implement this functionality? An if
it is known the is there any literature/posts available that says how
to control it with ectool or something?
If there are any test needed to be done to help about this subject,
then I can do them on my laptop. Hardware flashing is possible also.
Very best regards,