Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer

[Vladimir 'phcoder' Serbinenko]

On Tue, Apr 25, 2017, 20:15 Julius Werner  wrote:

> I'm very concerned with compatibility. You can't guarantee that coreboot
>> and payload match. And in case of mismatch you get a memory corruption that
>> is very hard to trace. Can we please change signature of cbmem entry?
>
>
> I would rather allow older implementations to continue working as best as
> possible. Changing the signature would mean that an old payload (or 'cbmem'
> command line tool, etc.) couldn't interoperate at all with the console. The
> changes I made are as backwards-compatible as possible: in many cases (e.g.
> before the console rolled over once) the old payload will continue working
> just fine. If the console did roll over, the old payload can no longer
> append lines and may print existing contents out of order. It will never
> access invalid memory, though. (You may have been worried about bit 31 I'm
> setting in the "cursor" field, but all existing implementations were
> already required to check (cursor < size) before trusting the cursor to be
> accessible since the old console would continue counting characters even
> after the buffer filled up.)
>
Did you check that all implementations use unsigned?

>
>
>> You mentioned having trouble building GRUB. Can you detail those?
>> What do you mean by not having hardware supported by grub-coreboot?
>> Grub-coreboot should work on all coreboot-supported boards.
>>
>
> I am able to build it, I just had to figure out how and install some
> dependencies. But I tried booting it on an HP Chromebook 14 2013 (falco)
> and it doesn't seem to recognize my keyboard
>
Is it PS2 or USB? Is at_keyboard included in the payload?

> and will reboot a few seconds after displaying the GRUB console. (Most of
> the devices I have are ARM unfortunately, which I'm assuming it doesn't
> support since all the coreboot code is in i386 directories?
>
Arm is in separate branch due to freeze.

>  even if it did, it probably wouldn't have a keyboard driver for them
> either. I assume there's no way to make it run over the UART instead?)
>
terminal_input serial_com0
terminal_output serial_com0
In etc/grub.cfg

Possibly the problem is that some module hangs. Can you try minimal GRUB
without non-essential modules?

>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer

[Vladimir 'phcoder' Serbinenko]

I'm very concerned with compatibility. You can't guarantee that coreboot
and payload match. And in case of mismatch you get a memory corruption that
is very hard to trace. Can we please change signature of cbmem entry?

You mentioned having trouble building GRUB. Can you detail those?
What do you mean by not having hardware supported by grub-coreboot?
Grub-coreboot should work on all coreboot-supported boards.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo Carbon X1

[Vladimir 'phcoder' Serbinenko]

Please send me the full log archive so I can reproduce. Also note: X1
carbon has soldered RAM which will need adjustements

Le Sun, Dec 13, 2015 à 10:59 PM, Gerhard Gappmeier  a
écrit :

> Hi all,
>
>
>
> unfortunately autoport didn't work well.
>
>
>
> This is the output on the 1st run:
>
> Unsupported PCI device 8086:1e56
>
> Unknown PCI device 8086:0085, assuming removable
>
> panic: runtime error: invalid memory address or nil pointer dereference
>
> [signal 0xb code=0x1 addr=0x20 pc=0x40a157]
>
>
>
> goroutine 1 [running]:
>
> main.LenovoEC(0xc20801edc0, 0x19, 0xc20801eec0, 0x1f, 0xc20804638f, 0x6,
> 0xc20804640a, 0x12, 0xc20803d9e0, 0x2d, ...)
>
> /home/gergap/work/opensource/coreboot/util/autoport/ec_lenovo.go:20 +0x1d37
>
> main.ScanRoot(0xc20801edc0, 0x19, 0xc20801eec0, 0x1f, 0xc20804638f, 0x6,
> 0xc20804640a, 0x12, 0xc20803d9e0, 0x2d, ...)
>
> /home/gergap/work/opensource/coreboot/util/autoport/root.go:33 +0x52a
>
> main.main()
>
> /home/gergap/work/opensource/coreboot/util/autoport/main.go:727 +0x683
>
>
>
>
>
> On further runs the system freezes.
>
> To fix the tree again I run
>
> sudo -R gergap .
>
> git clean -fdx
>
> git reset --hard
>
>
>
> This way I could reproduce the above output.
>
>
>
> The created log files can be found here:
>
> https://www.dropbox.com/s/1r2dvbk7rj68fuv/logs.tar.gz?dl=0
>
>
>
> The created mainboard folder is not really useful,
>
> but if you are interested here is the patch:
>
>
> https://www.dropbox.com/s/2ejds3ppae0y5md/0001-Add-lenovo-thinkpad_x1_carbon.patch?dl=0
>
>
>
> Any help is appreciated.
>
>
>
> On Sunday, December 13, 2015 07:52:31 PM you wrote:
>
> > Try util/autoport and it can be easier.
>
>
>
> --
>
> mfg,
>
> Gerhard Gappmeier
>
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo Carbon X1

[Vladimir 'phcoder' Serbinenko]

I was unable to download as I'm not willing to give dropbox access to my
contacts and I'm too lazy to make a new account now. Anyway the culprit is
unsupported LPC. Here you go: https://review.coreboot.org/12820

Le Sat, Jan 2, 2016 à 1:39 AM, Vladimir 'phcoder' Serbinenko <
phco...@gmail.com> a écrit :

> Please send me the full log archive so I can reproduce. Also note: X1
> carbon has soldered RAM which will need adjustements
>
> Le Sun, Dec 13, 2015 à 10:59 PM, Gerhard Gappmeier <gappy1...@gmx.net> a
> écrit :
>
>> Hi all,
>>
>>
>>
>> unfortunately autoport didn't work well.
>>
>>
>>
>> This is the output on the 1st run:
>>
>> Unsupported PCI device 8086:1e56
>>
>> Unknown PCI device 8086:0085, assuming removable
>>
>> panic: runtime error: invalid memory address or nil pointer dereference
>>
>> [signal 0xb code=0x1 addr=0x20 pc=0x40a157]
>>
>>
>>
>> goroutine 1 [running]:
>>
>> main.LenovoEC(0xc20801edc0, 0x19, 0xc20801eec0, 0x1f, 0xc20804638f, 0x6,
>> 0xc20804640a, 0x12, 0xc20803d9e0, 0x2d, ...)
>>
>> /home/gergap/work/opensource/coreboot/util/autoport/ec_lenovo.go:20
>> +0x1d37
>>
>> main.ScanRoot(0xc20801edc0, 0x19, 0xc20801eec0, 0x1f, 0xc20804638f, 0x6,
>> 0xc20804640a, 0x12, 0xc20803d9e0, 0x2d, ...)
>>
>> /home/gergap/work/opensource/coreboot/util/autoport/root.go:33 +0x52a
>>
>> main.main()
>>
>> /home/gergap/work/opensource/coreboot/util/autoport/main.go:727 +0x683
>>
>>
>>
>>
>>
>> On further runs the system freezes.
>>
>> To fix the tree again I run
>>
>> sudo -R gergap .
>>
>> git clean -fdx
>>
>> git reset --hard
>>
>>
>>
>> This way I could reproduce the above output.
>>
>>
>>
>> The created log files can be found here:
>>
>> https://www.dropbox.com/s/1r2dvbk7rj68fuv/logs.tar.gz?dl=0
>>
>>
>>
>> The created mainboard folder is not really useful,
>>
>> but if you are interested here is the patch:
>>
>>
>> https://www.dropbox.com/s/2ejds3ppae0y5md/0001-Add-lenovo-thinkpad_x1_carbon.patch?dl=0
>>
>>
>>
>> Any help is appreciated.
>>
>>
>>
>> On Sunday, December 13, 2015 07:52:31 PM you wrote:
>>
>> > Try util/autoport and it can be easier.
>>
>>
>>
>> --
>>
>> mfg,
>>
>> Gerhard Gappmeier
>>
>>
>>
>>
>> --
>> coreboot mailing list: coreboot@coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo Carbon X1

[Vladimir 'phcoder' Serbinenko]

f06b08a60fe49784c197929b46e22fdb0e1dbbf3 is how to handle. spd.bin is
generated by inteltool

Le Sat, Jan 2, 2016 à 1:49 AM, Vladimir 'phcoder' Serbinenko <
phco...@gmail.com> a écrit :

> I was unable to download as I'm not willing to give dropbox access to my
> contacts and I'm too lazy to make a new account now. Anyway the culprit is
> unsupported LPC. Here you go: https://review.coreboot.org/12820
>
> Le Sat, Jan 2, 2016 à 1:39 AM, Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> a écrit :
>
>> Please send me the full log archive so I can reproduce. Also note: X1
>> carbon has soldered RAM which will need adjustements
>>
>> Le Sun, Dec 13, 2015 à 10:59 PM, Gerhard Gappmeier <gappy1...@gmx.net> a
>> écrit :
>>
>>> Hi all,
>>>
>>>
>>>
>>> unfortunately autoport didn't work well.
>>>
>>>
>>>
>>> This is the output on the 1st run:
>>>
>>> Unsupported PCI device 8086:1e56
>>>
>>> Unknown PCI device 8086:0085, assuming removable
>>>
>>> panic: runtime error: invalid memory address or nil pointer dereference
>>>
>>> [signal 0xb code=0x1 addr=0x20 pc=0x40a157]
>>>
>>>
>>>
>>> goroutine 1 [running]:
>>>
>>> main.LenovoEC(0xc20801edc0, 0x19, 0xc20801eec0, 0x1f, 0xc20804638f, 0x6,
>>> 0xc20804640a, 0x12, 0xc20803d9e0, 0x2d, ...)
>>>
>>> /home/gergap/work/opensource/coreboot/util/autoport/ec_lenovo.go:20
>>> +0x1d37
>>>
>>> main.ScanRoot(0xc20801edc0, 0x19, 0xc20801eec0, 0x1f, 0xc20804638f, 0x6,
>>> 0xc20804640a, 0x12, 0xc20803d9e0, 0x2d, ...)
>>>
>>> /home/gergap/work/opensource/coreboot/util/autoport/root.go:33 +0x52a
>>>
>>> main.main()
>>>
>>> /home/gergap/work/opensource/coreboot/util/autoport/main.go:727 +0x683
>>>
>>>
>>>
>>>
>>>
>>> On further runs the system freezes.
>>>
>>> To fix the tree again I run
>>>
>>> sudo -R gergap .
>>>
>>> git clean -fdx
>>>
>>> git reset --hard
>>>
>>>
>>>
>>> This way I could reproduce the above output.
>>>
>>>
>>>
>>> The created log files can be found here:
>>>
>>> https://www.dropbox.com/s/1r2dvbk7rj68fuv/logs.tar.gz?dl=0
>>>
>>>
>>>
>>> The created mainboard folder is not really useful,
>>>
>>> but if you are interested here is the patch:
>>>
>>>
>>> https://www.dropbox.com/s/2ejds3ppae0y5md/0001-Add-lenovo-thinkpad_x1_carbon.patch?dl=0
>>>
>>>
>>>
>>> Any help is appreciated.
>>>
>>>
>>>
>>> On Sunday, December 13, 2015 07:52:31 PM you wrote:
>>>
>>> > Try util/autoport and it can be easier.
>>>
>>>
>>>
>>> --
>>>
>>> mfg,
>>>
>>> Gerhard Gappmeier
>>>
>>>
>>>
>>>
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> http://www.coreboot.org/mailman/listinfo/coreboot
>>
>>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Removal of AGESA - to be or NOT to be? A story of G505S

[Vladimir]

gether. Or I can be a build tester and constantly test your builds on my
hardware (and maybe donate Money/Things to you to support your efforts)

>
>>> On 11/07/2015 10:18 AM, Alex Gagniuc wrote:
>
>>
>> branch it off to some abandoned branch that nobody would care about.
>>
>
> You would obviously care about it, so that's a moot point.
>
>  We either keep everything in a "master" branch, or it's
dead. 
>

In my earlier messages I already told what sense I am putting behind these
words. Master branch will be receiving all the love: important bug fixes as
well as great new features, which would be a part of code thats common for
all the boards in a master branch. Meanwhile, nobody is going to constantly
track check and copy all these commits to this separate branch, which means
it would be abandoned.

>
>>> On 11/07/2015 10:18 AM, Alex Gagniuc wrote:
>
> I agreed to leave these discussions behind. I don't know why people
> _still_ keep bringing it up.
>

As you said before,

>
> Experience tells us that people are silent until their (broken) toys are
taken away, and only then start crying.
>

I dont know what you have been expecting, but I am not going to be a part
of this experience. I am not going to stay silent and watch how my precious
toys are broken and are taken away. I am going to stand up for all the
coreboot users/developers who are using coreboot on their G505S machine

>
>>> On 11/07/2015 10:18 AM, Alex Gagniuc wrote:
>
>>
>> PLEASE do NOT submit proposals that will negatively affect a support for
>> alive boards, because
>>
>
> If you want to treat logical separation as removal, that's on you
>

Your logical separation (regardless of how we call it) - it WILL negatively
affect a support for alive boards! I cannot stress it enough:

>
> Master branch will be receiving all the love: important bug fixes as well
as great new features, which would be a part of code thats common for all
the boards in a master branch. Meanwhile, > nobody is going to constantly
track check and copy all these commits to this separate branch, which means
it would be abandoned.
>

>
>>> On 11/07/2015 10:18 AM, Alex Gagniuc wrote:
>
>>
>> such malevolent plans are a great insult to a bright spirit of coreboot !
>>
>
> I'm insulted by your portrayal of me as aforementioned
>

Your recent proposals (in case if they would be accepted) will negatively
affect many boards, including the alive boards - such as G505S, a coreboot
LTS candidate. If you were expecting the praises of approval and kind words
for such intentions - well, I am sorry to bust your expectations

Best regards,
Vladimir Shipovalov

On 7 November 2015 at 12:18, Alex G. <mr.nuke...@gmail.com> wrote:

> On 11/06/2015 02:11 AM, Vladimir wrote:
> > * Did you know that Lenovo G505S is still widely available at some parts
> > of the world? (e.g. in Russia, 50+ online shops are still selling it)
>
> Yeah, I wrote most of the code for that.
>
> > * Did you know that Francis Rowe, head Libreboot developer, has proposed
> > the addition of G505S to Coreboot LTS Candidates list of laptops?
>
> Did you know that G505s is unsuitable for libreboot due to the many
> blobs it needs (VBIOS, SMU, IMC, make your pick) ?
>
> > * Did you know that Compal will still be making LA-A091P laptop
> > motherboard, the primary component of G505S, at least until the end of
> > 2018 year?
>
> And this is based on what?
>
> > It is unbelievable that some people here want to take alive-and-kicking
> > motherboard and 'remove it'
>
> I wrote most of the code to get it running in the first place.
>
> > or degrade it into a 'second class citizen' - by branching
>
> Geesh! Why don't you take over full maintainership of AGESA before
> whining why people who worked on that code no longer want to support it?
>
> > it off to some abandoned branch that nobody would care about.
>
> You would obviously care about it, so that's a moot point.
>
> > Don't know which is worse...
>
> I agreed to leave these discussions behind. I don't know why people
> _still_ keep bringing it up.
>
> >>>> Someone wrote:
>
> That was me
>
> >> I'm looking forward to seeing the draft of the removal plans. Maybe
> >> removal is even better than branching
>
> 
> Yes. Because everything is black and white. We either keep everything in
> a "master" branch, or it's dead.
> 
>
> > If Someone doesn't care about those boards which he doesn't own own, if
> > Someone has no idea how to set up makefiles so that they will not make
> > builds for boards that he doesn't care about, if Someone can't wait a
> > f

[coreboot] Removal of AGESA - to be or NOT to be? A story of G505S

[Vladimir]

While the possibility of AMD AGESA boards 'removal' is being discussed, I
would like to tell you about Lenovo G505S - which has Compal LA-A091P AMD
Family 15h RL AGESA board.

* Did you know that Lenovo G505S is still widely available at some parts of
the world? (e.g. in Russia, 50+ online shops are still selling it)
* Did you know that Francis Rowe, head Libreboot developer, has proposed
the addition of G505S to Coreboot LTS Candidates list of laptops?
* Did you know that Compal will still be making LA-A091P laptop
motherboard, the primary component of G505S, at least until the end of 2018
year?
(although these would be meant for Lenovo technical repair workshops, any
person will be able to buy them by request even at 1pcs quantities)

It is unbelievable that some people here want to take alive-and-kicking
motherboard and 'remove it': either 'remove' a support for it completely,
or degrade it into a 'second class citizen' - by branching it off to some
abandoned branch that nobody would care about. Don't know which is worse...

>
>>> Someone wrote:
> I'm looking forward to seeing the draft of the removal plans. Maybe
removal is even better than branching
>

If Someone doesn't care about those boards which he doesn't own own, if
Someone has no idea how to set up makefiles so that they will not make
builds for boards that he doesn't care about, if Someone can't wait a few
more extra minutes of compilation because he is in a 'great hurry':

then he should start his 'Removal Quest' from old boards like Intel I945
and AMD K8 - if nobody runs coreboot on them anymore.
Or from his own board, if his own board is EOL and old...

PLEASE do NOT submit proposals that will negatively affect a support for
alive boards, because such malevolent plans are a great insult to the
bright spirit of coreboot project !

Best regards,
Vladimir Shipovalov
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Removal of AGESA - to be or NOT to be? A story of G505S

[Vladimir]

Yes, I really want to participate in the Lenovo G505S porting from AGESA to
Native Init ! But, to be honest, I have never done such a task before, so
my experience is probably not enough for doing this port alone by myself :
I cannot even estimate the amount of necessary work and don't know where to
start... (Dear Timothy, could you please point me to any good examples of
AGESA --> Native Init porting?) However, I will be very glad to help as
much as I could by being a build tester: I can constantly test these
"native init" builds on my hardware - as many build iterations as it needed
in order to help make "Native Init" a stable and good enough candidate for
replacing AGESA

Also I will seriously consider donating some Money/Things to those coreboot
developers who will make significant commits for bringing G505S "Native
Init" port to life, although my financial abilities became very limited
after Rubble currency collapse so unfortunately I cannot guarantee this
type of support as well as how much would be the amount of donations...

Lenovo G505S uses quad core A10-5750M APU which is Richland architecture.
This architecture does not include PSP hardware ( ARM TrustZone security
co-processor) , so luckily this Family 15h RL laptop does not need a PSP
blob ;-)

By the way there are just two AMD-based laptops that are supported by
coreboot, and another one is HP M6-1035DX which has weaker hardware /
smaller availability / lack of manufacturer support (HP quickly forgets
their old laptop models and probably already stopped replacement
motherboards production for this laptop - but I'd be happy to be wrong
here) . As for now, G505S seems to be the only AMD laptop which is
supported by coreboot and is really alive , so hopefully its code will be
allowed to stay in its AGESA shape until a stable "Native Init" replacement
will be introduced

Best regards,
Vladimir Shipovalov



On 6 November 2015 at 20:34, Timothy Pearson <
tpear...@raptorengineeringinc.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 11/06/2015 04:11 AM, Vladimir wrote:
> > While the possibility of AMD AGESA boards 'removal' is being discussed,
> > I would like to tell you about Lenovo G505S - which has Compal LA-A091P
> > AMD Family 15h RL AGESA board.
> >
> > * Did you know that Lenovo G505S is still widely available at some parts
> > of the world? (e.g. in Russia, 50+ online shops are still selling it)
> > * Did you know that Francis Rowe, head Libreboot developer, has proposed
> > the addition of G505S to Coreboot LTS Candidates list of laptops?
> > * Did you know that Compal will still be making LA-A091P laptop
> > motherboard, the primary component of G505S, at least until the end of
> > 2018 year?
> > (although these would be meant for Lenovo technical repair workshops,
> > any person will be able to buy them by request even at 1pcs quantities)
> >
> > It is unbelievable that some people here want to take alive-and-kicking
> > motherboard and 'remove it': either 'remove' a support for it
> > completely, or degrade it into a 'second class citizen' - by branching
> > it off to some abandoned branch that nobody would care about. Don't know
> > which is worse...
>
> Slightly off topic, but if the Lenovo G505S uses a Family 15h processor
> it should be possible to port it over to native initialisation (thus
> ensuring it's continued existence as a first class citizen, even if this
> discussion comes up again eventually).
>
> I was also unaware that true Family 15h CPUs had made their way into
> laptops; do you know if that particular device requires a PSP blob or not?
>
> One last comment regarding removal.  At minimum I would expect that none
> of the boards, chipsets, or CPUs shown in the board status repository
> from at least the past few months should be candidates for removal.  As
> you can see K8 is definitely listed:
> http://review.coreboot.org/gitweb?p=board-status.git;a=summary
>
> Thanks!
>
> - --
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> http://www.raptorengineeringinc.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJWPOSUAAoJEK+E3vEXDOFbfCYH/2VinnxsFdvVNiNjYIM5IO17
> ThW6ezI/AocEiCE/PkXaLtDuhtaUpl4RFcp0ePcYc3/ybjLBGSwJgDUOKKZ5ZgA2
> X8cbEykYVWQ1qSEID47wUrfz6zZNlxr70oF8OXHUVa5+Mxi88fHqzqd5yIoSoPYY
> 7vkiNG3Lw2vvb5/LkORp7Fy5jvkb+h53Af4FF5OFvMMoXR2F3BH/0fhvKn8GEzXW
> BZmEcxGfd6XEejKcEaZUM2I7FWb/INnisV1DxaLn8cJHsxn9GgTWK3X9ZqItNbta
> KF9koT8AiKCspT3EszhyXzw7q3A6GgpWLHIY/6mMWpqqyA30/I6DZl4UREDl93c=
> =s96E
> -END PGP SIGNATURE-
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] A case for branching AGESA

[Vladimir]

I strongly disagree with this branching "solution". Why?
Because - if building all the targets is slow - then just don't build all
the targets at once! If you need a fast build and you are not concerned
about AMD boards - just because you don't have any - it is always possible
to skip AGESA build without moving it to a branch and separating from the
rest of the coreboot code . So this is seen as a really bad excuse

Best regards,
Vladimir Shipovalov




On 3 November 2015 at 01:14, Peter Stuge <pe...@stuge.se> wrote:

> Alex G. wrote:
> > >> users of AGESA can continue to contribute and work on the codebase.
> > > ... and diverge...
> >
> > And that's expected. Convergence is a dream.
>
> I disagree. I think it's a goal rather than a dream.
>
> > AGESA boards use BuildOpts for configuration, and not much
> > Kconfig/devicetree.cb
>
> I've done a bit of work on moving BuildOpts config for IDS into Kconfig,
> but it's not quite ready yet. I wrote the change dry and the only
> test data I have available reports coreboot not working after
> applying it. :) Sometime..
>
>
> > SPD parsing routines. I can go on and on.
> > non-divergence is a moot point.
>
> I disagree - I think we need to work towards less divergence rather
> than move in a direction which is likely to create more divergence.
>
> That's the only way to keep the codebase maintainable - which we all
> want. It was clear to me already when we saw the very first code from
> AMD that integration into our own codebase would take a while.
>
> I don't want to remove contributed code until we've given that a real shot.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Dell Dimension 8300 reboots when grub2 cbfs module is loaded

[Vladimir 'phcoder' Serbinenko]

Le 3 nov. 2015 6:46 PM, "Aaron Durbin" <adur...@google.com> a écrit :
>
> On Tue, Nov 3, 2015 at 10:28 AM, Vladimir 'phcoder' Serbinenko
> <phco...@gmail.com> wrote:
> > The code itself looks good but I'd like more details. Reading 0x
> > shouldn't cause reboot. Why does it?
>
> It's probably implementation defined reading a multi-byte object from
> 4GiB-1. Does it wrap? Blow up the machine? Machine check? Transaction
> never gets terminated?
>
It would be interesting to find out. Since it's P4, it may be related to
PAE but paging is disabled when GRUB is active However it shouldn't hold
this patch. Andrei: go ahead, just please add reference to machine and cpu
in the comment and the fact that we have little idea what's going on.
> >
> > Le 1 nov. 2015 3:53 PM, "Andrei Borzenkov" <arvidj...@gmail.com> a
écrit :
> >>
> >> I was debugging problem reported by user on Dell Dimension 8300 - it
> >> rebooted when doing "ls -l". It turned out, the problem was triggered
by
> >> loading cbfs which probed for header. System has 2GB memory, and
attempt to
> >> read from address 0x caused instant reboot. 0x was
returned
> >> by read from non-existing address 0xfffc.
> >>
> >> The proof of concept patch below avoids it, but I wonder what the
proper
> >> fix is.
> >>
> >> diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
> >> index a34eb88..a5a2fde 100644
> >> --- a/grub-core/fs/cbfs.c
> >> +++ b/grub-core/fs/cbfs.c
> >> @@ -344,8 +344,9 @@ init_cbfsdisk (void)
> >>
> >>ptr = *(grub_uint32_t *) 0xfffc;
> >>head = (struct cbfs_header *) (grub_addr_t) ptr;
> >> +  grub_dprintf ("cbfs", "head=%p\n", head);
> >>
> >> -  if (!validate_head (head))
> >> +  if (0x - ptr < sizeof (*head) || !validate_head (head))
> >>  return;
> >>
> >>cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
> >>
> >>
> >> ___
> >> Grub-devel mailing list
> >> grub-de...@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> >
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Dell Dimension 8300 reboots when grub2 cbfs module is loaded

[Vladimir 'phcoder' Serbinenko]

The code itself looks good but I'd like more details. Reading 0x
shouldn't cause reboot. Why does it?
Le 1 nov. 2015 3:53 PM, "Andrei Borzenkov"  a écrit :

> I was debugging problem reported by user on Dell Dimension 8300 - it
> rebooted when doing "ls -l". It turned out, the problem was triggered by
> loading cbfs which probed for header. System has 2GB memory, and attempt to
> read from address 0x caused instant reboot. 0x was returned
> by read from non-existing address 0xfffc.
>
> The proof of concept patch below avoids it, but I wonder what the proper
> fix is.
>
> diff --git a/grub-core/fs/cbfs.c b/grub-core/fs/cbfs.c
> index a34eb88..a5a2fde 100644
> --- a/grub-core/fs/cbfs.c
> +++ b/grub-core/fs/cbfs.c
> @@ -344,8 +344,9 @@ init_cbfsdisk (void)
>
>ptr = *(grub_uint32_t *) 0xfffc;
>head = (struct cbfs_header *) (grub_addr_t) ptr;
> +  grub_dprintf ("cbfs", "head=%p\n", head);
>
> -  if (!validate_head (head))
> +  if (0x - ptr < sizeof (*head) || !validate_head (head))
>  return;
>
>cbfsdisk_size = ALIGN_UP (grub_be_to_cpu32 (head->romsize),
>
>
> ___
> Grub-devel mailing list
> grub-de...@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

[Vladimir]

It would be really wrong to remove the whole AGESA code: there are
AMD-based products which are still very alive and actively sold (at the
developing markets) Moving the support for these products to a separate
coreboot branch, could create many inconveniences for those AMD product
owners who would like to test & use the latest and greatest coreboot build:
they will have to backport all the commits of code that's used by all the
boards, to that separate abandoned branch - which would cause a lot of
hassle and would basically cut them off from the development

I agree that removing could be done to some 2009 VIA-based EOL boards that
nobody cares about, but it would be a mistake to do that to all the AMD
products, some of which are still produced to this date and used together
with coreboot by lots of people from this mailing list

Also, that action will send a bad signal to AMD. AMD is actively supporting
the coreboot project and is much more friendly to open source community
than Intel with it's ME and creepy lock-it-all desires. Removing AGESA code
would be an equivalent of telling "we don't need your code" to AMD, one of
the largest coreboot supporters, and that could lead to a terrible
consequences


On 27 October 2015 at 22:40, Aaron Durbin  wrote:

> On Tue, Oct 27, 2015 at 2:35 PM, David Hendricks 
> wrote:
> > This all sounds fine from a developer's perspective, but what about AMD's
> > customers? I honestly have no clue if the decision to use an AMD product
> > with coreboot hinges on whether AMD's supplied AGESA code is used or not.
> > But I can imagine ripping out the AMD-supplied code might make it
> difficult
> > for AMD to support customers who use coreboot.
> >
> > I'm sure there are people on this list who _have actually supported
> > customers_ using AMD products and coreboot, so I'd like to hear their
> > perspective.
> >
> > /my $0.02.
>
> The code lives on a branch. People are more than happy to work within
> that branch. That's exactly what branches are for.
>
> I'll one up the recommendation and suggest all non-romcc code that
> #includes C files gets removed after the branch point. Or do such a
> thing in the next release. I'm sick of having to deal with and
> fighting against these development constructs.
>
> >
> > On Tue, Oct 27, 2015 at 12:20 PM, ron minnich 
> wrote:
> >>
> >> The AGESA code was always an awkward fit into coreboot. It was more
> like a
> >> badly designed artificial limb than a real part of the code base. I
> >> understand the idea of encouraging vendors to commit source but, at this
> >> point, the AMD ship has sailed off to Port Binary Blob. AGESA was
> helpful in
> >> its time but I think I'm with tpearson on this point.
> >>
> >> I believe we should drop AGESA on any boards that have native support,
> and
> >> the sooner the better.
> >>
> >> ron
> >>
> >> --
> >> coreboot mailing list: coreboot@coreboot.org
> >> http://www.coreboot.org/mailman/listinfo/coreboot
> >
> >
> >
> >
> > --
> > David Hendricks (dhendrix)
> > Systems Software Engineer, Google Inc.
> >
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > http://www.coreboot.org/mailman/listinfo/coreboot
>
> --
> coreboot mailing list: coreboot@coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

[Vladimir]

Although I agree with you that AMD is not innocent as well, if you would
check a "Binary situation" page at coreboot's wiki, you would see that
Intel is in three times more evil (still could not understand why some
incredibly talented coreboot developers are spending so much time fighting
Intel's ME issues, while AMD boards don't have that "dragon you have to
tame" on board)

In any case, it would be very sad to see the AMD code gone from the master
branch. Even the code for some unpopular boards like Intel Atom-based EOL
"Mohron Peak" was allowed to stay! Why AMD boards are considered worse? The
sole idea of AMD code going away, which will affect many alive-and-kicking
coreboot-supported AMD boards, is beyond my comprehension

On 27 October 2015 at 23:15, Timothy Pearson <
tpear...@raptorengineeringinc.com> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/27/2015 03:10 PM, Vladimir wrote:
> > It would be really wrong to remove the whole AGESA code: there are
> > AMD-based products which are still very alive and actively sold (at the
> > developing markets) Moving the support for these products to a separate
> > coreboot branch, could create many inconveniences for those AMD product
> > owners who would like to test & use the latest and greatest coreboot
> > build: they will have to backport all the commits of code that's used by
> > all the boards, to that separate abandoned branch - which would cause a
> > lot of hassle and would basically cut them off from the development
> >
> > I agree that removing could be done to some 2009 VIA-based EOL boards
> > that nobody cares about, but it would be a mistake to do that to all the
> > AMD products, some of which are still produced to this date and used
> > together with coreboot by lots of people from this mailing list
> >
> > Also, that action will send a bad signal to AMD. AMD is actively
> > supporting the coreboot project and is much more friendly to open source
> > community than Intel with it's ME and creepy lock-it-all desires.
> > Removing AGESA code would be an equivalent of telling "we don't need
> > your code" to AMD, one of the largest coreboot supporters, and that
> > could lead to a terrible consequences
>
> AMD is hardly innocent on that front; they require a large binary blob
> to execute on the auxiliary CPU at bootup, with unknown security
> consequences.  Also, as far as I understand there has been no new AGESA
> source release for some time, only binary blobs.
>
> - --
> Timothy Pearson
> Raptor Engineering
> +1 (415) 727-8645 (direct line)
> +1 (512) 690-0200 (switchboard)
> http://www.raptorengineeringinc.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJWL9tLAAoJEK+E3vEXDOFbGXEH/Ar/eErlZp8biCEOO3EUKXN3
> CXpvDMgjsWf8k0jmlW25ythzyEuD1fLsVhD84GvvO0anwMhT66IXtHVAyXUegd7T
> +iJd1MmthsSJRNW8xLhu9r+YEZInLAlq56HZ7ebnwbVmeokRhUdfCKUkUshPOO0N
> 73v5Q7SLQbhR8NwWzDF9jYF/DJyqfkgO1boBxDDGeV5XPzy5Ho+fwPFrH+E47nes
> 4u1uNxu8MYQvDoQzxIc/HE9scAhl79kuk3GUuiuoe6RlreKPlrFQVK0Rb+yIe/n+
> 63mz53ZLdHCoglQLiGpMYlrQDSgzwvHH7i+lfavacgctJd7+Q0n5MFh9TppN4Uc=
> =G6dr
> -END PGP SIGNATURE-
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

[Vladimir]

Thank you for this enlightening message about blobgesa... Luckily AMD was
10 years slow at following Intel's ME example, 10 years since ME first
version, and it was not until 2015 that built-in Platform Secure Processors
completely took over the AMD's Mobility family ( Kaveri from 2014 still
didnt have PSP ) . Desktop family has 2015 Godavari without the PSP. It
seems that PSP-blobgesa plague is going from low end to high end direction,
and - while it took over the mobility family - desktop high end is still
OK, and server family is far from it (so far only low end "seattle" servers
are affected)

Hopefully this blobgesa will be open sourced eventually - its not that far
from reality because AMD open sourced a lot of stuff during the past
months... Also it will be very interesting to see how AMD Zen platforms
will behave

Best regards,
Vladimir Shipovalov


On 28 October 2015 at 00:35, Felix Held <felix-coreb...@felixheld.de> wrote:

>
> if you would check a "Binary situation" page at coreboot's wiki, you would
>> see that Intel is in three times more evil
>>
> That page is outdated. Newer AMD systems have the platform security
> processor, which is quite similiar to the ME.
>
> http://www.uefi.org/sites/default/files/resources/UEFI_PlugFest_AMD_Security_and_Server_innovation_AMD_March_2013.pdf
> has some information on the PSP.
> Chips with PSP are btw. only supported by blobgesa.
>
> Also the AGESA source is quite a mess (I started to do some cleanups
> there, but finally dropped the project, because it wasn't worth the time
> for me) and having native initialization will be much better.
>
> Regards
> Felix
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Goodies for Bonn meeting

[Vladimir 'phcoder' Serbinenko]

Is size L ok for you?

Le Wed, Oct 7, 2015 à 8:20 AM, Marc Jones <marcj...@gmail.com> a écrit :

> Hi Vladimir,
>
> I'd love a shirt. See you in a few days.
>
> Marc
>
> On Tue, Oct 6, 2015, 11:53 PM Vladimir 'phcoder' Serbinenko <
> phco...@gmail.com> wrote:
>
>> Currently remaining are:
>> 8 x L T-shirts
>> 1 x XL T-shirts
>> 1 x yellow cup
>> 3 x plates
>> 3 x baseball cap
>> 8 x magnets
>> 5 x coasters
>> Every item under 20€
>> Images:
>>  http://coreboot.org/Coreboot_conference_Bonn_2015
>>
> --
>> coreboot mailing list: coreboot@coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Goodies for Bonn meeting

[Vladimir 'phcoder' Serbinenko]

Reminder, please write me if you want any of this. Right now only Ron
Minnich and echelon have ordered. I've added pictures at
http://coreboot.org/Coreboot_conference_Bonn_2015

Le Wed, Sep 9, 2015 à 9:29 AM, Vladimir 'φ-coder/phcoder' Serbinenko <
phco...@gmail.com> a écrit :

> 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.
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Goodies for Bonn meeting

[Vladimir 'phcoder' Serbinenko]

Currently remaining are:
8 x L T-shirts
1 x XL T-shirts
1 x yellow cup
3 x plates
3 x baseball cap
8 x magnets
5 x coasters
Every item under 20€
Images:
 http://coreboot.org/Coreboot_conference_Bonn_2015
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Goodies for Bonn meeting

[Vladimir 'phcoder' Serbinenko]

>
>
> I would like to order 3 plates, 1 white, 1 black, 1 pink cup and 1 magnet.
>
All reserved for you.

> If you have extra white cups I'll buy those too.
>
> Sorry, only 1 was left before this e-mail.

> If I don't make it in person I'll ask if someone might courier cash
> and goodies on my behalf. Let me know the amount.
>
> I'll send out the final prices on Thursday or Friday.

>
> Thanks a lot! (Images sell. :)
>
> You're welcome.

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

Re: [coreboot] Goodies for Bonn meeting

[Vladimir 'phcoder' Serbinenko]

Le Tue, Oct 6, 2015 à 10:55 PM, Peter Stuge <pe...@stuge.se> a écrit :

> Vladimir 'phcoder' Serbinenko wrote:
> > Reminder, please write me if you want any of this. Right now only
> > Ron Minnich and echelon have ordered. I've added pictures at
> > http://coreboot.org/Coreboot_conference_Bonn_2015
>
> The goodies look really great! :) How many cups, plates and magnets
> are there?
>
> Other than the ones already spoken for, I have:
8 L T-shirts
1 XL
3 white cups
1 x Black, yellow, orange and pink cup
6 x plates
3 x baseball cap
9 x magnets
5 x coasters

More is possible to order if I get replies quickly but I will not be able
to get them to the meeting, so we will have to arrange mail delivery.
If I get a reply before Friday we can order hoodies but again, they will
not be available for the conference

> What's the square thing that isn't a magnet? Coaster or mouse pad?
>
> It's coaster


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

[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] [Bug?] 3 different bytes in VGAbios after upgrade to coreboot

[Vladimir]

Thank you very much for solving this riddle!
And one more question for Rudolf: please tell, are you using atomDis
utility to disassemble atombios into C code? Or there are some other
special tools, which probably have more recent versions? (latest version of
atomDis is already 4 years old...)

On 3 June 2015 at 20:27, Rudolf Marek r.ma...@assembler.cz wrote:

 Hi all,

 First byte after IBM is usually a checksum. So in fact only two bytes
 differ.
 Now you may ask what it is... and it is a IOBASE :)

 typedef struct _ATOM_ROM_HEADER
 {
   ATOM_COMMON_TABLE_HEADER sHeader;
   UCHAR uaFirmWareSignature[4];/*Signature to distinguish between
 Atombios
 and non-atombios,atombios should init it as ATOM, don't change the
 position */
   USHORT usBiosRuntimeSegmentAddress;
   USHORT usProtectedModeInfoOffset;
   USHORT usConfigFilenameOffset;
   USHORT usCRC_BlockOffset;
   USHORT usBIOS_BootupMessageOffset;
   USHORT usInt10Offset;
   USHORT usPciBusDevInitCode;
   USHORT usIoBaseAddress; ---this changes

 I guess IOBASE of PCI device changes also...

   USHORT usSubsystemVendorID;
   USHORT usSubsystemID;
   USHORT usPCI_InfoOffset;.
   USHORT usMasterCommandTableOffset; /*Offset for SW to get all command
 table
 offsets, Don't change the position */
   USHORT usMasterDataTableOffset;   /*Offset for SW to get all data table
 offsets, Don't change the position */
   UCHAR  ucExtendedFunctionCode;
   UCHAR  ucReserved;
 }ATOM_ROM_HEADER;

 You can use atomDis to dump it I guess (Did not check if it dumps also the
 header.

 Thanks
 Rudolf

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

[coreboot] [Bug?] 3 different bytes in VGAbios after upgrade to coreboot

[Vladimir]

I retrieved my vgabios via Linux kernel 3.19 (ubuntu 15.04) using this
method - http://www.coreboot.org/VGA_support#Retrieval_via_Linux_kernel  ;
then I downloaded latest sources of SeaBIOS  Coreboot and built Coreboot
using compiled SeaBIOS payload as well as vgabios file ( 1002,990b )

After coreboot installation I have decided to retrieve vgabios again, using
exactly the same kernel and OS, and then diff'ed two vgabios files out of
curiosity. To my surprise, they are slightly different!
vgabios_before.bin - SHA1 checksum: e4d320eb278b0118c46e2e470e7154b12c41966d
vgabios__after.bin - SHA1 checksum: a9e2ed569bbaaea283b5380a5f6c44fc4efc3da4
Here is a report about 3 bytes difference between them -
http://www.diffnow.com/?report=2kwq3
(wait a few seconds while it loads)

Then I teardown a laptop, and check if vgabios inside coreboot's image
(flashed in chip) is 3 bytes different as well, but there was no difference
against the original vgabios.

So, it appears that, while loading vgabios from a flash chip, coreboot
modifies it slightly. Although this tiny difference is not causing any
graphical glitches or problems for me, this could be a result of a bug -
which is not necessarily limited to my hardware ( Lenovo G505s ) , and
maybe could lead to some other problems

Please tell your opinion, is it a bug or I am wrong at something?

Best regards,
Vladimir Shipovalov
-- 
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 phco...@gmail.com
 Date: Thu, May 21, 2015 at 2:29 PM
 Subject: Re: [coreboot] Coreboot T-shirts
 To: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net
 Cc: coreboot coreboot@coreboot.org
 
 
 
 Le 21 mai 2015 13:01, Carl-Daniel Hailfinger
 c-d.hailfinger.devel.2...@gmx.net 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] 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] 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 n...@terminal21.de
 mailto:n...@terminal21.de 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] x230 - vgabios

[Vladimir 'phcoder' Serbinenko]

Le Sat, May 23, 2015 à 4:46 AM, Michael Gerlach n...@terminal21.de a
écrit :

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi Patrick!

 Uhm - I do not explicitly compressed it. I just added it to config..

 Extracted it via

 echo 1  /sys/devices/pci\:00/\:00\:02.0/rom
 cp /sys/devices/pci\:00/\:00\:02.0/rom vgabios.bin

 That's your problem. ROM needs to be extracted, not dumped. You can
workaround immediate problem by disabling checksum in SeaBIOS but dumped
oprom for intel is not fully functional, i.a. LCD stays black with windows.


 How to check if it's compressed?


 Best regards,


 n3ph


 On 05/23/15 03:22, Patrick Georgi wrote:
  2015-05-23 1:06 GMT+02:00 Michael Gerlach n...@terminal21.de:
  GET_VBIOS: 7b46 3714 8b a2 e9
 
  printk(BIOS_DEBUG, GET_VBIOS: %x %x %x %x %x\n,
  oprom-signature, pcir-vendor, pcir-classcode[0],
  pcir-classcode[1], pcir-classcode[2]);
 
  But Signature should be 0x55aa:
  Just to double check: did you add the vgabios with or without
  compression? coreboot only supports uncompressed vgabios images
  (while seabios allows them compressed as well, if the name
  matches)
 
 
  Patrick
 


 - --
 Bitte benutzt GPG: http://de.wikipedia.org/wiki/GNU_Privacy_Guard



 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQEcBAEBAgAGBQJVX+XmAAoJEE1l5S41evqaQRcH/2fBtgPODZzmDNHX03Vi8UJY
 bRXIg4RwGo2lbfaepxfJuyi0EH5Rv5QAOCMBB6Eh7c6Tovf+wa4kbZivc+4Qn/k2
 zBb/qvURAmthHQzqVuRUBL5zI5SRL/KbcGX5l7jkjx+d1KVLlfZR+rT4KHHOVJLF
 FccnwT0P2OrSeyLMV31pCqkbK5Nf9lVsIRAJoQtcWwlaClTiaIUiji0TzJwjoJ5C
 JibGCNCRJ4yjgCTty4EwmRxrUYvBEjFg87g33HhE61Ya73Dh4xcetEC2y/stdnMs
 U4LV/Kzb/oDfOdmy6Em0+XnDAFTaSxkqTqU2V/zBGsZACNwj4fce4QrNi35DJpE=
 =DNks
 -END PGP SIGNATURE-

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

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

[coreboot] Coreboot T-shirts

[Vladimir 'phcoder' Serbinenko]

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. 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?
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Coreboot T-shirts

[Vladimir 'phcoder' Serbinenko]

Le 21 mai 2015 13:01, Carl-Daniel Hailfinger 
c-d.hailfinger.devel.2...@gmx.net 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
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Fwd: Coreboot T-shirts

[Vladimir 'phcoder' Serbinenko]

Apparently original mail didn't make it to the list. Resent


-- Forwarded message --
From: Vladimir 'phcoder' Serbinenko phco...@gmail.com
Date: Thu, May 21, 2015 at 2:29 PM
Subject: Re: [coreboot] Coreboot T-shirts
To: Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net
Cc: coreboot coreboot@coreboot.org



Le 21 mai 2015 13:01, Carl-Daniel Hailfinger
c-d.hailfinger.devel.2...@gmx.net 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


-- 
Regards
Vladimir 'phcoder' Serbinenko

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

Re: [coreboot] Regarding Intel (and Librem)

[Vladimir]

Today I discovered that CPU is indeed socket-ed on G505s, so it is possible
to get G505s with less powerful CPU (e.g. A8) , and - if it turns out to be
not compatible, or not fast enough for your needs, then you could get
A10-5750M and install by yourself. Saw it for ~$50-$80 at Aliexpress
(higher price for not used yet)

There are three slightly different motherboards which could be found in
Lenovo G505s, all made by Compal Electronics :
*1) *LA-A092P for only 8650G, which is built-in into APU (no dual graphics)
*2)* LA-A091P rev 1.0 for 8650G + AMD HD 8570M (dual graphics)
*3)* LA-A091P rev 1.A for 8650G + AMD R5 M230 ( dual graphics, slightly
more powerful than 2) )
And, some other Lenovo laptops have the same Compal motherboards, e.g.
G405s has LA-A091P.
If I am correct: there are more Lenovo AMD laptops supported by Coreboot,
they are just not tested yet...

Also, on my motherboard there was no MXIC chip, but cFeon QH32-104HIP bios
chip instead. As you see, lots of things could be added to Coreboot G505s
wiki. I've asked a coreboot wiki account so that I could improve g505s
page: add new information, and clarify older as well


On 17 April 2015 at 11:45, Vladimir quickcrackt...@gmail.com wrote:

 Problem with Librem is not just that it isn't fully free yet and doesn't
 seem to become so in future, but also that it is an Intel-based product.

 Intel is totally NOT friendly to coreboot project (and open source
 community in general) - that could be seen by their malevolent actions,
 such as introduction of Boot Guard feature. Intel tries to justify them
 by it's for your safety preaching; but, anytime someone puts a lock on
 something you own, against your wishes, and doesn't give you the key,
 they're not doing it for your benefit (Doctorow's Law)

 By purchasing a product of a company, you are fully supporting their
 policy. And that is why it is not good to support Intel by getting
 Intel-based products and developing for Intel, despite ~75% of x86/x86_64
 CPU market is owned by them.

 You are right, there are some difficulties about AMD products, such as the
 need to reverse engineer SMU and Atombios firmwares for their APUs. But at
 least they're not putting deliberate hardware obstacles in their new
 products, and if they don't become evil like Intel (hope so) AMD could be
 a future of coreboot x86/x86_64 branch.

 P.S. In addition to Lenovo G505s, I was very happy to find out that -
 thanks to latest contributors - coreboot is now supporting the ASROCK
 IMB-A180 and Biostar AM1ML which are based on AMD AM1 platform
 (architecture family 16h, Puma/Jaguar SoCs are compatible) Maybe some of
 these products have a potential to be RYF'ed, will see...

 Best regards,
 Vladimir Shipovalov

 On 11 April 2015 at 19:33, Peter Stuge pe...@stuge.se wrote:

 Alexandru Gagniuc wrote:
  figured out how to fuse the PCH to disable ME

 Please read ISBN 9781430265719.

 The ME firmware controls the host CPU reset.

 //Peter

 On 10 April 2015 at 08:45, Alexandru Gagniuc mr.nuke...@gmail.com
 wrote:

 On Monday, April 06, 2015 01:45:32 PM Vladimir wrote:
  Dear coreboot developers,
 
  Francis Rowe (main Libreboot developer) has hinted an idea about adding
  Lenovo G505S to Coreboot LTS Candidates list of laptops, which is
 hosted at
  MrNuke's User talk coreboot wiki page. I believe it is an excellent
 idea,
  because:
 
 You are free to add it, but keep in mind that anything with an AMD APU
 will
 fail the RYF-certifiable criteria due to SMU and atombios.

 If we're going to lower the bar, we should also consider Librem 15. At
 least
 that one has (should have) a much more durable construction and much
 better
 screen. If those guys aren't as full of it as they sound, and have
 figured out
 how to fuse the PCH to disable ME, then RYF'ing a Librem should be less
 work
 than anything APU.

  Best regards,
 Alex

 On 8 April 2015 at 12:49, Vladimir quickcrackt...@gmail.com wrote:

 What if A8 model is supported as well, just not tested yet? These APUs
 are very similar to each other, after all ;)
 Maybe a knowledgeable coreboot developers, especially those who have
 ported coreboot to G505S, could tell what parts of code are A10-specific -
 and, if there is indeed such a code, how to change the parameters of that
 code to make them suitable for A8 ?

 In case they don't reply: if you have SPI clip as well as BIOS
 programmer that supports many chips including MX25L1606E , could try a
 following scenario:
 1) get A8 G505S locally  try to install coreboot
 2) if it works, announce it to a mailing list that there's a support
 and keep a laptop to yourself ; but if it doesn't work - even after playing
 with parameters - and a laptop is bricked, you could restore a
 manufacturer's BIOS using SPI clip  BIOS programmer, and then return a
 laptop to seller...

 About A10 model - it does not seem to be US-only: there are a lot of
 offers in Russia, as well as at developing countries such as
 Thailand/India (maybe

[coreboot] Regarding Intel (and Librem)

[Vladimir]

Problem with Librem is not just that it isn't fully free yet and doesn't
seem to become so in future, but also that it is an Intel-based product.

Intel is totally NOT friendly to coreboot project (and open source
community in general) - that could be seen by their malevolent actions,
such as introduction of Boot Guard feature. Intel tries to justify them
by it's for your safety preaching; but, anytime someone puts a lock on
something you own, against your wishes, and doesn't give you the key,
they're not doing it for your benefit (Doctorow's Law)

By purchasing a product of a company, you are fully supporting their
policy. And that is why it is not good to support Intel by getting
Intel-based products and developing for Intel, despite ~75% of x86/x86_64
CPU market is owned by them.

You are right, there are some difficulties about AMD products, such as the
need to reverse engineer SMU and Atombios firmwares for their APUs. But at
least they're not putting deliberate hardware obstacles in their new
products, and if they don't become evil like Intel (hope so) AMD could be
a future of coreboot x86/x86_64 branch.

P.S. In addition to Lenovo G505s, I was very happy to find out that -
thanks to latest contributors - coreboot is now supporting the ASROCK
IMB-A180 and Biostar AM1ML which are based on AMD AM1 platform
(architecture family 16h, Puma/Jaguar SoCs are compatible) Maybe some of
these products have a potential to be RYF'ed, will see...

Best regards,
Vladimir Shipovalov

On 11 April 2015 at 19:33, Peter Stuge pe...@stuge.se wrote:

 Alexandru Gagniuc wrote:
  figured out how to fuse the PCH to disable ME

 Please read ISBN 9781430265719.

 The ME firmware controls the host CPU reset.

 //Peter

 On 10 April 2015 at 08:45, Alexandru Gagniuc mr.nuke...@gmail.com wrote:

 On Monday, April 06, 2015 01:45:32 PM Vladimir wrote:
  Dear coreboot developers,
 
  Francis Rowe (main Libreboot developer) has hinted an idea about adding
  Lenovo G505S to Coreboot LTS Candidates list of laptops, which is
 hosted at
  MrNuke's User talk coreboot wiki page. I believe it is an excellent
 idea,
  because:
 
 You are free to add it, but keep in mind that anything with an AMD APU
 will
 fail the RYF-certifiable criteria due to SMU and atombios.

 If we're going to lower the bar, we should also consider Librem 15. At
 least
 that one has (should have) a much more durable construction and much
 better
 screen. If those guys aren't as full of it as they sound, and have
 figured out
 how to fuse the PCH to disable ME, then RYF'ing a Librem should be less
 work
 than anything APU.

  Best regards,
 Alex

 On 8 April 2015 at 12:49, Vladimir quickcrackt...@gmail.com wrote:

 What if A8 model is supported as well, just not tested yet? These APUs
 are very similar to each other, after all ;)
 Maybe a knowledgeable coreboot developers, especially those who have
 ported coreboot to G505S, could tell what parts of code are A10-specific -
 and, if there is indeed such a code, how to change the parameters of that
 code to make them suitable for A8 ?

 In case they don't reply: if you have SPI clip as well as BIOS
 programmer that supports many chips including MX25L1606E , could try a
 following scenario:
 1) get A8 G505S locally  try to install coreboot
 2) if it works, announce it to a mailing list that there's a support and
 keep a laptop to yourself ; but if it doesn't work - even after playing
 with parameters - and a laptop is bricked, you could restore a
 manufacturer's BIOS using SPI clip  BIOS programmer, and then return a
 laptop to seller...

 About A10 model - it does not seem to be US-only: there are a lot of
 offers in Russia, as well as at developing countries such as
 Thailand/India (maybe that stock was inherited from EU countries) But,
 because of huge quantity of different laptop models/modifications, and
 dependence of their local availability on local retailers' preference,
 there are countries which got either a small stock of G505S or none at all!
 :P And that returns us to reasonable availability debate... In my
 perception:

 Reasonable availability for a laptop model, is when a person is able
 to get a new laptop (not used/refurbished) - for a price that does not
 exceed the manufacturer's list price by more than X % of it. (e.g. 25%).
 That additional condition regarding the list price is necessary, because if
 there would be some greedy retailers left - who didn't sold out their large
 stock just because of outrageous unreasonable prices - I wouldn't call this
 as reasonably available ;)

 As you see, reasonable availability is a quite subjective term,
 because if your country doesn't have a stock of this laptop:
 *) your price would be not just price of unit but also a shipping price
 from other country, + possible import taxes
 *) there are various risks: if, because of your location, you cannot buy
 a laptop in store after checking its quality,
 a laptop could have manufacturing defects that are not enough

Re: [coreboot] Lenovo G505S and Coreboot LTS Candidates list

[Vladimir]

What if A8 model is supported as well, just not tested yet? These APUs are
very similar to each other, after all ;)
Maybe a knowledgeable coreboot developers, especially those who have ported
coreboot to G505S, could tell what parts of code are A10-specific - and, if
there is indeed such a code, how to change the parameters of that code to
make them suitable for A8 ?

In case they don't reply: if you have SPI clip as well as BIOS programmer
that supports many chips including MX25L1606E , could try a following
scenario:
1) get A8 G505S locally  try to install coreboot
2) if it works, announce it to a mailing list that there's a support and
keep a laptop to yourself ; but if it doesn't work - even after playing
with parameters - and a laptop is bricked, you could restore a
manufacturer's BIOS using SPI clip  BIOS programmer, and then return a
laptop to seller...

About A10 model - it does not seem to be US-only: there are a lot of offers
in Russia, as well as at developing countries such as Thailand/India
(maybe that stock was inherited from EU countries) But, because of huge
quantity of different laptop models/modifications, and dependence of their
local availability on local retailers' preference, there are countries
which got either a small stock of G505S or none at all! :P And that returns
us to reasonable availability debate... In my perception:

Reasonable availability for a laptop model, is when a person is able to
get a new laptop (not used/refurbished) - for a price that does not exceed
the manufacturer's list price by more than X % of it. (e.g. 25%). That
additional condition regarding the list price is necessary, because if
there would be some greedy retailers left - who didn't sold out their large
stock just because of outrageous unreasonable prices - I wouldn't call this
as reasonably available ;)

As you see, reasonable availability is a quite subjective term, because
if your country doesn't have a stock of this laptop:
*) your price would be not just price of unit but also a shipping price
from other country, + possible import taxes
*) there are various risks: if, because of your location, you cannot buy a
laptop in store after checking its quality,
a laptop could have manufacturing defects that are not enough to request a
replacement/partial refund, e.g. laws based on ISO 13406-2 standard could
allow a seller to refuse a replacement of laptop if there are a few
annoying dead pixels.
These risks have a different weight in the eyes of different people, e.g.
many people wouldn't consider it as reasonably available even if it's
available from neighbor country with a low shipping price, because they do
not want to risk. And that makes this term even more subjective and hard to
measure by automatic metrics...

P.S. Indeed, some laptops that are listed in coreboot LTS Candidates list
( http://www.coreboot.org/User_talk:MrNuke/LTS_Candidates ) have A10-5750M
as well and seem to be more reasonably available than G505S, at least for
your country. But, despite having a somewhat similar hardware, nobody
ported a coreboot to them yet :P

Best regards,
Vladimir Shipovalov


On 7 April 2015 at 16:17, Emilian Bold emilian.b...@gmail.com wrote:

 My point is not to limit your LTS list to US laptops. US has
 *extraordinary* availability for a lot of gear.

 There's also the matter of procurement and warranty. A company won't
 bother importing some laptop from outside the EU just because a developer
 wants it -- they will look locally and as a last resort within the EU.

 Except some brands (Apple comes to mind) warranty becomes a hassle if the
 laptop breaks. Transport costs, long wait time and language issues
 complicate matters.

 Amazon Germany seems to have 2 laptops in stock with A10. Amazon
 Spain/France/Italy/Netherlands has none. Only Amazon UK seems to have it
 without giving a stock warning (but it's sold by a 3d party).

 Anyhow, I don't want to sidetrack this, but the first criteria for the LTS
 laptop is reasonable availability...

 Perhaps you should have some metric for availability (this could even be
 automated somewhat). Pick a list of top electronics sites/stores from a
 list of countries and define a formula based on model availability.

 Alternatively, it would be great to support the A8 too!

 To me the the G505S would clearly be a better machine to recommend
 compared to an ancient Thinkpad X2xx!

 --emi


 On Tue, Apr 7, 2015 at 3:28 PM, Vladimir quickcrackt...@gmail.com wrote:

 If I am not mistaken, your country is Romania... Unfortunately - if I
 didn't skip something - it looks like Romania went out of A10 stock just a
 couple of weeks ago! However, I found many offers from Hungary, which is
 very close! Some offers are listed on price list-type websites (e.g.
 http://www.arukereso.hu/CategorySearch.php?st=g505s+a10 ) while others
 are not listed anywhere (e.g.
 http://www.notebookspecialista.hu/lenovo_ideapad_g505s_59_422983_notebook-11928.html
 )
 Nice thing is that these offers

Re: [coreboot] Lenovo G505S and Coreboot LTS Candidates list

[Vladimir]

If I am not mistaken, your country is Romania... Unfortunately - if I
didn't skip something - it looks like Romania went out of A10 stock just a
couple of weeks ago! However, I found many offers from Hungary, which is
very close! Some offers are listed on price list-type websites (e.g.
http://www.arukereso.hu/CategorySearch.php?st=g505s+a10 ) while others are
not listed anywhere (e.g.
http://www.notebookspecialista.hu/lenovo_ideapad_g505s_59_422983_notebook-11928.html
)
Nice thing is that these offers usually have A10 + R5 230M, slightly faster
dual graphics. But the majority of G505S models selling in Europe have Win8
pre-installed, so I'm afraid it would be hard to avoid paying extra for
this bloatware, in your case :P

As for other European countries, it is difficult for me to look through the
entire EU because there are many countries with many languages. I only know
English as foreign language, and thats why the majority of foreign offers
I'm able to find, are in UK/US...

On 6 April 2015 at 23:12, Emilian Bold emilian.b...@gmail.com wrote:

 Well, the G505S with A10-5750M is explicitly listed as no longer being
 sold. So it's the A8 or nothing.

 Could you provide links within the EU with (online) shops still selling
 the A10 variant and having some actual stock?

 --emi

 On Mon, Apr 6, 2015 at 6:45 PM, Vladimir quickcrackt...@gmail.com wrote:

 Yes, in addition to A10-5750M based G505S there are also A8 and A6 ones.
 But there are some possible problems regarding them:
 1) their price is just slightly lower than with A10 - as result,
 price/performance ratio seems to be worse for these models
 2) I'm not sure if it is possible could upgrade their APU from A6/A8 to
 A10-5750M after purchase
 3) most importantly: some parameters inside a coreboot source code for
 G505S could be A10-specific ;
 I am not sure if a current A10-inclined build would run on A8/A6 out of
 the box, without additional tweaking

 A question from my last letter - about compatibility of G505S coreboot
 build with various graphics solutions found in different modifications, is
 not addressed yet... to remind, there are three groups of modifications:
 *) only 8650G (no dual graphics)
 *) 8650G + AMD HD 8570M (dual graphics)
 *) 8650G + AMD R5 M230 (dual graphics, slightly faster)

 P.S. Below is an =incomplete= list of SKUs for A10 G505S models that I
 was able to find. If there is a shortage in your country, maybe this list
 could assist you in search (those mods with windows 8 are about $50 more
 expensive and support evil M$, please dont get them ;-) )

 1) only 8650G (no dual graphics) + 4GB + FreeDOS = 59-410323
 2) only 8650G (no dual graphics) + 8GB + FreeDOS = 59-405169
 3) only 8650G (no dual graphics) + 4GB + Windows 8 = 59-380131
 4) only 8650G (no dual graphics) + 6GB + Windows 8 = 59-373010 / 59-406417
 5) only 8650G (no dual graphics) + 8GB + Windows 8 = 59-403088
 6) 8650G + AMD HD 8570M (dual graphics) + 4GB + FreeDOS = 59-405168
 7) 8650G + AMD HD 8570M (dual graphics) + 6GB + FreeDOS = 59-409773
 8) 8650G + AMD HD 8570M (dual graphics) + 8GB + FreeDOS = 59-380146 /
 59-387536
 9) 8650G + AMD HD 8570M (dual graphics) + 4GB + Windows 8 = 59-407135 /
 59410966
 10) 8650G + AMD HD 8570M (dual graphics) + 6GB + Windows 8 = 59-382102
 11) 8650G + AMD HD 8570M (dual graphics) + 8GB + Windows 8 = 59-401209
 12) 8650G + AMD R5 M230 (dual graphics, slightly faster) + 4GB + FreeDOS
 = 59-410881
 13) 8650G + AMD R5 M230 (dual graphics, slightly faster) + 8GB + FreeDOS
 = 59-410885
 14) 8650G + AMD R5 M230 (dual graphics, slightly faster)  + 4GB + Windows
 8 = 59-408604
 15) 8650G + AMD R5 M230 (dual graphics, slightly faster)  + 8GB + Windows
 8 = 59-410883

 On 6 April 2015 at 14:20, Emilian Bold emilian.b...@gmail.com wrote:

 I can confirm I'm still able to buy a G505S in my country but it seems
 to have the quad core A8-4500M (not the A10) with a dedicated Radeon HD
 8570M.

 It's a decent machine and it would be great to have it on the official
 LTS list.

 Speaking of the list, I cannot find any store selling the Toshiba
 Satellite C50D-A mentioned in the wiki.

 --emi


 On Mon, Apr 6, 2015 at 1:45 PM, Vladimir quickcrackt...@gmail.com
 wrote:

 Dear coreboot developers,

 Francis Rowe (main Libreboot developer) has hinted an idea about adding
 Lenovo G505S to Coreboot LTS Candidates list of laptops, which is hosted at
 MrNuke's User talk coreboot wiki page. I believe it is an excellent idea,
 because:

 *1)* Lenovo G505S contains AMD APU, so there is no need to deal with
 Intel ME/AMT so-called features
 *2)* this APU has Richland architecture: as result (unlike the more
 recent AMD offerings) it doesn't have AMD Secure feature -- based on ARM
 Trustzone technology which already has some exploits against it; there are
 security concerns about ARM Trustzone that are similar to concerns about
 Intel vPro feature (remote management etc.)
 *3)* this APU is A10-5750M, the most powerful mobile APU among
 Richland designs

[coreboot] Lenovo G505S and Coreboot LTS Candidates list

[Vladimir]

Dear coreboot developers,

Francis Rowe (main Libreboot developer) has hinted an idea about adding
Lenovo G505S to Coreboot LTS Candidates list of laptops, which is hosted at
MrNuke's User talk coreboot wiki page. I believe it is an excellent idea,
because:

*1)* Lenovo G505S contains AMD APU, so there is no need to deal with Intel
ME/AMT so-called features
*2)* this APU has Richland architecture: as result (unlike the more recent
AMD offerings) it doesn't have AMD Secure feature -- based on ARM
Trustzone technology which already has some exploits against it; there are
security concerns about ARM Trustzone that are similar to concerns about
Intel vPro feature (remote management etc.)
*3)* this APU is A10-5750M, the most powerful mobile APU among Richland
designs - as result, this laptop is still very competitive regarding its
performance, and also price/performance
*4)* Unlike the older HP M6-1035DX amd laptop, Lenovo G505S seems to be a
very popular model: even now, more than 1.5 years after its' introduction,
there are 200 Internet shops in my large city still selling it new in box
- not used/refurbished
*5)* Lenovo G505s works without microcode updates, and already has a
working Coreboot build (although Video BIOS and SMU firmware have blobs
that are still not reverse-engineered; and some minor issues - e.g. ACPI
not perfect yet )

These great points are making me wonder, why this interesting laptop still
haven't been added to that LTS Candidates list? Does it fail to meet some
requirement for LTS candidates in a not-obvious way
(RYF-certifiable,Sturdy,Long shelf-life,Cool factor) or there is some
not-listed AMD laptop that could be a better candidate?

By the way, I have discovered that there are many modifications of Lenovo
G505S, which could be divided into three primary groups by their major
difference - GPU *(minor differences, such as different size of RAM or hard
drive, are not interesting)*
GPU modification groups:
*1)* only 8650G, which is built-in into APU (no dual graphics)
*2)* 8650G + AMD HD 8570M (dual graphics)
*3)* 8650G + AMD R5 M230 ( dual graphics, slightly more powerful than 2) )
Are these modifications all supported by Coreboot? And would be there any
additional difficulties regarding modifications with dual graphics?

Your answers and opinions will be very welcome
Best regards,
Vladimir Shipovalov
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo G505S and Coreboot LTS Candidates list

[Vladimir]

Yes, in addition to A10-5750M based G505S there are also A8 and A6 ones.
But there are some possible problems regarding them:
1) their price is just slightly lower than with A10 - as result,
price/performance ratio seems to be worse for these models
2) I'm not sure if it is possible could upgrade their APU from A6/A8 to
A10-5750M after purchase
3) most importantly: some parameters inside a coreboot source code for
G505S could be A10-specific ;
I am not sure if a current A10-inclined build would run on A8/A6 out of
the box, without additional tweaking

A question from my last letter - about compatibility of G505S coreboot
build with various graphics solutions found in different modifications, is
not addressed yet... to remind, there are three groups of modifications:
*) only 8650G (no dual graphics)
*) 8650G + AMD HD 8570M (dual graphics)
*) 8650G + AMD R5 M230 (dual graphics, slightly faster)

P.S. Below is an =incomplete= list of SKUs for A10 G505S models that I was
able to find. If there is a shortage in your country, maybe this list could
assist you in search (those mods with windows 8 are about $50 more
expensive and support evil M$, please dont get them ;-) )

1) only 8650G (no dual graphics) + 4GB + FreeDOS = 59-410323
2) only 8650G (no dual graphics) + 8GB + FreeDOS = 59-405169
3) only 8650G (no dual graphics) + 4GB + Windows 8 = 59-380131
4) only 8650G (no dual graphics) + 6GB + Windows 8 = 59-373010 / 59-406417
5) only 8650G (no dual graphics) + 8GB + Windows 8 = 59-403088
6) 8650G + AMD HD 8570M (dual graphics) + 4GB + FreeDOS = 59-405168
7) 8650G + AMD HD 8570M (dual graphics) + 6GB + FreeDOS = 59-409773
8) 8650G + AMD HD 8570M (dual graphics) + 8GB + FreeDOS = 59-380146 /
59-387536
9) 8650G + AMD HD 8570M (dual graphics) + 4GB + Windows 8 = 59-407135 /
59410966
10) 8650G + AMD HD 8570M (dual graphics) + 6GB + Windows 8 = 59-382102
11) 8650G + AMD HD 8570M (dual graphics) + 8GB + Windows 8 = 59-401209
12) 8650G + AMD R5 M230 (dual graphics, slightly faster) + 4GB + FreeDOS =
59-410881
13) 8650G + AMD R5 M230 (dual graphics, slightly faster) + 8GB + FreeDOS =
59-410885
14) 8650G + AMD R5 M230 (dual graphics, slightly faster)  + 4GB + Windows 8
= 59-408604
15) 8650G + AMD R5 M230 (dual graphics, slightly faster)  + 8GB + Windows 8
= 59-410883

On 6 April 2015 at 14:20, Emilian Bold emilian.b...@gmail.com wrote:

 I can confirm I'm still able to buy a G505S in my country but it seems to
 have the quad core A8-4500M (not the A10) with a dedicated Radeon HD 8570M.

 It's a decent machine and it would be great to have it on the official LTS
 list.

 Speaking of the list, I cannot find any store selling the Toshiba
 Satellite C50D-A mentioned in the wiki.

 --emi


 On Mon, Apr 6, 2015 at 1:45 PM, Vladimir quickcrackt...@gmail.com wrote:

 Dear coreboot developers,

 Francis Rowe (main Libreboot developer) has hinted an idea about adding
 Lenovo G505S to Coreboot LTS Candidates list of laptops, which is hosted at
 MrNuke's User talk coreboot wiki page. I believe it is an excellent idea,
 because:

 *1)* Lenovo G505S contains AMD APU, so there is no need to deal with
 Intel ME/AMT so-called features
 *2)* this APU has Richland architecture: as result (unlike the more
 recent AMD offerings) it doesn't have AMD Secure feature -- based on ARM
 Trustzone technology which already has some exploits against it; there are
 security concerns about ARM Trustzone that are similar to concerns about
 Intel vPro feature (remote management etc.)
 *3)* this APU is A10-5750M, the most powerful mobile APU among Richland
 designs - as result, this laptop is still very competitive regarding its
 performance, and also price/performance
 *4)* Unlike the older HP M6-1035DX amd laptop, Lenovo G505S seems to be
 a very popular model: even now, more than 1.5 years after its'
 introduction, there are 200 Internet shops in my large city still selling
 it new in box - not used/refurbished
 *5)* Lenovo G505s works without microcode updates, and already has a
 working Coreboot build (although Video BIOS and SMU firmware have blobs
 that are still not reverse-engineered; and some minor issues - e.g. ACPI
 not perfect yet )

 These great points are making me wonder, why this interesting laptop
 still haven't been added to that LTS Candidates list? Does it fail to meet
 some requirement for LTS candidates in a not-obvious way
 (RYF-certifiable,Sturdy,Long shelf-life,Cool factor) or there is some
 not-listed AMD laptop that could be a better candidate?

 By the way, I have discovered that there are many modifications of Lenovo
 G505S, which could be divided into three primary groups by their major
 difference - GPU *(minor differences, such as different size of RAM or
 hard drive, are not interesting)*
 GPU modification groups:
 *1)* only 8650G, which is built-in into APU (no dual graphics)
 *2)* 8650G + AMD HD 8570M (dual graphics)
 *3)* 8650G + AMD R5 M230 ( dual graphics, slightly more powerful than
 2) )
 Are these modifications all

Re: [coreboot] Trouble with Coreboot on Lenovo G505s

[Vladimir]

Very sorry to hear that your LCD backlight problem is not resolved yet!
Are you confident that LCD backlight is not faulty, and have you tried
reinstalling coreboot?

If answer for both questions is yes - then you could try these two
advices:
1) Re-download a source code of coreboot from github, compile it and flash
again to your G505s.
Since your last try - at the end of January - there were 5 commits to
coreboot/src/mainboard/lenovo/g505s branch,
and also some commits to the common branches, changes that affect all the
mainboards supported by coreboot.
Maybe your issue will be resolved if you would try coreboot again, with
latest sources!

2) If 1st advice doesn't work, you could open
coreboot/src/mainboard/lenovo/g505s/buildOpts.c file
(which is the only file from G505s branch that has a reference to LCD)
Go to line 158, try to change the #define BLDCFG_CFG_LCD_BACK_LIGHT_CONTROL
200 parameter.
Default value seems to be 200 for most platforms, but you could try setting
it to 0. Then compile  flash again

=== Any advices from experienced coreboot members would be very welcome! ===

On 3 April 2015 at 17:46, 1 1 zilog...@gmail.com wrote:

 No. I not solved this problem.

 2015-04-03 17:08 GMT+04:00 Vladimir quickcrackt...@gmail.com:

  On Mon Jan 26 13:07:42 CET 2015 zilogpnz wrote:
  I'm trying to run Coreboot on Lenovo G505s and have a problem:
  - backlight of LCD is not turn on. But on the external LCD (by CRT
  connector) is all good.
 
  Could you help me with a solution to this problem?


 Sorry for such a long reply, but what is a current status of this problem?
 Have you resolved the LCD backlight problem with your G505s - and, if
 yes, how?



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

Re: [coreboot] Trouble with Coreboot on Lenovo G505s

[Vladimir]

Very sorry to hear that your LCD backlight problem is not resolved yet!
Are you confident that LCD backlight is not faulty, and have you tried
reinstalling coreboot?

If answer for both questions is yes, then you could try these two advices:

1) Redownload a source code of coreboot from github, compile it and flash
again to your G505s.
Since your last try - at the end of January - there were 5 commits to
coreboot/src/mainboard/lenovo/g505s branch,
and also some commits to the common branches, changes that affect all the
mainboards supported by coreboot.
Maybe your issue will be resolved if you would try coreboot again, with
latest sources!

2) If 1st advice doesn't work, you could open
coreboot/src/mainboard/lenovo/g505s/buildOpts.c file
(which is the only file from G505s branch that has a reference to LCD)
Go to line 158, try to change the #define
BLDCFG_CFG_LCD_BACK_LIGHT_CONTROL 200 parameter.
Default value seems to be 200 for most platforms, but you could try setting
it to 0. Then compile  flash again

=== Any advices from experienced coreboot members would be very welcome! ===

On 3 April 2015 at 17:46, 1 1 zilog...@gmail.com wrote:

 No. I not solved this problem.

 2015-04-03 17:08 GMT+04:00 Vladimir quickcrackt...@gmail.com:

  On Mon Jan 26 13:07:42 CET 2015 zilogpnz wrote:
  I'm trying to run Coreboot on Lenovo G505s and have a problem:
  - backlight of LCD is not turn on. But on the external LCD (by CRT
  connector) is all good.
 
  Could you help me with a solution to this problem?


 Sorry for such a long reply, but what is a current status of this problem?
 Have you resolved the LCD backlight problem with your G505s - and, if
 yes, how?



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

[coreboot] Trouble with Coreboot on Lenovo G505s

[Vladimir]

 On Mon Jan 26 13:07:42 CET 2015 zilogpnz wrote:
 I'm trying to run Coreboot on Lenovo G505s and have a problem:
 - backlight of LCD is not turn on. But on the external LCD (by CRT
 connector) is all good.

 Could you help me with a solution to this problem?


Sorry for such a long reply, but what is a current status of this problem?
Have you resolved the LCD backlight problem with your G505s - and, if yes,
how?
-- 
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]

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

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] 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 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

[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 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 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

[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 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 gail...@gmail.com
 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

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 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
 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: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
 phco...@gmail.com 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
  phco...@gmail.com 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] [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 phco...@gmail.com
 Date:   Wed Oct 8 21:18:31 2014 +0200

 amdfam14: Switch to per-device ACPI
 
 Change-Id: Icc663c28713f2d872bfeb1749303ce92db953bf5
 Signed-off-by: Vladimir Serbinenko phco...@gmail.com
 ---
  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] 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] 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] 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]

 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]

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] 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: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] [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 kra...@redhat.com
 ---
  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 linux/kernel.h
 +#include linux/slab.h
 +#include linux/mm.h
 +#include linux/screen_info.h
 +#include linux/platform_device.h
 +#include linux/platform_data/simplefb.h
 +#include video/vga.h
 +
 +#include asm/checksum.h
 +#include asm/io.h
 +#include asm/sysfb.h
 +
 +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 = 

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
 coreb...@guylhem.net 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 phco...@gmail.com mailto:phco...@gmail.com wrote:
 
 On 25.08.2014 22 tel:25.08.2014%2022: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.
 
 
 




signature.asc
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
http

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=30t=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/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] 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 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] 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 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] 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] 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
 gnu...@no-log.org 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: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] 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] 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 07:45, Stefan Reinauer wrote:
 * Andrew Wu andrewwu...@gmail.com [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] [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] 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 02:33, Stefan Reinauer wrote:
 * David Hubbard david.c.hubbard+coreb...@gmail.com [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 25.03.2014 06:34, ron minnich wrote:
 
 
 
 On Mon, Mar 24, 2014 at 10:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko
 phco...@gmail.com 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 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] 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 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] [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] 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 dhend...@google.com 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 lex...@gmail.com 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] 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] 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
 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: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
 phco...@gmail.com 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
  phco...@gmail.com 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
   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 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] 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] [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] 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] 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 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] Building a Thinkpad X230 coreboot image

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 17.03.2014 20:39, Grim Schjetne wrote:
 Bernie Innocenti ber...@codewiz.org 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] [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]

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