Re: [coreboot] Lenovo X220t variants with SMD-Flash-ROMs

[Philipp Stanner]

Yes, you're probably right.

Though I wonder when and how they programmed the firmware. Before or
after soldering?


Am 05.08.2017 um 19:41 schrieb Igor Skochinsky via coreboot:
> Hello Philipp,
>
> Saturday, August 5, 2017, 6:01:04 PM, you wrote:
> PS> PS: Rantmode: Why the hell don't they just solder a socket? It's not
> PS> that unrealistic that someone bricks the BIOS while updating the
> PS> firmware from time to time. Being able to replace the ROM with a fresh
> PS> one is a huge plus.
>
> A socket would add some cost; not just of the part itself but
> also cost of the assembly process since flash chip could not be soldered
> together with the rest of the components now, and possibly other
> logistical issues (e.g. they would have to order DIP chips
> specifically for this model instead of SMD parts like for everything
> else).
> It would also increase the height of the board, and you know how
> everyone is obsessed with thin laptops nowadays. 
>
> Just because it would be convenient for maybe ten people in the world
> doesn't make it an incentive for the manufacturers. 
>
> Besides, 99.9% users are not expected to ever open their device, let alone 
> mess
> with the chips. If they get a brick (which is a pretty rare thing
> nowadays AFAIK), they send it off for repairs.
>


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

Re: [coreboot] [Broadwell-U]How the eDP, DDI1, DDI2 are enabled?

[Zheng Bao]

At which stage do you want to enables these ports? in the OS? or during
boot? if the latter, which payload do you use?


Zheng: I want to enable these display port during boot. The payload is SeaBIOS.


Zheng



From: Nico Huber 
Sent: Saturday, August 5, 2017 12:17 PM
To: Zheng Bao; coreboot@coreboot.org
Subject: Re: [coreboot] [Broadwell-U]How the eDP, DDI1, DDI2 are enabled?

Hi Zheng,

On 04.08.2017 04:35, Zheng Bao wrote:
> I need to clarify my question.
>
> For Broadwell-U, are there internal 3 display ports? Is the first one set
> statically as eDP?

the first (DDI0 or DDI-A) is eDP only. The other two can be used for DP,
HDMI/DVI or both (aka DP++ or dual-mode DP). What you can actually con-
nect depends on your board and the physical connectors of course.

Broadwell-U doesn't provide analog VGA. If your board has a VGA connec-
tor, there's supposedly a converter chip onboard that is either attached
via HDMI or DP to the SoC.

>
> How can these ports be set as other type like VGA, HDMI?

That depends on the software you use. Traditionally, display bringup is
done in a separate program in the firmware (e.g. VGA BIOS, GOP). core-
boot does this as well on most platforms. Also the OS driver should be
able to detect and enable external displays automatically.

At which stage do you want to enables these ports? in the OS? or during
boot? if the latter, which payload do you use?

>
> Can all these 3 ports be enabled at same time?

Yes.

Nico

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

Re: [coreboot] Lenovo X220t variants with SMD-Flash-ROMs

[John Lewis]

On Sat, 5 Aug, 2017 at 5:01 PM, Philipp Stanner  
wrote:



PS: Rantmode: Why the hell don't they just solder a socket? It's not
that unrealistic that someone bricks the BIOS while updating the
firmware from time to time. Being able to replace the ROM with a fresh
one is a huge plus.


I guess that's just the throw-it-away philosophy ...
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Lenovo X220t variants with SMD-Flash-ROMs

[Igor Skochinsky via coreboot]

Hello Philipp,

Saturday, August 5, 2017, 8:41:42 PM, you wrote:

PS> Yes, you're probably right.

PS> Though I wonder when and how they programmed the firmware. Before or
PS> after soldering?

Most likely before, unless they have some debug header exposed. From
[1]:

> When the hardware and software nears production readiness, it is
> common practice to preprogram flash memory devices prior to
> starting high-volume PCB manufacturing flows for two principal
> reasons. First, firmware loaded onto the device can be used to
> perform basic booting and testing of the PCB during manufacturing
> to check system/module functionality. Second, loading the final
> firmware, operating system (OS), and application code on the flash
> device prior to manufacturing maintains a high-volume
> manufacturing beat rate. To support these usage models, multiple
> vendors provide systems for loading firmware and data into flash
> memory devices prior to the PCB solder flow process.

Modern flash chips don't have issues retaining programmed bits during reflow
soldering as long as the correct temperature profile is observed [2].

[1]: 
http://www.electronicdesign.com/memory/understanding-onboard-flash-programming
[2]: http://dataioinfo.com/LiveImages/26/20/DocumentURL.pdf



-- 
WBR,
 Igormailto:rox...@skynet.be


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

Re: [coreboot] Lenovo X220t variants with SMD-Flash-ROMs

[Philipp Stanner]

Do we have any idea what exactly they do to update the firmware internally?

The wiki says once coreboot is flashed you can flash it internally. I
suppose this means the blockade protecting the flash can be switched of
somehow, as the vendor's have to do it to install firmware-updates.


Am 05.08.2017 um 21:12 schrieb Igor Skochinsky via coreboot:
> Hello Philipp,
>
> Saturday, August 5, 2017, 8:41:42 PM, you wrote:
>
> PS> Yes, you're probably right.
>
> PS> Though I wonder when and how they programmed the firmware. Before or
> PS> after soldering?
>
> Most likely before, unless they have some debug header exposed. From
> [1]:
>
>> When the hardware and software nears production readiness, it is
>> common practice to preprogram flash memory devices prior to
>> starting high-volume PCB manufacturing flows for two principal
>> reasons. First, firmware loaded onto the device can be used to
>> perform basic booting and testing of the PCB during manufacturing
>> to check system/module functionality. Second, loading the final
>> firmware, operating system (OS), and application code on the flash
>> device prior to manufacturing maintains a high-volume
>> manufacturing beat rate. To support these usage models, multiple
>> vendors provide systems for loading firmware and data into flash
>> memory devices prior to the PCB solder flow process.
> Modern flash chips don't have issues retaining programmed bits during reflow
> soldering as long as the correct temperature profile is observed [2].
>
> [1]: 
> http://www.electronicdesign.com/memory/understanding-onboard-flash-programming
> [2]: http://dataioinfo.com/LiveImages/26/20/DocumentURL.pdf
>
>
>


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

Re: [coreboot] Lenovo X220t variants with SMD-Flash-ROMs

[persmule]

Hi Philipp,

It is just a wson-8 flash rom, whose soldering plates are compatible
with those for soic-8 chips, often found on thinkpads produced when 8MiB
soic-8 chip are hardly available.

The common way to deal with wson-8 chips is to blow it off with hot air
blower, suck up its content, and finally replace it with a soic-8 chip.

There is an article mentioned wson-8 chips:
https://www.coreboot.org/Board:lenovo/t430s

Persmule

在 2017年08月06日 00:01, Philipp Stanner 写道:
> Hi list,
>
> I don't know if it's common yet (the wiki article doesn't mention it)
> but today I discovered that there are Lenovo Thinkpads with very flat
> SMD-Flash-ROMs which make it impossible to access them with a SOIC-Clip
> or flash them by soldering wires to the pins directly.
>
> I aborted the flashing but am going to try finding a work-around.
>
> About the laptop:
> Type 4298-W28 S/N R9-E4CFC 11/06 (so probably manufactured in 2011)
>
> Product ID: 4298W28
>
> Maybe we should write one sentence in the wiki mentioning that not all
> chips are accessable very comfortably.
>
> Greetings,
>
> P.
>
> PS: Rantmode: Why the hell don't they just solder a socket? It's not
> that unrealistic that someone bricks the BIOS while updating the
> firmware from time to time. Being able to replace the ROM with a fresh
> one is a huge plus.
>
>
>

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

Re: [coreboot] Lenovo X220t variants with SMD-Flash-ROMs

[Igor Skochinsky via coreboot]

Hello Philipp,

Saturday, August 5, 2017, 6:01:04 PM, you wrote:
PS> PS: Rantmode: Why the hell don't they just solder a socket? It's not
PS> that unrealistic that someone bricks the BIOS while updating the
PS> firmware from time to time. Being able to replace the ROM with a fresh
PS> one is a huge plus.

A socket would add some cost; not just of the part itself but
also cost of the assembly process since flash chip could not be soldered
together with the rest of the components now, and possibly other
logistical issues (e.g. they would have to order DIP chips
specifically for this model instead of SMD parts like for everything
else).
It would also increase the height of the board, and you know how
everyone is obsessed with thin laptops nowadays. 

Just because it would be convenient for maybe ten people in the world
doesn't make it an incentive for the manufacturers. 

Besides, 99.9% users are not expected to ever open their device, let alone mess
with the chips. If they get a brick (which is a pretty rare thing
nowadays AFAIK), they send it off for repairs.

-- 
WBR,
 Igormailto:rox...@skynet.be


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

Re: [coreboot] Lenovo X1 carbon 3460 Screen stays black

[Nico Huber]

On 05.08.2017 15:40, Jo wrote:

Hello Guys,

I wanted to get coreboot on my Lenovo X1 Carbon 1gen (3460) ,

so i followed the tutorial, however after flashing it, the screen stayed
black.So i flashed the Vendorbios back and im kinda stuck now, help
would be really appreciated.

This is my*config file* (if you care to have a look)

https://pastebin.com/FYrsmXPb

and the output of *inteltool -m* (spd data)

https://pastebin.com/JZQYb3p3

also the output of *inteltool -g*

https://pastebin.com/wDNRxM4U

_and i*nteltool -G*_

https://pastebin.com/zJV3dE8A


As expected, you have a unsupport memory configuration. Here is a
patch that adds your dumped data:

  https://review.coreboot.org/#/c/20887/

You can check it out with

  git fetch https://review.coreboot.org/coreboot 
refs/changes/87/20887/1 && git checkout FETCH_HEAD


I hope it works, I didn't look very deep into it.

Nico


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

Re: [coreboot] About Paging, Realmode and what is going on

[ron minnich]

in the akaros virtual machine code, we set up a simple 1:1 map and start
linux at the 64-bit entry point, at which point it builds its own page
tables. So entering a payload in long mode is certainly possible and IMHO
ought to be the standard on amd64 -- not that anyone cares what I think
anyway :-)

Anyway, I'm going to be working on replacing ramstage with linux again, so
I'm not as concerted with coreboot ramstage just now ;-)

On Thu, Aug 3, 2017 at 9:16 AM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> OK Ron,
>
> I needed some time to reconcile my thoughts. So,as Aaron pointed, it is
> impossible to do any long mode paging in ROM stage.
>
> And here we come to the Mystery of CB Organism (h... It is very close
> to some other term). ;-)
>
> Now, here is how it will play for you and Coreboot, after ROM stage (I'll
> call it RON stage, since it is RAM stage, divided in two sections).
>
> Why RON? Ready Or Not, that is the question!
>
> So RON stage = RAM1 stage + RAM2 stage.
>
> RAM1 stage: Since some RAM Physical mapping (AFTER CRB) MUST be done at
> the beginning of the RAM stage, lookalike BIOS one (in PEI phase, I
> assume), CB will proceed with the usual activities, set in Protected Mode.
> And, as we know so far how it works, it'll finish this phase, looking for
> Payload.
>
> Now, instead of payload stage, here we go with the RAM2 stage. Now the CB
> will switch to the Long Mode (flat x86_64), addressing at maximum of 48
> bits of the physically available CPU address memory bus - 256 TB of DDRAM
> memory (I'll drop here 64 bit PAE extension (additional 4 bits of physical
> address space), for clarity).
>
> Here, you'll start initializing MMU, with 4 TLB tables: CR3 -> PML4 (512
> entries) -> PDTP (512 entries) -> PDT (512 entries) -> PT (512 entries +
> last 12 bits freed for the MMU attributes). So, if your HW have in average
> 8GB of memory, you'll need ONLY 1 entry in PML4, 8 entries in PDTP -> and
> full tables for these 8 entries. I see that you'll do NOT a Virtualization,
> rather a logical address shift for the constant address offset. With proper
> init of the attributes in the PE tables, per 4KB page - your finest
> granularity).
>
> And, YES, you'll have your memory protection in full swing (just for the
> de-referencing the NULL pointers), since you do NOT have more that one
> process working, in linear mode (so the bus error will appear ONLY for NULL
> pointers).
>
> Now, after you've done this, what is the next step, somebody will ask?
> [A] Reverting to Protected Mode prior Payload stage?
> [B] Proceeding with the Long Mode passing thread of execution to
> payloads... Which need to operate in Long Mode!? Really???
> [C] Reverting to Virtual x86 Mode???
> [D] Reverting to Real Mode???
>
> Seems that you will do scenario [A]. But if you choose to have payload as
> 64b Linux [B], then I see where you are pointing/going with this
> approach... To fast Server (?!) boot-ups, but you need to reconsider, since
> 64b Linux still will reconfigure MMU, doesn't it???
>
> Or you would like to skip kernel MMU init while booting 64b kernel.
> Letting kernel to pick up (already) hot MMU, on fly?
>
> As far, it'll be: Boot stage + ROM stage + RON stage (RAM1 stage in
> Protected Mode, + RAM2 stage in 64b Long Mode) + 64b kernel payload. Solely
> out of FLASH (smells as DOD MIL RT applications, drones, unmanned planes,
> missiles)... Interesting scenario, anyway!
>
> (Mysteries of CB organisms) ;-)
>
> Zoran
>
> On Wed, Aug 2, 2017 at 9:45 PM, ron minnich  wrote:
>
>> right, Aaron, you keep reminding me of that and I keep forgetting it :-)
>>
>> so, ok, ramstage it is for paging. The x86 is so darned annoying. We had
>> paging in the bootblock for PPC on linuxbios.
>>
>> On Wed, Aug 2, 2017 at 12:43 PM Aaron Durbin  wrote:
>>
>>> On Wed, Aug 2, 2017 at 1:36 PM, ron minnich  wrote:
>>> >
>>> >
>>> > On Wed, Aug 2, 2017 at 12:08 PM Zoran Stojsavljevic
>>> >  wrote:
>>> >>
>>> >>
>>> >>
>>> >> So, turning on the Virtual Mode (paging ON), you'll also imply that
>>> >> Coreboot will initialize and use MMU, don't you?
>>> >
>>> >
>>> > sure.
>>> >
>>> >>
>>> >>
>>> >> Am I correct, or you can use paging without MMU?!
>>> >
>>> >
>>> > MMU must be on.
>>> >
>>> >>
>>> >> I doubt that, perhaps. So, then, I would like to see this code in
>>> Coreboot
>>> >> where MMU is initialized. And how it is initialized (maybe there is a
>>> some
>>> >> over-simplified mode of operation using 2MB pages).
>>> >
>>> >
>>> > yep.
>>> >
>>> >>
>>> >>
>>> >> And my question is: what for? Or I did not get the idea... Who really
>>> >> needs to use paging in boot-loaders? Even INTEL, which (on purpose)
>>> makes
>>> >> things way over-dimensioned and over-complicated, does NOT use paging
>>> in
>>> >> UEFI BIOSes, so far???
>>> >>
>>> >
>>> > it's trivial to turn on paging. In harvey I've got it down to 160
>>> lines,

Re: [coreboot] [Broadwell-U]How the eDP, DDI1, DDI2 are enabled?

[Nico Huber]

Hi Zheng,

On 04.08.2017 04:35, Zheng Bao wrote:

I need to clarify my question.

For Broadwell-U, are there internal 3 display ports? Is the first one set
statically as eDP?


the first (DDI0 or DDI-A) is eDP only. The other two can be used for DP,
HDMI/DVI or both (aka DP++ or dual-mode DP). What you can actually con-
nect depends on your board and the physical connectors of course.

Broadwell-U doesn't provide analog VGA. If your board has a VGA connec-
tor, there's supposedly a converter chip onboard that is either attached
via HDMI or DP to the SoC.



How can these ports be set as other type like VGA, HDMI?


That depends on the software you use. Traditionally, display bringup is
done in a separate program in the firmware (e.g. VGA BIOS, GOP). core-
boot does this as well on most platforms. Also the OS driver should be
able to detect and enable external displays automatically.

At which stage do you want to enables these ports? in the OS? or during
boot? if the latter, which payload do you use?



Can all these 3 ports be enabled at same time?


Yes.

Nico


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

[coreboot] Lenovo X1 carbon 3460 Screen stays black

[Jo]

Hello Guys,

I wanted to get coreboot on my Lenovo X1 Carbon 1gen (3460) ,

so i followed the tutorial, however after flashing it, the screen stayed
black.So i flashed the Vendorbios back and im kinda stuck now, help
would be really appreciated.

This is my*config file* (if you care to have a look)

https://pastebin.com/FYrsmXPb

and the output of *inteltool -m* (spd data)

https://pastebin.com/JZQYb3p3

also the output of *inteltool -g*

https://pastebin.com/wDNRxM4U

_and i*nteltool -G*_

https://pastebin.com/zJV3dE8A

_cheers _

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

Re: [coreboot] Lenovo X1 carbon 3460 Screen stays black

[John Lewis]

Howdy,

In your config file you have:

# CONFIG_VGA_BIOS is not set

in coreboot, which will mean that coreboot doesn't setup the display, 
but in your SeaBIOS config you have:


CONFIG_SEABIOS_VGA_COREBOOT=y

which will try to reuse whatever coreboot has setup. So as you might 
understand, this causes a bit of a catch 22. :)


Either tell coreboot to run the BIOS *or* set the VGA Hardware Type to 
"none" in SeaBIOS.


Other common problems are getting the pci id's for your graphics card 
wrong and using the wrong offset for SeaBIOS to find CBFS (so it can 
run things like VGA ROM's).


It would be helpful if you had a distro already loaded, as that will 
try to initialise the display even if the BIOS hasn't, which can be 
handy (so you can get and see cbmem output to figure out what is wrong)


After all that, my first answer may not be the solution and there may 
also be something else stopping the system getting as far as running 
the VGA BIOS.


Hope this helps,

John.

On Sat, 5 Aug, 2017 at 2:40 PM, Jo  wrote:

Hello Guys,

I wanted to get coreboot on my Lenovo X1 Carbon 1gen (3460) ,

so i followed the tutorial, however after flashing it, the screen 
stayed black.So i flashed the Vendorbios back and im kinda stuck now, 
help would be really appreciated.

This is my config file (if you care to have a look)

https://pastebin.com/FYrsmXPb
and the output of inteltool -m (spd data)

https://pastebin.com/JZQYb3p3
also the output of inteltool -g

https://pastebin.com/wDNRxM4U

and inteltool -G

https://pastebin.com/zJV3dE8A

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