[coreboot] Goodies for Bonn meeting

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello, all. My girlfriend Maria (CC'ed) would like to organize some
goodies for coreboot meeting. Already available are black T-shirts:
2 x M, 8 x L, 1 x XL according to my notes, it's no guarantee, I can't
double-check now as I'm travelling.
Expected price is under €20 for any of items.
Capacity is limited, first come first serve, respond to this e-mail to
order.
What else we can do:
- White t-shirt
- white cups
- colour cups
- Fridge magnets
- case for iPhone (indicate which one), not sure which ones are available
- Beer coaster
- mouse pad
- baseball cap

In addition, if you're ok with waiting about a month + delivery time we
can order:
- Black t-shirt (other than the sizes mentioned above, or once the stock
is out)
- Colour t-shirt over €20

We're doing it just for fun and to serve the community, the price is
only to cover our costs.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Fwd: Coreboot T-shirts

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 31.05.2015 19:27, Matthias Apitz wrote:
> El día Sunday, May 31, 2015 a las 06:45:48PM +0200, Vladimir 
> 'φ-coder/phcoder' Serbinenko escribió:
> 
>> Good news: now it's possible to have them in black as well.
>> I received up to now only one request to which I replied by personal
>> mail. If you didn't receive any reply, please resend your request.
>> Please specify in request the size, color (white, black, few other
>> colors if someone is interested), quantity and if you want it single or
>> double-sided printing.
>>
>> Please tell me until Friday.
> 
> Please post again an URL of the t-shirt layout. Thanks
> 
I don't have the URL. I'm waiting for Carl-Daniel to give me the file
(in any format) wit layout he used last time.
>   matthias
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Fwd: Coreboot T-shirts

[Vladimir 'φ-coder/phcoder' Serbinenko]

Good news: now it's possible to have them in black as well.
I received up to now only one request to which I replied by personal
mail. If you didn't receive any reply, please resend your request.
Please specify in request the size, color (white, black, few other
colors if someone is interested), quantity and if you want it single or
double-sided printing.

Please tell me until Friday.

@Carl-Daniel: Still waiting for that PDF.

On 21.05.2015 15:41, Vladimir 'phcoder' Serbinenko wrote:
> Apparently original mail didn't make it to the list. Resent
> 
> 
> -- Forwarded message --
> From: Vladimir 'phcoder' Serbinenko 
> Date: Thu, May 21, 2015 at 2:29 PM
> Subject: Re: [coreboot] Coreboot T-shirts
> To: Carl-Daniel Hailfinger 
> Cc: coreboot 
> 
> 
> 
> Le 21 mai 2015 13:01, "Carl-Daniel Hailfinger"
>  a écrit :
>>
>> On 21.05.2015 12:51, Vladimir 'phcoder' Serbinenko wrote:
>>> A contact of mine proposes to print coreboot T-shirts for the community.
>>> Black printing on white T-shirt. Expected price is 30€-35€ + shipping from
>>> CH or DE, double-sided printing, one-sided is 5-8€ less. It will be printed
>>> in Russia.
>>
>> Please note that the coreboot T-Shirt I am wearing is black, with the
>> logo being a white plastic foil melted/glued to the t-shirt.
>> Could you ask your contact whether such a variant would be possible as
>> well? The foil variant is extremely durable and IMHO a black T-Shirt
>> fits a bit better with all the other hacker culture T-Shirts.
>>
> I already did. Unfortunately it's not possible at this point
>>> I need to know who wants one and sizes by June 5th. For payment
>>> I accept paypal and bank wiring.
>>> It will be available in ~August. Do we have some kind of dev meeting in
>>> autumn where I could bring them?
>>> @carldani: could you give me the file used for printing?
>>
>> Sure.
>>
>> Regards,
>> Carl-Daniel
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] SPD CRC failed

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 21.05.2015 16:19, Michael Gerlach wrote:
> Okay here we go...
> 
> I memtested the modules again and as expected no defect was found. So i
> retried latest master today and quite unusually it just boots up.
> 
Quite possibly you were just missing microcode update.
> It does not reach payload-state still, but ram and frequency is detected
> correctly. Fan is turning on and backlight gets activated but no output
> is displayed. Besides it seems to die at unpredictable states. I
> attached 3 different boot logs..
> 
> The only assumption could be a defect in some piece of hardware, but i
> do not had any trouble with this x230 yet..
> 
> On the other hand _this_ build was compiled on the x230 itself, while
> the other builds were compiled on a x201 with an identical bootstrapped
> toolchain..
> 
> Any idea what possibly cause a similar behavior too?
> 
It could be something with modules. They may have very unusual
high-frequency characteristics. I didn't see it occur with code that we
have currently but it remains a theoretical possibility.
> 
> 
> Best regards,
> 
> n3ph
> 
> 
> On 05/20/15 23:45, David Hendricks wrote:
>>
>>
>> On Wed, May 20, 2015 at 1:13 PM, Michael Gerlach > > wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> I forgot to mention that somehow the ram frequency is not detected
>> correctly...
>>
>>  PLL busy...done
>> PLL didn't lock. Retrying at lower frequency
>>  PLL busy...done
>> PLL didn't lock. Retrying at lower frequency
>>  PLL busy...done
>> PLL didn't lock. Retrying at lower frequency
>>  PLL busy...done
>> PLL didn't lock. Retrying at lower frequency
>> No lock frequency found
>>
>>
>> The SPD data should be read via SMBus long before PLL locking for the
>> DRAM itself takes place.
>>
>> If you're unable to successfully read the SPDs, then it makes sense that
>> later init would fail.
>>
>> -- 
>> David Hendricks (dhendrix)
>> Systems Software Engineer, Google Inc.
> 
> 
> 
> 


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] rfkill equivalent on the X60 - first partial success

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 08.12.2014 01:00, Charles Devereaux wrote:
> Sorry, but if it is like the X60 it can not be made the work.
> 
> Just like in the WWAN slot, but in reverse, the USB lines are not wired
> on the WLAN slot.
> 
> IIRC this is not the case on the X201 (a very nice machine, but coreboot
> support may not be as good for the moment. However the ACPI tables look
> more complete.)
> 
Please provide problem descriptions when doubting the quality of my
work. Otherwise you're empty-talking.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] rfkill equivalent on the X60 - first partial success

[Vladimir 'φ-coder/phcoder' Serbinenko]

> > To emulate rfkill functionality, just write directly to the ec, for ex
> > to turn on wwan and wifi:
> > ./ec_access -w 0x3a -v 0x60
> >
> Usecase?
> 
> 
> Example: I have a wwan card, but I mostly use it for GPS. I can save
> some power by turning it off without rebooting, while keeping wifi on with:
I'd like to see some real figures on power saved between idle wwan and
disabled wwan, I really doubt it's anything noticeable
> The hardware button is not safe enough : register 0x3A hasthe H/W
> Override bitto "enable to control wireless devices even if the global
> WAN disable switch is ON". Disabling the USB ports through the RCBA
> registers (nice idea!) would prevent such an override.
> 
> Also, it would save more power on the wwan that the hardware button :
> the wwan module is not fully desactivated since it replies to AT commands
> 
> Several persons do not fully trust a wwan module. Physically removing it
> is the solution suggested. Disabling the usb port would be a simpler
> solution for those than do not want to physically open their laptop yet
> do not trust the hardware button due to the override bit.
> 
wwan module is powered unconditionally. So if you don't trust it -
remove it. Also none of disables discussed here is irreversible if
you're concerned about rogue software.
> It seems to have several usecase.
None of them looks valid



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] rfkill equivalent on the X60 - first partial success

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 03.12.2014 23:32, Charles Devereaux wrote:
> Hello
> 
> As explained before, thinkpad-acpi can't control the non-wifi radio like
> bluetooth or wwan, because it expects some ACPI entries that aren't
> there - so there is no rfkill control for these, even if some
> non-working entries are shown with 'rfkill list'
> 
You have a hardware button to do an rfkill. I don't see why software
should mess more with this.
> To emulate rfkill functionality, just write directly to the ec, for ex
> to turn on wwan and wifi:
> ./ec_access -w 0x3a -v 0x60
> 
Usecase?
> It works great for bluetooth, basically "physically unplugging" the
> device so that if you have uhci_hcd as a module, an rmmod/modprobe will
> no longer show the device on lsusb.
> 
RCBA registers can disable any USB ports. But again: usecase?




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Infrastructure work

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello, all. I know I've signed up to fix board-status and cmos but I
don't want to go through painful reviews, so I'm not going to do this,
even though maintaining current CMOS stuff is a pain in itself.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] board-status "binary"

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 22.11.2014 17:28, John Lewis wrote:
> 
> 
> On 22/11/14 15:55, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 22.11.2014 12:22, John Lewis wrote:
>>>
>>>
>>> On 21/11/14 21:58, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>>> On 14.11.2014 12:44, John Lewis wrote:
>>>>> Hey y'all,
>>>>>
>>>>> I've modified the board-status script to have as few external
>>>>> dependencies as possible, be a self-extracting, self-running "binary".
>>>>> and removed the time-stamp to keep the number initial commits down.
>>>>> Feel
>>>>> free to tell me how bad it is and how it murdered your children. :P
>>>>>
>>>> Never send binaries to the list.
>>>
>>> A link could be just as malicious. What way should I do it?
>>>
>> A link would be fine. It wouldn't make everybody uninterested in this
>> topic but subscribed to the list download 1M file.
> 
> I understand what you mean now - people perhaps stuck on low-bandwidth
> links with expensive data plans.
> 
>>>> And about the idea: current code needs git tree. I tried to make
>>>> changes
>>>> to make it possible to have board-status without git tree.
>>>>
>>>> Result: those change were ignored, bikeshed or vetoed.
>>>>
>>>> Long story short: nobody cares.
>>>
>>> At some point Ron did care, otherwise we wouldn't have been talking
>>> about it, and I certainly do. I can tell you anecdotally which
>>> Chromebooks are being used and should remain live in the code-base
>>> (hint: all of them) but I thought we were trying to be more scientific
>>> about it than that.
>>>
>> Speaking is about where it usually stops. It's been very disappointing.
>> Usual scenario is that we get lots of discussion to do sth, everybody is
>> dissatisfied with current status and when I spend huge chunk of my
>> personal time to fix it, nobody is there to even review the patches.
>> That's understandable: otherwise what will we speak about next time if
>> the issue is solved? Still it's disappointing and I have better things
>> to do with my personal time than making patches nobody cares about.
>> The top of rename stack is at 7185. It's automated test and Stefan
>> agreed to it in principle in Prague, yet it's sitting there for already
>> 3 weeks.
> 
> Okay, well the binary as is will upload stuff to the current
> board-status repo, so maybe that's enough. I'm trying to encourage
> people to use it. We'll see if we can get maybe a few hundred people to
> upload something, given time.
> 
Determining of mainboard is wrong for clones. I was trying to fix this a
while ago but I stopped carying.
>>>>> John.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>>
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] board-status "binary"

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 22.11.2014 12:22, John Lewis wrote:
> 
> 
> On 21/11/14 21:58, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 14.11.2014 12:44, John Lewis wrote:
>>> Hey y'all,
>>>
>>> I've modified the board-status script to have as few external
>>> dependencies as possible, be a self-extracting, self-running "binary".
>>> and removed the time-stamp to keep the number initial commits down. Feel
>>> free to tell me how bad it is and how it murdered your children. :P
>>>
>> Never send binaries to the list.
> 
> A link could be just as malicious. What way should I do it?
> 
A link would be fine. It wouldn't make everybody uninterested in this
topic but subscribed to the list download 1M file.
>> And about the idea: current code needs git tree. I tried to make changes
>> to make it possible to have board-status without git tree.
>>
>> Result: those change were ignored, bikeshed or vetoed.
>>
>> Long story short: nobody cares.
> 
> At some point Ron did care, otherwise we wouldn't have been talking
> about it, and I certainly do. I can tell you anecdotally which
> Chromebooks are being used and should remain live in the code-base
> (hint: all of them) but I thought we were trying to be more scientific
> about it than that.
> 
Speaking is about where it usually stops. It's been very disappointing.
Usual scenario is that we get lots of discussion to do sth, everybody is
dissatisfied with current status and when I spend huge chunk of my
personal time to fix it, nobody is there to even review the patches.
That's understandable: otherwise what will we speak about next time if
the issue is solved? Still it's disappointing and I have better things
to do with my personal time than making patches nobody cares about.
The top of rename stack is at 7185. It's automated test and Stefan
agreed to it in principle in Prague, yet it's sitting there for already
3 weeks.
>>> John.
>>>
>>>
>>
>>
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] board-status "binary"

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 14.11.2014 12:44, John Lewis wrote:
> Hey y'all,
> 
> I've modified the board-status script to have as few external
> dependencies as possible, be a self-extracting, self-running "binary".
> and removed the time-stamp to keep the number initial commits down. Feel
> free to tell me how bad it is and how it murdered your children. :P
> 
Never send binaries to the list.
And about the idea: current code needs git tree. I tried to make changes
to make it possible to have board-status without git tree.

Result: those change were ignored, bikeshed or vetoed.

Long story short: nobody cares.
> John.
> 
> 


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] unable to build coreboot with grub

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 12.10.2014 13:30, Vipin Gahlaut wrote:
> Thanks a lot Valdimir,
> 
> After "make clean" ROM Size config changes kicked in as expected and I
> managed to build grub payload.
> 
Please keep the list CC'ed
> Thanks you very much for your help and support.
> 
> 
> 
> On Sun, Oct 12, 2014 at 4:39 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> mailto:phco...@gmail.com>> wrote:
> 
> On 12.10.2014 13:03, Vipin Gahlaut wrote:
> > Ok, I changed CONFIG_BOARD_ROMSIZE_KB_ to 512 directly in .config as
> > this is can not be changed in menuconfig.
> Don't. You don't need to change it at all.
> > My .config lokks like below
> > and it still it says 262KB is too big?
> >
> Always do "make clean" after config change
> > # CONFIG_BOARD_ROMSIZE_KB_256 is not set
> > CONFIG_BOARD_ROMSIZE_KB_512=y
> > # CONFIG_COREBOOT_ROMSIZE_KB_64 is not set
> > # CONFIG_COREBOOT_ROMSIZE_KB_128 is not set
> > # CONFIG_COREBOOT_ROMSIZE_KB_256 is not set
> > CONFIG_COREBOOT_ROMSIZE_KB_512=y
> > # CONFIG_COREBOOT_ROMSIZE_KB_1024 is not set
> > # CONFIG_COREBOOT_ROMSIZE_KB_2048 is not set
> > # CONFIG_COREBOOT_ROMSIZE_KB_4096 is not set
> > # CONFIG_COREBOOT_ROMSIZE_KB_8192 is not set
> > # CONFIG_COREBOOT_ROMSIZE_KB_12288 is not set
>     > # CONFIG_COREBOOT_ROMSIZE_KB_16384 is not set
> > CONFIG_COREBOOT_ROMSIZE_KB=512
> > CONFIG_ROM_SIZE=0x8
> >
> >
> > On Sun, Oct 12, 2014 at 4:21 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> > mailto:phco...@gmail.com>
> <mailto:phco...@gmail.com <mailto:phco...@gmail.com>>> wrote:
> >
> > On 12.10.2014 12:44, Vipin Gahlaut wrote:
> > > I tried changing under main mainboard -> rom chip size but
> does not seem
> > > to be helping. If I look at .config I suspect that the reason is
> > > CONFIG_BOARD_ROMSIZE_KB_256=y which doesn't change even if I
> change ROM
> > > size in main board.
> > CONFIG_BOARD_ROMSIZE_KB_* is the default used by
> > CONFIG_COREBOOT_ROMSIZE_KB_*
> >
> >
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] unable to build coreboot with grub

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 12.10.2014 13:03, Vipin Gahlaut wrote:
> Ok, I changed CONFIG_BOARD_ROMSIZE_KB_ to 512 directly in .config as
> this is can not be changed in menuconfig.
Don't. You don't need to change it at all.
> My .config lokks like below
> and it still it says 262KB is too big?
> 
Always do "make clean" after config change
> # CONFIG_BOARD_ROMSIZE_KB_256 is not set
> CONFIG_BOARD_ROMSIZE_KB_512=y
> # CONFIG_COREBOOT_ROMSIZE_KB_64 is not set
> # CONFIG_COREBOOT_ROMSIZE_KB_128 is not set
> # CONFIG_COREBOOT_ROMSIZE_KB_256 is not set
> CONFIG_COREBOOT_ROMSIZE_KB_512=y
> # CONFIG_COREBOOT_ROMSIZE_KB_1024 is not set
> # CONFIG_COREBOOT_ROMSIZE_KB_2048 is not set
> # CONFIG_COREBOOT_ROMSIZE_KB_4096 is not set
> # CONFIG_COREBOOT_ROMSIZE_KB_8192 is not set
> # CONFIG_COREBOOT_ROMSIZE_KB_12288 is not set
> # CONFIG_COREBOOT_ROMSIZE_KB_16384 is not set
> CONFIG_COREBOOT_ROMSIZE_KB=512
> CONFIG_ROM_SIZE=0x8
> 
> 
> On Sun, Oct 12, 2014 at 4:21 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> mailto:phco...@gmail.com>> wrote:
> 
> On 12.10.2014 12:44, Vipin Gahlaut wrote:
> > I tried changing under main mainboard -> rom chip size but does not seem
> > to be helping. If I look at .config I suspect that the reason is
> > CONFIG_BOARD_ROMSIZE_KB_256=y which doesn't change even if I change ROM
> > size in main board.
> CONFIG_BOARD_ROMSIZE_KB_* is the default used by
> CONFIG_COREBOOT_ROMSIZE_KB_*
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] unable to build coreboot with grub

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 12.10.2014 12:44, Vipin Gahlaut wrote:
> I tried changing under main mainboard -> rom chip size but does not seem
> to be helping. If I look at .config I suspect that the reason is
> CONFIG_BOARD_ROMSIZE_KB_256=y which doesn't change even if I change ROM
> size in main board.
CONFIG_BOARD_ROMSIZE_KB_* is the default used by
CONFIG_COREBOOT_ROMSIZE_KB_*



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] unable to build coreboot with grub

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 12.10.2014 11:57, John Lewis wrote:
> Hi,
> 
> It's in "Chipset Options" -> "Size of CBFS filesystem in ROM" - 0x20
> or 0x40 will work.
> 
This is only for recent intel chipsets.
> Cheers,
> 
> John.
> 
> On 12/10/14 10:51, Vipin Gahlaut wrote:
>> Thanks Vladimir,
>>
>>
>> Can you please let me know how to increase the ROM size?
>>
>>
>> -Original Message-
>> From: Vladimir 'φ-coder/phcoder' Serbinenko [mailto:phco...@gmail.com
>> <mailto:phco...@gmail.com>]
>> Sent: Sunday, October 12, 2014 3:02 PM
>> To: Vipin Gahlaut; coreboot
>> Subject: Re: [coreboot] unable to build coreboot with grub
>>
>> On 12.10.2014 08:03, Vipin Gahlaut wrote:
>>
>>  > Hi,
>>
>>  >
>>
>>  > I have cloned latest coreboot and trying to build with grub2 as
>> payload.
>>
>>  > in make menuconfig I select grub2 instead of seabios. when I fire make
>>
>>  > command it checkout latest grub and that fails to build. for 2
>> reasons.
>>
>>  >
>>
>>  > 1. Due to some initialization errors that I managed to fix with below
>>
>>  > changes
>>
>>  > -struct grub_linux_initrd_context initrd_ctx = { 0, };
>>
>>  > +struct grub_linux_initrd_context initrd_ctx = { 0,NULL,0 };
>>
>>  >
>>
>> Sounds like you have an old gcc
>>
>>  > 2. grub size issue as below that I am unable to resolve and looking
>>
>>  > for your help. I am building for QEMU and using QEMU version 2.1.2.
>>
>>  >
>>
>>  > E: Could not add
>>
>>  > [payloads/external/GRUB2/grub2/build/default_payload.elf, 268862 bytes
>>
>>  > (262 KB)@0x0]; too big?
>>
>>  > E: Failed to add
>>
>>  > 'payloads/external/GRUB2/grub2/build/default_payload.elf' into ROM
>> image.
>>
>>  >
>>
>> Increase ROM size.
>>
>>  >
>>
>>  >
>>
>>  >
>>
>>
>> On Sun, Oct 12, 2014 at 11:33 AM, Vipin Gahlaut > <mailto:gail...@gmail.com>> wrote:
>>
>> Hi,
>>
>> I have cloned latest coreboot and trying to build with grub2 as
>> payload. in make menuconfig I select grub2 instead of seabios. when
>> I fire make command it checkout latest grub and that fails to build.
>> for 2 reasons.
>>
>> 1. Due to some initialization errors that I managed to fix with
>> below changes
>> -  struct grub_linux_initrd_context initrd_ctx = { 0, };
>> +  struct grub_linux_initrd_context initrd_ctx = { 0,NULL,0 };
>>
>> 2. grub size issue as below that I am unable to resolve and looking
>> for your help. I am building for QEMU and using QEMU version 2.1.2.
>>
>> E: Could not add
>> [payloads/external/GRUB2/grub2/build/default_payload.elf, 268862
>> bytes (262 KB)@0x0]; too big?
>> E: Failed to add
>> 'payloads/external/GRUB2/grub2/build/default_payload.elf' into ROM
>> image.
>>
>>
>>
>>
>>
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Prague meeting: hardware

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello, all. I've updated
http://www.coreboot.org/PragueMeetingHardware#phcoder . If somebody
wants me to bring sth, please add a paragraph there, otherwise, I won't
take almost anything.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] unable to build coreboot with grub

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 12.10.2014 08:03, Vipin Gahlaut wrote:
> Hi,
> 
> I have cloned latest coreboot and trying to build with grub2 as payload.
> in make menuconfig I select grub2 instead of seabios. when I fire make
> command it checkout latest grub and that fails to build. for 2 reasons.
> 
> 1. Due to some initialization errors that I managed to fix with below
> changes
> -  struct grub_linux_initrd_context initrd_ctx = { 0, };
> +  struct grub_linux_initrd_context initrd_ctx = { 0,NULL,0 };
> 
Sounds like you have an old gcc
> 2. grub size issue as below that I am unable to resolve and looking for
> your help. I am building for QEMU and using QEMU version 2.1.2.
> 
> E: Could not add
> [payloads/external/GRUB2/grub2/build/default_payload.elf, 268862 bytes
> (262 KB)@0x0]; too big?
> E: Failed to add
> 'payloads/external/GRUB2/grub2/build/default_payload.elf' into ROM image.
> 
Increase ROM size.
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] broken boards

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 11.10.2014 03:20, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 11.10.2014 03:03, ron minnich wrote:
>> Android defaults sometimes surprise me.
>>
>> When we've had this kind of issue in the past a disassembly diff   of
>> good vs bad has sometimes led to diagnosis. I think you have a rough
>> idea what's broken so start there. Painful but necessary.
>>
> .car.data is linked at wrong address.
> Working:
>   4 .car.data 00b4  ff7f  ff7f  00012b00  2**5
>   CONTENTS
> Broken:
>   4 .car.data 00ac      00012b00  2**5
>   CONTENTS
> 
http://review.coreboot.org/7042
>> Ron
>>
>>
>>
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] broken boards

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 11.10.2014 03:03, ron minnich wrote:
> Android defaults sometimes surprise me.
> 
> When we've had this kind of issue in the past a disassembly diff   of
> good vs bad has sometimes led to diagnosis. I think you have a rough
> idea what's broken so start there. Painful but necessary.
> 
.car.data is linked at wrong address.
Working:
  4 .car.data 00b4  ff7f  ff7f  00012b00  2**5
  CONTENTS
Broken:
  4 .car.data 00ac      00012b00  2**5
  CONTENTS

> Ron
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [coreboot-gerrit] Patch set updated for coreboot: 3906937 amdfam14: Switch to per-device ACPI

[Vladimir 'φ-coder/phcoder' Serbinenko]

Success. Addresses are slightly different and new XSDT table but both
are ok and expected.
On 11.10.2014 00:16, Paul Menzel wrote:
> Dear Vladimir,
> 
> 
> Am Mittwoch, den 08.10.2014, 21:29 +0200 schrieb Vladimir Serbinenko:
>> Vladimir Serbinenko (phco...@gmail.com) just uploaded a new patch set to 
>> gerrit, which you can find at http://review.coreboot.org/7031
>>
>> -gerrit
>>
>> commit 390693798eebf2a371b32915a5ee239ba0b3a8bd
>> Author: Vladimir Serbinenko 
>> Date:   Wed Oct 8 21:18:31 2014 +0200
>>
>> amdfam14: Switch to per-device ACPI
>> 
>> Change-Id: Icc663c28713f2d872bfeb1749303ce92db953bf5
>> Signed-off-by: Vladimir Serbinenko 
>> ---
>>  src/mainboard/amd/inagua/acpi_tables.c | 206 
>> 
>>  src/mainboard/amd/persimmon/acpi_tables.c  | 205 
>> 
>>  src/mainboard/amd/south_station/acpi_tables.c  | 206 
>> 
>>  src/mainboard/amd/union_station/acpi_tables.c  | 206 
>> 
>>  src/mainboard/asrock/e350m1/acpi_tables.c  | 206 
>> 
>>  src/mainboard/gizmosphere/gizmo/acpi_tables.c  | 206 
>> 
>>  src/mainboard/jetway/nf81-t56n-lf/acpi_tables.c| 207 
>> -
>>  src/mainboard/lippert/frontrunner-af/acpi_tables.c | 206 
>> 
>>  src/mainboard/lippert/toucan-af/acpi_tables.c  | 206 
>> 
>>  src/northbridge/amd/agesa/family14/Kconfig |   1 +
>>  src/northbridge/amd/agesa/family14/northbridge.c   | 131 +
>>  11 files changed, 132 insertions(+), 1854 deletions(-)
> 
> […]
> 
> please find the acpidump outputs from running on the ASRock E350M1
> attached.
> 
> 
> Thanks,
> 
> Paul
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] X201i RAM upgrade not working

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 21.09.2014 04:12, ron minnich wrote:
> Here's the problem. There is caching of the DRAM configuration going
> on. So, a restart is not stateless.
> 
> I would be happier if you could guarantee that the mrc cache is
> disabled, or never used, each time you change the dram setup (move
> DIMMs, whatever). Because from your earlier description it sounds to
> me like that is skewing your tests.
> 
> If this makes no sense let me know.
> 
Cache is discarded if SPD is changed. But the easy way to be sure is to
delete mrc.cache in cbfs.
@Mono: Do you come to Prague?
> 
> ron
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Unsupported hardware - information listed

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 09.09.2014 20:52, Luigi Bai wrote:
> Per the wiki, I am offering this information to try to determine the
> status of coreboot support, especially for Intel/PM965 or Intel/82801H.
> I didn't see either under the lists of supported hardware
Unsupported, chipset unsupported. There is a very experimental CL
http://review.coreboot.org/#/c/5807/ to make i965 work but I can bet it
doesn't work as-is and probably very far from working.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] x86: add coreboot framebuffer support

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 06.09.2014 00:31, H. Peter Anvin wrote:
> On 09/05/2014 02:23 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 06.09.2014 00:18, ron minnich wrote:
>>> Vladimir can you point me to that patch? This sounds
>>> interesting.
>>>
>> https://lkml.org/lkml/2010/8/25/190
>>
> 
> I believe *most* of this patch has already gotten merged as we now use
> simplefb on x86 as well.  So all we need is probably the ID.
>
Yes, efifb has the same semantics. We just need some ID with clear
documentation saying sth like "implies framebuffer without anything
else" so that noone will get an idea to plug e.g. vga hooks into it.

>   -hpa
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] X201i RAM upgrade not working

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 06.09.2014 00:19, ron minnich wrote:
> I don't think it's random at all. Vladimir can confirm, but if he is
> caching the RAM parameters, then this 'solution' will work for you
> until the next time you reflash coreboot, or change your dram type, at
> which point it will stop working.
> 
Nehalem code discards cache if there is any mismatch between cache and
modules. There are 2 techniques in use:
1) If SPD mismatches, cache is discarded, so plugging new module will
discard cache.
2) Series of witnesses ensure that cache is only used if full algorithm
would yield the same result. E.g. if the result is a middle of timing
segment, then it saves the ends of segments and checks on next boot that
ends are the same. So even reseating the modules is likely to cause
cache to be discarded.

I think that his problem is either:
1) Badly seated modules
2) Only one permutation fails.
3) Code bug triggered by specific insertion of the said module
Since I've spent countless hours will all kinds of modules inserted and
reinserted on nehalem and the only bug I'm aware of is triggered by
having over 8G (maximum for nehalem) worth of RAM which causes die()
instead of proper ignore of extra RAM, without proof to contrary I'd
guess 1 is the case.





signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] x86: add coreboot framebuffer support

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 06.09.2014 00:18, ron minnich wrote:
> Vladimir can you point me to that patch? This sounds interesting.
> 
https://lkml.org/lkml/2010/8/25/190

> ron
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] x86: add coreboot framebuffer support

[Vladimir 'φ-coder/phcoder' Serbinenko]

> I'm not a fan of Coreboot having invented its own nonstandard hacks, but
> I guess it is pretty much unavoidable.
It's completely avoidable. The stub can copy this information to
standard framebuffer info structure. The only missing thing is to apply
patch by cjwatson or mjg59 (I'm not sure now who wrote it) for having an
ID for linear framebuffer which implies no specific hardware (it can be
any) or firmware (coreboot doesn't provide nay additional info or callback).

Please don't apply this patch it will break SeaBIOS booting with VGABIOS.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [PATCH] x86: add coreboot framebuffer support

[Vladimir 'φ-coder/phcoder' Serbinenko]

This code assumes that payload didn't change video mode which is
improper assumption if you're not a payload.
On 04.09.2014 12:25, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann 
> ---
>  arch/x86/Kconfig   |  12 +++
>  arch/x86/kernel/Makefile   |   1 +
>  arch/x86/kernel/coreboot.c | 232 
> +
>  3 files changed, 245 insertions(+)
>  create mode 100644 arch/x86/kernel/coreboot.c
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 778178f..3aeb038 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -2372,6 +2372,18 @@ config X86_SYSFB
>  
> If unsure, say Y.
>  
> +config COREBOOT
> + bool "coreboot"
> + depends on X86_SYSFB
> + depends on FB_SIMPLE
> + help
> +   Add coreboot framebuffer support to the linux kernel.  Say Y here
> +   if you want the linux kernel find and use the firmware framebuffer
> +   initialized by coreboot.  Useful when using the linux kernel as
> +   coreboot payload.
> +
> +   If unsure, or if you don't know what coreboot is, say N.
> +
>  endmenu
>  
>  
> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
> index ada2e2d..4b30b0e 100644
> --- a/arch/x86/kernel/Makefile
> +++ b/arch/x86/kernel/Makefile
> @@ -103,6 +103,7 @@ obj-$(CONFIG_UPROBES) += uprobes.o
>  obj-y+= sysfb.o
>  obj-$(CONFIG_X86_SYSFB)  += sysfb_simplefb.o
>  obj-$(CONFIG_EFI)+= sysfb_efi.o
> +obj-$(CONFIG_COREBOOT)   += coreboot.o
>  
>  obj-$(CONFIG_PERF_EVENTS)+= perf_regs.o
>  obj-$(CONFIG_TRACING)+= tracepoint.o
> diff --git a/arch/x86/kernel/coreboot.c b/arch/x86/kernel/coreboot.c
> new file mode 100644
> index 000..44ed3fa
> --- /dev/null
> +++ b/arch/x86/kernel/coreboot.c
> @@ -0,0 +1,232 @@
> +/*
> + * Find and parse coreboot tables.  Register framebuffer if present.
> + * See src/include/boot/coreboot_tables.h in coreboot source tree.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +struct cb_header {
> + u32 signature;
> + u32 header_bytes;
> + u32 header_checksum;
> + u32 table_bytes;
> + u32 table_checksum;
> + u32 table_entries;
> +};
> +
> +#define CB_TAG_MAINBOARD0x0003
> +#define CB_TAG_VERSION  0x0004
> +#define CB_TAG_FORWARD  0x0011
> +#define CB_TAG_FRAMEBUFFER  0x0012
> +
> +struct cb_mainboard {
> + u8  vendor_idx;
> + u8  part_idx;
> + charstrings[0];
> +};
> +
> +struct cb_framebuffer {
> + u64 physical_address;
> + u32 x_resolution;
> + u32 y_resolution;
> + u32 bytes_per_line;
> + u8  bits_per_pixel;
> + u8  red_mask_pos;
> + u8  red_mask_size;
> + u8  green_mask_pos;
> + u8  green_mask_size;
> + u8  blue_mask_pos;
> + u8  blue_mask_size;
> + u8  reserved_mask_pos;
> + u8  reserved_mask_size;
> +};
> +
> +struct cb_entry {
> + u32 tag;
> + u32 size;
> + union {
> + charstring[0];
> + u64 forward;
> + struct cb_mainboard   mb;
> + struct cb_framebuffer fb;
> + } u;
> +};
> +
> +#define CB_SIGNATURE 0x4f49424C  /* "LBIO" */
> +
> +/* Try to locate the coreboot header in a given address range. */
> +static __init struct cb_header *coreboot_find_header(u32 addr, int len)
> +{
> + struct cb_header *cbh, *copy;
> + int offset;
> + void *map;
> +
> + map = ioremap(addr, len);
> + for (offset = 0; offset < len; offset += 16) {
> + cbh = map + offset;
> + if (!cbh)
> + continue;
> + if (cbh->signature != CB_SIGNATURE)
> + continue;
> + if (!cbh->table_bytes)
> + continue;
> + if (ip_compute_csum(cbh, sizeof(*cbh)) != 0)
> + continue;
> + if (ip_compute_csum(cbh + 1, cbh->table_bytes)
> + != cbh->table_checksum)
> + continue;
> + pr_debug("coreboot: header found at 0x%x\n",
> +  addr + offset);
> + copy = kzalloc(sizeof(*cbh) + cbh->table_bytes, GFP_KERNEL);
> + memcpy(copy, cbh, sizeof(*cbh) + cbh->table_bytes);
> + iounmap(map);
> + return copy;
> + }
> + iounmap(map);
> + return NULL;
> +}
> +
> +static __init bool check_vga_text_mode(void)
> +{
> + uint8_t reg;
> +
> + if (screen_info.orig_video_isVGA != 1)
> + return false;
> +
> + reg = inb(VGA_GFX_I);
> + if (reg == 0xff)
> + /* no vga present */
> + return false;
> +
> + outb(VGA_GFX_MISC, VGA_GFX_I);
> + reg = inb(

Re: [coreboot] x60 : adding WWAN support

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 01.09.2014 22:19, Charles Devereaux wrote:
> Hello
> 
> I'm interested in WWAN support, mostly for the GPS features and the cool
> things you can do with them (like a stratum ntp server).
> 
Most GPS receivers don't have enough precision for any timing.
> I was told a EM770W doesn't even need a network registration to output
> NMEA coordinates
> (http://forum.thinkpads.com/viewtopic.php?f=30&t=114426#p735612) so I
> got one.
> 
> I looked at patch #4056 which enable WWAN for the EC, but it seems to
> only part of the job: the ACPI table should also contain a GWAN key for
> thinkpad-acpi
> 
Not necessary.
> Apparently, this last part cause the WWAN card not to be handled by
> thinkpad-acpi, which would otherwise provide rfkill support (usefull to
> save power, something I'd like to improve)
Soft rfkill is always available through wwan driver.

> I believe similar entries should be added to coreboot asl, but I'm not
> sure of how integrated they should be. If I understand correctly,
> following the logic of patch #5242, there should be a conditional
> statement then some acpigen.
> 
5242 is very special because of wacom tablet interaction (serial device
naming)
See src/ec/lenovo/h8/acpi/ec.asl and included files for the relevant scopes




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] IBM x60t test - DSDT is in fact incomplete

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 01.09.2014 22:08, Charles Devereaux wrote:
> Hello
> 
Keep list CC'ed.
https://wiki.ubuntu.com/Kernel/Reference/ACPITricksAndTips
> Sorry for the late reply. Yesterday I tried acpi_debug with various
> values, but even with 0x I could not get logs similar to yours :
> [17493.249126] ACPI : EC: push gpe query to the queue
> [17493.249198] ACPI : EC: = TASK =
> [17493.249207] ACPI : EC: ---> status = 0x28
> [17493.249213] ACPI : EC: <--- command = 0x84
> [17493.249293] ACPI : EC: = IRQ =
> [17493.249306] ACPI : EC: ---> status = 0x09
> [17493.249316] ACPI : EC: ---> data = 0x5c
> [17493.249329] ACPI : EC: ---> status = 0x08
> 
> Could you please tell me the cmdline you use, or the options you set in
> /sys to activate that kind of output?
> 
> In any case, I will soon try your patch even if I could not check the
> output (I have a test motherboard where I added an ISP wiring)
> 
> Thanks
> Charles
> 
> 
> 
> On Tue, Aug 26, 2014 at 12:28 AM, Charles Devereaux
> mailto:coreb...@guylhem.net>> wrote:
> 
> (offlist reply)
> 
> Hello
> 
> Very interesting, indeed, but I need to use my X60t tomorrow (and I
> already bricked it once while trying some simple coreboot patch so
> I'd rather not take any risk :-)
> 
> However I will try to test that as soon as possible and let you
> know, tomorrow night or wednesday.
> 
> I will also report you the ACPI EC results.
> 
>     Did you only had to activate CONFIG_ACPI_DEBUG to get these logs?
> 
> Thanks
> Charles
> 
> 
> 
>     On Mon, Aug 25, 2014 at 5:02 PM, Vladimir 'φ-coder/phcoder'
> Serbinenko mailto:phco...@gmail.com>> wrote:
> 
> On 25.08.2014 22 :53, Vladimir
> 'φ-coder/phcoder' Serbinenko wrote:
> >>> Ideally, the DSDT should be fixed within coreboot, but this
> goes beyond
> >>> my present abilities.
> >> Not true. Just do the same changes to the corresponding *.asl
> files in
> >> coreboot repo and send the patch to gerrit. Other than a layer of
> >> preprocessing, it's exactly the same code as you got from
> disassembly.
> >>
> > Sorry, I misread you. I thought that you extracted coreboot
> DSDT from
> > running system then patched it and used as custom DSDT. I'm
> going to
> > make few experiments on my x220t.
> >
> >
> This may interest you:
> On X220t
> stylus removal:
> [17424.931729] ACPI : EC: = TASK =
> [17424.931747] ACPI : EC: ---> status = 0x28
> [17424.931755] ACPI : EC: <--- command = 0x84
> [17424.931852] ACPI : EC: = IRQ =
> [17424.931865] ACPI : EC: ---> status = 0x09
> [17424.931874] ACPI : EC: ---> data = 0x5d
> [17424.931885] ACPI : EC: ---> status = 0x08
> 
> So it's _Q5D
> 
> Stylus reinsert:
> [17493.249126] ACPI : EC: push gpe query to the queue
> [17493.249198] ACPI : EC: = TASK =
> [17493.249207] ACPI : EC: ---> status = 0x28
> [17493.249213] ACPI : EC: <--- command = 0x84
> [17493.249293] ACPI : EC: = IRQ =
> [17493.249306] ACPI : EC: ---> status = 0x09
> [17493.249316] ACPI : EC: ---> data = 0x5c
> [17493.249329] ACPI : EC: ---> status = 0x08
> 
> So it's _Q5C
> 
> Turning LID around:
> [17582.701907] ACPI : EC: push gpe query to the queue
> [17582.701979] ACPI : EC: = TASK =
> [17582.701987] ACPI : EC: ---> status = 0x28
> [17582.701994] ACPI : EC: <--- command = 0x84
> [17582.702075] ACPI : EC: = IRQ =
> [17582.702092] ACPI : EC: ---> status = 0x09
> [17582.702096] ACPI : EC: ---> data = 0x5e
> [17582.702104] ACPI : EC: ---> status = 0x08
> So it's _Q5E
> 
> Back to laptop layout:
> [17590.610440] ACPI : EC: push gpe query to the queue
> [17590.610513] ACPI : EC: = TASK =
> [17590.610521] ACPI : EC: ---> status = 0x28
> [17590.610527] ACPI : EC: <--- command = 0x84
> [17590.610610] ACPI : EC: = IRQ =
> [17590.610620] ACPI : EC: ---> status = 0x09
> [17590.610628] ACPI : EC: ---> data = 0x5f
> [17590.610641] ACPI : EC: ---> status = 0x08
> so it's _Q5F
> 
> Do you get the same events 

Re: [coreboot] IBM/Lenovo X60t: LED_: Excess arguments - needs 1, found 2

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 26.08.2014 17:53, Charles Devereaux wrote:
> My understanding is that the OS does the call that correctly, but that
> coreboot ASL tables only expect one argument.
Please provide a refrence when doing such bold claims. LED method is not
specified in ACPI, so assuming that it takes any particular arguments is
wrong from OS side.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] IBM/Lenovo X60t: LED_: Excess arguments - needs 1, found 2

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 26.08.2014 08:50, Paul Menzel wrote:
> Dear Charles, dear David,
> 
> 
> Am Montag, den 25.08.2014, 11:21 -0600 schrieb David Hubbard:
> 
>> I'm focusing in on this error message first:
>>
>> ACPI Warning: For \_SB_.PCI0.LPCB.EC__.LED_: Excess arguments - needs 1,
>> found 2
>>
>> Can you take a look at the .asl files in your coreboot build? I believe you
>> will find something like "Method (LED, 2, NotSerialized)" which means the
>> LED method wants 2 arguments. Then look for calls to "LED ()" and if you
>> find one only passing 1 argument, that is the problem.
> 
> I also noticed that message and quickly looked through the coreboot ASL
> files, but could not find anything calling that message. Looking at the
> Linux kernel sources I was also unable to find a call site. But I’d say
> the OS call this method incorrectly.
> 
It's called by acpi_thinkpad module:
status = acpi_get_handle(ec_handle, "LED", &led_handle);

if (!acpi_evalf(led_handle, NULL, NULL, "vdd",
led, led_led_arg1[ledstatus]))
static const unsigned int led_led_arg1[] = { 0, 0x80, 0xc0 };

So first argument is 0-based LED number and the second is 0/0x80/0xc0
for state which matches EC bits pretty closely (up to some shifts).
We probably should rename out LED method to sth else and provide a
compatible LED method.
Technically whole acpi_thinkpad is outside of ACPI spec but it's needed
to use some features like Lock hotkey which is outside of ACPI spec as well.
> […]
> 
> 
> Thanks,
> 
> Paul
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] disabling bios usb stack

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 25.08.2014 23:28, ron minnich wrote:
> A friend asks me how to disable the usb stack in his bios. I have no
> clue, anyone?
>
Doesn't sound like end goal. But I'd go through setup menu to see if
something fits his *end* goal (disabling usb stack sounds like means to
goal, not the goal itself).

> ron
> 


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] IBM x60t test - DSDT is in fact incomplete

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 25.08.2014 22:53, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>>> Ideally, the DSDT should be fixed within coreboot, but this goes beyond
>>> my present abilities.
>> Not true. Just do the same changes to the corresponding *.asl files in
>> coreboot repo and send the patch to gerrit. Other than a layer of
>> preprocessing, it's exactly the same code as you got from disassembly.
>>
> Sorry, I misread you. I thought that you extracted coreboot DSDT from
> running system then patched it and used as custom DSDT. I'm going to
> make few experiments on my x220t.
> 
> 
This may interest you:
On X220t
stylus removal:
[17424.931729] ACPI : EC: = TASK =
[17424.931747] ACPI : EC: ---> status = 0x28
[17424.931755] ACPI : EC: <--- command = 0x84
[17424.931852] ACPI : EC: = IRQ =
[17424.931865] ACPI : EC: ---> status = 0x09
[17424.931874] ACPI : EC: ---> data = 0x5d
[17424.931885] ACPI : EC: ---> status = 0x08

So it's _Q5D

Stylus reinsert:
[17493.249126] ACPI : EC: push gpe query to the queue
[17493.249198] ACPI : EC: = TASK =
[17493.249207] ACPI : EC: ---> status = 0x28
[17493.249213] ACPI : EC: <--- command = 0x84
[17493.249293] ACPI : EC: = IRQ =
[17493.249306] ACPI : EC: ---> status = 0x09
[17493.249316] ACPI : EC: ---> data = 0x5c
[17493.249329] ACPI : EC: ---> status = 0x08

So it's _Q5C

Turning LID around:
[17582.701907] ACPI : EC: push gpe query to the queue
[17582.701979] ACPI : EC: = TASK =
[17582.701987] ACPI : EC: ---> status = 0x28
[17582.701994] ACPI : EC: <--- command = 0x84
[17582.702075] ACPI : EC: = IRQ =
[17582.702092] ACPI : EC: ---> status = 0x09
[17582.702096] ACPI : EC: ---> data = 0x5e
[17582.702104] ACPI : EC: ---> status = 0x08
So it's _Q5E

Back to laptop layout:
[17590.610440] ACPI : EC: push gpe query to the queue
[17590.610513] ACPI : EC: = TASK =
[17590.610521] ACPI : EC: ---> status = 0x28
[17590.610527] ACPI : EC: <--- command = 0x84
[17590.610610] ACPI : EC: = IRQ =
[17590.610620] ACPI : EC: ---> status = 0x09
[17590.610628] ACPI : EC: ---> data = 0x5f
[17590.610641] ACPI : EC: ---> status = 0x08
so it's _Q5F

Do you get the same events on X60t?

From thinkpad-acpi.c:
TP_HKEY_EV_TABLET_TABLET= 0x5009, /* tablet swivel up */
TP_HKEY_EV_TABLET_NOTEBOOK  = 0x500a, /* tablet swivel down */
TP_HKEY_EV_PEN_INSERTED = 0x500b, /* tablet pen inserted */
TP_HKEY_EV_PEN_REMOVED  = 0x500c, /* tablet pen removed */

So those are the values MHKP has to return.

http://review.coreboot.org/6765 implements it. Please test.

-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] IBM x60t test - DSDT is in fact incomplete

[Vladimir 'φ-coder/phcoder' Serbinenko]

>> Ideally, the DSDT should be fixed within coreboot, but this goes beyond
>> my present abilities.
> Not true. Just do the same changes to the corresponding *.asl files in
> coreboot repo and send the patch to gerrit. Other than a layer of
> preprocessing, it's exactly the same code as you got from disassembly.
> 
Sorry, I misread you. I thought that you extracted coreboot DSDT from
running system then patched it and used as custom DSDT. I'm going to
make few experiments on my x220t.



-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] IBM x60t test - DSDT is in fact incomplete

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 25.08.2014 04:39, Charles Devereaux wrote:
> Hello
> 
> Previously
> (http://www.coreboot.org/pipermail/coreboot/2014-July/078320.html) I
> mentioned that 3 bugs seemed to be related to the DSDT:
>  - missing ACPI events when the stylus is inserted/removed
How is the OS supposed to react to them?
>  - errors when trying to make the leds blink with tpacpi
details? usecase?
>  - errors during TPM initialization
Some people here would call it a feature.
> Ideally, the DSDT should be fixed within coreboot, but this goes beyond
> my present abilities.
Not true. Just do the same changes to the corresponding *.asl files in
coreboot repo and send the patch to gerrit. Other than a layer of
preprocessing, it's exactly the same code as you got from disassembly.




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] why is firmware 32 bit as opposed to 64 bit

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 10.08.2014 21:06, John de la Garza wrote:
> I understand that the calling functions in 32 bit C uses the stack and
> this is why coreboot needs to use cache as RAM.  Doesn't 64 bit C use
> registers to pass arguments to functions?  If this is the case why not
> run in 64 bit mode?
> 
> Also, even if cache as RAM is used and a stack is available, why not just
> build a 64 bit binary?  What are the advantages to using a 32 bit binary?
> 
>
long mode (64-bit) needs paging table in RAM. So no 64-bit for preram
binary. For rest it's theoretically possible but it's too much hassle
for no benefit.





signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] iy my pc supported for coreboot?

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 06.08.2014 00:08, Peter Stuge wrote:
> Simon Andrä wrote:
>> I want use coreboot but i dont know if my system is supportet:
>> I have an Acer Predator G3620
> 
> It isn't.
> 
> 
>> I hope someone can help me
> 
> As always with open source you have to help yourself.
> 
Or hire someone to do it.
> 
> //Peter
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ISP header for x60, fallback: indicating normal boot from grub2

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 19.07.2014 07:42, Charles Devereaux wrote:
> Hello,
> 
> On Wed, Jul 9, 2014 at 2:15 AM, Denis 'GNUtoo' Carikli
> mailto:gnu...@no-log.org>> wrote:
> 
> My pomona clip had issues with its contact pins(the ones in contact
> with the flash chip) over time, so I unmounted it and repaired it.
> 
> 
> I tried pushing the pins down - it looks better but it didn't help. Mine
> only work with a lot of duct tape to keep it firmly pressed to the
> motherboard. Otherwise, it slides up just a bit, enough to avoid making
> contact. It seems more like a problem with the plastic
>  
> 
> Example in grub.cfg:
> menuentry 'Normal' {
> cmosclean 0x30:0
> cmosclean 0x30:1
> cmosclean 0x30:2
> cmosclean 0x30:3
> cmosclean 0x30:4
> cmosclean 0x30:5
> 
> halt
> }
> 
> 
> Interesting. Is there a reason why different values are used on gluglug
> halt? cf http://samnoble.org/thinkpad/grub/gluglug.grub.custom.cfg:
> 
The values are exactly the same. Search for hex.
> There is only cbmemc, cbls and cbtime. They could be good menu options
> but the output is displayed without a pager (so you can't see them as it
> goes back to the menu - you have to enter a command line)
> 
pager=1
> Of all of these, cbtime would be especially interesting to add a title
> to grub menu, to show if the boot was in normal or fallback and how long
> it took. 
> 
> I'll see if it's possible to add the result of a command to grub menu




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] setting smbios values from the OS

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 20.06.2014 20:43, Patrick Georgi wrote:
> Am 20.06.2014 22:40, schrieb Vladimir 'φ-coder/phcoder' Serbinenko:
>> (think MAC address).
> I guess PC technology is finally beyond requiring those at fixed magic
> offsets. Some of our chipsets still need it that way.
> 
>> having fixed indexes doesn't scale.
> Neither do text files.
> 
I disagree. If you have a file named e.g. config.txt with a syntax like:

southbridge/ibexpeak/thermal_correction: 0x1222

one value per line, it perfectly scales.
> 
> Patrick
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] setting smbios values from the OS

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 20.06.2014 20:08, Patrick Georgi wrote:
> Am 20.06.2014 22:01, schrieb Rafael Vanoni:
>> Take serial number, for example. I'd like each different system that I
>> build to have its own serial number, and building coreboot for every
>> serial number doesn't scale.
> We have an .id section just below the 16bit entry point - that can
> (easily) be extended to host more fields, and our smbios table generator
> could fetch a number from there, overriding a compile time default.
> 
> To start, see src/arch/x86/lib/id.inc. It's really two tables: one
> containing the offsets, one containing the data (strings are 0-terminated).
> Both tables need to be prepended with new fields, since we're in a
> top-aligned world here.
> 
I think it's more sound to have a CBFS plain-text file with serial
numbers and other runtime configs. There is a fair number of board and
chipset-specific config that should be modifiable without recompilation
but are probably inappropriate for CMOS for various reasons as CMOS size
shortage or the need for persistance even across RTC power well failure
[aka bad clock battery] (think MAC address). having fixed indexes
doesn't scale.
> Patches accepted :-)
> 
> 
> Patrick
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] x60s tablet question : optimized kernel, coreboot with the video fix and serial ports support

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 11.06.2014 09:46, derpeter wrote:
> 
> I tried this last month. I cherrypickt everything execpt the video fix
> and got a working coreboot.
> Sadly i could not bring the wacom to work but i'm not sure if its a
> problem of coreboot or linux.
Submit logs then: Xorg log, dmesg and coreboot log.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [HELP!!!] Pavilion EC (similar to compal/ene932) and its woes

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 05.04.2014 19:02, mrnuke wrote:
> When an event happens, on the other hand, like a hotkey, or AC is removed, it 
> does not generate an SCI that would lead to a query call (_Qxx). Instead it 
> spits out an SMI. I know for a fact that the SCI and SMI GPEs are where we 
> expect them to be.
What do you mean by "expected"? Same as vendor BIOS? My guess is that
vendor BIOS handles SMI and then somehow triggers SCI in software. I'd
try to route all GPE to SCI.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [announce] coreboot for the 21st century

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 29.03.2014 08:41, Patrick Georgi wrote:
> Am Samstag, den 29.03.2014, 08:30 +0100 schrieb Vladimir
> 'φ-coder/phcoder' Serbinenko:
>> Do I get it correctly that your main problem is the heavy use of
>> #include romcc requires? If so why don't we just create a file with
>> #include's from all files from romstage-y? This will remove the #include
>> needs.
> There are also a bunch of places where we stick to some less than
> perfect C code to accommodate romcc.
> 
> The #include *.c stuff is mostly the visible effect, not the cause.
> Getting romcc raminits to compile self-contained (or with their own
> specific *.c files to include) fixes both.
> 
Do you mean having a separate stage "raminit" between bootblock and
romstage? If so it raises a question of what's romostage scope is.
> 
> Patrick
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [announce] coreboot for the 21st century

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 29.03.2014 07:45, Stefan Reinauer wrote:
> * Andrew Wu  [140327 14:00]:
>> Sorry, I checked Vortex86EX CPU datasheet, but it seems there is no
>> workaround can do it.
>>
>> So if I want to get rid of romcc, maybe I have to write DRAM init code
>> in assembly, That is not very easy. :(
>  
> Don't worry we'll figure something out that's better than writing ram
> init in assembly.
> 
Do I get it correctly that your main problem is the heavy use of
#include romcc requires? If so why don't we just create a file with
#include's from all files from romstage-y? This will remove the #include
needs.
> Stefan
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Miniboot

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 26.03.2014 00:33, The Gluglug wrote:
> --> alternatively:
> ship coreboot without anything in src/mainboard.
> have git repositories for each vendor/mainboard.
> user downloads what they need, and a default .config for the board of
> their choosing.
> 
Git is developpement tree, not user-fetch tree. It's optimized for devs.
If you feel like sth optimized for users is needed, feel free to create
an interface you want that would piggyback on top of official git.
> On 25/03/14 23:29, The Gluglug wrote:
>> This is focussed on users (non-developers).
> 
>> Most coreboot users only have perhaps a few machines that they are 
>> building for. Maybe even just one.
> 
>> Yet they are downloading the entire coreboot source tree and
>> selecting which board they want, configuring it, etc.
> 
>> My idea: --> a small set of source files (such as from
>> src/mainboard/vendor/board) --> a script (perhaps a simple git
>> checkout) which fetches the needed parts of the source from the
>> main branch, for building that board --> default/"sane"
>> configurations pre-defined for that board.
> 
>> Advantages: --> less headache for developers (user already has most
>> of what they need, less likely to request support) --> less to
>> download (less waiting required, especially for people with slow
>> connections)
> 
>> Essentially, I have in mind a more "modular" coreboot.
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Changes to the coreboot Project Structure

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 25.03.2014 06:34, ron minnich wrote:
> 
> 
> 
> On Mon, Mar 24, 2014 at 10:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> mailto:phco...@gmail.com>> wrote:
> 
> 
> I don't see how this prevents any of my propositions for the bulk of the
> boards. The problem you describe isn't going away with your proposition.
> We still want to have a top which is supposed to work on all boards.
> 
> 
> 
> All boards? The Arima HDAMA, 12 years old now, not sold for maybe 10?
> All boards? Are you sure?
> 
That's why I added *supposed to*. I'm aware that some boards are
probably broken and not much we can do about it.
> ron 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Changes to the coreboot Project Structure

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 25.03.2014 02:33, Stefan Reinauer wrote:
> * David Hubbard  [140323 20:33]:
>> On Sun, Mar 23, 2014 at 12:58 PM, Vladimir ' -coder/phcoder' Serbinenko <
>> phco...@gmail.com> wrote:
>>
>> On 23.03.2014 19:24, ron minnich wrote:
>> > So I believe the problem is not the idea of gatekeepers, but the
>> > manner in which they are proposed to work. Can you tell me what about
>> > this upsets you? I want to understand.
>> The problem is that the proposal is that all commits go through
>> gatekeepers. It's bottleneck. It makes much more sense to have per-path
>> maintainers and tiered code.
>> E.g. we could keep all boards rather than shooting them and the ones
>> that are considered to be too old can have less stringent requirements
>> on commits. This will free the qualified people time to concentrate on
>> boards where it's most important.
>> Also it will benefit "unimportant" boards as well as they'll be easier
>> to keep.
>>  Then per-path maintainer and gatekeeper are contradictory concepts. How
>> one can be maintainer if he can't commit to his maintained code. I feel,
>> for example, that nehalem code and resulting boards are my
>> responsibility and I should be able to commit there easily. Getekeeprs
>> will make this impossible as I'm more or less the only one who knows
>> nehalem code *and* cares about it.
>> I feel like the top-level maintainers would be only about overall
>> structure, not about details in Board:foo/bar they've never even seen
>> and solving disputes. Making everything go through 6 people is
>> unfeasible as 6 people can't represent broad range of interests and some
>> parts of code will get neglected more that they have to be of simple
>> scarceness of resources.
>>
>>
>> Without speaking for anyone or about anything else, can Stefan comment on 
>> this
>> proposal by Vladimir? It seems relatively cool and reasonable.
> 
> Tried to do so in the other mail... There's too much risk involved in
> working directly on upstream. The downsides just outweigh the benefits
> (for everybody, really)
> 
> For example, when getting to the "hot phase" of a new product, we don't
> even use our chromium "top of tree", but create a firmware branch
> specifically for a new product. Patches relevant to that product go into
> that branch (and top of tree, aka HEAD) but NOTHING else. For every
> firmware image that is released, there are also tests involving
> thousands and thousands of reboots and suspend/resume cycles to make
> sure that the product is absolutely stable. Because if 1/100k resumes
> crashes that means for a million users there are ten users every day
> whose computers crash. This level of testing is simply not possible when
> aiming at a moving target.
> 
I don't see how this prevents any of my propositions for the bulk of the
boards. The problem you describe isn't going away with your proposition.
We still want to have a top which is supposed to work on all boards.
> Stefan
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Changes to the coreboot Project Structure

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 23.03.2014 19:24, ron minnich wrote:
> I have friends who commit to grub2, and there seem to be gatekeepers
> there; how do you manage that process?
In case of grub2 I admit we have exactly the problems I described. I'm
open to having more maintainers but right now it doesn't seem to be
feasible. I proposed co-maintaining to some skilled people but they
didn't accept as of now. Here you have a chance of more people willing
to help maintain coreboot. Use this resoiurce.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Changes to the coreboot Project Structure

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 23.03.2014 19:24, ron minnich wrote:
> So I believe the problem is not the idea of gatekeepers, but the
> manner in which they are proposed to work. Can you tell me what about
> this upsets you? I want to understand.
The problem is that the proposal is that all commits go through
gatekeepers. It's bottleneck. It makes much more sense to have per-path
maintainers and tiered code.
E.g. we could keep all boards rather than shooting them and the ones
that are considered to be too old can have less stringent requirements
on commits. This will free the qualified people time to concentrate on
boards where it's most important.
Also it will benefit "unimportant" boards as well as they'll be easier
to keep.
 Then per-path maintainer and gatekeeper are contradictory concepts. How
one can be maintainer if he can't commit to his maintained code. I feel,
for example, that nehalem code and resulting boards are my
responsibility and I should be able to commit there easily. Getekeeprs
will make this impossible as I'm more or less the only one who knows
nehalem code *and* cares about it.
I feel like the top-level maintainers would be only about overall
structure, not about details in Board:foo/bar they've never even seen
and solving disputes. Making everything go through 6 people is
unfeasible as 6 people can't represent broad range of interests and some
parts of code will get neglected more that they have to be of simple
scarceness of resources.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Changes to the coreboot Project Structure

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 23.03.2014 04:10, Peter Stuge wrote:
> That isn't too different from creating a fork?
Fork is better. With fork we don't have to deal with the same people who
pushed the community out in the first place.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [announce] coreboot for the 21st century

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 20.03.2014 22:33, Stefan Reinauer wrote:
> During this time we collected over 250 different
> mainboards. A great achievement,
I suppose that most of boards were contributed by non-commercial
community. Yet now you propose to basically kill this chicken nesting
golden eggs and make coreboot commercial-only.
Sorry but your proposition with handling non-commercial community
doesn't make any sense at all. You propose to represent the community by
small number of people who most likely won't be available enough and who
don't represent the community as whole. No single person or small team
can represent an entire community, no matter how these persons are
knowledgeable and competent. Commercial entity could be represented by
one person but a community of independent volunteers can't.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Changes to the coreboot Project Structure

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 21.03.2014 01:39, Carl-Daniel Hailfinger wrote:
> Hi Stefan,
> 
> streamlining development and maintenance is definitely absoutely
> worthwhile. Getting rid of unmaintained code is also a good thing. The
> guidelines presented in your mail look mostly good IMHO, but I'd like to
> comment on a few things.
> 
> Am 20.03.2014 22:55 schrieb Stefan Reinauer:
>> * Significantly reduce number of submitters
>>   To ensure consistency, scalability and conformity with the general
>>   coreboot strategy, we need to define a clear committer structure that
>>   defines the original project structure of having a benevolent dictator
>>   aka project leader (Stefan Reinauer) and gatekeepers in place. The
>>   suggested structure will need to value both community interests and
>>   corporate interests equally and hence a good setup would be to have a
>>   final amount of six developers with submit rights, three community
>>   representatives and three corporate representatives (on from each major
>>   stakeholder):
> 
> I see a huge bottleneck in restricting the number of committers to six.
> - Corporate committers will be primarily obliged to get the stuff of
> their own employer committed, but if they are ill or on vacation,
> someone else would have to take over. This would either be another
> corporate committer (in which case their own employer would have to
> authorize spending time for a different company) or a community committer.
> - Community committers are not paid, and commit in their spare time.
> Spare time is not necessarily abundant all year round. Speaking from
> experience, the flashrom project has no shortage in developers or
> submitted patches, but a real and painful shortage in
> reviewers/committers. The flashrom project patch backlog is huge due to
> this. Doing a commit is easy, but making sure that a commit follows
> certain guidelines is a huge time sink with none of the fun of writing code.
> - New contributors (corporate or community) would have to find a
> "sponsor" to actually commit their code. With a large committer base,
> this can happen rather quickly. With only six committers facing their
> own deadlines or other shortages of time, this could take quite a while.
> 
The proposition of gatekeepers would essentially kill community effort.
Even in current infrastructure reviewing is a major slowdown. With small
number of gatekeepers there wouldn't be any significant contributions as
the gatekeepers wouldn't be able to review them in reasonable time,
which will, in turn discourage contributions. You may as well just stop
accepting community contributions right now: it turns out to be the same
thing, just a little bit quicker.
You cannot treat community as some kind of corporate entity.
>>   Peter Stuge, Kyösti Mälkki, N.N. (non-commercial part of the
>>   coreboot community)
Sounds like a joke. While Peter is competent, he's also very busy. I'd
expect his review thoughtput of perhaps a patch a week.
You can't realistically put such burden on few people.
If you want a corporate version of coreboot, I think you have to use a
workflow similar to Fedora vs Red Hat Enterprise Linux.
The changes you proposed would effectively make coreboot into corporate
project. I'd expect a community fork to emerge quickly, outside of this
new limiting infrastructure and I'll be surely moving to community fork.




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [announce] coreboot for the 21st century

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 20.03.2014 22:33, Stefan Reinauer wrote:
> coreboot for the 21st century
> 
> setting up the project for the next decade
> 
> Purpose: Purge all boards / chipsets / cpus that require ROMCC in
> romstage and known broken chipsets (sc520, i855)
> 
> coreboot is now officially 15 years old. One and a half long decades
> with ups and downs. During this time we collected over 250 different
> mainboards. A great achievement, but also a great maintenance burden.
> 
> * It is hard to keep 250+ mainboards working. Actually impossible.
> * Keeping them working comes at a cost. Keep old infrastructure around.
>   Workarounds, special cases
> * We don’t test except on the very last stuff we’re working on
> 
The boards and chipsets are sufficiently well insulated from each other
so that it's possible to improve one without breaking the others. With
board-status the potential users and devs have a good overview which
revisions work on which devices. The breakage will periodically occur no
matter if it's 25 board or 250 boards. And it will be fixed by those who
care about the particular board.
Also I feel like the amount of boards supported is actually a relatively
minor maintenance burden compared to number of *options* supported. I
think we should first go on killing the options noone really uses like
possibility disabling ACPI tables (I have a changeset for this, mixed
reception), disabling SMBIOS tables. "relocatable" modules should be
chosen by chipset, not be user-visible, and so on. There are more broken
option configurations than broken boards.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] GSoC-2014 Coreboot project

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 20.03.2014 13:45, Peter Stuge wrote:
> Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> On 20.03.2014 11:25, Allen Yan wrote:
>>> Hi, David,
>>>When at AsusTek Suzhou, my work is mainly responsible for bios
>>> porting and fixing bug.
>>
>> Do I understand it correctly, that you've had access to proprietary BIOS
>> code? If so which papers did you sign and under what license did you get
>> them?
> 
> Vladimir, I would assume that Jinyi signed a standard employment
> agreement. Employment agreements contain a non-disclure clause
> which covers all non-public information which the employer has
> received from suppliers and customers.
> 
> 
>> Depending on the answers it may partially or fully disqualify you
>> from contributing to coreboot.
> 
> I disagree, and I think your tone is rude.
> 
I didn't mean to be rude. I apologise if it sounded like this. I'm
somewhat pessimistic generally and a mathematician and so I look for
problems first.
> Please be supportive of GSoC candidates who are showing an interest
> in coreboot, especially candidates such as Jinyi who can obviously
> contribute with significant relevant experience from the firmware
> domain.
> 
I didn't mean to be dismissive, when I discuss problems it's to prevent
and fix them.
> Employment agreements have clauses about not working on competing
> products. coreboot in summer of 2014 does not compete with BIOS for
> commercial mainboards in 2008. I am obviously not a lawyer but I
> can not see a problem here.
> 
They sometimes also have draconian non-disclosure parts. We can't know
until such issues are checked by someone qualified. I'm not. Does
coreboot has some kind of experts it can use for those cases? On GNU
projects I'd refer to copyright clerk who would in turn refer further if
needed.
> 
> //Peter
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Hey

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 20.03.2014 13:34, Shant Kehyeian wrote:
> No I just gave in menuconfig the snow board ...and then as a payload I
> chose the GRUB2...that's what I meant ...:)
> 
Keep list CC'ed.
I'm surprised it compiled at all. It should have error'ed out.
> 
> On Thu, Mar 20, 2014 at 12:31 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> mailto:phco...@gmail.com>> wrote:
> 
> On 20.03.2014 13:27, Shant Kehyeian wrote:
> > Yess you are saying it right...
> > So I installed the coreboot source code and I compiled it with
> GRUB2 so
> > ...Do you think that I will get the grub options while the boot
> process ?
> > Thank you...
> >
> I don't know how you managed to compile GRUB2 for ARM coreboot but it's
> unlikely to work. I'm under impression that you compile for wrong
> mainboard altogether (you've chosen mobo in make menuconfig, right?)
> >
> > On Thu, Mar 20, 2014 at 12:23 PM, Vladimir 'φ-coder/phcoder'
> Serbinenko
> > mailto:phco...@gmail.com>
> <mailto:phco...@gmail.com <mailto:phco...@gmail.com>>> wrote:
> >
> > On 20.03.2014 13:10, Shant Kehyeian wrote:
> > > In fact I do need the SeaBios not the GRUB2 to be able to boot
> > from usb
> > > with live CD which I can format and install my preferred OS...
> > >
> > I think you're missing the "ARM" part. Only ARM distros have
> any chance
> > to work. Given fragmentation of ARM it may even mean that only
> > Linux-based works on your machine.
> > >
> > > On Thu, Mar 20, 2014 at 4:05 PM, Vladimir 'φ-coder/phcoder'
> Serbinenko
> > > mailto:phco...@gmail.com>
> <mailto:phco...@gmail.com <mailto:phco...@gmail.com>>
> > <mailto:phco...@gmail.com <mailto:phco...@gmail.com>
> <mailto:phco...@gmail.com <mailto:phco...@gmail.com>>>> wrote:
> > >
> > > On 20.03.2014 12:12, Shant Kehyeian wrote:
> > > > Hello,
> > > > I have Samsung ARM chromebook series 3 "Snow" and I am
> > trying to flesh
> > > > it and change the boot process.
> > > > So I build a coreboot.rom for that, but before I start
> to do
> > that I
> > > > would like to ask about the payload. When I did the "make
> > > menuconfig" it
> > > > wasn't by default the SeaBios., there wasn't at all
> ...there was
> > > GRUB 2
> > > > and I selected it...so My question is would it work as
> > SeaBios to boot
> > > > from usb ?
> > > There is no arm-coreboot GRUB2 port currently.
> > > > Thank you.
> > > >
> > > >
> > >
> > >
> > >
> >
> >
> >
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Hey

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 20.03.2014 13:27, Shant Kehyeian wrote:
> Yess you are saying it right...
> So I installed the coreboot source code and I compiled it with GRUB2 so
> ...Do you think that I will get the grub options while the boot process ?
> Thank you...
> 
I don't know how you managed to compile GRUB2 for ARM coreboot but it's
unlikely to work. I'm under impression that you compile for wrong
mainboard altogether (you've chosen mobo in make menuconfig, right?)
> 
> On Thu, Mar 20, 2014 at 12:23 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> mailto:phco...@gmail.com>> wrote:
> 
> On 20.03.2014 13:10, Shant Kehyeian wrote:
> > In fact I do need the SeaBios not the GRUB2 to be able to boot
> from usb
> > with live CD which I can format and install my preferred OS...
> >
> I think you're missing the "ARM" part. Only ARM distros have any chance
> to work. Given fragmentation of ARM it may even mean that only
>     Linux-based works on your machine.
> >
> > On Thu, Mar 20, 2014 at 4:05 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> > mailto:phco...@gmail.com>
> <mailto:phco...@gmail.com <mailto:phco...@gmail.com>>> wrote:
> >
> > On 20.03.2014 12:12, Shant Kehyeian wrote:
> > > Hello,
> > > I have Samsung ARM chromebook series 3 "Snow" and I am
> trying to flesh
> > > it and change the boot process.
> > > So I build a coreboot.rom for that, but before I start to do
> that I
> > > would like to ask about the payload. When I did the "make
> > menuconfig" it
> > > wasn't by default the SeaBios., there wasn't at all ...there was
> > GRUB 2
> > > and I selected it...so My question is would it work as
> SeaBios to boot
> > > from usb ?
> > There is no arm-coreboot GRUB2 port currently.
> > > Thank you.
> > >
> > >
> >
> >
> >
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Hey

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 20.03.2014 13:10, Shant Kehyeian wrote:
> In fact I do need the SeaBios not the GRUB2 to be able to boot from usb
> with live CD which I can format and install my preferred OS...
> 
I think you're missing the "ARM" part. Only ARM distros have any chance
to work. Given fragmentation of ARM it may even mean that only
Linux-based works on your machine.
> 
> On Thu, Mar 20, 2014 at 4:05 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> mailto:phco...@gmail.com>> wrote:
> 
> On 20.03.2014 12:12, Shant Kehyeian wrote:
> > Hello,
> > I have Samsung ARM chromebook series 3 "Snow" and I am trying to flesh
> > it and change the boot process.
> > So I build a coreboot.rom for that, but before I start to do that I
> > would like to ask about the payload. When I did the "make
> menuconfig" it
> > wasn't by default the SeaBios., there wasn't at all ...there was
> GRUB 2
> > and I selected it...so My question is would it work as SeaBios to boot
> > from usb ?
> There is no arm-coreboot GRUB2 port currently.
> > Thank you.
> >
> >
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Hey

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 20.03.2014 12:12, Shant Kehyeian wrote:
> Hello,
> I have Samsung ARM chromebook series 3 "Snow" and I am trying to flesh
> it and change the boot process.
> So I build a coreboot.rom for that, but before I start to do that I
> would like to ask about the payload. When I did the "make menuconfig" it
> wasn't by default the SeaBios., there wasn't at all ...there was GRUB 2
> and I selected it...so My question is would it work as SeaBios to boot
> from usb ?
There is no arm-coreboot GRUB2 port currently.
> Thank you.
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] GSoC-2014 Coreboot project

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 20.03.2014 11:25, Allen Yan wrote:
> Hi, David,
>When at AsusTek Suzhou, my work is mainly responsible for bios
> porting and fixing bug. There were four mainboards P5KPL-S, P5QL-E,
> P5QL-SE, P5QL. All based on Intel platform and AMI Legacy BIOS Core
>In the second half year of 2008, I worked on pre-development of
> EFI-BIOS for ASUS mainboard. I wrote a Dual bootblock module and added
> NTFS support(read only) for AutoRecovery module using AMI Apito
> platform (based on EFI).
> 
Do I understand it correctly, that you've had access to proprietary BIOS
code? If so which papers did you sign and under what license did you get
them? Depending on the answers it may partially or fully disqualify you
from contributing to coreboot.
> Interesting experience, but memories will fade! Details can't be
> remembered clearly.
> 
>> As Vladimir said, if the chipset is unsupported then writing MRC for it will 
>> be a very long and difficult process. If the chipset is supported then 
>> adding mainboard support may be a relatively simple task that not sufficient 
>> for GSoC.
>  Do we need to write MRC by ourselves in coreboot? Isn't MRC code
> supported by Intel?
> 
>> If you have experience with UEFI, perhaps you can implement features that 
>> are missing in our Tianocore support: http://www.coreboot.org/TianoCore .
> 
> Implementing UEFI CBFS driver and GOP driver are very clear goal.
> questions: I don't know whether coreboot or some payload implement
> common flash interface for flash programming software. If not, why?
> 
>> https://trello.com/b/pEdlwYTb/tiano-payload
> It seems that Tiano payload is a very activity project. I think I can
> try my best to implement one feature or twp for the project! Like use
> a seperate Fv in CBFS as Fault Tolerant Variable Storage
> 
> Look forward to your kind advice!
> 
> 
> 
> On 3/20/14, David Hendricks  wrote:
>> Hi Jinyi,
>> Can you provide more details about your work as a BIOS engineer?
>>
>> As Vladimir said, if the chipset is unsupported then writing MRC for it
>> will be a very long and difficult process. If the chipset is supported then
>> adding mainboard support may be a relatively simple task that not
>> sufficient for GSoC.
>>
>> If you have experience with UEFI, perhaps you can implement features that
>> are missing in our Tianocore support: http://www.coreboot.org/TianoCore .
>>
>>
>> On Wed, Mar 19, 2014 at 6:06 AM, Allen Yan  wrote:
>>
>>> Hi,
>>> I am Jinyi Yan , a second year PhD candidate from Shanghai Institute
>>> of Micro-system and Information Technology, Chinese Academy of
>>> Sciences. I used to be a mainboard BIOS engineer in ASUS Technology
>>> Suzhou Co., Ltd for about two years (2007.7~2009.2). My major now is
>>> optoelectronics. But I have a lot of fun while programming, in my
>>> heart the working experience of being a BIOS engineer is still very
>>> exciting.
>>> I think GsoC is a nice platform for me to participate the open source
>>> community. When I search the GsoC projects and organizations, the
>>> coreboot and flashrom projects are definitely the right choices for
>>> me. I have a spare ASUS P5KPL PC at my hand, but the chipset is not in
>>> the support list of coreboot project.
>>> As Stefan Tauner's suggestion, maybe porting coreboot to new mainboard
>>> or implementing advanced coreboot features on exsiting mainboards are
>>> nice too.
>>> Now I'm not very familiar with the program structure of coreboot, so I
>>> expect your guidence and hope to contribute for coreboot and flashrom
>>> even if my application is not accpeted.
>>> Thanks! Look forward to your kind advice!
>>> Regards,
>>> Jinyi Yan
>>>
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> http://www.coreboot.org/mailman/listinfo/coreboot
>>>
>>
>>
>>
>> --
>> David Hendricks (dhendrix)
>> Systems Software Engineer, Google Inc.
>>
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] GSoC-2014 Coreboot project

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 19.03.2014 21:06, Allen Yan wrote:
> As Stefan Tauner's suggestion, maybe porting coreboot to new mainboard
Just a quick note: for porting to new chipset to be accepted, you need to:
1) Justify why this chipset is relevant. E.g. old chipsets most probably
aren't.
2) Prove that you're able to do it. New raminit isn't an easy task.
Also from quick google it seems that this board uses i945 chipset which
is already supported. Port with already supported chipset is a task for
3-5 days for experienced dev, most likeyl too small for GSoC.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Building a Thinkpad X230 coreboot image

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 17.03.2014 20:39, Grim Schjetne wrote:
> Bernie Innocenti  writes:
> 
>> First of all, thank you very much for porting Coreboot to the X230.
> 
> Indeed, this has made me all the more interested in the Coreboot
> project. With an X201 and an X230 port, perhaps there is some hope
> for an X220 port as well?
It's different chipsets. So, no X201, X220 and X230 are very different
machines from coreboot point of view.
> I'm reading the wiki pages right now for ways
> I can help.
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Building a Thinkpad X230 coreboot image

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 17.03.2014 17:08, Bernie Innocenti wrote:
> Hello Vlad!
> 
> First of all, thank you very much for porting Coreboot to the X230.
> 
> I'm following your instructions [1] to build a coreboot image from head,
> but I'm not sure how to configure things in menuconfig. Would you mind
> sharing your .config file and a prebuilt, known-good rom file?
> 
Look at board-status repository. I will not share any "known-good" one
as you need external flasher anyway. Sharing a binary would just
encourage people to attempt stupid things like writing it with partially
locked flash.
> Also, while I'm waiting for the SOIC test clip to ship: do you know if
> anyone is working on getting flashrom to work with the X230?
> 
flashrom with layout patches works once flash is unlocked. But the only
way to unlock flash is to flash coreboot or slightly modified vendor
firmware. Either requires external flash.
> [1] http://www.coreboot.org/Board:lenovo/x230
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFT] Please test patch set intel/i945: Only write CID, PN and TCID once

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 17.03.2014 08:00, Mono wrote:
> Who knows, it might(!) fix some 5 year old bug?
Then it should be no problem for you to point one to us.
coreboot is not openhardware. It never was and never will be.
Openhardware is the only way to know what your hardware actually.
Coreboot is only how to kick the hardware into working.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] qemu

[Vladimir 'φ-coder/phcoder' Serbinenko]

@ron: please provide more information about your qemu: version, how
built, options, patches,... Try -M pc-q35-1.7 and -M pc-i440fx-1.7. Try
specifying --no-kvm and --enable-kvm. Speyifying -cpu may help as well.
From my experience with GRUB, qemu has following flaws:
- From version to version they sometimes do subtle changes which break
firmware.
- On some CPUs kvm bugs or behaves unexpectedly.
On 10.03.2014 14:43, David Hubbard wrote:
> On Sunday, March 09, 2014 08:26:05 PM you wrote:
>> On Sunday, March 09, 2014 05:14:51 PM you wrote:
>> > Story so far:
>> >
>> > 1. pick q35 chipset
>> > 2. qemu -M q35 etc. etc.
>>
>> $ qemu-system-i386 -M q35 --bios build/coreboot.rom
>>
>> -ENOREPRODUCE
>>
>> > 1. pick i440fx chipset.
>> > 2. qemu -M pc etc. etc.
>>
>> qemu-system-i386 --bios build/coreboot.rom
>>
>> -ENOREPRODUCE
>>
>> > Endless repetitions of
>> > qemu: unsupported keyboard cmd cmd=0x00
>> > or 0x80
>>
>> -ENOREPRODUCE
>>
>> Same with qemu-kvm.
>>
>> > This is with crossgcc.
>> > I'm disappointed it's this fragile. I'm worried that feature push has
>> > gotten ahead of reliability push.
>>
>> Or your qemu installation is b0rk3d.
> 
> Perhaps if it is that easy to break the installation -- remember, he did
> a clean checkout -- then there could be a broken dependency, or
> something similar which involves digging deeply into the build system.
> 
> In other words, even if what you say is true, we still need to have this
> conversation.
> 
> I feel like Coreboot is a bit fiddly to get set up right. To a degree,
> that helps communicate that working with coreboot is hard stuff. But
> still, we should implement some better quality controls, imho.
> 
> Hopefully we can figure out what Ron ran into. That would be a good start.
> 
> David
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] GSoC-2014- coreboot mainboard test suite

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 02.03.2014 09:01, Muhammad Ramshad wrote:
> When i search through the projects and organizations the coreboot
> project grabbed my focus towards it because i am more interested in
> Digital System Design and hardware a level development like processor
> design and ISA designs.
And absolutely no idea that HTML messages are not welcome on mailing
list. Use ASCII messages. It will also prevent you from screaming big
letters in the middle of a message.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] `DEBUG_INTEL_ME` (incorrectly) only selected for Intel BD82x6x

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 26.02.2014 04:24, mrnuke wrote:
> On Wednesday, February 19, 2014 11:06:40 PM Paul Menzel wrote:
>> looking through `src/console/Kconfig` I noticed
> You mean 'src/Kconfig' ?
> 
>> if SOUTHBRIDGE_INTEL_BD82X6X && DEFAULT_CONSOLE_LOGLEVEL_8
> This is a layering violation. We shouldn't have hardware-specific options in 
> top-level Kconfig. This should be moved to southbridge Kconfig, and not 
> depend 
> on LOGLEVEL. Maybe we need to move ME handling to a common dir and handle the 
> Kconfigs there.
> 
>> which seems odd as currently other chipsets needing the Intel Management
>> Engine were submitted.
>>
>> $ git grep DEBUG_INTEL_ME
>> [...]
> Smells like copypasta. Yet another reason to consider unifying ME handling 
> across southbridges.
> 
Don't. This particular code is a good example why it shouldn't be done.
On Ibexpeak this code (extended status print) would timeout.




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`

[Vladimir 'φ-coder/phcoder' Serbinenko]

> 
> You do not get raminit debug output printed in ramstage.
> 
> Unfortunately, the case of incompatible DIMMs seems to be common one
> with recent AGESA ports so information from romstage what DIMMs have
> worked is actually relevant.
Just read this data from registers and print it.
> 
> Kyösti
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 19.02.2014 23:03, Paul Menzel wrote:
> Am Mittwoch, den 19.02.2014, 00:47 +0100 schrieb Vladimir 'φ-coder/phcoder' 
> Serbinenko:
>> On 19.02.2014 00:18, Paul Menzel wrote:
>>>>>>> But in general I think I agree with Vladimir. CBMEM console should be
>>>>>>> supported and if not then that should be fixed.
>>> I also agree, but it’ll take more time and the above is a good
>>> work-around for the mean time.
>> Strongly disagree workarounds are like glue: they stick around. This one
>> is one that will stick around once implemented. It's better to avoid
>> workarounds if sane solution is within reach.
>> In this case you still haven't even named a single board where CBMEMC
>> doesn't work.
> 
> CBMEM console does not work for romstage on all AMD based boards. Ask
> Rudolf and Kyösti for more details, but as far as I understood them, the
> solution is *not* easy and not within reach at all.
> 
As I already told the info from romstage is likely of minor importance
if the board boots. And if it doesn't, well no board status. If any of
the info from romstage is relevant it can be printed in ramstage as well
> 
> Thanks,
> 
> Paul
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 19.02.2014 00:18, Paul Menzel wrote:
>>> > > But in general I think I agree with Vladimir. CBMEM console should be
>>> > > supported and if not then that should be fixed.
> I also agree, but it’ll take more time and the above is a good
> work-around for the mean time.
Strongly disagree workarounds are like glue: they stick around. This one
is one that will stick around once implemented. It's better to avoid
workarounds if sane solution is within reach.
In this case you still haven't even named a single board where CBMEMC
doesn't work.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] A Growing Concern

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 18.02.2014 06:21, amlo...@tfwno.gf wrote:
> As a privacy and freedom oriented PC/Linux user, it scares me how modern
> day devices are becoming extremely proprietary. Companies are beginning
> to ship their laptops/tablets with proprietary EFI systems which have
> some nasty things in them. I recently purchased a Dell Venue 8 Pro(one
> of many upcoming 8" windows 8.1(x86) tablets) and while i was searching
> through its BIOS, i noticed that it had the computrace option activated.
> After disabling it, i decided to try to put coreboot on it, only to find
> that its non-existent for my device. Although it says that its disabled,
> i dont trust it one bit. While it is a beautiful, fast and
> ultra-portable PC, it bothers me how there are no free alternatives for
> it. These types of devices are growing in numbers and will most likely
> continue on through the years.
> 
> All I ask of you is to try and make EFI alternatives to all these
> upcoming devices.
> 
All of them? Possible but will probably cost you millions in workforce.
If you really want coreboot on some devices that interest you, you'll
have to back it up with either work(do port yourself) or money (hire
someone, you can post a bounty)
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Trouble with coreboot for Roda RK9 (SOLVED)

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 14.02.2014 13:38, Dmitry Bagryanskiy wrote:
> //Enable Com3
> pci_write_config32(LPC_DEV, D31F0_GEN2_DEC, 0x001c02e1);
> //Enable Com4
> pci_write_config32(LPC_DEV, D31F0_GEN3_DEC, 0x001c03e1);
GEN*_DEC should not be set to com* ports. Instead there are dedicated
bits for enabling decode of serial port ranges. Consult southbridge
documentation.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Ram Init: Intel i945: Timing parameters

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 14.02.2014 00:03, Mohit Gupta wrote:
> I am having trouble understanding i945 ram init code especially timing
> parameters. Can some explain me in layman language? When I go through
> DDR2 specification, timing related text is too complex and confusing.
> Interested in getting very simple explanation.
> 
There isn't any. RAM init is difficult.
> Also, i945 ram init code is doing lot of settings in MCH. Is there any
> step by step documentation available?
> 
Sure:
1) Locate intel offices
2) Locate their top-secret safes
3) Observe security
4) Buy military gear
5) Recruit and train a company (~200 people) for a year
6) Launch assault on the office
7) Break into the safe
8) Get out of Intel building
9) Read the documentation

> Regards
> Mohit Gupta
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot port for macbook2,1

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 13.02.2014 23:47, Mono wrote:
> Hallo
> 
> finally I managed to enable SPI on the Beaglebone Black and use it as 
> external programmer with flashrom.
> I read the macbook's flash chip twice, as suggested. Both rom files are 
> identical. But: a few days/week ago I read the flash chip with the macbook's 
> internal programmer. This file differs from what the external programmer got. 
> Some 9500 bytes (out of 2MiB) differ. apart from a few exeptions those bytes 
> are 0xff read with the internal programmer, but have random hex code when 
> read with the external programmer. Well, between the usage of internal and 
> external programmer the macbook was in normal use. I didnt expect the OS or 
> EC(?) or something to write to the flash chip while it is in normal use. what 
> do you think? what could cause this differnce? I can paste the rom contents 
> later somewhere if that would help any.
> 
That is pretty normal. Some firmwares store debug log or parameters in
flash.
> best regards
> Mono
> 
> On Sat, Feb 08, 2014 at 03:37:40PM +0100, Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>> On 08.02.2014 15:27, Mono wrote:
>>> Hallo,
>>>
>>> On Mon, Feb 03, 2014 at 10:16:30PM +0100, Vladimir 'φ-coder/phcoder' 
>>> Serbinenko wrote:
>>>>> CY8C24794-24LFXI
>>>> My guess: it's part of keyboard + touchpad
>>>> Do you already know which port is USBdebug one?
>>> Yes, I found out with a USB stick, dmesg and lsusb -t.
>>>
>>>> Did you already test USB debug with dbgp?
>>> Yes, I tested USB debug for the Thinkpad X60, I assume it would work the 
>>> same for Macbook.
>>>
>> I meant that you can use debug port as early printk device. It's
>> recommended to check dongle this way if your dongle is the real dbgp dongle.
>>>>
>>>>> Um, there are much more 00's than for the Thinkpad X60. Not sure what
>>>> this means
>>>> Different firmware. Most likely less functions are on it (keyboard and
>>>> touchpad are on USB and handled by another chip). You'll need to make
>>>> directory ec/apple/h8 for it and no code from lenovo/h8 will be reusable.
>>>>
>>>>> What about those Block Protect things?
>>>> Forget them for now, you'll be flashing externally until you have
>>>> working version anyway
>>>>
>>>
>>> I updated the webpage about what I did ( 
>>> http://macbook.donderklumpen.de/coreboot/ ).
>>> At the moment I am looking at x60's romstage.c because I'd plan to copy as 
>>> much as possible from it. At the function static void ich7_enable_lpc(void) 
>>> I got stuck. I can make some guesses, but don't know where the details are 
>>> documented. If you could point me to any documentation, I'd love to read 
>>> it. I tried ich7 datasheet and LPC Interface Specification but did not spot 
>>> what the function ich7_enable_lpc does.
>>>
>>> By comparing the output of lspci -nnvvvxxx -s 00:1f.0 on the Thinkpad with 
>>> coreboot and the Macbook with factory bios I get the following:
>>>  
>>> on the Thinkpad
>>> $ lspci -nnvvvxxx -s 00:1f.0
>>> 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC 
>>> Interface Bridge [8086:27b9] (rev 02)
>>> Subsystem: Lenovo ThinkPad T60/R60 series [17aa:2009]
>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
>>> Stepping- SERR- FastB2B- DisINTx-
>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
>>> SERR- >> Latency: 0
>>> Capabilities: [e0] Vendor Specific Information: Len=0c 
>>> Kernel driver in use: lpc_ich
>>> Kernel modules: intel_rng, lpc_ich, leds_ss4200
>>> 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00
>>> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 09 20
>>> 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
>>> 40: 01 05 00 00 80 00 00 00 81 04 00 00 10 00 00 00
>>> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 60: 80 80 80 80 d0 00 00 00 80 80 80 80 00 00 00 00
>>> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> 80: 10 02 0d 1f 01 16 7c 00 e1 15 0c 00 81 16 1c 00
>>> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>> a0: ac 06 00 00 30 00 00 00 13 1c 0a 00 00 03 00 00
>>> b0: 00 00 f0 00 00 00 00 00 00 00 02 0a 00 00 00 00
>>> c0: 00 00 00 00 0

Re: [coreboot] SeaVGABIOS with native vga init (Need testers)

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 13.02.2014 01:23, Kevin O'Connor wrote:
>> Looking through the output of
>> > 
>> >$ git grep k8t890 src/mainboard/
>> > 
>> > the boards Asus A8V-E Deluxe, Asus A8V-E SE, Asus K8V-X, Asus M2V-MX SE
>> > and Asus M2V should theoretically support that.
> Okay.  The SeaVGABIOS implementation is expecting a coreboot table
> (LB_TAG_FRAMEBUFFER).  So, as long as that is present it should work.
> 
LB_TAG_FRAMEBUFFER is present only if display is placed in graphics
mode, otherwise EGA text mode is assumed.
EGA text mode is much easier to make use of (including for oprom) and
more compatible than graphics counterpart.
Lenovo X201 init makes use of EGA text mode as well.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 11.02.2014 01:56, mrnuke wrote:
> On Tuesday, February 11, 2014 12:04:33 AM Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>> If we let user supply
>> files at all, it should be added to report, not replace files, and it
>> should have some prefix to clearly indicate that user was involved in
>> creating them. E.g. user_serial_log.txt
>>
> There is a point at which the information becomes "too much". What is really 
> relevant, in my opinion, are the following three points:
> 
> 1. Is it an unmodified commit in master (AKA, not "-dirty").
> 2. Does it boot?
> 3. What does not work, if any ?
> 
> Point 1 and 2 are answered by "cbmem -c | head". It answers point 1 with the 
> first line of output, and point 2 by the fact that getting anything from 
> cbmem 
> means you've already booted your system.
> 
> Point 3 is more complicated, and it seems it is because of this point that we 
> want to collect any and all information we can possibly get our hands on.
> 
> Other than "cbmem -c | head" and .config, a majority of people just don't 
> care 
> about all the pesky details. They're only useful when debugging problems some 
> poor guy or gal is having. In that case, we can ask them for this info 
> manually. It's not of any use in tracking down which revision + config works 
> on _this_ board.
> 
This is not the only uses of board-status. It's also useful to see if
some boards have an issue which one meets in particular board. This
information is important in tracking bugs down but hard to collect
unless it's in the board-status.
> Alex
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 10.02.2014 23:47, David Hendricks wrote:
> On Sun, Feb 9, 2014 at 4:50 AM, Paul Menzel
>  > wrote:
> 
> Dear coreboot folks,
> 
> 
> currently no coreboot messages are stored for boards not supporting
> CBMEM console (or where this option is disabled (currently by default))
> or no coreboot *romstage* messages are stored for boards, where the data
> cannot be preserved (passed to ramstage).
> 
> Using the serial (or USB) console all these messages can be captured
> with no problem, so I propose to just add these captured messages into
> the file `serial_console.txt`. Of course this file probably contains
> also the payload and (Linux) kernel log, but I think that is fine.
> 
> SeaBIOS’ `readserial.py` should be used for capturing the messages as it
> adds time stamps.
> 
> Scripting this is going to be hard, as the log is captured on a
> different system. So for now I propose to add it manually.
> 
> 
> I don't think the script itself should be responsible for collecting
> serial output. Instead, how about adding an argument to override the
> default behavior of running "cbmem -c" on the target so that the user
> can pass in a filename? The user will simply capture the serial output
> using whatever tool they like, dump the output to a text file, and run
> the script with an argument to use the file instead of calling "cbmem
> -c". Here is a proof-of-concept: http://review.coreboot.org/#/c/5191 .
> 
This requires user to do right manipulations. While keyboard and chair
are usually fine, the space between them exhibits strong bug-inducing
properties. The idea of the script is to reduce a possibility of user
error creating strange reports. In this case the common erro I expect is
using a stale file fom some other version. It's a particularly nasty one
as at first glance in may look fine but would be almost useless to track
how details changed from one submit to the next. If we let user supply
files at all, it should be added to report, not replace files, and it
should have some prefix to clearly indicate that user was involved in
creating them. E.g. user_serial_log.txt
> But in general I think I agree with Vladimir. CBMEM console should be
> supported and if not then that should be fixed.
> 
> -- 
> David Hendricks (dhendrix)
> Systems Software Engineer, Google Inc.
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 09.02.2014 14:34, Paul Menzel wrote:
> Am Sonntag, den 09.02.2014, 14:18 +0100 schrieb Vladimir 'φ-coder/phcoder' 
> Serbinenko:
>> On 09.02.2014 13:50, Paul Menzel wrote:
> 
>>> currently no coreboot messages are stored for boards not supporting
>>> CBMEM console
>>
>> Is there any remaining? If so it's an issue to be fixed
> 
> Sorry, no idea. I thought there were some. At least not all boards have
> been tested to my knowledge.
> 
board-status is all about testing. When we see incomplete
coreboot_console.txt it means there is a bug to be fixed, not workarounded.
>>> (or where this option is disabled (currently by default))
>>
>> Change the defaults.
> 
> It is not safe or wanted for all boards I believe. But others are more
> knowledgeable to comment on that issue.
> 
I don't see any problem with enabling cbmemc by default on all boards.
>>> or no coreboot *romstage* messages are stored for boards, where the data
>>> cannot be preserved (passed to ramstage).
>>
>> which boards are concerned? Which boards use ROMCC for romstage? Do they
>> output anything useful in romstage? If so, can't it be compensated by
>> ramstage?
> 
> In my case it is the Asus M2V-MX SE (AMD, pre-AGESA).
> 
What is the info we need from it? ROMCC boards usually don't output much.
>>> Using the serial (or USB)
Your argument with USB console is completele broken as EHCI debug is not
supported on ROMCC boards at all.
>>> console all these messages can be captured
>>> with no problem, so I propose to just add these captured messages into
>>> the file `serial_console.txt`. Of course this file probably contains
>>> also the payload and (Linux) kernel log, but I think that is fine.
>>>
>>> SeaBIOS’ `readserial.py` should be used for capturing the messages as it
>>> adds time stamps.
>>>
>>> Scripting this is going to be hard, as the log is captured on a
>>> different system. So for now I propose to add it manually.
>>
>> Having to capture serial makes setup needed for board-status more
>> difficult.
> 
> Surely it will not be a requirement to capture the serial output. My
> proposal is about adding it, when it is captured already and what file
> name to use.
> 
And who will care about it then?
>> Certainly, one needs to have a recovery method for case of
>> brick
> 
> You always need that in case of a brick. What is special about serial
> log?
> 
I use debricking setup perhaps every 20 flashes on a supported board.
Not every time.
>> but having a complete serial setup will heavily reduce board-status
>> input which already isn't huge.
> 
> Again, it is not meant to be a requirement in addition to what is
> currently captured.
> 
> 
> Thanks,
> 
> Paul
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [RFC] board_status: Add serial log to `serial_console.txt`

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 09.02.2014 13:50, Paul Menzel wrote:
> Dear coreboot folks,
> 
> 
> currently no coreboot messages are stored for boards not supporting
> CBMEM console
Is there any remaining? If so it's an issue to be fixed
> (or where this option is disabled (currently by default))
Change the defaults.
> or no coreboot *romstage* messages are stored for boards, where the data
> cannot be preserved (passed to ramstage).
> 
which boards are concerned? Which boards use ROMCC for romstage? Do they
output anything useful in romstage? If so, can't it be compensated by
ramstage?
> Using the serial (or USB) console all these messages can be captured
> with no problem, so I propose to just add these captured messages into
> the file `serial_console.txt`. Of course this file probably contains
> also the payload and (Linux) kernel log, but I think that is fine.
> 
> SeaBIOS’ `readserial.py` should be used for capturing the messages as it
> adds time stamps.
> 
> Scripting this is going to be hard, as the log is captured on a
> different system. So for now I propose to add it manually.
> 
Having to capture serial makes setup needed for board-status more
difficult. Certainely, one needs to have a recovery method for case of
brick but having a complete serial setup will heavily reduce
board-status input which already isn't huge.
> 
> Thanks,
> 
> Paul
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] LinuxTag in Berlin from May 8–10, 2014

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 08.02.2014 23:13, Paul Menzel wrote:
> Dear coreboot folks,
> 
> 
> just a short announcement that after FOSDEM last weekend the next free
> software event (in Europe(?)) is going to be LinuxTag in Berlin from May
> 8–10, 2014.
> 
I won't be able to attend
> The location is going to be different this year. Since several years it
> won’t be happening at Messe Berlin but at STATION BERLIN [2].
> 
> So please mark that in your calender and let’s see what we can come up
> with coreboot wise for that event.
> 
> 
> Thanks,
> 
> Paul
> 
> 
> [1] http://linuxtag.de/2014/en/
> [2] http://www.station-berlin.de/en/location_directions/location.html
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot port for macbook2,1

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 08.02.2014 15:27, Mono wrote:
> Hallo,
> 
> On Mon, Feb 03, 2014 at 10:16:30PM +0100, Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>>> CY8C24794-24LFXI
>> My guess: it's part of keyboard + touchpad
>> Do you already know which port is USBdebug one?
> Yes, I found out with a USB stick, dmesg and lsusb -t.
> 
>> Did you already test USB debug with dbgp?
> Yes, I tested USB debug for the Thinkpad X60, I assume it would work the same 
> for Macbook.
> 
I meant that you can use debug port as early printk device. It's
recommended to check dongle this way if your dongle is the real dbgp dongle.
>>
>>> Um, there are much more 00's than for the Thinkpad X60. Not sure what
>> this means
>> Different firmware. Most likely less functions are on it (keyboard and
>> touchpad are on USB and handled by another chip). You'll need to make
>> directory ec/apple/h8 for it and no code from lenovo/h8 will be reusable.
>>
>>> What about those Block Protect things?
>> Forget them for now, you'll be flashing externally until you have
>> working version anyway
>>
> 
> I updated the webpage about what I did ( 
> http://macbook.donderklumpen.de/coreboot/ ).
> At the moment I am looking at x60's romstage.c because I'd plan to copy as 
> much as possible from it. At the function static void ich7_enable_lpc(void) I 
> got stuck. I can make some guesses, but don't know where the details are 
> documented. If you could point me to any documentation, I'd love to read it. 
> I tried ich7 datasheet and LPC Interface Specification but did not spot what 
> the function ich7_enable_lpc does.
> 
> By comparing the output of lspci -nnvvvxxx -s 00:1f.0 on the Thinkpad with 
> coreboot and the Macbook with factory bios I get the following:
>  
> on the Thinkpad
> $ lspci -nnvvvxxx -s 00:1f.0
> 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface 
> Bridge [8086:27b9] (rev 02)
>   Subsystem: Lenovo ThinkPad T60/R60 series [17aa:2009]
>   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
>   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> SERR-Latency: 0
>   Capabilities: [e0] Vendor Specific Information: Len=0c 
>   Kernel driver in use: lpc_ich
>   Kernel modules: intel_rng, lpc_ich, leds_ss4200
> 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 09 20
> 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
> 40: 01 05 00 00 80 00 00 00 81 04 00 00 10 00 00 00
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 80 80 80 80 d0 00 00 00 80 80 80 80 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 10 02 0d 1f 01 16 7c 00 e1 15 0c 00 81 16 1c 00
> 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: ac 06 00 00 30 00 00 00 13 1c 0a 00 00 03 00 00
> b0: 00 00 f0 00 00 00 00 00 00 00 02 0a 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 33 22 11 00 67 45 00 00 cf ff 00 00 08 00 00 00
> e0: 09 00 0c 10 b4 02 24 17 00 00 00 00 00 00 00 00
> f0: 01 c0 d1 fe 00 00 00 00 86 0f 02 00 00 00 00 00
> 
> and on the Macbook
> $ lspci -nnvvvxxx -s 00:1f.0
> 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface 
> Bridge [8086:27b9] (rev 02)
>   Subsystem: Intel Corporation Device [8086:7270]
>   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
>   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
> SERR-Latency: 0
>   Capabilities: [e0] Vendor Specific Information: Len=0c 
>   Kernel driver in use: lpc_ich
>   Kernel modules: intel_rng, lpc_ich, leds_ss4200
> 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00
> 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 70 72
> 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
> 40: 01 04 00 00 80 00 00 00 01 05 00 00 10 00 00 00
> 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 60: 80 80 80 80 d0 00 00 00 80 80 80 80 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 10 00 07 38 81 06 0c 00 41 16 0c 00 00 00 00 00
> 90: 01 03 1c 00 00 00 00 00 00 00 00 00 00 00 00 00
> a0: 04 02 00 00 01 00 00 00 13 1c 0a 00 00 03 00 00
> b0: 00 00 f0 00 00 00 00 00 08 80 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 33 22 00 00 67 45 00 00 00 ff 00 00 00 00 00 00
> e0: 09 00 0c 10 b4 02 24 17 00 00 00 00 00 00 00 00
&g

Re: [coreboot] HP Chromebook 14 (Falco)

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 07.02.2014 17:57, Rubén Torrero Marijnissen wrote:
> Hi,
> 
> I grew tired today of the default firmware that comes with my Google
> Chromebook 14; just when I had my Arch Linux install perfectly working
> somehow, by letting it attempt to boot Chrome OS, it messed up my
> partitions.
> 
> If I have understood correctly (please, correct me if i'm wrong), the
> code for this model is alredy in place in the Git repository but no one
> has really tested it (or has reported anything on the wiki).
> 
> Does anyone have more info? should I be able to flash it with flashrom
> after I build it?
> 
If you use upstream, please submit board-status result
> Any help is appreciated, I will update the wiki will all the info once
> i'm done.
> 
> Thanks!
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Support for Dell desktop motherboard

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 06.02.2014 23:46, Ramkumar Ramachandra wrote:
> Hi,
> 
> I have a Dell T5500 desktop, and I'd like to know if Coreboot supports
> this.
No. http://www.coreboot.org/Supported_Motherboards
> According to dmidecode, the motherboard is a Dell 0D883F.
> 
> Thanks.
> 
> Ram
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] [RFT] Lenovo convertible tablets X60t, X201t, X230t

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello, all. I've uploaded digitizer support for X*t variants. Not tested
in current form yet (was developped on Jens Erat's X201T during FOSDEM).
Please test:
- X60t owners: http://review.coreboot.org/#/c/5113/
- X201t owners: http://review.coreboot.org/#/c/5096
- X230t owners: should work without additional support (USB).
Please report test result be it either positive or negative.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot port for macbook2,1

[Vladimir 'φ-coder/phcoder' Serbinenko]

> CY8C24794-24LFXI
My guess: it's part of keyboard + touchpad
Do you already know which port is USBdebug one?
Did you already test USB debug with dbgp?

> Um, there are much more 00's than for the Thinkpad X60. Not sure what
this means
Different firmware. Most likely less functions are on it (keyboard and
touchpad are on USB and handled by another chip). You'll need to make
directory ec/apple/h8 for it and no code from lenovo/h8 will be reusable.

> What about those Block Protect things?
Forget them for now, you'll be flashing externally until you have
working version anyway



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Motherboard Not on Support MB List -> Specs

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 03.02.2014 17:37, lee.changhan wrote:
> Hi, I have some info about my motherboard here according to the FAQ page
> to see if anyone can tell me about the compatibility between my BIOS and
> coreboot.
> 
Your motherboard is not compatible with coreboot.

> 1. Gigabyte GA-Z77-HD3 Motherboard
>Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz
>
> 2. lspci -tvnn
> 
> -[:00]-+-00.0  Intel Corporation Xeon E3-1200 v2/3rd Gen Core
> processor DRAM Controller [8086:0150]
>+-01.0-[01]--+-00.0  Advanced Micro Devices, Inc. [AMD/ATI]
> Caicos [Radeon HD 6450/7450/8450] [1002:6779]
>|\-00.1  Advanced Micro Devices, Inc. [AMD/ATI]
> Caicos HDMI Audio [Radeon HD 6400 Series] [1002:aa98]
>+-14.0  Intel Corporation 7 Series/C210 Series Chipset Family
> USB xHCI Host Controller [8086:1e31]
>+-16.0  Intel Corporation 7 Series/C210 Series Chipset Family
> MEI Controller #1 [8086:1e3a]
>+-1a.0  Intel Corporation 7 Series/C210 Series Chipset Family
> USB Enhanced Host Controller #2 [8086:1e2d]
>+-1b.0  Intel Corporation 7 Series/C210 Series Chipset Family
> High Definition Audio Controller [8086:1e20]
>+-1c.0-[02]--
>+-1c.2-[03]00.0  Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168]
>+-1c.3-[04-05]00.0-[05]--
>+-1d.0  Intel Corporation 7 Series/C210 Series Chipset Family
> USB Enhanced Host Controller #1 [8086:1e26]
>+-1f.0  Intel Corporation Z77 Express Chipset LPC Controller
> [8086:1e44]
>+-1f.2  Intel Corporation 7 Series/C210 Series Chipset Family
> 4-port SATA Controller [IDE mode] [8086:1e00]
>+-1f.3  Intel Corporation 7 Series/C210 Series Chipset Family
> SMBus Controller [8086:1e22]
>\-1f.5  Intel Corporation 7 Series/C210 Series Chipset Family
> 2-port SATA Controller [IDE mode] [8086:1e08]
> 
> 3. superiotool -dV
> superiotool r6637
> Probing for ALi Super I/O at 0x3f0...
>   Failed. Returned data: id=0x, rev=0xff
> Probing for ALi Super I/O at 0x370...
>   Failed. Returned data: id=0x, rev=0xff
> Probing for Fintek Super I/O at 0x2e...
>   Failed. Returned data: vid=0x, id=0x
> Probing for Fintek Super I/O at 0x4e...
>   Failed. Returned data: vid=0x, id=0x
> Probing for Fintek Super I/O at 0x2e...
>   Failed. Returned data: vid=0x, id=0x
> Probing for Fintek Super I/O at 0x4e...
>   Failed. Returned data: vid=0x, id=0x
> Probing for ITE Super I/O (init=standard) at 0x25e...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=it8502e) at 0x25e...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=it8761e) at 0x25e...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=it8228e) at 0x25e...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=0x87,0x87) at 0x25e...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=standard) at 0x2e...
>   Failed. Returned data: id=0x8728, rev=0x1
> Probing for ITE Super I/O (init=it8502e) at 0x2e...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=it8761e) at 0x2e...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=it8228e) at 0x2e...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=0x87,0x87) at 0x2e...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=standard) at 0x4e...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=it8502e) at 0x4e...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=it8761e) at 0x4e...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=it8228e) at 0x4e...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=0x87,0x87) at 0x4e...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=legacy/it8661f) at 0x370...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for ITE Super I/O (init=legacy/it8671f) at 0x370...
>   Failed. Returned data: id=0x, rev=0xf
> Probing for NSC Super I/O at 0x2e...
>   Failed. Returned data: port=0xff, port+1=0xff
> Probing for NSC Super I/O at 0x4e...
>   Failed. Returned data: port=0xff, port+1=0xff
> Probing for NSC Super I/O at 0x15c...
>   Failed. Returned data: port=0xff, port+1=0xff
> Probing for NSC Super I/O at 0x164e...
>   Failed. Returned data: port=0xff, port+1=0xff
> Probing for Nuvoton Super I/O at 0x164e...
>   Failed. Returned data: chip_id=0x
> Probing for Nuvoton Super I/O (sid=0xfc) at 0x164e...
>   Failed. Returned data: sid=0xff, id=0x, rev=0x00
> Probing for Nuvoton Super I/O at 0x2e...
>   Failed. Returned data: chip_id=0x
> Probing for Nuvoton Super I/O (sid=0xfc) at 0x2e...
>   Failed. Returned data: sid=0

Re: [coreboot] coreboot port for macbook2,1

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 03.02.2014 21:43, Mono wrote:
> Hallo Vladimir, Peter and Stefan
> 
> thank you for your emails! You already helped me alot. I don't expect to 
> successfully close this project in a fast run and I'm willing to learn a 
> number of tools.
> 
> At the moment I am still collecting hardware informations about this computer.

> I dissembled it completely and documented the chip names of what I thought 
> might be of interest.

> Please see http://macbook.donderklumpen.de/coreboot/ for what I got.

That is good example of relevant info collection.

> My biggest concern is with the EC.

> It is a Renesas H8S/2116V. I read about this chip that it makes coreboot 
> impossible on other machines,

> but I do not know whether this issue is machine specific, or if the chip 
> definitely makes coreboot impossible for this macbook too.

> Could you comment on this?

Type of EC doesn't matter. What matters is how it is connected. It may
really get in the way or have almost no impact. My guess would be that
on your system its influence is minor.
X60 has H8 as well but with very different firmware which makes it a
completely different chip from coreboot perspective.
> Also I do not know yet how I could verify whether the EC shares memory with 
> the main system.
> 
That flashrom didn't create any ill effects when reading is an
indication of separate flash. If you can flash externally you can leave
the issue of internal flash for later and if you don't, don't flash.
> As for the ability of flashing the EPROM chip, I plan to test it in the near 
> future

> (at first with an empty brand new chip, then with the soldered one). The 
> EPROM is supported by flashrom

> and I plan to use a Beaglebone Black to be the programmer. (this page shows 
> Beaglebone Black can

> flash a chip via SPI also flashrom is not used here: 
> http://www.linux.com/learn/tutorials/746860-how-to-access-chips-over-the-spi-on-beaglebone-black
>  )

> I already learned how to use the Beaglebone Black to debug what coreboot 
> outputs to the USB port on a Thinkpad X60.

> I assume this should work the same for the macbook (the debug port at the 
> macbook seems to exist, but the factory BIOS does not write anything to it). 
Good
> 
> One more question: The macbook atm uses a 32bit EFI which when it was 
> purchased booted a 32bit kernel,

> and today boots a 64bit linux-libre kernel. Would I need to expect any 
> additional problems from the fact that

> it is not a traditional BIOS, but some EFI which is to be replaced? My 
> optimistic wish is to replace that

> EFI with coreboot plus a 64bit GRUB2 payload (same as done on my Thinkpad 
> X60). Or would the payload need to be kept at 32bit?
What Apple ships as firmware is irrelevant.
However, decision to omit BIOS comes from higher-level decision of
omiting compatibility with 95-era systems. So it's possible you won't be
able to boot old OS even with coreboot due to lack of compatibility
devices. I'd say it's a minor problem (95-era OS wouldn't work reliably
on modern system anyway)
> 
> thanks again and
> with best regards
> Mono
> 
> On Wed, Jan 29, 2014 at 10:24:58PM +0100, Stefan Reinauer wrote:
>> * Mono  [140124 23:20]:
>>> Hallo,
>>> Would you help me on a coreboot port? I just installed coreboot on a 
>>> Thinkpad X60 following the wiki. Now I want it on this mid-2007 macbook2,1 
>>> too.
>>> I read some pages in the wiki and started to collect information about the 
>>> macbook. it seems it has no superIO chip and I dont know what to think of 
>>> the ectool output. As I understood by now, not knowing how the ec might 
>>> interfere with the bios or coreboot is one of the big obstacles, no? I hope 
>>> that once I would try a coreboot flash, recovery might be possible by an 
>>> external programmer (which I do not have, yet). the flash chip is the same 
>>> as on the X60 (I've read the factory bios already) as is the northbridge 
>>> and southbridge. an usb debug port seems available.
>>> I've put the log files here: http://macbook.donderklumpen.de/coreboot/
>>> Any comment about what you think about this and how I should proceed is 
>>> very much welcome!
>>
>> - Make sure you have the external tools in place to recover from a bad
>>   flash. You will notg boot successfully on the first attempt.
>>
>> - Keep a copy of the original firmware around
>>
>> - Try to make sure that your USB debug gadget is working before starting
>>
>> - Start with one of the existing i945 based notebooks
>>
>> - find out what EC is used, and if it shares flash with the main system
>>
>> - try to get hold of schematics
>>
>> Regards,
>> Stefan
>>
>>
>> -- 
>> coreboot mailing list: coreboot@coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Please use Git commit hooks

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 02.02.2014 12:05, Paul Menzel wrote:
> Dear coreboot folks,
> 
> 
> if you push patches please either check them manually or simply let the
> Git commit hooks do it for you by running `make gitconfig`. I know they
> take a lot of time especially when you run them the first time in a
> session. This will be hopefully improved soon.
> 
The problem is not this. The problem is that they regularly fail and
prevent you from doing any commit
> 
> Thanks,
> 
> Paul
> 
> 
> 


-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo Thinkpad T61

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 31.01.2014 20:30, ron minnich wrote:
> If you want a laptop to tear into and learn from, the old samsung x86
> chromebook is hard to beat. ram and disk are standard and upgradable,
> you can put a clip on the flash part, ...
Lenovo X201 and X230 both have those characteristics as well. Unlike
chromebooks it doesn't come with a nice firmware preinstalled though.
But I have to admit that compared to other vendors (especially the one
called "To be filled by O.E.M."), lenovo's BIOS and EFI are good.
> it's just a very hackable
> machine. I still have one and really like it.
> 
> More recent ones to mess around with include the acer c720.
> 
> The difficulty of dealing with chipsets is what keeps me pushing on
> chromebooks. It's a real time saver. I'd still like to find an AMD
> solution however.
> 
I'm thinking of lenovo x140e. Not available in Europe though.

> ron
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo Thinkpad T61

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 31.01.2014 17:21, ron minnich wrote:
> If your only way to flash the flash is via a program, or something
> embedded in the lenovo bios, stop now, or stockpile 20 or 30 of these
> laptops, because you're going to create some bricks along the way.
> 
Let me elaborate on this:
RTFM http://flashrom.org/ISP
RTFM http://flashrom.org/Technology
RTFM http://flashrom.org/Supported_programmers

> ron
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo Thinkpad T61

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 31.01.2014 17:08, Roberto A. Foglietta wrote:
> 
> 
> 
> 2014-01-31 Peter Stuge mailto:pe...@stuge.se>>:
> 
> Roberto A. Foglietta wrote:
> > I check the list of supported motherboards and laptops but I did
> not found
> > in them the Lenovo Thinkpad T61
> 
> That means that it is not supported.
> 
> 
> Thanks Peter for the fast answer.
>  
> 
> 
> > I would like to understand the magnitude of probability to brick
> > the laptop before.
> 
> The probability is 1.0.
> 
> 
> I am interested in the probability after some development / adaption,
> not as-is.
> 
> How much developing effort do you think the support of T61 would require?
> 
Northbridge (i965) is unsupported. It's almost impossible to write
raminit without having a lot of low-level experience and even then it
takes couple of months of quite intensive work.
You may get lucky and i945 raminit may work with only minor adaptations but:
1) I wouldn't count on it
2) And even then find out what exactly needs adaptation is no easy task.
I have a laptop with i965  as well, in storage but I have to tell it's
simply not worth the effort. You'd be better off cuying some recent
supported laptop (see supported mobos pages, especially chromebooks and
Lenovos) or some almost supported laptop and adapt to it. But:
a) Problems may pop up in unexpected places.
b) While guys in #coreboot are extremely helpful you end up being on
your own in 95% of problems (unless someone has a similar chipset and
works on it, currently nobody AFAIK).
c) Easiest (but not easy) to adapt would be (from easiest to difficult,
no guarantee, problems may pop up in unexpected places):
- T410. All components are already in the tree. The problem with this
laptop is that it has TSOP chip, for which clip is very expensive, so
you probably would have to solder to the chip with all the risks it
entails. Actually for most people it means to ask someone to solder for you
- Nehalem-based laptops. Main problem is likely EC
- AMD-based laptops. Main problem is likely EC.
- Lenovo *30 laptops (ivybridge). Dual graphics can be a headache but
it's feasible. If chip is TSOP, see T410 comment.
- Other ivy or sandy laptops. Depends on how much MRC code likes or
dislikes your laptop.
I repeat again that even the easiest ones are hard if you have no
low-level experience and even if you do can become hard in case of
unexpected problem.
On the other hand if you're curious about it , do it! It's a fantastic
learning experience.
> To answer to this second question I suppose you need logs, do not you?
> 
lspci -vvnn is available for most laptops with quick google. It (+some
experience with individual manufacturers about EC interface) allows to
estimate hardness.
> Cheers,
> R.
>  
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] cmos.layout upgradability

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 26.01.2014 05:55, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
>> http://www.coreboot.org/Infrastructure_Projects#Provide_update_paths_and_avoid_conflicts_in_addressing
>>
>> (which mentions another solution to the problem)
>>
> Flashrom solution is interesting but it doesn't handle external
> flashing. It would be a nice addition to checksums for internal flashing
> though.
> Patrick's solution would have only one advantage compared to my
> prototype: possibility of coreboot migrating the options rather than
> resetting.
Patrick's solution relies on mathematical impossibility. You can't have
such function with only 16-bit salt. Let's take any partition of 248
(see http://mathworld.wolfram.com/PartitionFunctionP.html), then create
options A,B,C,... with sizes according to this partition. The hashing
function as per Patrick's proposal would have to map them to
non-interlapping regions. By evaluating this function at A,B,C,... you
can extract the partition if number of chunks is known. Since number of
chunks is an integer from 1 to 248 so the function has to store at least:
Log2[PartitionsP[248]]-Log2[248]> 39
bits of information. So salt has to be at least 40 bits. Probably even
more if you put into mix that we also need sub-byte options and you have
to handle option names. This means:
1) You can't bruteforce such a parameter space during compile, so some
structure is needed.
2) You'll need more than 40 bits of storage in CMOS.
At this point I feel like Patrick's proposal is not practical.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] cmos.layout upgradability

[Vladimir 'φ-coder/phcoder' Serbinenko]

> http://www.coreboot.org/Infrastructure_Projects#Provide_update_paths_and_avoid_conflicts_in_addressing
> 
> (which mentions another solution to the problem)
> 
Flashrom solution is interesting but it doesn't handle external
flashing. It would be a nice addition to checksums for internal flashing
though.
Patrick's solution would have only one advantage compared to my
prototype: possibility of coreboot migrating the options rather than
resetting.
But there is a problem with attempting this: when you request for option
the hashing would always give a number, even if that option doesn't
exist. And then we're back to reading garbage for new options.
>> 2a) instead of having separate field we could make XOR layout checksum
>> into CMOS checksum. This would save 2 bytes but will break any existing
>> users if they check checksum.
> 
> (IIRC we already have problems with the Linux nvram driver which does
> checksumming somehow differently. Or maybe that was fixed already.)
> 
Ok. Let's hold 2a in reserve if 2 bytes is considered too expensive
> ...but the above reminded me that it is ultimately a responsibility
> of our source code and our design to never let booting fail simply
> due to some garbage in NVRAM.
> 
> Code and design really must ensure a working state.
> 
There are number of problems with this:
1) Overclocking options. If you overclock too much, you don't boot
successfully.
2) FILO uses options to control its behaviour. If by garbage tells to
boot from bad filename, it will probably stop unable to find the file.
3) vbnv field may be a problem.
Even if this goal is achieved we still need an upgrade way as new option
with garbage may make the system bootable but uncomfortable to most of
users, which is to avoid. E.g. disabling touchpad: I personally disable
touchpad (but through OS facilities, not coreboot) but many users would
get confused by disabled touchpad.




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Unique information

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello, all. There is amount of information that should be unique to each
machine and is supplied by coreboot. Most common examples are:
- mobo serial number
- UUID
- Internal mac.

While first 2 are not very important, the fact that currently on some
boards all of them will share the same API is disturbing. For some
machines like thinkpads this info is in some EEPROM and can be easily
read (see my path on gerrit to do so)
On other boards that info is stored in vendor flash and currently
coreboot just uses some hardcoded string which is a problem. I think
that this info should be stored in some text config file in CBFS. E.g:

Mainboard serial: 99887766
Mainboard UUID: acdea9c8-be5e-4799-a972-ead8dab8e5c0
Internal MAC: 00:11:22:33:44:55

The file would be added at compile time from info supplied by user or
randomly-generated strings if user didn't supply it.
In case of missing file coreboot should disable internal NIC if
possible. Duplicate macs should never go into networks.
It being a separate file allows it to be easly replaced without
recompilation.
Is everyone ok with such plan of action?



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] cmos.layout upgradability

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 25.01.2014 01:28, mrnuke wrote:
> On Saturday, January 25, 2014 12:51:25 AM Vladimir 'φ-coder/phcoder' 
> Serbinenko wrote:
>> Hello, all. Due to my failue to foresee this problem if one upgrades X60
>> coreboot, you need to manually reset CMOS config or your trackpad may
>> not work as option "trackpad_enable" will get a garbage value. While I
>> admit my part of fault, I feel like we should have a way to update
>> options safely. I see following possibilities:
>> 1) Hide ourselves and tell that on upgrade you always have to clear
>> CMOS. I don't think it's really an option as users will continue just
>> running flashrom and in case of external flashing, CMOS reset may
>> require full power removal with cell battery sometimes in difficult to
>> access places inside laptop.
>> 2) Have some version field to check and if it mismatches reset CMOS to
>> default. To avoid having to maintain version manually I propose to
>> checksum option table and write 16-bit result to CMOS. 16-bit should
>> give enough confidence without excessively using CMOS. I've made a
>> prototype at http://review.coreboot.org/#/c/4790/4 . If we can agree
>> that it's a right approach, I'll make this prototype into complete patch
>> (mostly missing is laborous adding of version field)
>> 2a) instead of having separate field we could make XOR layout checksum
>> into CMOS checksum. This would save 2 bytes but will break any existing
>> users if they check checksum.
> 
> You mean it won't write the cmos.default after upgrade?
> 
Not it won't. Checksum covers the same range and is at same position. So
checksum is still valid.
> And why would you need to reset CMOS if trackpad is disabled?
> 
>  # nvramtool -a
>  # nvramtool -w trackpad_enable=Enable
> 
You could do it in this particular case but user isn't required to know
this. And settings may be something more drammatic. It may happen that
the system doesn't boot with garbage settings at all. The fact that you
have to handle garbage in saved option indicates that something is wrong.




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Fwd: Re: coreboot port for macbook2,1

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 25.01.2014 01:23, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> 
> 
> 
>  Original Message 
> Subject: Re: [coreboot] coreboot port for macbook2,1
> Date: Sat, 25 Jan 2014 01:23:12 +0100
> From: Vladimir 'φ-coder/phcoder' Serbinenko 
> To: Mono 
> 
> On 24.01.2014 23:20, Mono wrote:
>> Hallo,
>> Would you help me on a coreboot port? I just installed coreboot on a 
>> Thinkpad X60 following the wiki. Now I want it on this mid-2007 macbook2,1 
>> too.
>> I read some pages in the wiki and started to collect information about the 
>> macbook. it seems it has no superIO chip and I dont know what to think of 
>> the ectool output. As I understood by now, not knowing how the ec might 
>> interfere with the bios or coreboot is one of the big obstacles, no? I hope 
>> that once I would try a coreboot flash, recovery might be possible by an 
>> external programmer (which I do not have, yet). the flash chip is the same 
>> as on the X60 (I've read the factory bios already) as is the northbridge and 
>> southbridge. an usb debug port seems available.
>> I've put the log files here: http://macbook.donderklumpen.de/coreboot/
>> Any comment about what you think about this and how I should proceed is very 
>> much welcome!
>>
> Good news is that other than EC and some minor points, your macbook is a
> copy of X60. With some luck a qualified dev can do it in a week (you may
> want to post bounty for it). You need to get console. EHCI debug would
> be the best option on your laptop.
> http://www.coreboot.org/EHCI_Debug_Port#Finding_the_USB_debug_port
> Take USB 2.0 stick and plug it into different port until it appears as
> device one on bus 3.
I meant port 1 on bus managed by ehci_pci (exact bus numbers are unstable)
> You'll have to make a USB debug dongle or buy one
> (short supply).
> You'll also need to find your flash chip. Your laptop has this chip:
> http://orzparts.com/index.php?main_page=product_info&products_id=732
> You'll have to teardown the whole laptop, looking at every chip which
> seems similar. Remember to discharge from static electricity before
> opening your laptop and not to wear anything that produces it. This has
> a risk of breaking your laptop, proceed at your own risk, you've been
> warned.
>> thanks
>> Mono
>>
> 
> 
> 
> 
> 
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Fwd: Re: coreboot port for macbook2,1

[Vladimir 'φ-coder/phcoder' Serbinenko]

 Original Message 
Subject: Re: [coreboot] coreboot port for macbook2,1
Date: Sat, 25 Jan 2014 01:23:12 +0100
From: Vladimir 'φ-coder/phcoder' Serbinenko 
To: Mono 

On 24.01.2014 23:20, Mono wrote:
> Hallo,
> Would you help me on a coreboot port? I just installed coreboot on a Thinkpad 
> X60 following the wiki. Now I want it on this mid-2007 macbook2,1 too.
> I read some pages in the wiki and started to collect information about the 
> macbook. it seems it has no superIO chip and I dont know what to think of the 
> ectool output. As I understood by now, not knowing how the ec might interfere 
> with the bios or coreboot is one of the big obstacles, no? I hope that once I 
> would try a coreboot flash, recovery might be possible by an external 
> programmer (which I do not have, yet). the flash chip is the same as on the 
> X60 (I've read the factory bios already) as is the northbridge and 
> southbridge. an usb debug port seems available.
> I've put the log files here: http://macbook.donderklumpen.de/coreboot/
> Any comment about what you think about this and how I should proceed is very 
> much welcome!
> 
Good news is that other than EC and some minor points, your macbook is a
copy of X60. With some luck a qualified dev can do it in a week (you may
want to post bounty for it). You need to get console. EHCI debug would
be the best option on your laptop.
http://www.coreboot.org/EHCI_Debug_Port#Finding_the_USB_debug_port
Take USB 2.0 stick and plug it into different port until it appears as
device one on bus 3. You'll have to make a USB debug dongle or buy one
(short supply).
You'll also need to find your flash chip. Your laptop has this chip:
http://orzparts.com/index.php?main_page=product_info&products_id=732
You'll have to teardown the whole laptop, looking at every chip which
seems similar. Remember to discharge from static electricity before
opening your laptop and not to wear anything that produces it. This has
a risk of breaking your laptop, proceed at your own risk, you've been
warned.
> thanks
> Mono
> 








signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] cmos.layout upgradability

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello, all. Due to my failue to foresee this problem if one upgrades X60
coreboot, you need to manually reset CMOS config or your trackpad may
not work as option "trackpad_enable" will get a garbage value. While I
admit my part of fault, I feel like we should have a way to update
options safely. I see following possibilities:
1) Hide ourselves and tell that on upgrade you always have to clear
CMOS. I don't think it's really an option as users will continue just
running flashrom and in case of external flashing, CMOS reset may
require full power removal with cell battery sometimes in difficult to
access places inside laptop.
2) Have some version field to check and if it mismatches reset CMOS to
default. To avoid having to maintain version manually I propose to
checksum option table and write 16-bit result to CMOS. 16-bit should
give enough confidence without excessively using CMOS. I've made a
prototype at http://review.coreboot.org/#/c/4790/4 . If we can agree
that it's a right approach, I'll make this prototype into complete patch
(mostly missing is laborous adding of version field)
2a) instead of having separate field we could make XOR layout checksum
into CMOS checksum. This would save 2 bytes but will break any existing
users if they check checksum.



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Seeking for reviewers: X201 (enable S3 & al) and X230

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello, all. I've just uploaded 2 patchsets: X201 which fixes all known
issues including S3 resume but except Gnome battery reporting. Top for
x201 is at
http://review.coreboot.org/#/c/4632/
and few separate patches with theme "x201" (X201-specific) and
"thinkpad" (having benefits for X60/T60 as well).
X230 top is at http://review.coreboot.org/#/c/4679/




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Remove GENERATE_ACPI_TABLES

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 07.01.2014 00:12, mrnuke wrote:
> On Monday, January 06, 2014 07:52:20 PM Vladimir 'φ-coder/phcoder' Serbinenko 
> wrote:
>> By now most boards and OS don't run correctly if ACPI tables are not
>> supplied. Ability by user to enable/disable their generation is just
>> increasing configuration matrix for no benefit. So I propose to hardwire
>> it to HAVE_ACPI_TABLES.
> 
> You mean you haven't found a need for it in your recent use cases. I don't 
> think this can be used to generalize for all boards, and is most certainly a 
> naive proposal for ARM boards. So you end up depending this shit on ARCH_x86, 
> then ARM adds ACPI, then it again makes sense to HAVE_ACPI_TABLES, but only 
> for ARM, so now we make it depend on ARCH_ARM, and we get a clusterfuck by 
> the 
> end of the day.
> At the end of it all, you are proposing to take away a freedom that has hurt 
> no-one. -2. I can't see the justification.
> 
You misunderstood. I don't propose to remove HAVE_ACPI_TABLES.
HAVE_ACPI_TABLES remains per-board characteristic.
The only thing I remove is GENERATE_ACPI_TABLES which is user-visible
option.
This way presence of ACPI-tables is determined by board porter based on
the need and availability of ACPI tables
>> I feel like in current config there are too many options of kind "Do you
>> want a working system? (y/n)" and they should be hardwired to right
>> answer rather than adding configuration.
>>
> Flashing coreboot is a minefield of these questions: "Do you want to brick 
> your 
> system? (ok/cancel)". You can't make it fool proof, and nanny-state-ing users 
> is not the solution. Provide sane defaults.
> 
Right now we're at opposite end when you almost have to use genetic
algorithm to find which configuration works.
> Alex
> 
> P.S. If you don't know what you're doing, you will brick your board, no 
> matter 
> how many coreboot condoms you wear.
> 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Remove GENERATE_ACPI_TABLES

[Vladimir 'φ-coder/phcoder' Serbinenko]

By now most boards and OS don't run correctly if ACPI tables are not
supplied. Ability by user to enable/disable their generation is just
increasing configuration matrix for no benefit. So I propose to hardwire
it to HAVE_ACPI_TABLES.
I feel like in current config there are too many options of kind "Do you
want a working system? (y/n)" and they should be hardwired to right
answer rather than adding configuration.

http://review.coreboot.org/#/c/4609/



signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot