-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
4 cores, SMT4. There's an 8-core available for $190 more, and AFAIK
there are plans to start offering an 18-core server chip very shortly.
These are the OpenPOWER machines, so there is hardware virtualization
support (including I/O passthrough) that works well with kvm and QEMU.
I haven't really heard anything referred to as "LPAR" on these newer
POWER8/POWER9 machines outside of legacy documents.
On 01/23/2018 12:47 PM, ron minnich wrote:
> how many cores is that? Does it come with LPAR?
>
> On Mon, Jan 22, 2018 at 9:48 PM Taiidan(a)gmx.com <mailto:Taiidan@gmx.com>
> <Taiidan(a)gmx.com <mailto:Taiidan@gmx.com>> wrote:
>
> In case anyone wants to know the (non-coreboot) libre firmware TALOS 2
> single CPU/board combo is now only 2.5K.
>
> I still can't figure out how they managed to make it so affordable, this
> is seriously great.
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> <mailto:coreboot@coreboot.org>
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
- --
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
https://www.raptorengineering.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJaZ4U2AAoJEK+E3vEXDOFbBUEIAKxL6cD2L27yZh63OhM0TD8h
BZD2r0nYF/NLfGi50KuMZPNzb2lpzgLHc06ZHZmJBU0sFUbTdI3WrYibDPtY4lva
1uG3gedN2u+sUCzTKrLILOyrstlJ2lQ4+8jxyO8PncK9Zx3LtgbSlGVGq+pvxsXI
Ac8Yqm+de6Is8aaAHMMzaT9UNxcjXCAs/zZm3iWcPkA2B0CVVUoKnsFuhtGG1cGd
j4bukGJrojkUMEFxIG93qphcurdP2AjuvOaUdZVuoC0uxdVL2az77SgRUH8Vmxdd
SFhAzG7j4LsqGMwiZBkubBZpSMPj6kPyRQUIxwwAk/vRLpOxoPdaEbrI/9wyIaM=
=PFaf
-----END PGP SIGNATURE-----
On my board with broadwell, the EHCI controller is disable after refcode runs.
RCBA(FD) is 1. After refcode, RCBA(FD) is 0x8001.
So I doubt the PEI data is not filled correctly.
I change all ports like this.
pei_data_usb2_port(pei_data, 0, 0x0080, 1, USB_OC_PIN_SKIP, //1,
USB_PORT_BACK_PANEL);
But it still does not work.
The refcode is extracted from SAMUS board shell ball.
Anybody has an idea? Thanks.
Zheng
Hi,
I would like to test my -rt kernels releases on the minnowboard. Though
cyclictest always reports 2 to 4 ms spikes. It looks like that the
original firmware is stealing those cycles. So my plan was to try out
coreboot and see if my theory is correct or not.
Now, I am struggling with getting anything working. All my attempts to
bake a working binary have been completely fruitless. Not a single char
on the serial port. If I would at least get something on the serial port
I could find my way through the maze.
I am confident that flashing the device is works correctly via my
raspberry pi [2]. When I flash the original firmware, the device comes
back to live again.
Unfortunately, the documentation on how to configure and build coreboot
a bit outdated [1]. My google-foo didn't help either.
Could someone share his/her current config and also post the SHAs of
coreboot? This would rule out that part. I am not sure if my binary
blobs I extracted or downloaded are okay (fd, me, gbe, FSB).
Thanks,
Daniel
[1] https://elinux.org/Minnowboard:MinnowMaxCoreboot
[2]
https://3mdeb.com/firmware/flashing-minnowboard-turbot-with-raspberry-pi-ze…
Hi Michael and Zoran,
On 03/22/2018 08:45 PM, Zoran Stojsavljevic wrote:
> IIRC, there are two types of BYT-i used for IOTG, in INTEL. The CPUIDs
> are 0x30673 (for Revision B) and 0x30679 (for Revision D). You can
> retrieve CPUID using simplistic CLI: dmesg | grep microcode after
> bringing Linux up:
root@mb:~# dmesg | grep microcode
[ 3.332005] microcode: CPU0 sig=0x30679, pf=0x1, revision=0x906
[ 3.332024] microcode: CPU1 sig=0x30679, pf=0x1, revision=0x906
>> What type of Minnowboard do you use?
dmidecode says:
System Information
Manufacturer: ADI
Product Name: Minnowboard Turbot D0 PLATFORM
Version: D0
>> First thing is to make sure the microcode is right without that it will hang
>> before giving any output.
As suggested by Piotr, I just flashed the the bios section of the flash
and now I get some serial output. That seems not suprising because I
went back and took the BAYTRAIL_FSP_GOLD_003_16-SEP-2014.fd FSP.
Thanks,
Daniel
> First thing is to make sure the microcode is right without that it will hang before giving any output.
IIRC, there are two types of BYT-i used for IOTG, in INTEL. The CPUIDs
are 0x30673 (for Revision B) and 0x30679 (for Revision D). You can
retrieve CPUID using simplistic CLI: dmesg | grep microcode after
bringing Linux up:
[vuser@localhost ~]$ dmesg | grep microcode
[ 0.000000] Intel Spectre v2 broken microcode detected; disabling
Speculation Control
[ 3.796088] microcode: sig=0x40651, pf=0x40, revision=0x21
[ 3.796202] microcode: Microcode Update Driver: v2.2.
[vuser@localhost ~]$
Daniel,
I suggest to you to put/flash original BYT-I BIOS back and read from
CMOS the CPUID and MCU numbers. Then you'll know exactly what
ingredients you'll need for Coreboot.
Here are some MCU numbers for BYT-I CPUIDs: 0x30673 (Rev. B) and
0x30679 (Rev. D):
https://lists.denx.de/pipermail/u-boot/2016-May/255536.html
Best Regards,
Zoran
_______
On Thu, Mar 22, 2018 at 6:47 PM, Michael Graichen
<michael.graichen(a)hotmail.com> wrote:
> Hey Daniel,
>
> What type of Minnowboard do you use?
>
> First thing is to make sure the microcode is right without that it will hang
> before giving any output.
>
> Best regards
> Michael
>
>
>
>
>
> -------- Ursprüngliche Nachricht --------
> Von: Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com>
> Datum: 21.03.18 13:23 (GMT+01:00)
> An: Daniel Wagner <wagi(a)monom.org>
> Cc: coreboot <coreboot(a)coreboot.org>
> Betreff: Re: [coreboot] Minnowboard
>
> Hello Daniel,
>
> You need to properly build Coreboot, integrating BYT-I (as I recall
> minnow board) FSP, and the info about BYT-I FSP you can find here:
> https://github.com/IntelFsp/FSP
>
> Zoran
> _______
>
> On Wed, Mar 21, 2018 at 12:47 PM, Daniel Wagner <wagi(a)monom.org> wrote:
>> Hi,
>>
>> I would like to test my -rt kernels releases on the minnowboard. Though
>> cyclictest always reports 2 to 4 ms spikes. It looks like that the
>> original firmware is stealing those cycles. So my plan was to try out
>> coreboot and see if my theory is correct or not.
>>
>> Now, I am struggling with getting anything working. All my attempts to
>> bake a working binary have been completely fruitless. Not a single char
>> on the serial port. If I would at least get something on the serial port
>> I could find my way through the maze.
>>
>> I am confident that flashing the device is works correctly via my
>> raspberry pi [2]. When I flash the original firmware, the device comes
>> back to live again.
>>
>> Unfortunately, the documentation on how to configure and build coreboot
>> a bit outdated [1]. My google-foo didn't help either.
>>
>> Could someone share his/her current config and also post the SHAs of
>> coreboot? This would rule out that part. I am not sure if my binary
>> blobs I extracted or downloaded are okay (fd, me, gbe, FSB).
>>
>> Thanks,
>> Daniel
>>
>> [1] https://elinux.org/Minnowboard:MinnowMaxCoreboot
>> [2]
>>
>> https://3mdeb.com/firmware/flashing-minnowboard-turbot-with-raspberry-pi-ze…
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
Hey Daniel,
What type of Minnowboard do you use?
First thing is to make sure the microcode is right without that it will hang before giving any output.
Best regards
Michael
-------- Ursprüngliche Nachricht --------
Von: Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com>
Datum: 21.03.18 13:23 (GMT+01:00)
An: Daniel Wagner <wagi(a)monom.org>
Cc: coreboot <coreboot(a)coreboot.org>
Betreff: Re: [coreboot] Minnowboard
Hello Daniel,
You need to properly build Coreboot, integrating BYT-I (as I recall
minnow board) FSP, and the info about BYT-I FSP you can find here:
https://github.com/IntelFsp/FSP
Zoran
_______
On Wed, Mar 21, 2018 at 12:47 PM, Daniel Wagner <wagi(a)monom.org> wrote:
> Hi,
>
> I would like to test my -rt kernels releases on the minnowboard. Though
> cyclictest always reports 2 to 4 ms spikes. It looks like that the
> original firmware is stealing those cycles. So my plan was to try out
> coreboot and see if my theory is correct or not.
>
> Now, I am struggling with getting anything working. All my attempts to
> bake a working binary have been completely fruitless. Not a single char
> on the serial port. If I would at least get something on the serial port
> I could find my way through the maze.
>
> I am confident that flashing the device is works correctly via my
> raspberry pi [2]. When I flash the original firmware, the device comes
> back to live again.
>
> Unfortunately, the documentation on how to configure and build coreboot
> a bit outdated [1]. My google-foo didn't help either.
>
> Could someone share his/her current config and also post the SHAs of
> coreboot? This would rule out that part. I am not sure if my binary
> blobs I extracted or downloaded are okay (fd, me, gbe, FSB).
>
> Thanks,
> Daniel
>
> [1] https://elinux.org/Minnowboard:MinnowMaxCoreboot
> [2]
> https://3mdeb.com/firmware/flashing-minnowboard-turbot-with-raspberry-pi-ze…
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
--
coreboot mailing list: coreboot(a)coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot
Hello!
I'm working with Haswell+Lynxpoint chip and it has 6 PCIe bridges presented
on one southbridge device "1c" as six functions (I mean "1c.0", "1c.1", ...,
"1c.5"). As I understand, every function (bridge in this example) can drive
only one INTX line of its "1c" device.
For example, function 1c.2 can drive only INTC of "1c" device. Does it mean
that every device behind 1c.2 PCIe bridge should connect all of its INTA-D
lines to INTC of 1c.2 in order to work?
(by "connect" I mean declare interrupt routing in ACPI/MP table/PIRQ table)
Best Regards,
Aladyshev Konstantin
I am curious of any intel insiders know if there will be microcode
updates released for older intel CPU's (ex: sandy/ivybridge) and failing
that, what can be done in regards to securing them from meltdown/spectre.
I believe this is a relevant coreboot topic considering how many
coreboot boards have these and older CPU's....without a fix there will
be only one coreboot compatible laptop with open source hardware
initiation that is remotely secure (lenovo g505s as has a pre-PSP AMD
CPU) and theoretically owner controllable (as the previous C2D/C2Q's
such as the X200 are now permanently insecure without intervention from
intel apparently)
At this point even a massive performance loss is better than having to
throw out so much now-useless hardware.
Dear coreboot folks,
I’d be great, if you took a few minutes to upload the status of your
board to the board status repository [1].
Please make sure, that in the coreboot repository `git describe --
dirty` doesn’t return a string with *dirty* in it. Often it is caused
by changes in the directory `3rdparty`, which you can fix by running
`make gitconfig` and `git sup`.
Please also make sure to configure at least a valid email address in
git, so in case of questions you can be contacted.
Note, SeaBIOS master is currently broken, meaning that, there are huge
delays if a TPM chip is not found [2]. So, please stay with 1.11.0 or
1.11.1 until the patches [3] are added to SeaBIOS’ master branch.
Thank you for your help,
Paul
PS: I am aware, that the board status script needs to be made more user
friendly, but as long as nobody has time to improve it, it’s what we
have.
[1] util/board_status/README
[2] https://mail.coreboot.org/pipermail/seabios/2018-March/012191.html
[3] https://mail.coreboot.org/pipermail/seabios/2018-March/012223.html
