On Thu, May 29, 2014 at 4:44 PM, Silkie Carlo <silkiecarlo(a)gmail.com> wrote:
> Hi guys,
>
> I do hope you can help me! I am working on an infosec project at the
> moment, trying to fight the good fight...
>
> I see Coreboot offers excellent lists of compatible chipsets and
> motherboards.
>
> However, I am wondering if anyone has access to a matrix of pre-2009 (i.e.
> pre Intel Advanced Management Technology / pre Intel 965 chipsets)
> motherboards, that Coreboot is compatible with?
>
Does it need to be an Intel chipset? There are some more recent options
available based on AMD and ARM-based chips.
>
> I am *so* hopeful that this may already exist, as I am aware it will take
> a fair amount of digging to pull such a list together!
>
> I am aware, of course, that an X60/s is a great example of such a machine.
> But I am looking for other options too.
>
> With great thanks, in advance.
>
> Silkie
>
> --
>
> Silkie Carlo
>
> silkiecarlo(a)gmail.com (PGP encrypted)
> silkiecarlo(a)cantab.net
>
> www.silkiecarlo.com
> http://about.me/silkiecarlo
>
> 44 7749143651
>
> PGP fingerprint:
> C457 CE9F 77CB 5505 23FC 3196 5983 0D37 3BDC 882E
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
Hello
After my previous failure, I'm now just trying to compile a coreboot with
x60 native video init following libreboot tutorial.
What I did so far:
$ *git clone http://review.coreboot.org/p/coreboot
<http://review.coreboot.org/p/coreboot>*
$ *cd coreboot*
$ *git submodule update --init --checkout*
$ git fetch http://review.coreboot.org/coreboot refs/changes/20/5320/6 &&
git checkout FETCH_HEAD
$ git fetch http://review.coreboot.org/coreboot refs/changes/45/5345/1 &&
git cherry-pick FETCH_HEAD
$ git fetch http://review.coreboot.org/coreboot refs/changes/68/5868/1 &&
git cherry-pick FETCH_HEAD
However at compilation time, I get an implicit declaration of function
"set_top_of_ram" in i945/northbridge.c (173:2)
I guess I'm doing something wrong with git, but I'm not sure what.
Could anyone provide instructions to checkout a version of coreboot with
the native x60 video init that compiles? (and ideally with the serial port
for tablet mode too)
Thanks
I was wondering what is the process for creating new products and what
to call them. In short, who comes up with these names?
For instance, there are a few Intel CPUs called Baytrail - Celerons for
Desktops and Tablets, Atoms for Embedded. They are both represented now
in the coreboot source tree. The Celeron Baytrail-T seems to have been
provided by Google for their Rambi Chromebook. The sources have gone in
src/soc/intel/baytrail.
OK, that seems fair. But it isn't for the Baytrail-I processor (from the
ISG division of Intel). Just recently Sage has committed code for
Baytrail-I as src/soc/intel/fsp_baytrail. I find this very unwieldy and
lacking clarity in naming conventions.
1) In no way is it clear from the names that src/soc/intel/baytrail is
for "D,M,T" versions of the CPU.
2) In no way is it clear from the names that src/soc/intel/fsp_baytrail
is for "I" versions.
3) Why in the world is fsp_ added to the name like that? FSP support
should be somewhat generic in nature and IMHO doesn't need to be spelled
out like that.
4) There is a lot of copied code from src/soc/intel/baytrail to
src/soc/intel/fsp_baytrail. Some integration would by nice.
It would be great if some person or committee were to help clarify and
make naming conventions a little easier to understand.
By the way, I have a fully functional version working on Baytrail-I as
well and I put it in my tree as src/soc/intel/baytrail-isg. Works great
for Bakersport and BayleyBay CRBs. It was my intention to contribute
this at some point, but I doubt now it will get accepted even if better
and more complete.
Cheers,
Sean
Hello
I recently purchased a x60s tablet to learn more about coreboot, and how to
make the boot process as fast as possible. The wacom capabilities are
important as this machine will also be used to take notes - so I figured I
would just apply the patches for the video fix and serial ports support
I applied in this order:
- the video fix described on http://www.libreboot.org/howto.html :
$ git clone http://review.coreboot.org/coreboot
$ cd coreboot
$ git fetch http://review.coreboot.org/coreboot refs/changes/20/5320/6 &&
git checkout FETCH_HEAD
$ git fetch http://review.coreboot.org/coreboot refs/changes/45/5345/1 &&
git cherry-pick FETCH_HEAD
In src/mainboard/lenovo/x60/devicetree.cb, change register "gpu_backlight"
= "0x1280128" to register "gpu_backlight" = "0x879F879E"
- the motherboard recon (needed by serial port) on
http://review.coreboot.org/#/c/5246/5
git fetch http://review.coreboot.org/coreboot refs/changes/46/5246/6 && git
checkout FETCH_HEAD
- the serial port on http://review.coreboot.org/#/c/5239/ :
git fetch http://review.coreboot.org/coreboot refs/changes/39/5239/17 &&
git checkout FETCH_HEAD
- the irda fix on http://review.coreboot.org/#/c/5242/:
git fetch http://review.coreboot.org/coreboot refs/changes/42/5242/15 &&
git checkout FETCH_HEAD
Problem is, after running the sequence of git commands, the video fix is
gone.
I created a new branch as suggested by git to keep the patches (git branch
new_branch_name ....), but since I never played with git before I guess I
did something wrong.
I could take the patches and manually apply them (in fact I'm about to do
that!), but I wonder what is the proper way to do it - and also if I'm
missing any important recent patch not mentioned in the online guides.
Also, would anyone here already have a .config for a more or less kernel
finetuned (ie no useless peripherals or modules) for a x60 using coreboot?
Starting from a good base would save some time.
Thanks for any help !
I wanted to know which physical port of my multiple USB controllers have
the debug capability. There was no way to find that easily, so I created
a tool which will do most of the work for the user.
Example output:
The following PCI devices support a USB debug port (says lspci):
0000:00:1d.7
The following PCI devices support a USB debug port (says the kernel):
0000:00:1d.7
PCI device 0000:00:1d.7, USB bus 3, USB physical port 1
Currently connected high-speed devices:
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M
|__ Port 2: Dev 20, If 0, Class=stor., Driver=usb-storage, 480M
The output can be improved, but it's a good start.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Am 30.05.2014 01:44, schrieb Silkie Carlo:
> However, I am wondering if anyone has access to a matrix of pre-2009
> (i.e. pre Intel Advanced Management Technology / pre Intel 965 chipsets)
> motherboards, that Coreboot is compatible with?
GM45 has optional ME - if there's no ME firmware to be found, it
deactivates itself. We benefit from that on the roda/rk9 model.
Patrick
I thought you had to go further back than 2009 to get pre-AMT chipsets,
was I wrong on that?
ron
On Thu, May 29, 2014 at 4:44 PM, Silkie Carlo <silkiecarlo(a)gmail.com> wrote:
> Hi guys,
>
> I do hope you can help me! I am working on an infosec project at the
> moment, trying to fight the good fight...
>
> I see Coreboot offers excellent lists of compatible chipsets and
> motherboards.
>
> However, I am wondering if anyone has access to a matrix of pre-2009 (i.e.
> pre Intel Advanced Management Technology / pre Intel 965 chipsets)
> motherboards, that Coreboot is compatible with?
>
> I am *so* hopeful that this may already exist, as I am aware it will take
> a fair amount of digging to pull such a list together!
>
> I am aware, of course, that an X60/s is a great example of such a machine.
> But I am looking for other options too.
>
> With great thanks, in advance.
>
> Silkie
>
> --
>
> Silkie Carlo
>
> silkiecarlo(a)gmail.com (PGP encrypted)
> silkiecarlo(a)cantab.net
>
> www.silkiecarlo.com
> http://about.me/silkiecarlo
>
> 44 7749143651
>
> PGP fingerprint:
> C457 CE9F 77CB 5505 23FC 3196 5983 0D37 3BDC 882E
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
Hi guys,
I do hope you can help me! I am working on an infosec project at the
moment, trying to fight the good fight...
I see Coreboot offers excellent lists of compatible chipsets and
motherboards.
However, I am wondering if anyone has access to a matrix of pre-2009 (i.e.
pre Intel Advanced Management Technology / pre Intel 965 chipsets)
motherboards, that Coreboot is compatible with?
I am *so* hopeful that this may already exist, as I am aware it will take a
fair amount of digging to pull such a list together!
I am aware, of course, that an X60/s is a great example of such a machine.
But I am looking for other options too.
With great thanks, in advance.
Silkie
--
Silkie Carlo
silkiecarlo(a)gmail.com (PGP encrypted)
silkiecarlo(a)cantab.net
www.silkiecarlo.comhttp://about.me/silkiecarlo
44 7749143651
PGP fingerprint:
C457 CE9F 77CB 5505 23FC 3196 5983 0D37 3BDC 882E
Yes, that worked. Thank you so much!
Seems obvious in restrspect.
:-)
Mark Mason
Engineering Design Team
> Mark C. Mason [mailto:mark@edt.com] wrote:
>
> ]Hey Scott, we're working with a design where only DIMM 0 is present.
> ]Do you happen to know where AMD excludes the out-of-place dimm?
> ]
> ]Thanks,
> ]Mark
>
> Hello Mark,
>
> I think it might be in mmExcludeDimm.c, or maybe
> the caller of one of the functions in that file.
> I remember finding it a few years ago and it
> wasn't easy. The good news is that you shouldn't
> have to modify the agesa code. The solution might
> be to change the buildOpts.c line:
>
> NUMBER_OF_DIMMS_SUPPORTED (ANY_SOCKET, ANY_CHANNEL, 2)
>
> from 2 to 1. Once you do this, update spdAddrLookup
> in devicetree.cb to match.
> Thanks,
> Scott
options are broken for x86 because it is assuming big endian. A quick
patch to make it work:
diff --git a/payloads/libpayload/drivers/options.c
b/payloads/libpayload/drivers
index 70c2b17..a7a5d82 100644
--- a/payloads/libpayload/drivers/options.c
+++ b/payloads/libpayload/drivers/options.c
@@ -69,7 +69,7 @@ int options_checksum_valid(const struct nvram_accessor
*nvram)
checksum += nvram->read(i);
}
- checksum_old = ((nvram->read(checksum_location)<<8) |
nvram->read(checks
+ checksum_old = ((nvram->read(checksum_location+1)<<8) |
nvram->read(chec
return (checksum_old == checksum);
}
Maybe a union and assigning each byte is the correct approach?
Cheers,
Sean
