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]

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

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

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

[coreboot] AMD Geode LX 800 and the CS5536

[Vladimir Alexeev]

Greets to COREBOOT!

Please help me!

I have a motherboard from unknown manufacturer based on the AMD Geode
LX 800 and the CS5536 with Winbond W83627HG
And the ROM BIOS of this motherboard are broken. Could you send me the
binary IMAGE of ROM BIOS for my motherboard?
I hope this image help me return my motherboard to life.

If have this binary image. Or if u have the any compatible binary
image from COREBOOT project for use with HARDWARE FLASH PROGRAMMER.
My FLASH ROM chip are M50FLW040A-K5

The IBASE IB520 system board are very similar to my.
http://www.ibase-i.com.tw/ib520.htm

I can't find any BIOS on the internet. Please, someone - help me with
my problem.

Wbr, Vladimir.

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

[coreboot] AMD Geode LX 800 and the CS5536

[Vladimir Alexeev]

oh-ho-hohhh this words sounds like a judgement sentence for my hardware...

please, please do something =) i can't watch my motherboard
she absolutly dead... i can't see that.

why? why she not supported? southbridge, main chipset and super i/o
chip are similar

2009/8/20 Myles Watson myle...@gmail.com:
 I have a motherboard from unknown manufacturer based on the AMD Geode
 LX 800 and the CS5536 with Winbond W83627HG
 We don't have your board supported.  We have several similar boards
 with the Geode LX, cs5536, and w83627hf.
 digitallogic/msm800sev
 amd/db800
 pcengines/alix1c
 iei/pcisa-lx-800-r10

 It would probably take some work on your part and some trial and
 error, but it would be doable to port Coreboot to your board.

 Myles


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

Re: [coreboot] AMD Geode LX 800 and the CS5536

[Vladimir Alexeev]

Yes, this board work with current BIOS. But this BIOS is fully
propretary. I can't to log in BIOS Setup.
Some strings in the image sign to GENERAL SOFTWARE (www.gensw.com) but
their site are closed.

Current BIOS are fully closed. I can post it if someone have a time
for this rubbish - do not spend the time on this.

I hope that codebase of coreboot project help me to understand how
System BIOS works. But i think my current skills not sufficient.

Myles, Ron, Carl-Danial
Big thanks for you time and tips

Keep on rockin! =)
I belive in the Coreboot. It's a great project!

2009/8/27 Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net:
 Hi Vladimir,

 does the board work with the current BIOS?

 In general, it is recommended to use v3 for all GeodeLX targets.

 Regards,
 Carl-Daniel

 --
 http://www.hailfinger.org/



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

Re: [coreboot] AMD Geode LX 800 and the CS5536

[Vladimir Alexeev]

I'm check their mail server via DNS records for gensw.com and the
result is negative.
No mail server registred for this domain. This is realy bad. Seems to
be thier company are closed for contacts via email.

Global crysis must be to eat the GENERAL SOFTWARE.

I'm try to boot linux on this motherboard. But currently without any success.

Myles, Ron thanks for ideas and datasheet for WINBOND W83627HG

I'm checked (with Multimeter turned on resistance meter) the circuits
beetwen COM1 DB-9 coonnectors and PINS number 53 and 54 (Serial Input
 Output for COM/UART A) on the W83627HG.
The reuslt is my COM1 is connected to W83627HG:
DB-9 pin 2 to W83627HG pin 53 - 9kOm
DB-9 pin 3 to W83627HG pin 54 - tester not indicate Resistance, but
i'm not shure that must be.

Motherboard doesn't have any PCI slot for POST card.

How do you thinks - it's possible to do something?


2009/8/28 Gregg C Levine hansolofal...@worldnet.att.net:
 Hello!
 I just checked your facts, Vladimir, regarding General Software at

 http://www.gensw.com and indeed that spot is holding a landing page. (That

 means that the domain is there but no content is available.)

 For me this is sad news as I was a great fan of their embedded DOS.
 However, can you tell us who it is who made the board you are having issues
 with? This might be a big help.

 And of course the usual requests:
 Can you boot into Linux to do an lspci, etc?  That would be helpful.

  lspci -tvnn
  superiotool -dV
  flashrom -V 
 --
 Gregg C Levine hansolofal...@worldnet.att.net
 The Force will be with you always. Obi-Wan Kenobi



 -Original Message-
 From: coreboot-bounces+hansolofalcon=worldnet.att@coreboot.org
 [mailto:coreboot-
 bounces+hansolofalcon=worldnet.att@coreboot.org] On Behalf Of Myles
 Watson
 Sent: Thursday, August 27, 2009 4:00 PM
 To: 'Vladimir Alexeev'
 Cc: coreboot@coreboot.org
 Subject: Re: [coreboot] AMD Geode LX 800 and the CS5536


  Yes, this board work with current BIOS. But this BIOS is fully
  propretary. I can't to log in BIOS Setup.
  Some strings in the image sign to GENERAL SOFTWARE (www.gensw.com) but
  their site are closed.
 Can you boot into Linux to do an lspci, etc?  That would be helpful.

 lspci -tvnn
 superiotool -dV
 flashrom -V

 Thanks,
 Myles


 --
 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] AMD Geode LX 800 and the CS5536

[Vladimir Alexeev]

hmm...
realy on another part of internet, from another host i have

srv1# host gensw.com
gensw.com has address 216.227.217.181
gensw.com mail is handled (pri=10) by twn-mta.phoenix.com
gensw.com mail is handled (pri=5) by scl-mta.phoenix.com


but from my network host (1) returns error.

sorry for my mistakes.


2009/8/28 Stefan Reinauer ste...@coresystems.de:
 On 8/28/09 11:41 AM, Vladimir Alexeev wrote:
 I'm check their mail server via DNS records for gensw.com and the
 result is negative.
 No mail server registred for this domain. This is realy bad. Seems to
 be thier company are closed for contacts via email.

 Seems Phoenix got 'em:

 $ host gensw.com
 gensw.com has address 216.227.217.181
 gensw.com mail is handled by 5 scl-mta.phoenix.com.
 gensw.com mail is handled by 10 twn-mta.phoenix.com.


 --
 coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
 Email: i...@coresystems.de  • http://www.coresystems.de/
 Registergericht: Amtsgericht Freiburg • HRB 7656
 Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866



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

[coreboot] Winbond W83627 HG revision request

[Vladimir Alexeev]

Greets!

Can anyone make support for Winbond W83627-based microcontroller for
HG revision this chip under AMD Geode LX generic motherboard.
Or if can anyone make a patch for early blind initialization UART A
port for debug output?

wbr, Vladimir

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

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] 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] grub payload fails on coreboot

[Vladimir 'φ-coder/phcoder' Serbinenko]

Andreas B. Mundt wrote:
 Dear list,

 after some time of absence from the coreboot list and latest
 development I tried to compile coreboot for m57sli (Revision: 5043)
 which works fine with seabios but it failed with grub as payload
 (revno: 2107, following http://grub.enbug.org/CoreBoot).

 The last messages observed on the serial console are: 

 [...]
 Jumping to boot code at 8200
 entry= 0x8200
 lb_start = 0x0010
 lb_size  = 0x0004a000
 adjust   = 0xbfea6000
 buffer   = 0xbff5c000
  elf_boot_notes = 0x0012f960
 adjusted_boot_notes = 0xbffd5960

 This behavior has also been shortly discussed in:

 http://www.coreboot.org/pipermail/coreboot/2009-July/050977.html

 and from the mailing list it looks to me as if nobody else uses grub
 as payload anymore. Is this correct? If not, any help is appreciated.

 I attach the full serial console log and cc the grub list, perhaps
 someone there is also interested in getting it running. 

   
Is your coreboot compiled with multiboot support?
 Cheers,

   Andi 
   
 

 ___
 Grub-devel mailing list
 grub-de...@gnu.org
 http://lists.gnu.org/mailman/listinfo/grub-devel


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko




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

Re: [coreboot] [PATCH] Fix coreboot qemu RAM size detection

[Vladimir 'φ-coder/phcoder' Serbinenko]

Stefan Reinauer wrote:
 On 5/2/10 5:00 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
 Hello, when testing on QEMU I noticed that it always assumed 64 MiB RAM.
 Fix attached. Tested from 16 MiB to 2047 MiB

   
 Hi Vladimir,

 please sign off your patch so we can commit it:

 http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure

This patch is done by me based on info retrieved from
grub-as-qemu-firmware. The chunk which contained the needed info was 4
lines long. So it's not copyright-significant. Since this patch is small
I hereby give up my copyright on it and release it to public domain.
Signed-off-by: Valdimir 'φ-coder' Serbinenko phco...@gmail.com

 Thanks,
 Stefan


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko




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

Re: [coreboot] spkmodem

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 18.01.2013 12:01, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

 Hello, all. I send a patch to make coreboot output console using system
 beeper and a corresponding code to interpret those beeps. I publish it
 under GPLv2+ but other licensing arrangements are possible. This was
 very useful to get console on X201 where I have neither serial nor EHCI
 debug.

This would need some improvements as currently it sometimes loses bits
and it causes it to lose sync. I'll think how to do it.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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

Re: [coreboot] spkmodem

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 18.01.2013 17:18, Paul Menzel wrote:

 Am Freitag, den 18.01.2013, 17:12 +0100 schrieb Peter Stuge:
 Vladimir 'φ-coder/phcoder' Serbinenko wrote:
 Hello, all. I send a patch to make coreboot output console using system
 beeper and a corresponding code to interpret those beeps. I publish it
 under GPLv2+ but other licensing arrangements are possible. This was
 very useful to get console on X201 where I have neither serial nor EHCI
 debug.

 I haven't gotten your original email? Weird.
 
 Me neither. Maybe it is stuck in the moderation queue – due to not being
 subscribed during that time or size of the attachment.

I'm subscribed since quite some time and files are just 3K + 5K. Trying
to resend


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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

[coreboot] Fwd: spkmodem

[Vladimir 'φ-coder/phcoder' Serbinenko]

 Original Message 
Subject: spkmodem
Date: Fri, 18 Jan 2013 12:01:15 +0100
From: Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com
To: coreboot@coreboot.org

Hello, all. I send a patch to make coreboot output console using system
beeper and a corresponding code to interpret those beeps. I publish it
under GPLv2+ but other licensing arrangements are possible. This was
very useful to get console on X201 where I have neither serial nor EHCI
debug.
-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

diff --git a/src/console/Kconfig b/src/console/Kconfig
index b1f41de..76864ae 100644
--- a/src/console/Kconfig
+++ b/src/console/Kconfig
@@ -114,6 +114,12 @@ config TTYS0_LCS
 	default 3
 	depends on CONSOLE_SERIAL8250 || CONSOLE_SERIAL8250MEM
 
+config SPKMODEM
+	bool Spkmodem (console on speaker) console output
+	default n
+	help
+	  Send coreboot debug output through speaker
+
 # Use select HAVE_USBDEBUG on southbridges which have Debug Port code.
 config HAVE_USBDEBUG
 	def_bool n
diff --git a/src/console/Makefile.inc b/src/console/Makefile.inc
index 3c4777f..5e120c9 100644
--- a/src/console/Makefile.inc
+++ b/src/console/Makefile.inc
@@ -16,6 +16,7 @@ romstage-y += die.c
 
 ramstage-$(CONFIG_CONSOLE_SERIAL8250) += uart8250_console.c
 ramstage-$(CONFIG_CONSOLE_SERIAL8250MEM) += uart8250mem_console.c
+ramstage-$(CONFIG_SPKMODEM) += spkmodem_console.c
 ramstage-$(CONFIG_USBDEBUG) += usbdebug_console.c
 ramstage-$(CONFIG_CONSOLE_LOGBUF) += logbuf_console.c
 ramstage-$(CONFIG_CONSOLE_NE2K) += ne2k_console.c
diff --git a/src/console/spkmodem_console.c b/src/console/spkmodem_console.c
new file mode 100644
index 000..ccebc0a
--- /dev/null
+++ b/src/console/spkmodem_console.c
@@ -0,0 +1,141 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2003 Eric Biederman
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include console/console.h
+#include arch/io.h
+
+#define SPEAKER_PIT_FREQUENCY		0x1234dd
+
+
+enum {
+	PIT_COUNTER_0 = 0x40,
+	PIT_COUNTER_1 = 0x41,
+	PIT_COUNTER_2 = 0x42,
+	PIT_CTRL = 0x43,
+	PIT_SPEAKER_PORT = 0x61,
+};
+
+
+enum {
+	PIT_SPK_TMR2 = 0x01,
+	PIT_SPK_DATA = 0x02,
+	PIT_SPK_TMR2_LATCH = 0x20
+};
+
+enum {
+	PIT_CTRL_SELECT_MASK = 0xc0,
+	PIT_CTRL_SELECT_0 = 0x00,
+	PIT_CTRL_SELECT_1 = 0x40,
+	PIT_CTRL_SELECT_2 = 0x80,
+
+	PIT_CTRL_READLOAD_MASK= 0x30,
+	PIT_CTRL_COUNTER_LATCH = 0x00,
+	PIT_CTRL_READLOAD_LSB = 0x10,
+	PIT_CTRL_READLOAD_MSB = 0x20,
+	PIT_CTRL_READLOAD_WORD = 0x30,
+
+	PIT_CTRL_MODE_MASK = 0x0e,
+	PIT_CTRL_INTR_ON_TERM = 0x00,
+	PIT_CTRL_PROGR_ONE_SHOT = 0x02,
+
+	PIT_CTRL_RATE_GEN = 0x04,
+
+	PIT_CTRL_SQUAREWAVE_GEN = 0x06,
+	PIT_CTRL_SOFTSTROBE = 0x08,
+
+	PIT_CTRL_HARDSTROBE = 0x0a,
+
+
+	PIT_CTRL_COUNT_MASK = 0x01,
+	PIT_CTRL_COUNT_BINARY = 0x00,
+	PIT_CTRL_COUNT_BCD = 0x01
+};
+
+static void
+make_tone (uint16_t freq_count, unsigned int duration)
+{
+	outb (PIT_CTRL_SELECT_2
+		   | PIT_CTRL_READLOAD_WORD
+		   | PIT_CTRL_SQUAREWAVE_GEN
+		   | PIT_CTRL_COUNT_BINARY, PIT_CTRL);
+	outb (freq_count  0xff, PIT_COUNTER_2);
+	outb ((freq_count  8)  0xff, PIT_COUNTER_2);
+
+	outb (inb (PIT_SPEAKER_PORT)
+		   | PIT_SPK_TMR2 | PIT_SPK_DATA,
+		   PIT_SPEAKER_PORT);
+
+	for (; duration; duration--) {
+		unsigned short counter, previous_counter = 0x;
+		while (1) {
+			counter = inb (PIT_COUNTER_2);
+			counter |= ((uint16_t) inb (PIT_COUNTER_2))  8;
+			if (counter  previous_counter)
+			{
+previous_counter = counter;
+break;
+			}
+			previous_counter = counter;
+		}
+	}
+}
+
+static void spkmodem_init(void)
+{
+	/* Some models shutdown sound when not in use and it takes for it
+	   around 30 ms to come back on which loses 3 bits. So generate a base
+	   50 Hz continously. */
+	make_tone (SPEAKER_PIT_FREQUENCY / 50, 20);
+}
+
+static void spkmodem_tx_byte(unsigned char c)
+{
+	int i;
+
+	for (i = 7; i = 0; i--) {
+		if ((c  i)  1)
+			make_tone (SPEAKER_PIT_FREQUENCY / 2000, 20);
+		else
+			make_tone (SPEAKER_PIT_FREQUENCY / 4000, 40);
+		make_tone (SPEAKER_PIT_FREQUENCY / 1000, 10);
+	}
+	make_tone (SPEAKER_PIT_FREQUENCY / 50, 0);
+}
+
+static void spkmodem_tx_flush(void)
+{
+}
+
+static unsigned char spkmodem_rx_byte(void)
+{
+	return 0;
+}
+
+static int spkmodem_tst_byte(void)
+{
+	return 0;
+}
+
+static const struct console_driver spkmodem_console __console = {
+	.init = spkmodem_init

Re: [coreboot] spkmodem

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 18.01.2013 17:12, Peter Stuge wrote:

 Vladimir 'φ-coder/phcoder' Serbinenko wrote:
 Hello, all. I send a patch to make coreboot output console using system
 beeper and a corresponding code to interpret those beeps. I publish it
 under GPLv2+ but other licensing arrangements are possible. This was
 very useful to get console on X201 where I have neither serial nor EHCI
 debug.
 
 I haven't gotten your original email? Weird.
 
 
 This would need some improvements as currently it sometimes loses
 bits and it causes it to lose sync. I'll think how to do it.
 
 What modulation and symbol rate are you using?
 

custom FSK variant at 10ms per bit. I'll just introduce a 5ms tone to
split bytes.

 
 //Peter
 
 
 



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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

[coreboot] spkmodem

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello, all. I send a patch to make coreboot output console using system
beeper and a corresponding code to interpret those beeps. I publish it
under GPLv2+ but other licensing arrangements are possible. This was
very useful to get console on X201 where I have neither serial nor EHCI
debug.
-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
diff --git a/src/console/Kconfig b/src/console/Kconfig
index b1f41de..76864ae 100644
--- a/src/console/Kconfig
+++ b/src/console/Kconfig
@@ -114,6 +114,12 @@ config TTYS0_LCS
 	default 3
 	depends on CONSOLE_SERIAL8250 || CONSOLE_SERIAL8250MEM
 
+config SPKMODEM
+	bool Spkmodem (console on speaker) console output
+	default n
+	help
+	  Send coreboot debug output through speaker
+
 # Use select HAVE_USBDEBUG on southbridges which have Debug Port code.
 config HAVE_USBDEBUG
 	def_bool n
diff --git a/src/console/Makefile.inc b/src/console/Makefile.inc
index 3c4777f..5e120c9 100644
--- a/src/console/Makefile.inc
+++ b/src/console/Makefile.inc
@@ -16,6 +16,7 @@ romstage-y += die.c
 
 ramstage-$(CONFIG_CONSOLE_SERIAL8250) += uart8250_console.c
 ramstage-$(CONFIG_CONSOLE_SERIAL8250MEM) += uart8250mem_console.c
+ramstage-$(CONFIG_SPKMODEM) += spkmodem_console.c
 ramstage-$(CONFIG_USBDEBUG) += usbdebug_console.c
 ramstage-$(CONFIG_CONSOLE_LOGBUF) += logbuf_console.c
 ramstage-$(CONFIG_CONSOLE_NE2K) += ne2k_console.c
diff --git a/src/console/spkmodem_console.c b/src/console/spkmodem_console.c
new file mode 100644
index 000..ccebc0a
--- /dev/null
+++ b/src/console/spkmodem_console.c
@@ -0,0 +1,141 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2003 Eric Biederman
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include console/console.h
+#include arch/io.h
+
+#define SPEAKER_PIT_FREQUENCY		0x1234dd
+
+
+enum {
+	PIT_COUNTER_0 = 0x40,
+	PIT_COUNTER_1 = 0x41,
+	PIT_COUNTER_2 = 0x42,
+	PIT_CTRL = 0x43,
+	PIT_SPEAKER_PORT = 0x61,
+};
+
+
+enum {
+	PIT_SPK_TMR2 = 0x01,
+	PIT_SPK_DATA = 0x02,
+	PIT_SPK_TMR2_LATCH = 0x20
+};
+
+enum {
+	PIT_CTRL_SELECT_MASK = 0xc0,
+	PIT_CTRL_SELECT_0 = 0x00,
+	PIT_CTRL_SELECT_1 = 0x40,
+	PIT_CTRL_SELECT_2 = 0x80,
+
+	PIT_CTRL_READLOAD_MASK= 0x30,
+	PIT_CTRL_COUNTER_LATCH = 0x00,
+	PIT_CTRL_READLOAD_LSB = 0x10,
+	PIT_CTRL_READLOAD_MSB = 0x20,
+	PIT_CTRL_READLOAD_WORD = 0x30,
+
+	PIT_CTRL_MODE_MASK = 0x0e,
+	PIT_CTRL_INTR_ON_TERM = 0x00,
+	PIT_CTRL_PROGR_ONE_SHOT = 0x02,
+
+	PIT_CTRL_RATE_GEN = 0x04,
+
+	PIT_CTRL_SQUAREWAVE_GEN = 0x06,
+	PIT_CTRL_SOFTSTROBE = 0x08,
+
+	PIT_CTRL_HARDSTROBE = 0x0a,
+
+
+	PIT_CTRL_COUNT_MASK = 0x01,
+	PIT_CTRL_COUNT_BINARY = 0x00,
+	PIT_CTRL_COUNT_BCD = 0x01
+};
+
+static void
+make_tone (uint16_t freq_count, unsigned int duration)
+{
+	outb (PIT_CTRL_SELECT_2
+		   | PIT_CTRL_READLOAD_WORD
+		   | PIT_CTRL_SQUAREWAVE_GEN
+		   | PIT_CTRL_COUNT_BINARY, PIT_CTRL);
+	outb (freq_count  0xff, PIT_COUNTER_2);
+	outb ((freq_count  8)  0xff, PIT_COUNTER_2);
+
+	outb (inb (PIT_SPEAKER_PORT)
+		   | PIT_SPK_TMR2 | PIT_SPK_DATA,
+		   PIT_SPEAKER_PORT);
+
+	for (; duration; duration--) {
+		unsigned short counter, previous_counter = 0x;
+		while (1) {
+			counter = inb (PIT_COUNTER_2);
+			counter |= ((uint16_t) inb (PIT_COUNTER_2))  8;
+			if (counter  previous_counter)
+			{
+previous_counter = counter;
+break;
+			}
+			previous_counter = counter;
+		}
+	}
+}
+
+static void spkmodem_init(void)
+{
+	/* Some models shutdown sound when not in use and it takes for it
+	   around 30 ms to come back on which loses 3 bits. So generate a base
+	   50 Hz continously. */
+	make_tone (SPEAKER_PIT_FREQUENCY / 50, 20);
+}
+
+static void spkmodem_tx_byte(unsigned char c)
+{
+	int i;
+
+	for (i = 7; i = 0; i--) {
+		if ((c  i)  1)
+			make_tone (SPEAKER_PIT_FREQUENCY / 2000, 20);
+		else
+			make_tone (SPEAKER_PIT_FREQUENCY / 4000, 40);
+		make_tone (SPEAKER_PIT_FREQUENCY / 1000, 10);
+	}
+	make_tone (SPEAKER_PIT_FREQUENCY / 50, 0);
+}
+
+static void spkmodem_tx_flush(void)
+{
+}
+
+static unsigned char spkmodem_rx_byte(void)
+{
+	return 0;
+}
+
+static int spkmodem_tst_byte(void)
+{
+	return 0;
+}
+
+static const struct console_driver spkmodem_console __console = {
+	.init = spkmodem_init,
+	.tx_byte  = spkmodem_tx_byte,
+	.tx_flush = spkmodem_tx_flush,
+	.rx_byte  = spkmodem_rx_byte,
+	.tst_byte = spkmodem_tst_byte,
+};
/* spkmodem-recv.c - decode spkmodem signals

[coreboot] [PATCH v2] spkmodem

[Vladimir 'φ-coder/phcoder' Serbinenko]

A new version of spkmodem. This one doesn't lose the bit sync even if I
disconnect the cable for the short time (but, of course data sent when
no cable is attached is lost)
-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
diff --git a/src/console/Kconfig b/src/console/Kconfig
index b1f41de..76864ae 100644
--- a/src/console/Kconfig
+++ b/src/console/Kconfig
@@ -114,6 +114,12 @@ config TTYS0_LCS
default 3
depends on CONSOLE_SERIAL8250 || CONSOLE_SERIAL8250MEM
 
+config SPKMODEM
+   bool Spkmodem (console on speaker) console output
+   default n
+   help
+ Send coreboot debug output through speaker
+
 # Use select HAVE_USBDEBUG on southbridges which have Debug Port code.
 config HAVE_USBDEBUG
def_bool n
diff --git a/src/console/Makefile.inc b/src/console/Makefile.inc
index 3c4777f..5e120c9 100644
--- a/src/console/Makefile.inc
+++ b/src/console/Makefile.inc
@@ -16,6 +16,7 @@ romstage-y += die.c
 
 ramstage-$(CONFIG_CONSOLE_SERIAL8250) += uart8250_console.c
 ramstage-$(CONFIG_CONSOLE_SERIAL8250MEM) += uart8250mem_console.c
+ramstage-$(CONFIG_SPKMODEM) += spkmodem_console.c
 ramstage-$(CONFIG_USBDEBUG) += usbdebug_console.c
 ramstage-$(CONFIG_CONSOLE_LOGBUF) += logbuf_console.c
 ramstage-$(CONFIG_CONSOLE_NE2K) += ne2k_console.c
diff --git a/src/console/spkmodem_console.c b/src/console/spkmodem_console.c
new file mode 100644
index 000..f90dc68
--- /dev/null
+++ b/src/console/spkmodem_console.c
@@ -0,0 +1,143 @@
+/*
+ * This file is part of the coreboot project.
+ *
+ * Copyright (C) 2013 Vladimir Serbinenko
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include console/console.h
+#include arch/io.h
+
+#define SPEAKER_PIT_FREQUENCY  0x1234dd
+
+
+enum {
+   PIT_COUNTER_0 = 0x40,
+   PIT_COUNTER_1 = 0x41,
+   PIT_COUNTER_2 = 0x42,
+   PIT_CTRL = 0x43,
+   PIT_SPEAKER_PORT = 0x61,
+};
+
+
+enum {
+   PIT_SPK_TMR2 = 0x01,
+   PIT_SPK_DATA = 0x02,
+   PIT_SPK_TMR2_LATCH = 0x20
+};
+
+enum {
+   PIT_CTRL_SELECT_MASK = 0xc0,
+   PIT_CTRL_SELECT_0 = 0x00,
+   PIT_CTRL_SELECT_1 = 0x40,
+   PIT_CTRL_SELECT_2 = 0x80,
+
+   PIT_CTRL_READLOAD_MASK= 0x30,
+   PIT_CTRL_COUNTER_LATCH = 0x00,
+   PIT_CTRL_READLOAD_LSB = 0x10,
+   PIT_CTRL_READLOAD_MSB = 0x20,
+   PIT_CTRL_READLOAD_WORD = 0x30,
+
+   PIT_CTRL_MODE_MASK = 0x0e,
+   PIT_CTRL_INTR_ON_TERM = 0x00,
+   PIT_CTRL_PROGR_ONE_SHOT = 0x02,
+
+   PIT_CTRL_RATE_GEN = 0x04,
+
+   PIT_CTRL_SQUAREWAVE_GEN = 0x06,
+   PIT_CTRL_SOFTSTROBE = 0x08,
+
+   PIT_CTRL_HARDSTROBE = 0x0a,
+
+
+   PIT_CTRL_COUNT_MASK = 0x01,
+   PIT_CTRL_COUNT_BINARY = 0x00,
+   PIT_CTRL_COUNT_BCD = 0x01
+};
+
+static void
+make_tone (uint16_t freq_count, unsigned int duration)
+{
+   outb (PIT_CTRL_SELECT_2
+  | PIT_CTRL_READLOAD_WORD
+  | PIT_CTRL_SQUAREWAVE_GEN
+  | PIT_CTRL_COUNT_BINARY, PIT_CTRL);
+   outb (freq_count  0xff, PIT_COUNTER_2);
+   outb ((freq_count  8)  0xff, PIT_COUNTER_2);
+
+   outb (inb (PIT_SPEAKER_PORT)
+  | PIT_SPK_TMR2 | PIT_SPK_DATA,
+  PIT_SPEAKER_PORT);
+
+   for (; duration; duration--) {
+   unsigned short counter, previous_counter = 0x;
+   while (1) {
+   counter = inb (PIT_COUNTER_2);
+   counter |= ((uint16_t) inb (PIT_COUNTER_2))  8;
+   if (counter  previous_counter)
+   {
+   previous_counter = counter;
+   break;
+   }
+   previous_counter = counter;
+   }
+   }
+}
+
+static void spkmodem_init(void)
+{
+   /* Some models shutdown sound when not in use and it takes for it
+  around 30 ms to come back on which loses 3 bits. So generate a base
+  200 Hz continously. */
+   make_tone (SPEAKER_PIT_FREQUENCY / 200, 0);
+}
+
+static void spkmodem_tx_byte(unsigned char c)
+{
+   int i;
+
+   make_tone (SPEAKER_PIT_FREQUENCY / 200, 4);
+   for (i = 7; i = 0; i--) {
+   if ((c  i)  1)
+   make_tone (SPEAKER_PIT_FREQUENCY / 2000, 20);
+   else

Re: [coreboot] [PATCH v2] spkmodem

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 21.01.2013 15:10, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

 A new version of spkmodem. This one doesn't lose the bit sync even if I
 disconnect the cable for the short time (but, of course data sent when
 no cable is attached is lost)

Did you receive this mail? The attachments in it are of type text/plain
and application/pgp-signature.

-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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

Re: [coreboot] [PATCH v2] spkmodem

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 22.01.2013 20:08, Stefan Reinauer wrote:

 * Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com [130121 15:10]:
 A new version of spkmodem. This one doesn't lose the bit sync even if I
 disconnect the cable for the short time (but, of course data sent when
 no cable is attached is lost)
 -- 
 Regards
 Vladimir 'φ-coder/phcoder' Serbinenko
 
 This is awesome...

Thank you

 Do you also have it working in romstage?

I haven't have an opportunity to test yet but it should be, other than
evtl a problem with build system.

 
 Stefan
 
 



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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

Re: [coreboot] Gerrit problem: Not able to sign in

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 31.01.2013 09:52, Paul Menzel wrote:

 Dear coreboot admins,
 
 
 currently I am not able to sign into Gerrit using my Google Mail
 account.
 
 Not found
 
 The page you requested was not found, or you do not have permission 
 to view this page.
 
 Do you have similar problems?
 
 
 Thanks,
 
 Paul

I have the same problem

 
 
 



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



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

[coreboot] X201 status

[Vladimir 'φ-coder/phcoder' Serbinenko]

Current status.
Raminit: works with delays/printfs currently in place, 1-ranked memory
populating one slot. Didn't test in any other config yet (either
removing debug and delays or trying other type of memory). Looks like
resulting settings are slower than original BIOS due to me skipping some
of advanced training.
EHCI and AHCI work in GRUB shell.
VGA option ROM works
keyboard works.
LAN card doesn't show up in lspci
ACPI tables are visible in GRUB but mysteriously disappear when Linux is
booted (working theory is that some other device got mapped over).
Linux boots into debian netinst (images taken from USB stick).




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

Re: [coreboot] X201 status

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 28.02.2013 22:59, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

 Current status.
 Raminit: works with delays/printfs currently in place, 1-ranked memory
 populating one slot. Didn't test in any other config yet (either
 removing debug and delays or trying other type of memory). Looks like
 resulting settings are slower than original BIOS due to me skipping some
 of advanced training.
 EHCI and AHCI work in GRUB shell.
 VGA option ROM works
 keyboard works.
 LAN card doesn't show up in lspci

Fixed, was corrupted ME firmware.

 ACPI tables are visible in GRUB but mysteriously disappear when Linux is
 booted (working theory is that some other device got mapped over).

The range c-f is still handled by ROM but cached as if it was
RAM. Hence as long as data is still in cache it seems to work but when
it gets flushed I get ROM contents back. Don't know yet how to configure
c-f behaviour

 Linux boots into debian netinst (images taken from USB stick).
 
 





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

[coreboot] X201 port is in gerrit

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello, all. I've pushed my X201 work to gerrit. It also contains
spkmodem and serialice improvements (target-side, like EHCI debug
support). Host-side I attach a small patch to redirect clflush to
target. Code quality is bad but it already works.
Current known issues:
speedstep doesn't work
S3 doesn't work
many ACPI buttons don't work.

Not tested:
dock



diff --git a/qemu-0.15.x/target-i386/helper.h
b/qemu-0.15.x/target-i386/helper.h
index 6b518ad..3c1068a 100644
--- a/qemu-0.15.x/target-i386/helper.h
+++ b/qemu-0.15.x/target-i386/helper.h
@@ -47,6 +47,7 @@ DEF_HELPER_1(lmsw, void, tl)
 DEF_HELPER_0(clts, void)
 DEF_HELPER_2(movl_drN_T0, void, int, tl)
 DEF_HELPER_1(invlpg, void, tl)
+DEF_HELPER_1(clflush, void, tl)

 DEF_HELPER_3(enter_level, void, int, int, tl)
 #ifdef TARGET_X86_64
diff --git a/qemu-0.15.x/target-i386/op_helper.c
b/qemu-0.15.x/target-i386/op_helper.c
index 1823c74..20d8d2d 100644
--- a/qemu-0.15.x/target-i386/op_helper.c
+++ b/qemu-0.15.x/target-i386/op_helper.c
@@ -3053,6 +3053,12 @@ void helper_invlpg(target_ulong addr)
 tlb_flush_page(env, addr);
 }

+void helper_clflush(target_ulong addr)
+{
+if (serialice_active)
+  serialice_handle_clflush ((uint32_t)addr);
+}
+
 void helper_rdtsc(void)
 {
 uint64_t val;
diff --git a/qemu-0.15.x/target-i386/translate.c
b/qemu-0.15.x/target-i386/translate.c
index ccef381..c23585a 100644
--- a/qemu-0.15.x/target-i386/translate.c
+++ b/qemu-0.15.x/target-i386/translate.c
@@ -7551,6 +7551,9 @@ static target_ulong disas_insn(DisasContext *s,
target_ulong pc_start)
 if (!(s-cpuid_features  CPUID_CLFLUSH))
 goto illegal_op;
 gen_lea_modrm(s, modrm, reg_addr, offset_addr);
+   gen_helper_clflush(cpu_A0);
+   gen_jmp_im(s-pc - s-cs_base);
+   gen_eob(s);
 }
 break;
 default:



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

Re: [coreboot] X201 port is in gerrit

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 12.03.2013 16:09, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

 Hello, all. I've pushed my X201 work to gerrit. It also contains
 spkmodem and serialice improvements (target-side, like EHCI debug
 support). Host-side I attach a small patch to redirect clflush to
 target. Code quality is bad but it already works.
 Current known issues:
 speedstep doesn't work
 S3 doesn't work
 many ACPI buttons don't work.

You will also need following blobs:
descriptor + me firmware
VGA BIOS
cpu microcode
All are extractible from original BIOS by using the extract tool I
published previously. cpu_microcode
(UUID=3030435f---ff00-) has a range of ff...ff at
the beginning you have to strip.
VGA UUID is 3030525f---ff00-.
descriptor and me firmware are files 001_descriptor.bin and 002_me.bin

 
 Not tested:
 dock
 
 
 
 diff --git a/qemu-0.15.x/target-i386/helper.h
 b/qemu-0.15.x/target-i386/helper.h
 index 6b518ad..3c1068a 100644
 --- a/qemu-0.15.x/target-i386/helper.h
 +++ b/qemu-0.15.x/target-i386/helper.h
 @@ -47,6 +47,7 @@ DEF_HELPER_1(lmsw, void, tl)
  DEF_HELPER_0(clts, void)
  DEF_HELPER_2(movl_drN_T0, void, int, tl)
  DEF_HELPER_1(invlpg, void, tl)
 +DEF_HELPER_1(clflush, void, tl)
 
  DEF_HELPER_3(enter_level, void, int, int, tl)
  #ifdef TARGET_X86_64
 diff --git a/qemu-0.15.x/target-i386/op_helper.c
 b/qemu-0.15.x/target-i386/op_helper.c
 index 1823c74..20d8d2d 100644
 --- a/qemu-0.15.x/target-i386/op_helper.c
 +++ b/qemu-0.15.x/target-i386/op_helper.c
 @@ -3053,6 +3053,12 @@ void helper_invlpg(target_ulong addr)
  tlb_flush_page(env, addr);
  }
 
 +void helper_clflush(target_ulong addr)
 +{
 +if (serialice_active)
 +  serialice_handle_clflush ((uint32_t)addr);
 +}
 +
  void helper_rdtsc(void)
  {
  uint64_t val;
 diff --git a/qemu-0.15.x/target-i386/translate.c
 b/qemu-0.15.x/target-i386/translate.c
 index ccef381..c23585a 100644
 --- a/qemu-0.15.x/target-i386/translate.c
 +++ b/qemu-0.15.x/target-i386/translate.c
 @@ -7551,6 +7551,9 @@ static target_ulong disas_insn(DisasContext *s,
 target_ulong pc_start)
  if (!(s-cpuid_features  CPUID_CLFLUSH))
  goto illegal_op;
  gen_lea_modrm(s, modrm, reg_addr, offset_addr);
 +   gen_helper_clflush(cpu_A0);
 +   gen_jmp_im(s-pc - s-cs_base);
 +   gen_eob(s);
  }
  break;
  default:
 





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

[coreboot] X201 bootblock unlocking

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello all. On X201 top 192K are locked. Fortunately the original BIOS
has a way to update this region.
If you extract a X201 image you'll find a lzint compressed file which
makes 192K decompressed. It's the update. In it you can simply replace
74f8d1fe (PR0) with 74f8d0ff (harmless address with the same checksum),
recompress, correct checksum, update, reboot and PR0 is inactive. tools
to do all this were posted previously (x201_analyze and
x201_reconstruct) except compressor. You need compressor at least as
performant as original. I attach here my own version which is about 2%
underperformant. If you want to have a try, be my guest
Otherwise I simply use external flashing.
#include algorithm
#include queue
#include stdio.h
#include string.h

using namespace std;

#define MAX_DICBIT13
#define MAX_DICSIZ (1  MAX_DICBIT)
#define NP (MAX_DICBIT + 1)
#define PBIT 4

typedef unsigned char grub_uint8_t;
typedef unsigned short grub_uint16_t;
typedef unsigned long grub_size_t;
typedef signed short grub_int16_t;
typedef unsigned int grub_uint32_t;

#define MAXMATCH 256
#define THRESHOLD  3
#define UCHAR_MAX ((1(sizeof(unsigned char)*8))-1)
#define NC (UCHAR_MAX + MAXMATCH + 2 - THRESHOLD)
#define USHRT_BIT 16
#define NT (USHRT_BIT + 3)
#define TBIT 5

grub_uint8_t *
lzint_compress (grub_uint8_t *src_in, grub_uint8_t *srcend_in);

static int
count_sim (grub_uint8_t *a, grub_uint8_t *b, grub_size_t lim)
{
  grub_size_t i;
  for (i = 0; i  lim  i  MAXMATCH; i++)
if (a[i] != b[i])
  break;
  return i;
}

struct freq_node
{
  grub_uint16_t val;
  struct freq_node *left;
  unsigned idx;
  struct freq_node *right;

  const int operator  (const struct freq_node b)
const
  {
return this-val  b.val;
  }
};

struct code_elem
{
  int len;
  grub_uint32_t val;
};

static void
process_node (grub_uint32_t c, int depth, freq_node *n, grub_uint32_t *codeword, int target_depth,
	  priority_queue unsigned, vector unsigned, greater unsigned  q)
{
  if (n-right)
{
  process_node (c  1, depth + 1, n-left, codeword, target_depth, q);
  process_node ((c  1) | 1, depth + 1, n-right, codeword, target_depth, q);
  return;
}
  if (depth != target_depth)
return;
  q.push (n-idx);
}

static int
get_max_depth (freq_node *n)
{
  if (n-right)
return max (get_max_depth (n-left), get_max_depth (n-right)) + 1;
  return 0;
}

static struct code_elem *
construct_code (grub_uint16_t *freq, grub_size_t sz)
{
  grub_size_t i;
  priority_queue freq_node, vector freq_node, greater freq_node  pq;
  freq_node r;
  struct code_elem *ret;
  grub_uint32_t codeword = 0;
  int md;

  for (i = 0; i  sz; i++)
if (freq[i])
  {
	freq_node node;
	node.val = freq[i];
	node.idx = i;
	node.left = 0;
	node.right = 0;
	pq.push (node);
  }
  if (pq.size () == 0)
{
  ret = (code_elem *) malloc (sz * sizeof (ret[0]));
  memset (ret, 0, sz * sizeof (ret[0]));
  return ret;
}

  while (pq.size () = 2)
{
  freq_node a = pq.top (), *aa;
  pq.pop ();
  freq_node b = pq.top (), *bb;
  freq_node n;
  pq.pop ();
  n.left = (freq_node *) malloc (sizeof (a));
  n.right = (freq_node *) malloc (sizeof (b));
  n.val = a.val + b.val;
  if (a.idx  b.idx)
	{
	  *n.left = a;
	  *n.right = b;
	}
  else
	{
	  *n.left = b;
	  *n.right = a;
	}
  n.idx = n.left-idx;
  pq.push (n);
}
  r = pq.top ();
  ret = (code_elem *) malloc (sz * sizeof (ret[0]));
  memset (ret, 0, sz * sizeof (ret[0]));
  md = get_max_depth (r) + 1;
  for (i = 0; i  md; i++)
{
  priority_queue unsigned, vector unsigned, greater unsigned  q;
  process_node (0, 0, r, codeword, i, q);
  while (!q.empty ())
	{
	  unsigned id = q.top ();
	  q.pop ();
	  ret[id].len = i;
	  ret[id].val = codeword;
	  codeword++;
	}
  codeword = 1;
}
  return ret;
}

struct outbuf
{
  grub_uint8_t *ptr;
  grub_uint8_t *s;
  int bitn;
};

static void
write_bits (struct outbuf *out, grub_uint16_t val, int sz)
{
  while (sz--)
{
  if (val  (1  sz))
	*out-ptr |= out-bitn;
  if (out-bitn != 1)
	out-bitn = 1;
  else
	{
	  out-ptr++;
	  out-bitn = 0x80;
	}
}
}

static void
write_p_code (struct code_elem *code, grub_size_t sz, struct outbuf *out,
	  int nbit, int i_special, int li)
{
  int last, i;
  for (last = sz - 1; last = 0; last--)
if (code[last].len)
  break;
  write_bits (out, last + 1, nbit);
  if (last == -1)
{
  write_bits (out, li, nbit);
  return;
}

  for (i = 0; i = last; i++)
{
  if (code[i].len  7)
	{
	  write_bits (out, code[i].len, 3);
	}
  else
	{
	  write_bits (out, ~0, code[i].len - 4);
	  write_bits (out, 0, 1);
	}

  if (i == i_special)
	{
	  int c = 0;
	  while (i + 1 = last  c  3  code[i + 1].len == 0)
	i++, c++;
	  write_bits (out, c, 2);
	}
}
}


static int
get_highest_bit (grub_uint16_t v)
{
  int i;
  for (i = 15; i= 0; i--)
if (v  (1  i))
  break;
  return i;
}

static void
write_c_code 

Re: [coreboot] On loongson CPU or MIPS ARCH

[Vladimir 'φ-coder/phcoder' Serbinenko]

 do we have plan to add loongson CPU or MIPS ARCH support?
 

Loongson platforms are very different from any x86 boards. I believe
that coreboot in this case would get more in the way than help. I ported
GRUB to be firmware on Yeloong 2F and Fuloong 2F. Everything coreboot
does on x86 including video init holds under 1000 lines of assembly code
for yeeloong. See fwstart.S in GRUB tree.
What is your goal? Can we perhaps adapt GRUB to your needs?

 There is no plan that I know of.
 
 It seems no person from loongson contribute to this,
 and can I try to make some efforts on this topic?
 
 I guess people contributing stuff are always welcome. Though I have no
 experience with loongson and MIPS, so I cannot comment how feasible this
 is.
 
 
 Thanks,
 
 Paul
 
 
 ¹ Is that your first name?
 
 
 PS: You should probably subscribe to the coreboot list, so your message
 are not delivered with a delay.
 
 
 





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

Re: [coreboot] On loongson CPU or MIPS ARCH

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 26.04.2013 23:07, ron minnich wrote:

 I'll look at that code.
 

As a side note: fwstart.S inits video on yeeloong, this was done so
because I was under impression that watchdog was conditioned on video
init while in fact I applied wrong GPIO map. It stayed this way but
doesn't have to be so.

Also if there is enough interest I'm willing to consider detaching init
code in a way reusable by other payloads as long as it doesn't incur
maintainance time on me.

 ron
 





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

Re: [coreboot] On loongson CPU or MIPS ARCH

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 29.04.2013 03:18, li guang wrote:

 在 2013-04-26五的 22:08 +0200，Vladimir 'φ-coder/phcoder' Serbinenko写
 道：


 do we have plan to add loongson CPU or MIPS ARCH support?


 Loongson platforms are very different from any x86 boards. I believe
 that coreboot in this case would get more in the way than help. I ported
 GRUB to be firmware on Yeloong 2F and Fuloong 2F. Everything coreboot
 does on x86 including video init holds under 1000 lines of assembly code
 for yeeloong. See fwstart.S in GRUB tree.
 What is your goal? Can we perhaps adapt GRUB to your needs?
 
 First step is to boot a platform based on loongson 2E, so I have to
 at least port CPU start up code, bonito and vt82c686(seems done in
 coreboot) init code.
 

But what is the bigger picture? Don't get me wrong, coreboot is great
for x86 but for loongson its init framework is somewhat overkill and
initing naively is more appropriate. What do you think to use as
payload? You need something as GRUB for it since the chip is too small
to hold a kernel anyway.
You can already load GRUB from pmon on fuloong 2E so you can get an
idea. I myself don't have a 2E system so as-firmware port was never done.



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

Re: [coreboot] On loongson CPU or MIPS ARCH

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 29.04.2013 04:09, ron minnich wrote:

 not everyone wants or needs grub. So that's part of the point.

Could we have a sane discussion about why it's not suitable for this or
that scenario and what would need to be fixed? Not just quasi-fanatical
I don't want it.



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

Re: [coreboot] On loongson CPU or MIPS ARCH

[Vladimir 'φ-coder/phcoder' Serbinenko]

 Yes, I'm querying coreboot for the similar consideration.
 Is payload indispensable?
 can we directly load kernel image?

Not in the tiny ROM available on this machine (512KiB). And 512K is
absolute maximum you can put on it (parallel flash)




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

Re: [coreboot] On loongson CPU or MIPS ARCH

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 29.04.2013 04:48, Peter Stuge wrote:

 Vladimir 'φ-coder/phcoder' Serbinenko wrote:
 not everyone wants or needs grub. So that's part of the point.

 Could we have a sane discussion about why it's not suitable
 
 IMO it's a clusterfuck as far as usability is concerned for one. But
 this isn't the GRUB mailing list, so actually it's wholly
 inappropriate to discuss GRUB any further here. If someone
 wants to continue discussing with Vladimir please do so off list.
 

The thing is that coreboot is useless without some kind of payload. The
bigggest part of effort of making coreboot-based firmware work on
Loongson is porting the payload as the job of coreboot on this platform
is reduced to mere 1000-2000 lines. At this the payload could simply be
linked with fwstart.S and I was going to propose sharing this code with
the other payload if other payload is willing to port and maintain
Loongson. But for this I need the answers to questions I asked and
everybody avoids answering.



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

Re: [coreboot] On loongson CPU or MIPS ARCH

[Vladimir 'φ-coder/phcoder' Serbinenko]

 Loongson platform be designed mostly like a PC, it also control PCI

 devices.
 

It has just one PCI bus with all devices fixed. That hardly requires the
whole complexity of coreboot.

 because of the payload
 concept, where coreboot only initializes only the minimum of the
 hardware and a payload, like SeaBIOS, FILO and GRUB, can take over.
 
 I'm not quite clear about code flow between bootblock and payload
 for now, so, is there some document about it?
 or can you give some hints for code flow?

It's simple: coreboot does hardware init, bringing devices to usable
state. Payload does everything else.



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

[coreboot] Coreboot hackathon hardware

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello, all. I'll be at LinuxTAG and hackathon. This mail is to ask if
someone needs some of hw I can take with me (list at the end), I won't
take it unless I have requests.
Does anybody want to share rooms to save on hotel costs?

HW List:
PL2303 USB-RS232 converter
bus pirate
2 SOIC 8-pin clips
Raspberry Pie
Thinkpad X201 (coreboot)
USB rollable keyboard
cables of all kind
NET20DC USBdebug
gear for network
USB wireless
USB 3G modems
Thinkpad X230 (my next port)
Asus A8N-E (corebootable)
PLCC32 parallel flash chips
PLCC32 FWH/LPC chips
PLCC extractor
Lemote Yeeloong 2F
Lemote Fuloong 2F
Lemote Yeeloong 3A
Apple Powerbook G4

Too big for transport but I can setup SSH in advance if needed: ia64,
alpha, sparc64, SGI Indy, hppa




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

[coreboot] Management engine firmware

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello, all. In order to build X201 rom, you need management engine
firmware. For chromebook the appropriate blobs are in 3rdparty repo, I
suppose supplied by Intel. The only place where I could get ME firmware
for X201 is by dumping chip with external programmer. It's probably not
appropriate for coreboot to distribute those blobs (I'm unsure on their
license) and given that it writes a log to its section which may contain
private data, I don't want to distribute it either. Yet without this
blob the build legitimately fails. Any suggestions on handling this?



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

Re: [coreboot] Management engine firmware

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 13.06.2013 03:41, George Chriss wrote:
 On Wed, Jun 12, 2013 at 7:16 PM, Vladimir 'φ-coder/phcoder' Serbinenko
 phco...@gmail.com mailto:phco...@gmail.com wrote:

 Hello, all. In order to build X201 rom, you need management engine
 firmware. For chromebook the appropriate blobs are in 3rdparty repo, I
 suppose supplied by Intel. The only place where I could get ME firmware
 for X201 is by dumping chip with external programmer. It's probably not
 appropriate for coreboot to distribute those blobs (I'm unsure on their
 license) and given that it writes a log to its section which may contain
 private data, I don't want to distribute it either. Yet without this
 blob the build legitimately fails. Any suggestions on handling this?
 
 Are the coreboot dependencies function calls or something
 hardware-specific?
Coreboot send ME a message to tell it what to use for UMA.
ACPI (at least CPU temperature) also goes through ME even if you read it
from EC.
  Is it possible to build a 'dummy' management engine
 that still boots the X201, even with reduced functionality?
It will reboot or hard lock after 30 minutes
  (Is ME
 binary code executed at any point using coreboot?)
 
No, it's executed on coprocessor, it's in the same flash but coreboot
doesn't have to do anything to load it.
 Sincerely,
 George
 
 
 




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

Re: [coreboot] google/butterfly: Erratic touchpad behavior in cold weather

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 30.11.2013 16:25, mrnuke wrote:
 Have any of you noticed this with the Pavilion 14 Chromebook? You take
 it outside from the warm house, open the lid to resume, and the mouse
 pointer moves heratically. It becomes impossible to co control, and the
 only way to bring it back to sanity is to completely power off. When the
 system comes back on, the issue is gone.
 
My guess would be tiny droplets condensating on touchpad. Water can
confuse capacitative touchpads. By the time you reboot they are frozen
and no longer an issue.I'd try wiping the droplets with tissue.
 Alex
 




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

Re: [coreboot] Lenovo X201i

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 30.11.2013 17:51, Chris Mailer wrote:
 Hello Coreboot,
 
 I would like to play around with Coreboot on a Lenovo X201i convertible
 laptop.
 According to http://www.coreboot.org/Supported_Motherboards#Laptops and
 some wiki-entries Coreboot does do well on the X201. Does this imply
 Coreboot will do on a X201i (-note the i), as to my knowledge the
 only difference between these two versions is that the latter one
 features a multitouch touchscreen?
 Thank you in advance!
 
My tree should work on X201i as well. The screen probably doesn't matter
unless it has different vbt in which case you'll need to change fake vbt
or use VGA option ROM.
Some X201 submodels may have weird differences
 The top of my thread is http://review.coreboot.org/#/c/3408/
In any case you need external flasher and follow intstructions on the
wiki. If it fails you can always reflash original BIOS.

 Chris
 
 




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

[coreboot] CBFS hardlinks

[Vladimir 'φ-coder/phcoder' Serbinenko]

Hello, all. Currently coreboot does the mapping from PCIID to the name
of option ROM in platform-dependent part (one PCIID is chosen as
representative of whole family). Unfortunately SeaBIOS doesn't have this
mapping and so doesn't find the right file. Could we perhaps have
hardlinks in CBFS and store the same file under several names?
The hardlink would have a type 0xf1 (File Link) and would be a file with
just 2 fields:
4-byte big-endian offset
4-byte big-endian size
which point to the real contents of the file.
Should I prepare patches for this approach?



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

Re: [coreboot] Removing microcode updates from blobs

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 14.12.2013 07:46, mrnuke wrote:
 On 12/14/2013 12:36 AM, ron minnich wrote:
 And I think it even worse to put the microcode blobs in a location in
 the tree that implies, by its existence, that you can build without
 them and get a more free, working firmware image.

 You can't have a working build on a bunch of recent hardware without
 blobs. So the assumption that you can build without blobs is false.
 Pure and simple.
 
What about making it explicit and forbid builds without blobs repo on
cpus which have microcode update? The forbidding part would be just one
line per CPU and those whi remove it modify source, so they take
responsibility for themselves if something goes wrong.
I'm not fan of running without microcode update and I agree with you in
most points. I see advantage in maintainance by using separate repo for
thing under different license but since I'm not the one doing most of
the maintainance it's purely decision of those who do (do-o-cracy).



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

Re: [coreboot] Removing microcode updates from blobs

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 14.12.2013 07:59, ron minnich wrote:
 On Fri, Dec 13, 2013 at 10:46 PM, mrnuke mr.nuke...@gmail.com wrote:
 
 What's the point? Why not just enlighten them? I just can not understand this.
Some distros have a policy of putting free and non-free components in
separate repositories (E.g Debian contrib/free vs non-free) and having
appropriate dependencies to show that free package needs something
non-free. I'd hate to see coreboot land in some non-free repo over
microcode issues, it would send wrong message.



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

Re: [coreboot] New laptop: Lenovo ThinkPad X230 tablet, with dumps to go with it

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 15.09.2012 05:47, Keith Hui wrote:
 Hi all,
 
 I'm back. With a new laptop.
 
 I'm now rocking a Lenovo x230 tablet,

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





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

Re: [coreboot] does coreboot support kvm WPCE775x other questions

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 05.01.2014 07:15, Gregg Levine wrote:
  Part of the problem with laptops is that there is a thing on them
 called an Embedded Controller, EC for short. Those devices do all of
 the housekeeping chores that the main system has delegated to them.
 For example certain functions are on it.
 
 To that end most laptops aren't supported because these devices are
 proprietary in their designs and the programing of them.
While ECs are a problem for flashrom (unless they run off a separate
flash), they are usually of marginal importance to coreboot.
You cn always use external flasher.



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

[coreboot] Remove GENERATE_ACPI_TABLES

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

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



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

Re: [coreboot] Remove GENERATE_ACPI_TABLES

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 07.01.2014 00:12, mrnuke wrote:
 On Monday, January 06, 2014 07:52:20 PM Vladimir 'φ-coder/phcoder' Serbinenko 
 wrote:
 By now most boards and OS don't run correctly if ACPI tables are not
 supplied. Ability by user to enable/disable their generation is just
 increasing configuration matrix for no benefit. So I propose to hardwire
 it to HAVE_ACPI_TABLES.
 
 You mean you haven't found a need for it in your recent use cases. I don't 
 think this can be used to generalize for all boards, and is most certainly a 
 naive proposal for ARM boards. So you end up depending this shit on ARCH_x86, 
 then ARM adds ACPI, then it again makes sense to HAVE_ACPI_TABLES, but only 
 for ARM, so now we make it depend on ARCH_ARM, and we get a clusterfuck by 
 the 
 end of the day.
 At the end of it all, you are proposing to take away a freedom that has hurt 
 no-one. -2. I can't see the justification.
 
You misunderstood. I don't propose to remove HAVE_ACPI_TABLES.
HAVE_ACPI_TABLES remains per-board characteristic.
The only thing I remove is GENERATE_ACPI_TABLES which is user-visible
option.
This way presence of ACPI-tables is determined by board porter based on
the need and availability of ACPI tables
 I feel like in current config there are too many options of kind Do you
 want a working system? (y/n) and they should be hardwired to right
 answer rather than adding configuration.

 Flashing coreboot is a minefield of these questions: Do you want to brick 
 your 
 system? (ok/cancel). You can't make it fool proof, and nanny-state-ing users 
 is not the solution. Provide sane defaults.
 
Right now we're at opposite end when you almost have to use genetic
algorithm to find which configuration works.
 Alex
 
 P.S. If you don't know what you're doing, you will brick your board, no 
 matter 
 how many coreboot condoms you wear.
 




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

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

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




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

[coreboot] cmos.layout upgradability

[Vladimir 'φ-coder/phcoder' Serbinenko]

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



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

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

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








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

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 25.01.2014 01:23, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
 
 
 
  Original Message 
 Subject: Re: [coreboot] coreboot port for macbook2,1
 Date: Sat, 25 Jan 2014 01:23:12 +0100
 From: Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com
 To: Mono m...@posteo.de
 
 On 24.01.2014 23:20, Mono wrote:
 Hallo,
 Would you help me on a coreboot port? I just installed coreboot on a 
 Thinkpad X60 following the wiki. Now I want it on this mid-2007 macbook2,1 
 too.
 I read some pages in the wiki and started to collect information about the 
 macbook. it seems it has no superIO chip and I dont know what to think of 
 the ectool output. As I understood by now, not knowing how the ec might 
 interfere with the bios or coreboot is one of the big obstacles, no? I hope 
 that once I would try a coreboot flash, recovery might be possible by an 
 external programmer (which I do not have, yet). the flash chip is the same 
 as on the X60 (I've read the factory bios already) as is the northbridge and 
 southbridge. an usb debug port seems available.
 I've put the log files here: http://macbook.donderklumpen.de/coreboot/
 Any comment about what you think about this and how I should proceed is very 
 much welcome!

 Good news is that other than EC and some minor points, your macbook is a
 copy of X60. With some luck a qualified dev can do it in a week (you may
 want to post bounty for it). You need to get console. EHCI debug would
 be the best option on your laptop.
 http://www.coreboot.org/EHCI_Debug_Port#Finding_the_USB_debug_port
 Take USB 2.0 stick and plug it into different port until it appears as
 device one on bus 3.
I meant port 1 on bus managed by ehci_pci (exact bus numbers are unstable)
 You'll have to make a USB debug dongle or buy one
 (short supply).
 You'll also need to find your flash chip. Your laptop has this chip:
 http://orzparts.com/index.php?main_page=product_infoproducts_id=732
 You'll have to teardown the whole laptop, looking at every chip which
 seems similar. Remember to discharge from static electricity before
 opening your laptop and not to wear anything that produces it. This has
 a risk of breaking your laptop, proceed at your own risk, you've been
 warned.
 thanks
 Mono

 
 
 
 
 
 




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

Re: [coreboot] cmos.layout upgradability

[Vladimir 'φ-coder/phcoder' Serbinenko]

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




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

Re: [coreboot] cmos.layout upgradability

[Vladimir 'φ-coder/phcoder' Serbinenko]

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




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

Re: [coreboot] cmos.layout upgradability

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 26.01.2014 05:55, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
 http://www.coreboot.org/Infrastructure_Projects#Provide_update_paths_and_avoid_conflicts_in_addressing

 (which mentions another solution to the problem)

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



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

Re: [coreboot] Lenovo Thinkpad T61

[Vladimir 'φ-coder/phcoder' Serbinenko]

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




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

Re: [coreboot] Lenovo Thinkpad T61

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

 ron
 




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

Re: [coreboot] Lenovo Thinkpad T61

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

 ron
 




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

Re: [coreboot] Please use Git commit hooks

[Vladimir 'φ-coder/phcoder' Serbinenko]

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


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

Re: [coreboot] coreboot port for macbook2,1

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

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

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

That is good example of relevant info collection.

 My biggest concern is with the EC.

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

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

 Could you comment on this?

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

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

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

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

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

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

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

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

 EFI with coreboot plus a 64bit GRUB2 payload (same as done on my Thinkpad 
 X60). Or would the payload need to be kept at 32bit?
What Apple ships as firmware is irrelevant.
However, decision to omit BIOS comes from higher-level decision of
omiting compatibility with 95-era systems. So it's possible you won't be
able to boot old OS even with coreboot due to lack of compatibility
devices. I'd say it's a minor problem (95-era OS wouldn't work reliably
on modern system anyway)
 
 thanks again and
 with best regards
 Mono
 
 On Wed, Jan 29, 2014 at 10:24:58PM +0100, Stefan Reinauer wrote:
 * Mono m...@posteo.de [140124 23:20]:
 Hallo,
 Would you help me on a coreboot port? I just installed coreboot on a 
 Thinkpad X60 following the wiki. Now I want it on this mid-2007 macbook2,1 
 too.
 I read some pages in the wiki and started to collect information about the 
 macbook. it seems it has no superIO chip and I dont know what to think of 
 the ectool output. As I understood by now, not knowing how the ec might 
 interfere with the bios or coreboot is one of the big obstacles, no? I hope 
 that once I would try a coreboot flash, recovery might be possible by an 
 external programmer (which I do not have, yet). the flash chip is the same 
 as on the X60 (I've read the factory bios already) as is the northbridge 
 and southbridge. an usb debug port seems available.
 I've put the log files here: http://macbook.donderklumpen.de/coreboot/
 Any comment about what you think about this and how I should proceed is 
 very much welcome!

 - Make sure you have the external tools in place to recover from a bad
   flash. You will notg boot successfully on the first attempt.

 - Keep a copy of the original firmware around

 - Try to make sure that your USB debug gadget is working before starting

 - Start with one of the existing i945 based notebooks

 - find out what EC is used, and if it shares flash with the main system

 - try to get hold of schematics

 Regards,
 Stefan


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




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

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

 1. Gigabyte GA-Z77-HD3 Motherboard
Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz

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

Re: [coreboot] coreboot port for macbook2,1

[Vladimir 'φ-coder/phcoder' Serbinenko]

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

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

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



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

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

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



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

Re: [coreboot] Support for Dell desktop motherboard

[Vladimir 'φ-coder/phcoder' Serbinenko]

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




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

Re: [coreboot] HP Chromebook 14 (Falco)

[Vladimir 'φ-coder/phcoder' Serbinenko]

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




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

Re: [coreboot] coreboot port for macbook2,1

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 08.02.2014 15:27, Mono wrote:
 Hallo,
 
 On Mon, Feb 03, 2014 at 10:16:30PM +0100, Vladimir 'φ-coder/phcoder' 
 Serbinenko wrote:
 CY8C24794-24LFXI
 My guess: it's part of keyboard + touchpad
 Do you already know which port is USBdebug one?
 Yes, I found out with a USB stick, dmesg and lsusb -t.
 
 Did you already test USB debug with dbgp?
 Yes, I tested USB debug for the Thinkpad X60, I assume it would work the same 
 for Macbook.
 
I meant that you can use debug port as early printk device. It's
recommended to check dongle this way if your dongle is the real dbgp dongle.

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

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

 
 I updated the webpage about what I did ( 
 http://macbook.donderklumpen.de/coreboot/ ).
 At the moment I am looking at x60's romstage.c because I'd plan to copy as 
 much as possible from it. At the function static void ich7_enable_lpc(void) I 
 got stuck. I can make some guesses, but don't know where the details are 
 documented. If you could point me to any documentation, I'd love to read it. 
 I tried ich7 datasheet and LPC Interface Specification but did not spot what 
 the function ich7_enable_lpc does.
 
 By comparing the output of lspci -nnvvvxxx -s 00:1f.0 on the Thinkpad with 
 coreboot and the Macbook with factory bios I get the following:
  
 on the Thinkpad
 $ lspci -nnvvvxxx -s 00:1f.0
 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface 
 Bridge [8086:27b9] (rev 02)
   Subsystem: Lenovo ThinkPad T60/R60 series [17aa:2009]
   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
   Latency: 0
   Capabilities: [e0] Vendor Specific Information: Len=0c ?
   Kernel driver in use: lpc_ich
   Kernel modules: intel_rng, lpc_ich, leds_ss4200
 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 09 20
 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
 40: 01 05 00 00 80 00 00 00 81 04 00 00 10 00 00 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 80 80 80 80 d0 00 00 00 80 80 80 80 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 80: 10 02 0d 1f 01 16 7c 00 e1 15 0c 00 81 16 1c 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: ac 06 00 00 30 00 00 00 13 1c 0a 00 00 03 00 00
 b0: 00 00 f0 00 00 00 00 00 00 00 02 0a 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 33 22 11 00 67 45 00 00 cf ff 00 00 08 00 00 00
 e0: 09 00 0c 10 b4 02 24 17 00 00 00 00 00 00 00 00
 f0: 01 c0 d1 fe 00 00 00 00 86 0f 02 00 00 00 00 00
 
 and on the Macbook
 $ lspci -nnvvvxxx -s 00:1f.0
 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC Interface 
 Bridge [8086:27b9] (rev 02)
   Subsystem: Intel Corporation Device [8086:7270]
   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
   Latency: 0
   Capabilities: [e0] Vendor Specific Information: Len=0c ?
   Kernel driver in use: lpc_ich
   Kernel modules: intel_rng, lpc_ich, leds_ss4200
 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 70 72
 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
 40: 01 04 00 00 80 00 00 00 01 05 00 00 10 00 00 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 80 80 80 80 d0 00 00 00 80 80 80 80 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 80: 10 00 07 38 81 06 0c 00 41 16 0c 00 00 00 00 00
 90: 01 03 1c 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: 04 02 00 00 01 00 00 00 13 1c 0a 00 00 03 00 00
 b0: 00 00 f0 00 00 00 00 00 08 80 00 00 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 33 22 00 00 67 45 00 00 00 ff 00 00 00 00 00 00
 e0: 09 00 0c 10 b4 02 24 17 00 00 00 00 00 00 00 00
 f0: 01 c0 d1 fe 00 00 00 00 86 0f 02 00 00 00 00 00
 
 In the Thinkpad output I can spot the values written by coreboot:
 0xd0 at 0x64 // Enable Serial IRQ, this is the same for what the Macbook 
 outputs, but where can I read that this enables serial IRQ? 
 0x0210 and 0x1f0d at 0x80 and 0x82 // decode ranges, the Macbook outputs 
 different values here
 0x1601, 0x007c, 0x15e1, 0x000c, 0x1681, 0x001c from 0x84 to 0x8e // the 
 Thinkpad has three ranges

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

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




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

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

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




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

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 09.02.2014 14:34, Paul Menzel wrote:
 Am Sonntag, den 09.02.2014, 14:18 +0100 schrieb Vladimir 'φ-coder/phcoder' 
 Serbinenko:
 On 09.02.2014 13:50, Paul Menzel wrote:
 
 currently no coreboot messages are stored for boards not supporting
 CBMEM console

 Is there any remaining? If so it's an issue to be fixed
 
 Sorry, no idea. I thought there were some. At least not all boards have
 been tested to my knowledge.
 
board-status is all about testing. When we see incomplete
coreboot_console.txt it means there is a bug to be fixed, not workarounded.
 (or where this option is disabled (currently by default))

 Change the defaults.
 
 It is not safe or wanted for all boards I believe. But others are more
 knowledgeable to comment on that issue.
 
I don't see any problem with enabling cbmemc by default on all boards.
 or no coreboot *romstage* messages are stored for boards, where the data
 cannot be preserved (passed to ramstage).

 which boards are concerned? Which boards use ROMCC for romstage? Do they
 output anything useful in romstage? If so, can't it be compensated by
 ramstage?
 
 In my case it is the Asus M2V-MX SE (AMD, pre-AGESA).
 
What is the info we need from it? ROMCC boards usually don't output much.
 Using the serial (or USB)
Your argument with USB console is completele broken as EHCI debug is not
supported on ROMCC boards at all.
 console all these messages can be captured
 with no problem, so I propose to just add these captured messages into
 the file `serial_console.txt`. Of course this file probably contains
 also the payload and (Linux) kernel log, but I think that is fine.

 SeaBIOS’ `readserial.py` should be used for capturing the messages as it
 adds time stamps.

 Scripting this is going to be hard, as the log is captured on a
 different system. So for now I propose to add it manually.

 Having to capture serial makes setup needed for board-status more
 difficult.
 
 Surely it will not be a requirement to capture the serial output. My
 proposal is about adding it, when it is captured already and what file
 name to use.
 
And who will care about it then?
 Certainly, one needs to have a recovery method for case of
 brick
 
 You always need that in case of a brick. What is special about serial
 log?
 
I use debricking setup perhaps every 20 flashes on a supported board.
Not every time.
 but having a complete serial setup will heavily reduce board-status
 input which already isn't huge.
 
 Again, it is not meant to be a requirement in addition to what is
 currently captured.
 
 
 Thanks,
 
 Paul
 
 
 




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

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

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




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

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 11.02.2014 01:56, mrnuke wrote:
 On Tuesday, February 11, 2014 12:04:33 AM Vladimir 'φ-coder/phcoder' 
 Serbinenko wrote:
 If we let user supply
 files at all, it should be added to report, not replace files, and it
 should have some prefix to clearly indicate that user was involved in
 creating them. E.g. user_serial_log.txt

 There is a point at which the information becomes too much. What is really 
 relevant, in my opinion, are the following three points:
 
 1. Is it an unmodified commit in master (AKA, not -dirty).
 2. Does it boot?
 3. What does not work, if any ?
 
 Point 1 and 2 are answered by cbmem -c | head. It answers point 1 with the 
 first line of output, and point 2 by the fact that getting anything from 
 cbmem 
 means you've already booted your system.
 
 Point 3 is more complicated, and it seems it is because of this point that we 
 want to collect any and all information we can possibly get our hands on.
 
 Other than cbmem -c | head and .config, a majority of people just don't 
 care 
 about all the pesky details. They're only useful when debugging problems some 
 poor guy or gal is having. In that case, we can ask them for this info 
 manually. It's not of any use in tracking down which revision + config works 
 on _this_ board.
 
This is not the only uses of board-status. It's also useful to see if
some boards have an issue which one meets in particular board. This
information is important in tracking bugs down but hard to collect
unless it's in the board-status.
 Alex
 




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

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

[Vladimir 'φ-coder/phcoder' Serbinenko]

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



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

Re: [coreboot] coreboot port for macbook2,1

[Vladimir 'φ-coder/phcoder' Serbinenko]

On 13.02.2014 23:47, Mono wrote:
 Hallo
 
 finally I managed to enable SPI on the Beaglebone Black and use it as 
 external programmer with flashrom.
 I read the macbook's flash chip twice, as suggested. Both rom files are 
 identical. But: a few days/week ago I read the flash chip with the macbook's 
 internal programmer. This file differs from what the external programmer got. 
 Some 9500 bytes (out of 2MiB) differ. apart from a few exeptions those bytes 
 are 0xff read with the internal programmer, but have random hex code when 
 read with the external programmer. Well, between the usage of internal and 
 external programmer the macbook was in normal use. I didnt expect the OS or 
 EC(?) or something to write to the flash chip while it is in normal use. what 
 do you think? what could cause this differnce? I can paste the rom contents 
 later somewhere if that would help any.
 
That is pretty normal. Some firmwares store debug log or parameters in
flash.
 best regards
 Mono
 
 On Sat, Feb 08, 2014 at 03:37:40PM +0100, Vladimir 'φ-coder/phcoder' 
 Serbinenko wrote:
 On 08.02.2014 15:27, Mono wrote:
 Hallo,

 On Mon, Feb 03, 2014 at 10:16:30PM +0100, Vladimir 'φ-coder/phcoder' 
 Serbinenko wrote:
 CY8C24794-24LFXI
 My guess: it's part of keyboard + touchpad
 Do you already know which port is USBdebug one?
 Yes, I found out with a USB stick, dmesg and lsusb -t.

 Did you already test USB debug with dbgp?
 Yes, I tested USB debug for the Thinkpad X60, I assume it would work the 
 same for Macbook.

 I meant that you can use debug port as early printk device. It's
 recommended to check dongle this way if your dongle is the real dbgp dongle.

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

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


 I updated the webpage about what I did ( 
 http://macbook.donderklumpen.de/coreboot/ ).
 At the moment I am looking at x60's romstage.c because I'd plan to copy as 
 much as possible from it. At the function static void ich7_enable_lpc(void) 
 I got stuck. I can make some guesses, but don't know where the details are 
 documented. If you could point me to any documentation, I'd love to read 
 it. I tried ich7 datasheet and LPC Interface Specification but did not spot 
 what the function ich7_enable_lpc does.

 By comparing the output of lspci -nnvvvxxx -s 00:1f.0 on the Thinkpad with 
 coreboot and the Macbook with factory bios I get the following:
  
 on the Thinkpad
 $ lspci -nnvvvxxx -s 00:1f.0
 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC 
 Interface Bridge [8086:27b9] (rev 02)
 Subsystem: Lenovo ThinkPad T60/R60 series [17aa:2009]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0
 Capabilities: [e0] Vendor Specific Information: Len=0c ?
 Kernel driver in use: lpc_ich
 Kernel modules: intel_rng, lpc_ich, leds_ss4200
 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 aa 17 09 20
 30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00
 40: 01 05 00 00 80 00 00 00 81 04 00 00 10 00 00 00
 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 60: 80 80 80 80 d0 00 00 00 80 80 80 80 00 00 00 00
 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 80: 10 02 0d 1f 01 16 7c 00 e1 15 0c 00 81 16 1c 00
 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 a0: ac 06 00 00 30 00 00 00 13 1c 0a 00 00 03 00 00
 b0: 00 00 f0 00 00 00 00 00 00 00 02 0a 00 00 00 00
 c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 d0: 33 22 11 00 67 45 00 00 cf ff 00 00 08 00 00 00
 e0: 09 00 0c 10 b4 02 24 17 00 00 00 00 00 00 00 00
 f0: 01 c0 d1 fe 00 00 00 00 86 0f 02 00 00 00 00 00

 and on the Macbook
 $ lspci -nnvvvxxx -s 00:1f.0
 00:1f.0 ISA bridge [0601]: Intel Corporation 82801GBM (ICH7-M) LPC 
 Interface Bridge [8086:27b9] (rev 02)
 Subsystem: Intel Corporation Device [8086:7270]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
 Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
 TAbort- MAbort- SERR- PERR- INTx-
 Latency: 0
 Capabilities: [e0] Vendor Specific Information: Len=0c ?
 Kernel driver in use: lpc_ich
 Kernel modules: intel_rng, lpc_ich, leds_ss4200
 00: 86 80 b9 27 07 00 10 02 02 00 01 06 00 00 80 00
 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 70 72
 30: 00 00 00 00 e0 00 00 00 00 00 00 00