[coreboot] Setup required for autotest & older boards?

[Jeremy Banks]

Hello all,

Two questions:

First, I was reading the Testing section of the Development Guidelines
on the wiki [1] and the autotest section caught my eye. It said to ask
on the mailing list, so here I am. Besides the always-online host
system, what is the special circuitry required? Is it particularly
expensive or difficult to acquire or set up?

Second, what kinds of boards are considered valuable testing targets? Is
coreboot wanting more testing on newer boards or are there gaps in older
boards, chipsets, super I/Os that need a hardware testing target? I ask
because I'm in the process of cleaning up and have some older
motherboards boards and related parts I will be disposing of. Think
socket AM3, AM2 and older. It's helpful to have these available as
testing targets, great. Otherwise, I'll be disposing of them.

Regards,
Jeremy Banks

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

Re: [coreboot] x200s' nvram will reset to default value if last boot is a normal boot of debian.

[Zoran Stojsavljevic]

Hello Persmule,

Please, forgive for my ignorance regarding X200 HW. No clue how it really
looks inside (except normal, usual configuration).

I have looked into the log, and I do not understand the romstage phase,
namely this:

Memory configured in dual-channel asymmetric mode.
Memory map:
TOM   =   512MB
TOLUD =   512MB
TOUUD =   512MB
REMAP: base  = 65535MB
limit = 0MB
usedMEsize: 0MB
*Performing Jedec initialization at address 0x.*
*Performing Jedec initialization at address 0x0800.*
*Performing Jedec initialization at address 0x1000.*
*Performing Jedec initialization at address 0x1800.*

Seems that you have somewhere in X200 128MB NVRAM as four banks (gives
total of 512MB NVRAM). So, if this repeats every time, regardless how you
shutdown Linux, you need to skip this depending upon the shutdown
conditions.

I repeat, I have no idea what this NVRAM is for? And where/how it is
located? Anyway, 512MB of NVRAM for booting Coreboot, or BIOS (for keeping
postmortem boot-loader or OS parameters) seems too much (at least to me),
don't you think?

Zoran

On Thu, Jan 19, 2017 at 10:11 AM, Persmule  wrote:

> Hi all,
>
> I recently built and flashed a coreboot image to my thinkpad x200s, with
> an IFD generated by libreboot's ich9gen. After flashing, everything seems
> okay, but if I let the Debian GNU/Linux installed on that machine finish
> its booting, all the reasonable value inside NVRAM will be reset to default
> during next boot (detected via nvrancui), whether I shut it down properly
> or cut its power violently.
>
> I have done several tests, whose result is listed below:
>
> Boot mode
> NVRAM reset?
> payload (reboot immediately) no
> parted magic
> no
> trisquel live
> no
> kali live
> no
> Debian recovery mode (reboot immediately)
> no
> Debian installer
> no
> Debian normal boot (with or without display manager)
> yes
> Debian recovery mode (finish recovery and continue booting)
> yes
> Debian normal boot with kernel of Debian installer yes
>
> If I modify those value with nvramtool and reboot, they will be reset to
> default. If I zero the nvram region in a normal booted Debian by running "#
> nvramtool -B /dev/zero" and reboot, the content of NVRAM will keep all
> zero, and will reset during next reboot.
>
> Now in order to keep using my preferred value, I may have to write those
> value to cmos.default, enable STATIC_OPTION_TABLE, and then build them into
> the image.
>
> The problem should be inside the Debian user land. Do you guys have any
> clue how to locate it?
>
> Best regards,
>
> Persmule
>
>
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] !! Resource didn't fit !! / Porting coreboot to the Supermicro X9SPU-F mainboard

[Renze Nicolai]

Hello everyone,

Thanks to some help on IRC the culprit causing the "pci" errors was
found. Disabling the hardware monitoring part of the Super I/O causes
the error to disappear.

Current state is that linux boots with "acpi=off" in the cmdline. With
ACPI the system crashes. A bootlog of linux booting using coreboot on
the X9SPU-F with ACPI enabled, showing the crash, can be found here:

https://gist.github.com/rnplus/99866582dd692557ecccd11a3920edcd

Now that things (sort of) work (linux can boot using acpi=off and the
graphics card works using an extracted vgabios) I would like to learn
how to solve the remaining issues.

The first issue is the hardware monitoring: why does coreboot crash and
what changes to the devicetree should I make to get the hardware
monitoring to function?

The second issue is that Coreboot always tries to enable the IGD (Intel
graphics), even when using a CPU without IGD (Xeon) and without the
Intel VGABIOS. This  results in a crash obviously.

To disable the IGD I put a "return 0;" at the start of the
"init_igd_opregion" function in
"src/northbridge/intel/sandybridge/acpi.c".

Is this the only way to disable IGD or could there be a better place to
stop the IGD code from being run? I think a kconfig parameter like
"DISABLE_IGD" could be a solution, but how are things like this
normally solved?

Also: when there is no VBIOS then maybe the IGD should not be
initialized as well. I suggest doing something with the return value of
"init_opregion_vbt(opregion)", stopping the IGD init when loading the
VBIOS has failed.

I suspect the ACPI issues also have to do with the IGD. Could someone
confirm this?

So the actual question is:
What would be the best way to disable all IGD related code when using a
board that will never make use of the IGD? (The Supermicro X9SPU-F
board has a separate PCIe graphics chip [WPCM450] which is used for
video output)

More information can be found here:
https://github.com/rnplus/coreboot-dev-supermicro-x9spu-f

The board code can be found here:
https://github.com/rnplus/coreboot-dev-supermicro-x9spu-f/tree/master/c
oreboot/src/mainboard/supermicro/x9spu-f

Thank you all for your help!

Greetings,
Renze Nicolai

On zo, 2017-01-15 at 15:28 +0100, Renze Nicolai wrote:
> Hello everyone,
> 
> A small update: The serial port (finally) works! (apparently a
> kconfig
> entry was needed for the superio code to actually enable the serial
> port when it is enabled in code)
> 
> However the actual problem still remains:
> The bootlog reports that something is wrong with the PCI(e) resources
> and when the pci resources are being enabled the boot stops.
> 
> Bootlog can be found here:
> https://github.com/rnplus/coreboot-dev-supermicro-x9spu-f/blob/master
> /i
> nfo/bootlog
> 
> The board code as it is now can be found here:
> https://github.com/rnplus/coreboot-dev-supermicro-x9spu-f/tree/master
> /c
> oreboot-x9spu-f/src/mainboard/supermicro/x9spu-f
> 
> What controls the pci resources? And where could the problem be?
> 
> Also I don't understand where the "subsystemid" values in the device
> tree come from and what they are used for. If someone could explain
> that to me it would help as well.
> 
> Greetings,
> Renze Nicolai
> 
> 
> 
> On Sat, 2017-01-14 at 21:31 +0100, Renze Nicolai wrote:
> > Hello everyone,
> > 
> > I am trying to port coreboot to the Supermicro X9SPU-F mainboard,
> > starting with the code for the ga-b75m-d3v mainboard (which is also
> > based on the Intel C216 chipset).
> > 
> > I've put the code here:
> > https://github.com/rnplus/coreboot-dev-supermicro-x9spu-f/tree/mast
> > er
> > /c
> > oreboot-x9spu-f/src/mainboard/supermicro/x9spu-f
> > 
> > And I've put all the information that might be needed here:
> > https://github.com/rnplus/coreboot-dev-supermicro-x9spu-f/tree/mast
> > er
> > /i
> > nfo
> > 
> > Including a bootlog extracted using the PC speaker:
> > https://github.com/rnplus/coreboot-dev-supermicro-x9spu-f/blob/mast
> > er
> > /i
> > nfo/bootlog
> > 
> > I did not get the serial ports to work yet. The mainboard has both
> > a
> > WPCM450 and a NCT6776F superio chip. I think the serial port on the
> > back of the machine is connected to the NCT6776F chip, which is
> > driven
> > by the WPCM450.
> > 
> > If anyone knows what I did wrong with the superio chips please do
> > tell
> > me!
> > 
> > But the main problem is with the PCI express config: The board
> > stops
> > booting when it tries to enable the resources for PCI 00:1c.6
> > 
> > Earlier in the bootlog this message appears:
> > 
> > 
> > 
> > Setting resources...
> > DOMAIN:  io: base:65 size:203a align:12 gran:0 limit:2f7
> > !! Resource didn't fit !!
> > aligned base 1000 size 1000 limit 2f7  
> > 1fff needs to be <= 2f7 (limit)
> > PCI: 00:1c.6 1c *  [0x0 - 0xfff] io  
> > PCI: 00:1c.6 1c *  [0x0 - 0xfff] io
> > !! Resource didn't fit !!
> > aligned base 1000 size 1000 limit 2f7
> > 1fff needs to be <= 2f7 (limit)
> > PCI: 00:1c.7 1c *  [0x1000 - 0x1fff] 

Re: [coreboot] REACTS Pricing Changes

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/20/2017 02:59 PM, Stefan Reinauer wrote:
> * Timothy Pearson  [170111 23:38]:
>> When you purchase a REACTS license, you are helping us continue to
>> maintain and improve the only publicly available CI hardware testing
>> solution for coreboot.
> 
> The only other one besides this one, which has been available without
> license restrictions and free of charge since 2006:
> 
> https://www.coreboot.org/Distributed_and_Automated_Testsystem
> https://www.coreboot.org/PDFs/LinuxBIOS-testing/coreboot-testsystem.tar.gz

Thank you for correcting that; I keep forgetting about that system.  Do
you know why that system never saw any real uptake?

For what it's worth, REACTS is integrated into the Gerrit workflow and
the board-status repository, and has additional tests that the older
system does not.  We are also working on extending the REACTS to support
new architectures beyond x86, and Raptor Engineering's REACTS instance
has a proven reliability track record spanning over 1 1/2 years of
continuous production operation.  Finally, we do provide the core files
under the AGPL for those with the requisite knowledge and expertise
wishing to roll their own system; the licensed REACTS copies are
intended for the commercial market where reliability, ease of use, and
availability of support are of high importance.

Thanks!

- -- 
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
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYgoHLAAoJEK+E3vEXDOFbmaUIAKz0Mc709amlLry12B1a585B
ujRia34ihZ4RQbMPER9c81DpfZYlPllzUC4pOeVUWagnohKCKE8uVj4VJViZMdrK
Ninbow7EvdAIckgmFhaeqMzT4/9jC66SqLlECVgWdv52rzaRrZ7BThXrE5fy3dt4
F+AbZdyp8m+Co02tQFe2sDGOYzAW1YrCPSu7g3xezri7x2rftS2G8gmnJOxB2axj
E6EY/iOfHkaNwJ0vu872uJqFfofTtClJpRG4A2y6MzCUoRb5pAmZmd9Eu6kioiDX
BySG4xTDzmc8tB9TxQPBpNg4X5ViclZGYZoEmfL/PaATRi9s1AMyoIdMJE1eLuk=
=LaN5
-END PGP SIGNATURE-

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

Re: [coreboot] REACTS Pricing Changes

[Stefan Reinauer]

* Timothy Pearson  [170111 23:38]:
> When you purchase a REACTS license, you are helping us continue to
> maintain and improve the only publicly available CI hardware testing
> solution for coreboot.

The only other one besides this one, which has been available without
license restrictions and free of charge since 2006:

https://www.coreboot.org/Distributed_and_Automated_Testsystem
https://www.coreboot.org/PDFs/LinuxBIOS-testing/coreboot-testsystem.tar.gz

Thanks,

Stefan


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

Re: [coreboot] Fund a TALOS Secure Workstation as coreboot build system

[Zoran Stojsavljevic]

Ron,

Google should devote more funds to you, guys, for the experiments. This is
what I am trying to say. Google should fund couple of these extravagant
platforms, in order to spread Coreboot usage to these server platform
architectures.

Sergey Brin is Russian, and he should help to push Open Source mentality.
Ordinary Russians are very good guys too! ;-)

Zoran

On Fri, Jan 20, 2017 at 7:03 AM, ron minnich  wrote:

> Zoran, you are one of The Good Guys in my world. But I don't understand
> what you're trying to say.
>
> ron
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ASUS KCMA-D8 workstation board port offer

[Timothy Pearson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/20/2017 07:33 AM, Leah Rowe wrote:
> I would also like to point out that Timothy is a psychopath. The
> reason I told him I couldn't pay the final 15k on the KCMA-D8 is
> because I would have ended up *homeless* if I did. He told me he
> didn't care, and that I didn't deserve a home or to eat properly. He
> only cared about that 15k, despite the fact that I already paid the
> full 75 for the D16 contract, and despite all the positive endorsement
> and support that I gave TALOS on libreboot.org when that campaign was
> still running.

All I wish to say is that this is not correct, taken out of context, and
manipulated to sound and mean something very different than it did in
normal online conversation.  The statements above do not reflect
reality, nor what was actually discussed.

Rowe, this is libel in its purest form.  You don't need to compound your
mistakes like this, nor pollute this list with private, confidential
discussions.  You've already admitted you are not going to pay, and
Raptor has already responded by deciding to consider the KCMA-D8 a large
gift to the coreboot community.  All you have accomplished by doing this
was make it so that we are going to have a very difficult time
justifying any work on low to mid range libre software development going
forward.  This doesn't hurt us nearly as much as it hurts the overall
community in the medium range, and I'm saddened to learn that you value
the community and the continuation of reasonably powerful libre-friendly
hardware so little.

- -- 
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
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJYgiydAAoJEK+E3vEXDOFbwZ4IAIDTmGZqfAR1IiU5TB6rYGFL
xtd5nBks1k2uunUP/L06atUZqE63YkY5akII6pt0oXfOJpduokdPq6NpXeMTw2YO
lVrAlGkzPqwIaJmCdB71eoDOQcbYBZBEoi8FJ9TAEule+d3AcqrZiAB1bDXjH6cd
nJdwiXWnPqBLFyCwtY7wkUIJiWAZZHN1hULwpc0P8nZ5LJsmFav3U2y8Vx5M9HKP
ZSRUSE+5P/6Y4jxtWQAdReRVKTkNqx+h/A8fMnTCoYLJcx3q4jOhsr2oXucrIYuh
DbbnFXjGkYkGBjjocMaKPUbQ1DEZYaaEAj0CK/8A9ShWxtSVqBE7z7Pvs4E2mGw=
=nLCr
-END PGP SIGNATURE-

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

[coreboot] Rangeley FSP reports "Err[24]: GetSet Value exceeds limits" during memory init

[Andy Knowles]

I'm trying to bring up an Intel Rangeley based prototype board using coreboot 
and Intel FSP. During FspInitEntry, FSP prints:

Err[24]: GetSet Value exceeds limits

to serial debug and halts. Does anyone know what this means?

I'm using the Memory Down option in the FSP and filling in the 
MEM_DOWN_DIMM_CONFIG structure in mainboard/.../romstage.c
I can see that the FSP is reading and validating this structure, as changing 
the ram speed has an effect on memory clock frequency, and if I put in invalid 
values the FSP will complain. I've tried reducing memory speed, disabling ECC, 
disabling channel 1 but I always get the same error.

Does anyone else have any experience with Memory Down on Rangeley?

Andy Knowles
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ASUS KCMA-D8 workstation board port offer

[Leah Rowe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I would also like to point out that Timothy is a psychopath. The
reason I told him I couldn't pay the final 15k on the KCMA-D8 is
because I would have ended up *homeless* if I did. He told me he
didn't care, and that I didn't deserve a home or to eat properly. He
only cared about that 15k, despite the fact that I already paid the
full 75 for the D16 contract, and despite all the positive endorsement
and support that I gave TALOS on libreboot.org when that campaign was
still running.

I had every intention of paying Timothy that 15k, if I became able to.
But now that will not happen, as a result of what he has done and said
in the last 24 hours.

On 20/01/17 13:15, Leah Rowe wrote:
> I'm just going to paste what I wrote on phoronix's comments
> section.
> 
> On 19/01/17 17:58, Timothy Pearson wrote:
>> Sorry to revive an old thread, but as many of you are aware 
>> Minifree (Leah Rowe) contracted with us to port the KCMA-D8 and 
>> release it.  We performed this work and the KCMA-D8 continues to 
>> operate, however Minifree has decided not to pay their contract
>> on this work.  We strongly recommend that no person do any
>> business with Minifree or its founder Leah Rowe, as they do not
>> honor their legally binding contracts.
> 
> 
> 
> I'm perfectly happy for Raptor to publicly complain. This is only 
> fair, and they have the right. However, there are certain facts
> that I would like to point out clearly for the community.
> 
> Fact 1: I paid 100% of the KGPE-D16 contract with was 75k USD I
> did not pay the KCMA-D8 contract which was 15k. Timothy's email
> implies that I barely paid any of it. The D8 was a mere extension
> on top of the D16 and was a few weeks work for Timothy. The article
> also implies that I was unwilling to pay the remaining 15k. I was
> actually *unable* to pay. Big difference. I fully paid for the
> KGPE-D16 contract, and D16 is all that Minifree sells. Most people
> don't use D8 and it wasn't viable to sell. I would also like to
> point out that several organisations now use the KGPE-D16 with
> libreboot. This includes the Free Software Foundation, to host
> their websites. I personally sacrificed a lot to pull that off. I
> find it deeply insulting that Timothy causes all this fuss about
> the D8. The D8 port was also missold to me. I was lead to believe
> that the hardware was readily available when it wasn't (unlike D16
> hardware), so the work for the D8 was more or less a waste of
> resources.
> 
> Fact 2: Libreboot is not a dead project. We are currently working
> on a new release behind the scenes. We've merged an entirely new
> build system that was written from scratch, to replace the old one
> (the one that is "stagnant and hard to use" according to the
> article). It's in the libreboot git repository as I speak, it was
> merged a few days ago. Please mention this. The new build system is
> extremely modern, flexible and easy to use. It adds many features
> which the old build system lacked, such as (but certainly not
> limited to): * easy ability to build and integrate linux kernel
> payloads (*hint* petitboot *hint*) * integrates all
> chromebook-related utils, for rockchip ARM chromebooks * integrates
> chromeos flashrom, in addition to upstream flashrom * generally
> better design, more modular, easier to maintain, easier to build *
> plus a whole host of other advantages * about 10 new chromebooks
> have been added to libreboot. So much for libreboot being dead,
> eh?
> 
> Please also mention that Libreboot is actually abandoning coreboot
> and will be using Librecore as upstream. This will be covered in
> my upcoming FOSDEM talk too. We have been quite public about this 
> already, on the Libreboot bug tracker.
> 
> I would also like to point out, that so far Raptor Engineering has
> not fixed the bug on KGPE-D16 where above 128GiB RAM becomes
> unstable to the point of being unusable. Only up to 128GiB works.
> This is less than what the contract suggests. They also released
> source code that was broken; memory initialization was broken on
> most memory modules. It took 6 months after the initial release of
> the KGPE-D16 source code for them to make memory initialization
> work, and even now raminit only works with a few modules.
> 
> This is in addition to other bugs which they haven't fixed. I also 
> have IRC logs of private conversations between me and Timothy,
> where he states that he's willing to let the free/libre hardware
> movement crash and burn. This was before the dispute that happened
> yesterday regarding payment.
> 
> 
> 
> 

- -- 
Leah Rowe

Libreboot developer

Use free software. Free as in freedom.
https://en.wikipedia.org/wiki/Free_software

Use a free operating system, GNU+Linux.
https://libreboot.org/docs/distros/
Or BSD:
https://libreboot.org/docs/bsd/

Use a free BIOS.
https://libreboot.org/

Support computer user freedom.
https://peers.community/

Minifree Ltd, trading as Ministry of 

Re: [coreboot] ASUS KCMA-D8 workstation board port offer

[Leah Rowe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm just going to paste what I wrote on phoronix's comments section.

On 19/01/17 17:58, Timothy Pearson wrote:
> Sorry to revive an old thread, but as many of you are aware
> Minifree (Leah Rowe) contracted with us to port the KCMA-D8 and
> release it.  We performed this work and the KCMA-D8 continues to
> operate, however Minifree has decided not to pay their contract on
> this work.  We strongly recommend that no person do any business
> with Minifree or its founder Leah Rowe, as they do not honor their
> legally binding contracts.
> 
> 

I'm perfectly happy for Raptor to publicly complain. This is only
fair, and they have the right. However, there are certain facts that I
would like to point out clearly for the community.

Fact 1: I paid 100% of the KGPE-D16 contract with was 75k USD I did
not pay the KCMA-D8 contract which was 15k. Timothy's email implies
that I barely paid any of it. The D8 was a mere extension on top of
the D16 and was a few weeks work for Timothy. The article also implies
that I was unwilling to pay the remaining 15k. I was actually *unable*
to pay. Big difference. I fully paid for the KGPE-D16 contract, and
D16 is all that Minifree sells. Most people don't use D8 and it wasn't
viable to sell. I would also like to point out that several
organisations now use the KGPE-D16 with libreboot. This includes the
Free Software Foundation, to host their websites. I personally
sacrificed a lot to pull that off. I find it deeply insulting that
Timothy causes all this fuss about the D8. The D8 port was also
missold to me. I was lead to believe that the hardware was readily
available when it wasn't (unlike D16 hardware), so the work for the D8
was more or less a waste of resources.

Fact 2: Libreboot is not a dead project. We are currently working on a
new release behind the scenes. We've merged an entirely new build
system that was written from scratch, to replace the old one (the one
that is "stagnant and hard to use" according to the article). It's in
the libreboot git repository as I speak, it was merged a few days ago.
Please mention this. The new build system is extremely modern,
flexible and easy to use. It adds many features which the old build
system lacked, such as (but certainly not limited to):
* easy ability to build and integrate linux kernel payloads (*hint*
petitboot *hint*)
* integrates all chromebook-related utils, for rockchip ARM chromebooks
* integrates chromeos flashrom, in addition to upstream flashrom
* generally better design, more modular, easier to maintain, easier to
build
* plus a whole host of other advantages
* about 10 new chromebooks have been added to libreboot. So much for
libreboot being dead, eh?

Please also mention that Libreboot is actually abandoning coreboot and
will be using Librecore as upstream. This will be covered in my
upcoming FOSDEM talk too. We have been quite public about this
already, on the Libreboot bug tracker.

I would also like to point out, that so far Raptor Engineering has not
fixed the bug on KGPE-D16 where above 128GiB RAM becomes unstable to
the point of being unusable. Only up to 128GiB works. This is less
than what the contract suggests. They also released source code that
was broken; memory initialization was broken on most memory modules.
It took 6 months after the initial release of the KGPE-D16 source code
for them to make memory initialization work, and even now raminit only
works with a few modules.

This is in addition to other bugs which they haven't fixed. I also
have IRC logs of private conversations between me and Timothy, where
he states that he's willing to let the free/libre hardware movement
crash and burn. This was before the dispute that happened yesterday
regarding payment.



- -- 
Leah Rowe

Libreboot developer

Use free software. Free as in freedom.
https://en.wikipedia.org/wiki/Free_software

Use a free operating system, GNU+Linux.
https://libreboot.org/docs/distros/
Or BSD:
https://libreboot.org/docs/bsd/

Use a free BIOS.
https://libreboot.org/

Support computer user freedom.
https://peers.community/

Minifree Ltd, trading as Ministry of Freedom | Registered in England,
No. 9361826 | VAT No. GB202190462
Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK |
Web: https://minifree.org/

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYgg1YAAoJEP9Ft0z50c+UTDsH/i6Fwabc7reI7Nnyx0lK64um
8IbM52hji5sJRlZVK3gDgsxRpumXXlIfwEVq0ZTTzvc/ITYO0nrVnQMQAGfGqpDn
r8niubgtTIxpM+ZGKMZTGXTbSjiVi6HhMneckvXl28CljwR5jLwdIeXuD7uW1NCd
JnjOG72UbD8gUfrNao0JDg1q3NFFVwJh9Ri2O0KEP1lvfpgBDx0TQaG6lNTzzOJd
vRUf9UdGAzKvJIvmccUEExXpS7ZDBYtNughr4xHwjaIvoD6+1vvWDoVldkbEGr5Z
Ou9GBXKdQsjaaTbUi+bf+6oenfLElANCXIFdSrRJpMqPefQ1tetKbcqUj1zpVL0=
=3fqL
-END PGP SIGNATURE-

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

Re: [coreboot] ASUS KCMA-D8 workstation board port offer

[Leah Rowe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256



On 19/01/17 17:58, Timothy Pearson wrote:
> Sorry to revive an old thread, but as many of you are aware
> Minifree (Leah Rowe) contracted with us to port the KCMA-D8 and
> release it.  We performed this work and the KCMA-D8 continues to
> operate, however Minifree has decided not to pay their contract on
> this work.  We strongly recommend that no person do any business
> with Minifree or its founder Leah Rowe, as they do not honor their
> legally binding contracts.

Once again, you are painting the picture to be worse than it actually is
.

I paid you 75k USD for KGPE-D16, and didn't pay the 15k for KCMA-D8.

- -- 
Leah Rowe

Libreboot developer

Use free software. Free as in freedom.
https://en.wikipedia.org/wiki/Free_software

Use a free operating system, GNU+Linux.
https://libreboot.org/docs/distros/
Or BSD:
https://libreboot.org/docs/bsd/

Use a free BIOS.
https://libreboot.org/

Support computer user freedom.
https://peers.community/

Minifree Ltd, trading as Ministry of Freedom | Registered in England,
No. 9361826 | VAT No. GB202190462
Registered Office: 19 Hilton Road, Canvey Island, Essex SS8 9QA, UK |
Web: https://minifree.org/

-BEGIN PGP SIGNATURE-

iQEcBAEBCAAGBQJYggwWAAoJEP9Ft0z50c+UITsH/RlN6QX7NUdhGvHkkipN92Ob
EjlTjd88zfvMn+gXcEgrsOuf5ms4gpkJHEouelgXTQqn02slOcNSz736e50U/zsZ
Rn9OCten5Vmh87PHs19uSHNL8yvO4RPEPBT0pFJT+uAoCkhQ5GkE0Ci9hx7o0ljV
KDcwTswP+RBdzhG9C7eliBFlJm24UHw1njULbL8ojje9bokBT2BsmxETorMCxZfe
mJPT/z1dVi0sMSWywO8HTYdxzphUS2zn4CXysYazHOsTaXJwMlgQbHaE9NYTaAxQ
w9XEqP8rwZU0DxGKmsDhrGpsWdosUXbBNtwDmDX14PjtSdvXjkQ7ZvQo4ibnxZc=
=8+gr
-END PGP SIGNATURE-

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