-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
Greetings
Alex Veek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlNxKzsACgkQ53cWmi2XuzOOXAD8CNLPoycJNftQzeHnMQbl8ZG9
4y2SPIHwLota1/Gsfm0BAJzhG2M+MKXDBJgazHjt/HM2DyAeHi6S24sGcwd1W2GN
=sFKM
-----END PGP SIGNATURE-----
Dear coreboot administrators,
Currently, I am unable to fetch the newest commits/objects(?) from the
coreboot git server.
```
$ LANG=C git fetch -vv origin
[…]
have ccbaabe5cf6b7eaa20fc323858680a404383537b
got ack 3 dee643a360ad75787f2982a013c62a4d49352121
got ack 3 a1de1a0810892c3c3a22ed6e2868fbef3bde8134
got ack 3 6a720e16e7e966b034c462242ccdf99e371a1ad7
got ack 3 5d5fb1402be06cacc45d4785201b719e8c3501d1
got ack 3 eb9b2c8105642ba99c34bd727e26483ffc6a0b57
got ack 3 9e882dfff180a75c28a01c49d80e27f545bddb3a
got ack 3 26ee056a55ee835a9c3bfc8b18854cb121e9371c
got ack 3 27c8b82d09083e1733bcd60bb42fc52693615ce8
got ack 3 fec58518a57f67e6e1186a573503ccaec7bcf8e6
got ack 3 4d4286faa0b5e134c71c65e0e3a3a7480ca0d79d
got ack 3 907a0831fb4ac4dc491656d68191274411c65944
got ack 3 30796a481fb752d63bb9b2f939595a29cb18c823
got ack 3 bdcf664a03ef6a4a17b1b367c9ab2fbf34aea244
got ack 3 4be4ad343aa40deaf627ef02da7c07dfcad47b6c
got ack 4 91ec3f1264a85aa57715e059276d96bfbc178c80
done
got ack (4) ccbaabe5cf6b7eaa20fc323858680a404383537b
got ack (1) 4be4ad343aa40deaf627ef02da7c07dfcad47b6c
fatal: internal server error
remote: internal server error
fatal: protocol error: bad pack header
```
Aaron reported the same problem in the IRC channel some days ago, and I
remember having this problem some months ago too.
Could you please take a look on the server?
Kind regards,
Paul
Dear folks and techpriests,
the more I want to contribute and learn about low-level-code the less I
understand, it seems.
1. cb switches the CPU immediately to Protected Mode, yet Payloads like
seaBIOS work in Real Mode. Does coreboot switch the CPU always back
to RM before jumping to the payload?
2. When CB switches to PM - who generates and administrates the Page
Tables and where?
3. Gustavo Duarte writes
<http://duartes.org/gustavo/blog/post/how-computers-boot-up/> that
GRUB switches from protected mode to real mode and vice versa all
the time to address >1MiB of RAM and also use the BIOS-calls. If
this is true using GRUB as payload would not work, as GRUB needs to
call the non-existent BIOS, right?
4. Once CB is in PM it can't access physical addresses anymore? It
doesn't need to, too?
5. PM means RAM-access is only possible through virtual addresses which
are translated by the MMU using the Page Tables. This question is
similar to [2.]: If coreboot generates the Page Tables and the
payload would start in PM as well (is this even possible? At least
the Linux-Kernel has entry points for RM and PM) this would mean the
payload needs to use the Page Tables generated by CB. That wouldn't
be a problem as they're linked in the register CR3 anyways?
And an unimportant bonus question:
* Why does every modern CPU still start in RM? I do get the
compatibility problem, but on the other hand: Do you need it for
anything beside booting MS-DOS on your Ryzen? Is it really
impossible for AMD and Intel to create a new CPU-generation with the
x86-instruction set without RM, 16-bit-registers and 20-bit-mode
registers like CS, SS etc. No modern OS uses bios calls. No CPU is
ever switched to RM again after booting up. They should get rid of
this old stuff.
Would be cool if someone could put this in its true light.
Thanks,
Philipp
Hi,
I wanted to try caching of the MRC training data. As described in Timothy's post, I commented the following line:
> allow_config_restore = 0;
However, I was not able to measure any effects regarding boot time. Does this setting only work with cbfs enabled? And if so, is it necessary to set additionally any cbfs variables?
Cheers, Daniel
P.S.
Hope this time I've set the Reply-To header correctly.
> On 03/02/2017 02:17 PM, Paul Menzel wrote:
> > Dear Arthur, dear Timothy,
> >
> >
> > Am Donnerstag, den 02.03.2017, 13:38 -0600 schrieb Timothy Pearson:
> >> On 03/02/2017 01:30 PM, Arthur Heymans wrote:
> >>> Paul Menzel writes:
> >>>
> >>>> I think most of the time is spent in RAM initialization.
> >>>>
> >>>> 1. Do board owners with similar amount of memory (independent of the
> >>>> board) have similar numbers?
> >>>> 2. What are the ways to improve that? Is it possible? For example, can
> >>>> the modules be probed in parallel (if that isn?t done already)?
> >>>>
> >>>
> >>> I'm not the right person to answer this since I don't know this
> >>> code/hardware that well, but on modern Intel hardware native code uses
> >>> the MRC cache to store dram training results and restore those on
> >>> next boots (and resume from suspend) if no change in dimm configuration
> >>> was detected.
> >>>
> >>> Maybe something like this could also be applied here (or maybe it's already
> >>> the case since it includes code to access spi flash)?
> >>
> >> Yes, this is already implemented as an option, and it does a fairly
> >> decent job of reducing training overhead to almost nothing,
> >
> > Interesting. What option is that?
> >
> > Also, besides the file `s3nv` I don?t see anything else in CBFS. Where
> > is the training data cached?
>
> That's it. The cache is mandatory for S3 resume, and optional at boot.
>
> That being said, the pathways are present but are deactivated due to
> historical instability and are not tied in to an nvram variable at this
> time. If you want to test, you'll need to edit the source file
> "src/northbridge/amd/amdmct/mct_ddr3/mct_d.c"; near line 2730 you'll see
> a FIXME comment and this line:
>
> allow_config_restore = 0;
>
> Comment that line out and recompile to test. I strongly suggest running
> memtest across multiple warm and cold boots (and reboots) before
> determining the functionality is stable enough for use.
by Raptor Engineering Automated Coreboot Test Stand
The ASUS KGPE-D16 fails verification for branch master as of commit ba973bd2de8bf91cc83431333519124bf0f1fd72
The following tests failed:
BOOT_FAILURE
Commits since last successful test:
ba973bd util/abuild: Set exit status on failure
6c1c9d5 Update vboot submodule to upstream master
8f1e1bd Update arm-trusted-firmware submodule to upstream master
See attached log for details
This message was automatically generated from Raptor Engineering's ASUS KGPE-D16 test stand
Want to test on your own equipment? Check out https://www.raptorengineering.com/content/REACTS/intro.html
Raptor Engineering also offers coreboot consulting services! Please visit https://www.raptorengineering.com for more information
Please contact Timothy Pearson at Raptor Engineering <tpearson(a)raptorengineering.com> regarding any issues stemming from this notification
Hello,
im currently following the "Build_Howto" instructions for Coreboot for a
Lenovo X1 Carbon 1gen (3460) and do have a Question: Do ich have to
check "Use native Graphics init", and if not, which one is the correct
configuration?
Sorry for my horrible english,
cheers and greetings from Germany
Jo
you want to extract the refcode blob as so:
cbfstool shellball.rom extract -r BOOT_STUB -n fallback/refcode -f
refcode.elf -m x86
then add it into your build
On Mon, Jul 31, 2017 at 8:43 AM, Zheng Bao <fishbaoz(a)hotmail.com> wrote:
> Thanks. That really helps.
>
>
> About the REFCODE_BLOB, the BLOB I extracted from ball-rom is BIN,
> instead of ELF which is required by current CBFS and rmodule in source.
> (And revision in ball-rom is not in main tree of repository.)
>
> Any idea to get REFCODE_BLOB?
>
>
> Thanks.
>
>
> Zheng
> ------------------------------
> *From:* Nico Huber <nico.huber(a)secunet.com>
> *Sent:* Monday, July 31, 2017 10:52 AM
> *To:* Zheng Bao; coreboot(a)coreboot.org; Matt DeVillier;
> stefan.reinauer(a)coreboot.org
> *Subject:* Re: [coreboot] Broadwell-U hangs at VGA init
>
> Hi Zheng,
>
> On 30.07.2017 16:13, Zheng Bao wrote:
> > I have got the mrc.bin and mem init has got passed.
> > Now the new problem is that it hangs at VGA init.
> >
> > static void igd_setup_panel(struct device *dev)
> > {
> > config_t *conf = dev->chip_info;
> > u32 reg32;
> >
> > /* Setup Digital Port Hotplug */
> > reg32 = gtt_read(PCH_PORT_HOTPLUG); <------- It hangs here.
> > if (!reg32) {
> > reg32 = (conf->gpu_dp_b_hotplug & 0x7) << 2;
> > reg32 |= (conf->gpu_dp_c_hotplug & 0x7) << 10;
> > reg32 |= (conf->gpu_dp_d_hotplug & 0x7) << 18;
> > gtt_write(PCH_PORT_HOTPLUG, reg32);
> > }
> >
> > It turns out as soon as i access VGA bar0+0xc4030, it hangs.
> > while accessing bar0 + 0xa00a is ok.
>
> sounds like the PCH part of the display engine isn't operational (pro-
> bably not all, but most register offsets with bit 19 set reside in the
> PCH). There are few steps to enable it [1], yet the Broadwell port seems
> to rely on the blob to do it. The datasheet [2] suggests that the same
> settings should be done for Broadwell too, but I can't find it in the
> source. So that leads to the conclusion: You forgot to add the second
> blob (HAVE_REFCODE_BLOB, it's BS, it's annoying, but you need it).
>
> That publicly documented settings move from the open source code into
> blobs is a very bad sign, IMO. Now, anybody tell me again, that things
> with Intel are getting better and they might become more open (the sta-
> tistics seem to say the opposite: the blobs get bigger, weirder, take
> over more responsibilities _and_ do a lot of stuff we already had open
> source for earlier platforms).
>
> Nico
>
> [1] src/southbridge/intel/lynxpoint/lpc.c:725
> [2] Intel Document Number: 330837
>
