Re: [coreboot] how does FSP play its role in Haswell/Broadwell/Skylake

[Matt DeVillier]

Haswell and Broadwell don't use FSP, they use the MRC blob for RAM init.
For Haswell, coreboot does all of the silicon init as well; for Broadwell,
coreboot does most of the silicon init, and some bits are handled by
another blob (refcode.elf).  Skylake uses FSP (1.1 or 2.0, depending on the
board in question) for both RAM and silicon init.

cheers,
Matt

On Sun, Mar 4, 2018 at 11:12 PM, Zheng Bao  wrote:

> Hi,
>
> how does FSP play its role in Haswell/Broadwell/Skylake?
>
>
> Take the Broadwell as the example, which I ported coreboot successfully.
>
>
> I use the mrc.bin and vboot.bin from Chromebook BIOS image.
>
> I use the ME tool, fitc, to add the IFD to the BIOS image.
>
> The final image works well and boots linux.
>
>
> But where is FSP? Or which is FSP?
>
>
> Zheng
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] how does FSP play its role in Haswell/Broadwell/Skylake

[Zheng Bao]

Hi,

how does FSP play its role in Haswell/Broadwell/Skylake?


Take the Broadwell as the example, which I ported coreboot successfully.


I use the mrc.bin and vboot.bin from Chromebook BIOS image.

I use the ME tool, fitc, to add the IFD to the BIOS image.

The final image works well and boots linux.


But where is FSP? Or which is FSP?


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

Re: [coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch

[Nico Huber]

Hello Mark,

On 04.03.2018 11:45, Mark Wylde wrote:
> The ASUS C201 comes with an 11.6inch EDP display. I was wondering if you
> could simply swap it for a 15'' EDP display. I tried it, but as expected
> it didn't work, however the backlight came on and I had the following
> logs:
> 
> 
snip
> Configuring PLL at ff760040 with NF = 1346, NR = 59 and NO = 4 (VCO = 
> 547525KHz, output = 136881KHz)
> requested signal parameters: lane 0 voltage 0.6V pre_emph 0dB
> requested signal parameters: lane 1 voltage 0.6V pre_emph 0dB
> using signal parameters: voltage 0.6V pre_emph 0dB
> requested signal parameters: lane 0 voltage 0.8V pre_emph 0dB
> requested signal parameters: lane 1 voltage 0.8V pre_emph 0dB
> using signal parameters: voltage 0.8V pre_emph 0dB
> requested signal parameters: lane 0 voltage 1.2V pre_emph 0dB
> requested signal parameters: lane 1 voltage 1.2V pre_emph 0dB
> using signal parameters: voltage 1.2V pre_emph 0dB
> clock recovery reached max voltage
> clock recovery failed
> link train failed!
> edp enable err
> 

This is the DP training sequence. DP has two communication channels to
the display, 1. up to 4 data lanes for the picture data operating at GHz
rates that have to be trained, 2. an AUX channel operating at MHz speed
that is supposed to just work (it does here).

Basically, your display keeps telling through the AUX channel "I can't
hear you, speak louder!". Until the highest voltage is reached.

> 
> It looks to me (as a complete noob) that the display
> (http://www.yslcd.com.tw/docs/product/N156HGE-EAB.pdf) needs around 3.3
> volts.

The 3.3V are the power supply voltage for the display. This is (usually)
not configurable, but if it were, then likely not from coreboot but the
EC. You should make sure that the electrical characteristics (4.3.1 in
that datasheet) match those of the old display. If they don't, all bets
are off.

> 
> Looking at the code, it seems the ./src/soc/rockchip/common/edp.c
> handles this part of the booting process. Line 38 seems to imply the
> maximum voltage is 1.2v.

This, however, is about the i/o voltage for the data lanes, and unre-
lated to the 3.3V.

> 
>  static
> const char *voltage_names[] = { "0.4V", "0.6V", "0.8V", "1.2V" };
> 
> 
> Is there a reason this is the maximum? Unfortunately there doesn't seem
> to be much information on the specifications of the C201, I guess as
> it's not really an open machine. Maybe the motherboard can only handle
> that voltage?

It's the maximum specified for DP.

> 
> I'm extremely new to coreboot, and to be honest not even sure the C201
> can even handle a 15'' display. Does anyone know if I'm on the right
> track, or if this is a pointless exercise?

Your problem has nothing to do with coreboot, I guess. Though, that log
is useful for debugging of course. If the electrical characteristics
match those of the old display (i.e. we can expect that the new display
is generally operational), it might be a signal integrity problem, or
something is not connected correctly at all...

The C201 generally shouldn't care about the size or the resolution of
the display. At the eDP level, everything should be compatible. The
power supply for the display, OTOH, is not part of the eDP specification
and just has to match what the board supplies (or you have to build your
own power supply).

Hope that helps,
Nico

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

[coreboot] ARM Veyron Speedy - Replacing 11.6 inch display for 15 inch

[Mark Wylde]

The ASUS C201 comes with an 11.6inch EDP display. I was wondering if you could 
simply swap it for a 15'' EDP display. I tried it, but as expected it didn't 
work, however the backlight came on and I had the following logs:


Attempting to setup EDP display.
do not get hpd single, force hpd
Extracted contents:
header:  00 ff ff ff ff ff ff 00
serial number:   0d ae c4 15 00 00 00 00 28 17
version: 01 04
basic params:95 22 13 78 02
chroma info: ef 05 90 54 52 93 29 25 50 54
established: 00 00 00
standard:01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01
descriptor 1:5e 35 80 96 70 38 14 40 2c 1c 24 00 58 c1 10 00 00 18
descriptor 2:00 00 00 fe 00 4e 31 35 36 48 47 45 2d 45 41 42 0a 20
descriptor 3:00 00 00 fe 00 43 4d 4e 0a 20 20 20 20 20 20 20 20 20
descriptor 4:00 00 00 fe 00 4e 31 35 36 48 47 45 2d 45 41 42 0a 20
extensions:  00
checksum:1d

Manufacturer: CMN Model 15c4 Serial Number 0
Made week 40 of 2013
EDID version: 1.4
Digital display
6 bits per primary color channel
DisplayPort interface
Maximum image size: 34 cm x 19 cm
Gamma: 220%
Check DPMS levels
Supported color formats: RGB 4:4:4
First detailed timing is preferred timing
Established timings supported:
Standard timings supported:
Detailed timings
Hex of detail: 5e358096703814402c1c240058c11018
Detailed mode (IN HEX): Clock 136620 KHz, 158 mm x c1 mm
   0780 07ac 07c8 0816 hborder 0
   0438 043a 043e 044c vborder 0
   -hsync -vsync
Did detailed timing
Hex of detail: 00fe004e3135364847452d4541420a20
ASCII string: N156HGE-EAB
Hex of detail: 00fe00434d4e0a202020202020202020
ASCII string: CMN
Hex of detail: 00fe004e3135364847452d4541420a20
ASCII string: N156HGE-EAB
Checksum
Checksum: 0x1d (valid)
Configuring PLL at ff760040 with NF = 1346, NR = 59 and NO = 4 (VCO = 
547525KHz, output = 136881KHz)
requested signal parameters: lane 0 voltage 0.6V pre_emph 0dB
requested signal parameters: lane 1 voltage 0.6V pre_emph 0dB
using signal parameters: voltage 0.6V pre_emph 0dB
requested signal parameters: lane 0 voltage 0.8V pre_emph 0dB
requested signal parameters: lane 1 voltage 0.8V pre_emph 0dB
using signal parameters: voltage 0.8V pre_emph 0dB
requested signal parameters: lane 0 voltage 1.2V pre_emph 0dB
requested signal parameters: lane 1 voltage 1.2V pre_emph 0dB
using signal parameters: voltage 1.2V pre_emph 0dB
clock recovery reached max voltage
clock recovery failed
link train failed!
edp enable err


It looks to me (as a complete noob) that the display 
(http://www.yslcd.com.tw/docs/product/N156HGE-EAB.pdf) needs around 3.3 volts.

Looking at the code, it seems the ./src/soc/rockchip/common/edp.c handles this 
part of the booting process. Line 38 seems to imply the maximum voltage is 1.2v.


static const char *voltage_names[] = {
"0.4V", "0.6V", "0.8V", "1.2V"
};


Is there a reason this is the maximum? Unfortunately there doesn't seem to be 
much information on the specifications of the C201, I guess as it's not really 
an open machine. Maybe the motherboard can only handle that voltage?

I'm extremely new to coreboot, and to be honest not even sure the C201 can even 
handle a 15'' display. Does anyone know if I'm on the right track, or if this 
is a pointless exercise?

Thank you and sorry if these are silly questions.

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

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Paul Kocialkowski]

Hi,

Le vendredi 16 février 2018 à 14:09 -0500, Youness Alaoui a écrit :
> > > Sure, you can trust hardware flashing more than software flashing,
> > > but
> > > I really need software flashing. If it was just for me, yeah, I
> > > could
> > > fiddle with it to flash it by hardware for my personal needs, but
> > > when
> > > it's about deploying it to all our customer base, that's another
> > > story, the only solution is software flashing. Obviously, it would
> > > have to work in coreboot, so whatever coreboot is doing wrong (or
> > > AMI
> > > is doing right.. my guess is that it's probably something with the
> > > EC
> > > ACPI code), we'd have to figure that out first in order to get the
> > > read/write support.
> > 
> > Either way, since the EC firmware resides in the SPI flash, it'll be
> > no
> > issue to reflash it both by software and hardware.
> 
> On the librems, the EC firmware resides in a separate 64KB SPI flash,
> it's not shared with the bios, and I haven't found a way to access it.

Is it really only 64 KiB? The chip definitely supports more and it seems
a bit small to fit the whole firmware.

> The 'ectool' is able to read it (ram idx reads if i remember
> correctly) but it only worked with AMI BIOS. So there will definitely
> be some work to be done there. You probably know a lot more about this
> already, like what this 'ram idx' is, and why it didn't work in
> coreboot, or if it's possible to read/write the flash using this EDI
> interface, etc...
> 
> > 
> > > > Latest status update for Origami-EC firmware:
> > > > https://www.mail-archive.com/coreboot@coreboot.org/msg50646.html
> > > 
> > > Thanks! Good to see the status update on that.
> > 
> > In order to kickstart the development of the Origami-EC firmware, I
> > am
> > designing evaluation boards for both the KB9012 and the KB3930 that
> > will expose most of the I/O ports with headers, LEDs, buttons,
> > connectors, etc. The design is done with KiCAD and will be released
> > under the GPLv3+ as part of the Origami-EC project. I am also
> > preparing
> > a debug board to reflash the EC on the G505s from the keyboard
> > connector.
> > 
> > There is also ongoing work on the emulator and the SerialICE-like
> > library for relatying and tracing I/O on the device via UART. Also,
> > note that the emulator can now emulate a virtual console so it's
> > already possible to build and interract with the firmware!
> > 
> 
> That's some really great news. A dev board will definitely be useful
> for testing/debugging/developing Origami-EC!
> 
> > Cheers,
> > 
> > Paul
> > 
> > > > On Mon, Feb 5, 2018 at 9:47 PM, Youness Alaoui
> > > >  wrote:
> > > > > Hi Marty,
> > > > > 
> > > > > Unfortunately, the EC firmware on the Librems is not open and
> > > > > we
> > > > > have
> > > > > someone working on that aspect, but with everything we have to
> > > > > handle,
> > > > > I think it's only being done part time.
> > > > > We found something similar to you with the private submodule
> > > > > for
> > > > > the
> > > > > PS/2 module on the OLPC code.
> > > > > More specifically :
> > > > > http://lists.laptop.org/pipermail/openec/2011-January/000158.h
> > > > > tml
> > > > > And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=393
> > > > > 0-A
> > > > > 1
> > > > > 
> > > > > I had opened a ticket a while ago here :
> > > > > https://tracker.pureos.net/T178 which mentions Origami-EC. I
> > > > > don't
> > > > > know the status of that project, maybe you can contact the
> > > > > developer
> > > > > (Paul Kocialkowski) and see where he's at with his development
> > > > > of
> > > > > that
> > > > > project (which, I need to mention, hasn't been publicly
> > > > > launched
> > > > > yet,
> > > > > as far as I know) and he might benefit from your help if you
> > > > > are
> > > > > interested in doing that.
> > > > > The last time we spoke he said :
> > > > > "The OLPC code is nowhere close to usable on any other
> > > > > platform.
> > > > > Additionally, it is so poorly written that I don't think it is
> > > > > a
> > > > > suitable codebase for any future development. On the other
> > > > > hand,
> > > > > my
> > > > > Origami-EC project (that I will publicly launch soon) should
> > > > > provide a
> > > > > flexible codebase to add support for new devices."
> > > > > 
> > > > > Note that the tracker ticket above is quite outdated, we know
> > > > > how
> > > > > to
> > > > > dump the EC (the problem was that it can't be done via
> > > > > hardware
> > > > > because the EC is on the same power rail as the 64KB flash
> > > > > chip,
> > > > > so
> > > > > when we power the flash via hardware, the EC boots and takes
> > > > > control
> > > > > of the SPI lines) but for some reason, we could only dump it
> > > > > via
> > > > > software (using ectool) through the AMI BIOS firmware, with
> > > > > coreboot,
> > > > > we only get 0xFF returned, I don't believe we had time to
> > > > > investigate
> > > > >