[coreboot] Re: Any live usb for recovery flash coreboot?

[Alberto Bursi]

On 31/10/19 19:08, da...@tutanota.com wrote:
> It turns out installing archlinux to a usb doesn't work. The screen is black 
> and there are no logs. I don't know why.
>
> I think I just need a live usb with iomem=relaxedalready set. How to make 
> this?
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org


You should ask that in Arch forums, not Coreboot mailing list.

I still suggest disregarding Arch pride and use another distro that has 
a GRUB screen to get out of this pickle.


-Alberto

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Any live usb for recovery flash coreboot?

[Alberto Bursi]

On 31/10/19 07:58, Dalao wrote:
Hi, I was using Seabios but recently switched to Tianocore. However, the 
tianocore can't boot my Manjaro linux distribution which was installed using 
the non-uefi method. So I want to flash back.

I only have a Manjaro live usb at hand. The tianecore can boot it. However this 
live usb is not set with iomem=relaxed, so I can't read or write the bios using 
flashrom.

I don't know how to set the live usb's grub settings because when it boots, 
it's already running commands. When using this tianocore with vgabios I can't 
see the grub screen when booting.

So how to set the live usb with iomem=relaxed?
Is there any live usb that already have the iomem=relaxed set?
Could anyone help me build a usb image dedicated for automatically recover 
flashing?



Most other distros I know (Debian, Ubuntu, OpenSUSE) will have GRUB boot 
splash, and from there you can add kernel command line parameters.

See https://wiki.ubuntu.com/Kernel/KernelBootParameters for example.

So just make another liveUSB with a different distro.

-Alberto
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: ASUS AM1I-A and AM1M-A, ECC

[Alberto Bursi]

Unbuffered and/or NOT registered.

The buffered/registered is cheaper on ebay, and also higher density (up to 32GB 
or 64GB per DDR3 DIMM) so it could look like a bargain but it isn't.

It's cheaper because you can't use it on most consumer hardware.

AMD hardware that supports buffered and/or Registered ECC is Threadripper or 
server processors (Opteron, Epyc).

Similar for Intel, only server-grade Xeons and Enthusiast i7 processors (Socket 
2xxx or something) support that.

Buffered/Registered RAM exists for servers that need to use large amounts of 
RAM, hundreds of GB or even a TB or more (for multi-CPU systems).

-Alberto

On 26/09/19 03:34, Matt B wrote:
Hello,

This might be a dumb question, but not having a manual to go off of, would the 
ECC ram have to be buffered or unbuffered? (if it can be made to work with the 
AM1I-A at all) Any other important specifications?

I bought a AM1I-A (I've had my eye on a good deal on ebay) and it should be 
here in a couple of weeks.

Sincerely,
-Matt


On Mon, Sep 23, 2019 at 8:06 PM Matt B 
mailto:matthewwbradl...@gmail.com>> wrote:
Hello,

That has short but very informative indeed. Thank you. :)

Even if the pinout is the same, is it possible that some connections have been 
left disconnected or components unpopulated on the board, which would prevent 
ECC from working?

As a more general porting question, what steps should be taken in porting 
coreboot to the larger board (the 'M' variant) to avoid unpleasant consequences?

I would think the PCI layout would be different (obvious, since one board has 
more slots then the other) but what should not be assumed to be the same?

Thanks,
-Matt



___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to 
coreboot-le...@coreboot.org

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] T430s prop BIOS Image

[Alberto Bursi]

Afaik there are companies that will ship you a pre-programmed SPI chip for most 
devices, for like 20 euros.

I used this one in the past http://www.bios-chip24.com/en_US but there are 
others too.

This is of course just as secure as getting it from some random guy on the 
internet (i.e. not that much).

-Alberto

On 09/11/18 16:23, Maillist wrote:

Hi,

thank you, i tried that already , but it didnt work, neither simply mounting 
the iso, not with 7zip under windows,  neither with dd to usb nor with nero/ 
burning it to a cd ( i used nero because i saw in hexeditor that the iso was 
build with it).

Therefor, i really need that image somehow. No worrys about me getting hacked, 
neither that image nor that board will be used (just ifd for a little test).

Let me know if you have any ideas left.

cheers jonathan

On 11/9/18 11:47 AM, Rafael Machado wrote:
Hi
The safer solution is to get it from the Manufacturer's website (nor relying on 
someone's image, you may be hacked this way).
In this case you can download this .iso and "dd" to a usbdevice.
With this you will find the .bin with the entire bios image:

https://support.lenovo.com/br/pt/downloads/ds029725

Hope it can help.

Best Regards
Rafael R. Machado

Em qui, 8 de nov de 2018 às 18:06, Maillist 
mailto:maill...@cryptogs.de>> escreveu:
Hey Guys, does anyone happen to have a t430s bios image? I kinda had way
to much mate this morning, so i was a little bit to enthusiastically
while desoldering and ripped the WSON-8 chip from the board. I soldered
wires to the pins, but wasnt able to recover the image, and without ifd,
i cant build coreboot.


cheers


--
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

Re: [coreboot] UEFI Payload update

[Alberto Bursi]

Slim-bootloader is BSD-license. Not just NIH, it "fixes" one of the last 
big Coreboot "isses", the license.

Gotta protect your IP man, think of the children.

-Alberto

On 9/18/2018 11:54 AM, Ivan Ivanov wrote:
> Slim Bootloader? Thanks, but
> " We wanted the open source Intel ME / FSP firmwares, and all we got
> is this lousy byproduct of Not-Invented-Here syndrome "
> /thread
> вт, 18 сент. 2018 г. в 5:18, You, Benjamin :
>> Hi,
>>
>> A staging project "UEFIPayload" has been started to upgrade the 
>> Coreboot*Pkgs in EDK II repository.
>>
>> The new features are:
>> - Supporting Slim Bootloader (https://github.com/slimbootloader) in addition 
>> to Coreboot
>> - Source file configuration using .ini format
>> - User extension using simple "C" libs
>> - Platform supporting lib
>>
>> The link of this project is: 
>> https://github.com/tianocore/edk2-staging/tree/UEFIPayload
>>
>> Thanks,
>>
>> - ben
>>
>>
>> --
>> 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] Equus "WHITEBOX OPEN" servers ship with Coreboot/LinuxBoot

[Alberto Bursi]

There was an announcement [1] about a new line of servers called 
WHITEBOX OPEN (yes, all caps)

which appears to be about servers with Coreboot or Linuxboot and OpenBMC.

Has anyone any experience with this company?


-Alberto

1. https://www.prweb.com/releases/2018/06/prweb15571110.htm

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

Re: [coreboot] KGPE-D16: Trouble using three PCIe cards simultaneously

[Alberto Bursi]

On 02/06/2018 22:03, Daniel Kulesz via coreboot wrote:
> Hi folks,
>
> maybe this is not really coreboot-related, but I am experiencing an issue 
> with the KGPE-D16 that there seems to be no working constellation how the 
> following three cards can be put into service:
>
> - nvidia GPU (PCIe 3 x16, takes 1 slot but occupies two)
> - ASUS hypercard (PCIe 3 x16, takes 1 slot, has four M.2 slot with PCIe x4 
> each), see [1]
> - USB3 controller card (PCIe x4, takes 1 slot)
>
> No matter what I try, the hypercard is unable to detect more than two M.2 
> ssds. And only in the following config:
>
> 1 (MIO): empty
> 2: GPU
> 3: (GPU)
> 4: Hypercard
> 5: empty
>
> When I put the USB3 card in 5, only one of the M.2 ssds on the hypercard is 
> recognized. Therefore, I also tried swapping stuff in many combinations such 
> as the following:
>
> 1: empty
> 2: Hypercard
> 3: empty
> 4: USB3
> 5: GPU
>
> But no matter what I do, there seems to be now way to get all three cards 
> working simulaneously. Even with JUST the hypercard and nothing else it will 
> only detect two of the three M.2 cards inserted. :/
>
> Seems like the vendor bios has the same issue. My plan now is to get a GPU 
> that occupies only 1 slot and put the USB3 card next to it.
>
> Any help and clarifying explanations on this topic are warmly welcome.
>
> Cheers, Daniel
>
>
> [1] https://www.asus.com/Motherboard-Accessory/HYPER-M-2-X16-CARD/
>

It might need to be booted in UEFI mode to work, are you using tianocore 
payload (the UEFI payload) in your coreboot firmware on that board?

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

Re: [coreboot] When does AMD release the fam15 spectre microcode updates?

[Alberto Bursi]

On 22/05/2018 07:03, taii...@gmx.com wrote:
> AMD has at long last coughed up the stuff to the linux-firmware people
>
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/diff/amd-ucode/microcode_amd_fam15h.bin?id=77101513943ef198e2050667c87abf19e6cbb1d8
>
> The fam15h microcode update adds IBPB
>
>    * Indirect Branch Prediction Barrier (IBPB)
>      * PRED_CMD MSR is available:  YES
>      * CPU indicates IBPB capability:  YES  (IBPB_SUPPORT feature bit)
>
> The question is what about the other stuff? IBRS, STIBP? This is
> confusing due to zero documentation on these updates from amd...Why
> don't they have those in this update? Would it be possible to easily add
> the support flags without microcode for those who use libreboot?
>

What you mean with "add the support flags without microcode"?

A CPU either supports some instructions (like IBPB) because it actually 
does (i.e. the microcode tells it how to do that), or it does not.

I don't know if you can fake enable these support flags, but I don't 
think it is a good idea at all, at best it would just be a lie, at worst 
it could cause issues (crashing?) if the kernel calls an instruction 
that isn't available (I don't know how that is handled).

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

Re: [coreboot] flashrom on osx ...

[Alberto Bursi]

On 11/05/2018 19:42, ron minnich wrote:
> if I just want to use a dediprog sf100 what's the best way to build 
> flashrom on osx?
>
> besides "throw the macbook in the trash and get a real computer" :-)
>
> ron
>
>

There is "homebrew" package manager for OSX/MacOS, see here https://brew.sh/

They have latest flashrom https://formulae.brew.sh/formula/flashrom 
among  a big list of other commandline stuff you might find useful.

-Alberto

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

Re: [coreboot] Server systems shipped with coreboot

[Alberto Bursi]

I was writing within context of this mail thread.

This mail "thread" is about Coreboot on server systems, and no major 
manufacturer I know of, apart from IBM and the board from Raptor 
Engineering ever used Coreboot on server systems, so yeah, on server 
boards it is nearly always retrofitted by the end user or some third 
party that resells it.

-Alberto


On 03/24/2018 12:08 AM, Nico Huber wrote:
> On 23.03.2018 22:37, Alberto Bursi wrote:
>> I wanted to say what I said.
>> Dell, HP, Supermicro, Tyan, and whatever other OEM making commercial
>> servers I know of
>> is highly unlikely to accept a RMA or provide any support on their
>> hardware if you install Coreboot.
> What I was trying to tell you was that they might already ship hardware
> with coreboot. You make the impression that you have no idea about how
> much coreboot is already used in products.
>
> What you mean, I guess, is installing coreboot on hardware that didn't
> ship with it. But you make it sound like coreboot is always something
> retrofitted.
>
> Nico

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

Re: [coreboot] Server systems shipped with coreboot

[Alberto Bursi]

It IS lying if you don't tell them you installed Coreboot and pretend 
the issue happened with UEFI.

Also, manufacturer warranty does not cover damage done by the user, and 
flashing a third party firmware is usually enough to claim whatever 
happens to it afterwards it's your fault.
In general, anything can be used to claim the damage is your fault and 
just laugh and deny the RMA request. Who sues them over a RMA anyway.

In the EU consumer laws add seller warranty where the seller basically 
has to replace the device regardless (as they require the seller to 
demonstrate that the damage was done by the custom firmware), but that's 
another thing, and in 99% of the cases they actually honour the warranty 
(which isn't a given, Amazon and bigger ones usually do) they just toss 
your RMA in the bin and give you a new one.

-Alberto

On 03/23/2018 11:54 PM, taii...@gmx.com wrote:
> On 03/23/2018 06:33 PM, Alberto Bursi wrote:
>
>> Yeah, getting an RMA isn't hard if you just lie. Won't work for non-RMA 
>> support requests though.
> It isn't lying if OEM never stated pre-purchase that you aren't allowed
> to flash your own firmware.
> It is the same as how many laptop OEM's want you to have windows
> installed when you RMA a laptop.
>

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

Re: [coreboot] Server systems shipped with coreboot

[Alberto Bursi]

Yeah, getting an RMA isn't hard if you just lie. Won't work for non-RMA 
support requests though.


-Alberto


On 03/23/2018 10:43 PM, taii...@gmx.com wrote:
> On 03/23/2018 05:37 PM, Alberto Bursi wrote:
>
>> I wanted to say what I said. Dell, HP, Supermicro, Tyan, and whatever other 
>> OEM making commercial servers I know of is highly unlikely to accept a RMA 
>> or provide any support on their hardware if you install Coreboot.
>> Therefore any seller of such devices would have to provide such support  and 
>> warranty on their own.
>>
>> If you just tampered the UEFI firmware is much less of an issue for RMA and 
>> support (in my experience), depending on how bad you tampered with it, 
>> anyway.
> Which is why you re-flash the original factory firmware before you RMA
> it >:D
>

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

Re: [coreboot] Server systems shipped with coreboot

[Alberto Bursi]

I wanted to say what I said.
Dell, HP, Supermicro, Tyan, and whatever other OEM making commercial 
servers I know of
is highly unlikely to accept a RMA or provide any support on their 
hardware if you install Coreboot.
Therefore any seller of such devices would have to provide such support 
and warranty on their own.

If you just tampered the UEFI firmware is much less of an issue for RMA 
and support (in my experience), depending on how bad you tampered with 
it, anyway.

-Alberto


On 03/23/2018 10:17 PM, Nico Huber wrote:
> On 23.03.2018 20:28, Alberto Bursi wrote:
>> Of course they will have to be able to provide any warranty and support
>> over the devices they sell because Intel or whoever actually made the
>> server/board will not really support nor accept RMAs of stuff with
>> Coreboot on it.
> That's some unfortunate wording. I guess what you wanted to say is
> something like "stuff with tampered firmware". coreboot isn't strange
> to every manufacturer. Why would it be? it's the best firmware you can
> get for your hardware.
>
> Nico

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

Re: [coreboot] Server systems shipped with coreboot

[Alberto Bursi]

Same "I am not a lawyer" disclaimer for what I'm going to say here.


I don't think the seller can be held liable for anything, as long as 
they clearly stated what they did to the hardware they are selling.

Of course they will have to be able to provide any warranty and support 
over the devices they sell because Intel or whoever actually made the 
server/board will not really support nor accept RMAs of stuff with 
Coreboot on it.

-Alberto

On 03/23/2018 06:55 PM, tpear...@raptorengineering.com wrote:
> I am not a lawyer, but have some understanding of the relevant liability
> law.  This is not legal advice.
>
> If damage is cause to the hardware that the ME would have prevented, very
> likely.  Same goes for any security holes opened by removing the ME.  This
> is not a supported option by Intel, so (practically*) they have no further
> liability for anything that goes wrong on ME scrubbed systems.
>
> * You would need to prove in an airtight manner that the same defect shows
> up on fully updated ME-enabled systems.  Given the closed nature of the ME
> this may be difficult in a legal environment short of reproducing a defect
> across multiple ME-enabled identical systems.
>
>> Hi all,
>>
>> Searching legal implications of reselling deblobbed hardware, and can't
>> fight straight answers.
>>
>> If the bios is replaced, and ME is disabled with its modules erased, could
>> the maker pursue the seller for having made those modifications?
>>
>> Thanks,
>> Thierry
>>
>> Le mar. 23 janv. 2018 13:56, Timothy Pearson
>> 
>> a écrit :
>>
>>> -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 taii...@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@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-
>>>
>>> --
>>> 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

Re: [coreboot] Real name policy

[Alberto Bursi]

On 08/03/2018 01:05, taii...@gmx.com wrote:
> A lot of people whos opinions I respect have commented on this and I 
> thank them for their time but that being said I still don't understand 
> how a "real" name policy helps avoid problems, it isn't as if the 
> coreboot leadership meets someone in real life and asks them to 
> present a passport which is then verified by a handy federal officer.
>

It's not to verify your name, as you pointed out it's not very effective 
at that.

The measure is there to make sure that a company can't say the code you 
posted was theirs (which is what happened with SCO).

With a real/plausible name, if they want to claim it's their stuff in 
court, then they need to pull up someone with that name, using that 
email, which is also a programmer that could have plausibly done that, 
and also claim that this person was their own employee at the time the 
code was posted.

It's not impossible to pull this off, but it is so much harder than if 
the project accepted nicknames without email (that have no legal value, 
i.e. you don't have the nickname on your ID card) or totally anonymous 
contributions.

And any company that told the judge that their man was posting with a 
fake name would just get laughed out of court.

> I wish to correct a few small bugs but at the same time I don't want 
> to provide my name, what should I do? (C) Taiidan 2018 all rights 
> reserved? IANAL but I don't see that as any different from an 
> unverified name.
>

Human names, even if fake, work for the above thing, nicknames don't.

It's a measure to protect the project from legal trolling, not to 
confirm the contributors identity.

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

Re: [coreboot] (libre) Add-on cards for getting higher SSD throughput on the KGPE-D16?

[Alberto Bursi]

On 03/01/2018 09:20 PM, Timothy Pearson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/01/2018 01:36 PM, Daniel Kulesz via coreboot wrote:
>> Hi,
>>
>>
>> (3) put in some PCIe SATA3 card => any recommended chips that respect 
>> freedom?
> There are very few.  You can try some of the Marvell devices but you
> will still be limited by the host side bus as these old Opterons only
> support PCIe v2.
>

Marvell and Asmedia controllers on sata cards are kinda garbage, many 
quirks.

Neither respects freedom anyway but a SAS controller crossflashed to IT 
(dumb) mode (so that it does not have any RAID capability) is the most 
reliable way to add Sata ports to a board, as SAS is retrocompatible 
with Sata, and SAS controllers have an entirely different level of 
quality (both hardware and drivers).

>> (4) get a m.2 SSD instead together with some PCIe adapter => the cards don't 
>> have a co-processor, right?
> Yes, they do.  NVMe devices have an integrated proprietary controller to
> manage data storage / wear levelling.

If we go that way, also mechanical hard drives, USB flash drives and 
pretty much any storage device showing up as "block device" has a 
storage controller running a proprietary firmware.

SSD firmware is more complex and their controllers are very beefy and 
usually multicore because of performance though.

>> (5) stay with SATA2 and live with the limited speed
>>
>> Any recommendations for a freedom-respecting choice?
>

Sata2 speed limitation is less bad than it might sound. What matters 
most for system responsiveness is the transfer speed on random 
read/writes, which is NOT anywhere near Sata 2 speed cap, more like 
20-50MB/s at most on very fast SSDs. Just look up SSD benchmarks for 
actual stats.

The high speed numbers on SSDs are for sequential transfers, for example 
when you copy over a relatively large file, and that will hit the Sata 2 
speed limitation.

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

Re: [coreboot] External flashing PCI-e RAID card firmware

[Alberto Bursi]

On 15/02/2018 02:56, taii...@gmx.com wrote:
> I am contemplating the purchase of an ASUS PIKE for my KGPE-D16 and I 
> was wondering if anyone here knows if it is possible to externally 
> re-flash them.
>
> I notice a SOIC-8 chip on the front of the card and I imagine the 
> firmware is there, does it entail simply hooking up a test clip and 
> using flashrom as one would with a motherboard?
>
> 20% chance the manufacturers utility performs some type of secret 
> sauce that is required for it to function.
>

the sas controllers require multiple flashes at different positions,  
and afaik only the manufacturer's utility knows where.

I don't think it is doing anything particularly exotic, and it works 
from FreeDOS, so you can just follow the tutorials and then use the 
external flasher to see what is being done to the flash chip so you know 
where it writes stuff, and maybe write down some info about this in a 
wiki for future readers.

But then again what's the point, you're (cross)flashing a proprietary 
firmware anyway, just use the tools provided by manufacturer.
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Microcode updates for slightly older intel CPU's re: meltdown/spectre

[Alberto Bursi]

This assumes security was a concern in the first place, which is not 
what I see where I live/work.


On 01/11/2018 11:27 PM, Timothy Pearson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> What I'm more concerned about right now is something I'd term "security
> apathy".  We just learned 99% of the world's computers are insecure in
> one way or another; security is now something that (to most people)
> apparently cannot be purchased.  In such an environment, the cheapest
> system per unit performance always wins, even if it happens to contain
> rampant abuses of privacy / backdoors.
>
> Probably a discussion best had over coffee, since it's largely
> unfixable, but suffice it to say we're already starting to see this even
> in our original customer base.
>
> On 01/11/2018 04:22 PM, taii...@gmx.com wrote:
>> On 01/11/2018 05:05 AM, Nico Huber wrote:
>>
>>> you seem to be misinformed about the G505s. There is no open-source gfx
>>> init for AMD (not in firmware, not in the OS), so within your require-
>>> ments it's not usable as a laptop.
>> I forgot to include my usual suffix mentioning that blobs are required
>> for video (and power management)
>>
>> I believe it is still much better than the C2D laptops in terms of
>> security despite the video blob as it has an IOMMU [1] and no ME/PSP.
>> [1] with the high end quad core CPU option
 (as the previous C2D/C2Q's
 such as the X200 are now permanently insecure without intervention from
 intel apparently)
>>> It depends on the software you run. Please read more about Meltdown and
>>> Spectre. When you understood it, you can still start to worry.
>>>
 At this point even a massive performance loss is better than having to
 throw out so much now-useless hardware.
>>> Yes? and that can be accomplished without microcode updates, AFAIK.
>> I was and still am under the impression that fixing both issue classes
>> requires microcode updates, can you link to a better explanation?
>>
>
> - -- 
> 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
>
> iQEcBAEBAgAGBQJaV+TkAAoJEK+E3vEXDOFbghEH/ivQ84bm11KHSDs8+EIWSP1J
> XeQvhxHlsz5ZNYA16a7QU+dWhn8vOo6es3yBmTgOPsVzu1PUgXwgX1QnfUyAzrml
> 59d7TZE7p8MtgCAmsUruNgVdPgXEPK/Qh/6uUarVh8U7bRpaOEVcc2thJZCRDLQw
> U4m8+Z5RudnDz9ZiPVfMKhpqSVJ+FTBzr3uCp+Mqr9CFIV3GxbwWCkoEPbo1hNrq
> O+ZfCk24GseFfI8fjfpP523nARd8bX0WEUodRaw/l58+vspjGo3DyvjrWpcdJRHg
> X+dg0I9CKVPt7doFh4NscPmNAhia9R8JfeTj3qCoMiFAvSHcBgb7p8Q8xitIkw0=
> =gkEr
> -END PGP SIGNATURE-
>

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

Re: [coreboot] smd work

[Alberto Bursi]

If it's a one-off thing, then soldering iron with small tip (and possibly some 
temperature control), solder, thin solder wick, then watch some youtube videos 
to see how to use them for smd work.

Basically you blob solder on all pins to have the thing heat up all the pins 
together so you can then remove the chip. For soldering you solder without 
caring too much about bridging pins with solder, then apply solder wick and 
soldering iron to suck up any excess solder. You basically waste a ton of 
solder.

Solder wick is magic stuff. Very recommended for any fine soldering job.

If you want to do this more than a few times, then get a hot air rework 
station, which is a box with an air pump connected to a tool with a tube (many 
also have a temperature-controlled soldering iron with a small tip) or hot air 
desoldering gun. SMD rework tools with hot air must have some kind of 
temperature control for their airflow, that's what makes them different from 
DIY-oriented hot air guns (those used to strip paint).

Without temperature control on the airflow it will likely burn the board or the 
components. Again watching youtube videos helps, as you will have to heat up 
well the part, and don't pull with any real strenght, if some pin isn't fully 
unsoldered you will ruin the trace on the board and then it will get fun to try 
to fix that.

-Alberto

On 12/28/2017 06:47 PM, ron minnich wrote:
A friend of mine wants to do some SPI rework. He wants a  16M part in his 
chromebook, not 8M. (hmm, so do I). Given the huge expertise of this group, I 
wonder if you have advice about equipment he should get.

Soldering irons? hot air guns? magic wands?

thanks

ron



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

Re: [coreboot] Re : Re: Coreboot Purism BIOS is free? open?

[Alberto Bursi]

"TrustZone is only an operational mode of the CPU, not a whole computing 
subsystem like ME with its own CPU running its OS"

Both do the same job, allowing a customer to run its applications in a 
"safe" environment.

I don't know why Intel could not just do something similar to TrustZone, 
maybe Intel CPUs have too much legacy modes so trying to make another 
mode is too hard, or Intel went for the more secret and "safe" way it 
could do, as a dedicated processor is much more secret and "safer".

"the physical and .. legal owner for me.."

Many embedded devices are just tools to provide a service. You did not 
buy the hardware, you bought the service.

Like for example the smartphones provided by mobile carriers. You bought 
a phone contract where the phone was included (for cheap), but the phone 
is not really yours.

They keep pushing this mindset into PCs where it does not belong (yet), 
but in embedded it's very common.


"If ARM SoCs can live without this kind of ... companion for the main 
CPU, what remains the argument of Intel to convince us of the fact the 
their CPUs cannot live without their beloved ME running side-by-side"

Because they used their ME also for themselves, to keep their own 
proprietary components "safe". As I said, the ME is responsible of 
initialization and of running some advanced hardware features (like fan 
control or power management).

It's called "eating their own dog food". 
https://en.wikipedia.org/wiki/Eating_your_own_dog_food

They genuinely think ME is so great and safe that they are the first 
using it to hide their own secrets.

-Alberto

On 12/25/2017 12:07 AM, eche...@free.fr wrote:
> Thank you Alberto for the answers, but I was not questioning the ME "per-se".
> Anyway, if ME is required for platform initialization, why not stopping it 
> after said "platform initialization"?
> Also you said "ARM provides TrustZone, which is something like Intel ME". 
> Permit me to disagree : TrustZone is only an operational mode of the CPU, not 
> a whole computing subsystem like ME with its own CPU running its OS..
> Also as you said ARM ltd doesn't strongarm (pun unintented..) its customers 
> to make ALWAYS Trustzone uncontrolable by the "end user" (the physical and .. 
> legal owner for me..)
> If ARM SoCs can live without this kind of ... companion for the main CPU, 
> what remains the argument of Intel to convince us of the fact the their CPUs 
> cannot live without their beloved ME running side-by-side (I know, I know, 
> Intel doesn't have to speak to us miserable microbes, their real customers 
> are more noble entities...)
>
> But anyway (and I will stop here with my trolls..), back to the main topic of 
> this thread:
>   - Purism guys : I for one, I think that you are doing a really great job 
> (my previous mail was a troll/sarcasm, take it with a tongue in cheek :-P) 
> and I wish you great successes, but as other senders said in this thread, I 
> think that we, the Libre community cannot put big hopes in the promises of 
> entities like Intel or AMD anymore, and should actively explore alternatives 
> to the x86 world (and encourage initiative like Talos..)
>
> That being said have a nice and happy Christmas!
>Florentin Demetrescu
>   
> - Mail d'origine -
> De: Alberto Bursi <alberto.bu...@outlook.it>
> À: coreboot@coreboot.org, eche...@free.fr
> Envoyé: Sun, 24 Dec 2017 22:27:28 +0100 (CET)
> Objet: Re: [coreboot] Coreboot Purism BIOS is free? open?
>
> Meh, Intel ME is necessary for x86 platform initalization. Without ME
> the PC does not start at all.
>
> Anyway, the ME is used to provide third parties control and "security"
> over the user's system by cutting out the middleman (board firmware).
> Due to technical reasons they added all this functionality in a single
> place, because it would be silly to have 3 different hardware backdoors
> when you can just have one doing 3 different things.
>
> On consumer PCs it provides DRM, and on office PCs it provides limited
> (but quite useful) remote management, plus more (it can execute a
> customer's dedicated java applications on its own integrated JVM, for
> example).
>
> For example I've seen some Dell PCs that had integrated some kind of
> third party anti-theft functionality inside their UEFI firmware, where
> you would license a third party software and then connect your PC's UEFI
> firmware to their servers or something, so when it is stolen it can
> still be tracked whenever it connects to the internet again.
> Don't know if this feature is using the Intel ME, but it is an example
> of feature the OEM might want to add to their products.
>
> Intel themselves also added random 

Re: [coreboot] Coreboot Purism BIOS is free? open?

[Alberto Bursi]

Meh, Intel ME is necessary for x86 platform initalization. Without ME 
the PC does not start at all.

Anyway, the ME is used to provide third parties control and "security" 
over the user's system by cutting out the middleman (board firmware). 
Due to technical reasons they added all this functionality in a single 
place, because it would be silly to have 3 different hardware backdoors 
when you can just have one doing 3 different things.

On consumer PCs it provides DRM, and on office PCs it provides limited 
(but quite useful) remote management, plus more (it can execute a 
customer's dedicated java applications on its own integrated JVM, for 
example).

For example I've seen some Dell PCs that had integrated some kind of 
third party anti-theft functionality inside their UEFI firmware, where 
you would license a third party software and then connect your PC's UEFI 
firmware to their servers or something, so when it is stolen it can 
still be tracked whenever it connects to the internet again.
Don't know if this feature is using the Intel ME, but it is an example 
of feature the OEM might want to add to their products.

Intel themselves also added random stuff to the ME (like advanced fan 
speed control), just because they had a relatively powerful processor in 
there, so why not add more features to it. see here 
https://en.wikipedia.org/wiki/Intel_Management_Engine#Modules

Does the industry ask for this? Maybe. What is sure is that Intel thinks 
that this backdoor thingy offers features their customers want or might 
find interesting to add features to their products. These features 
should be the ones sought after by end users.

And "Customers" in this case is companies designing PCs and embedded 
systems with Intel products. Not people, end users. End users buy 
motherboards or PCs from Intel's customers.

Note that ARM provides TrustZone, which is something like Intel ME, but 
is a generic feature, the OEM can do whatever it wants with it, even 
disable and not use it at all.
AMD mindlessly followed Intel's footsteps by integrating ARM cores 
running the TrustZone feature, and calling this Platform Security Processor.

So it's not just Intel that thinks his customers might want more control 
over the products they sell to the end user. Maybe they are all 
misguided. Maybe not.

Remember, it does not matter what is actually real, but what company 
managers think is real.

There is many people that still thinks that "secret" is "safe", and that 
does not understand that software will have bugs, that it's only a 
matter of time before it becomes vulnerable.

For example, HDCP (HDMI cable antipiracy feature) is still in use even 
if it was (and is) regularly busted by 30$ devices. Not even for 
pirating, usually it is busted because it is causing compatibility 
issues in devices.

The people in charge of government agencies in the US know better, at 
least. They asked for a ME feature to disable it in the hardware with 
High Assurance Platform certification.
And due to Intel being cheap, this switch is available in all MEs after 
version 11, Intel didn't make a custom ME only for the US government. 
Currently it requires using external tools to edit the setting on the 
motherboard's flash chip (or being an OEM), same as the older method of 
nuking modules manually.


I hope I helped you understand the most likely reasons why ME exists.

-Alberto

On 12/24/2017 08:46 PM, eche...@free.fr wrote:
>   By the way you said : "ODMs/OEMs are the real customers of Intel/AMD" and 
> "Intel/AMD serve them law" (which law???)
>   I have a scoop : a friend of mine happened to work in the marketing 
> department of a (very large) OEM, and speaking about ME he told me that Intel 
> OBLIGED them to adopt and integrate the ME! (in the beging the OEM guys were 
> reluctant..)
>   Of course this is only "street whispering" (and I will not force you to buy 
> this..) but, but, as we say in Romanian "there is no smoke without fire..." 
> ;-)
> Just my 2 satoshis..
>Florentin
>
> - Mail d'origine -
> De: eche...@free.fr
> À: coreboot@coreboot.org
> Envoyé: Sun, 24 Dec 2017 20:31:53 +0100 (CET)
> Objet: Re : Re: [coreboot] Coreboot Purism BIOS is free? open?
>
>   No you didn't answer my question Peter, sorry!..
>   I am NOT questioning the "legitimacy" of ME/PSP (be it from a purely 
> corporate/financial point of view..). (By the way I have no "legitimacy" 
> myself to put this question of "legitimacy" to begin with..)
>   I simply don't understand (and this is why I pollute the coreboot ML with 
> this blah-blah..) why ALL (I insist on capital letters _ALL_) the systems 
> (consumer/office even .. industrial..) have to have this kind of .. 
> "technology" activated ALL the time (at least from the Intel/AMD point of 
> view)??
>   For me this is simply irrational!.. Period!..
> (And for the fact that consumer devices outnumber 
> office/industrial/governmental devices, I will belive you when I see REAL 
> 

Re: [coreboot] Coreboot Purism BIOS is free? open?

[Alberto Bursi]

On 12/23/2017 11:54 AM, Nico Huber wrote:
> On 23.12.2017 11:39, Nico Huber wrote:
>> [1] I'm convinced that this is easily doable. At least compared to the
>>  effort you already put in liberating the unliberatable. If the i.MX8
>>  turns out to be as controllable and well documented as the i.MX6,
>>  you'd be catapulted towards the end of your freedom roadmap.
>>
> Now that I've looked at your roadmap again, there's a flaw at the
> beginning: AUIU, at least Acer, Dell, HP and Lenovo sell products
> that are on par with yours (Chromebooks). Actually you're basing
> your firmware on their investments into it. So it seems unfair to
> list them there. Some even sell ARM devices that are far ahead (in
> terms of freedom and owner-controllability; not in your roadmap
> because that has a very weird order).
>
> Nico
>

Meh, chromebooks aren't exactly powerful systems anyway. Also I don't 
know other ARM devices that are more free than ARM chromebooks (again 
not really powerful systems).

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

Re: [coreboot] Disabling Intel ME 11 via undocumented mode

[Alberto Bursi]

On 12/08/2017 02:59 PM, Timothy Pearson wrote:
>
> That's just the HAP bit.  The ME is limited but NOT disabled, and the
> remaining stubs are still hackable [1].
>
> Neither the ME or the PSP can ever be removed from their respective
> systems.  They can both be limited to some extent, but to call either of
> them "disabled" is rather far from the truth.
>
>

Hacking them requires being able to write in the SPI flash, or to have 
buggy UEFI firmware. Which means most systems are still vulnerable.

But it is also true that if someone can hack UEFI he pwns you anyway, 
even without ME.

So imho ME with the HAP bit can be called "disabled", although the fight 
isn't over as ME isn't the only thing that was a threat anyway.

There is still need to secure the UEFI firmware (which is needed even if 
ME didn't exist), and doing a hardware mod to have a hardware switch to 
turn the SPI chip read-only at the hardware level (also needed 
regardless of ME).

I think many SPI chips only need some pin pulled high/low to go in 
read-only mode, and I frankly trust a dumb switch many orders of 
magnitude more than Boot Guard or anything software-based.

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

Re: [coreboot] a blast from the past

[Alberto Bursi]

On 10/28/2017 03:27 PM, ron minnich wrote:
2005, los alamos, a talk on EFI I had forgotten I had done.

https://www.coreboot.org/images/d/d1/Openefi.pdf

relevant to the current era.



Sounds like the evil master plan behind your NERF project. https://trmm.net/NERF

Good luck with it, we really need this.

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

Re: [coreboot] ast2400 / ast2500

[Alberto Bursi]

On 10/21/2017 07:22 PM, Tirumalesh wrote:
> Using complete open source firmware is just one of the important 
> advantages.
>
> In my understanding coreboot provides lot more than that for a small team.
>
> 1. No drivers in firmware(leaving some basic things like spi etc)
> 2. A single image (firmware + Linux + rootfs)
> 3. The above means it’s very convenient for updates (major source of 
> security bugs)
> 4. Using same firmware on x86 and bmc means, what ever infra we 
> develop for board bring up and ops (as coreboot payload) works on both.
> 5. Same thing for secure booting.
>
>
> Most of the time the above things are also very important.
>
> Thanks,
> Tirumalesh.

Coreboot is hardware-specific, so the Coreboot that runs in the x86 
system will be very different from the one running in the BMC. They will 
have the same interfaces to boot a payload of course.

I'm not sure what kind of firmware you plan to deploy on both the x86 
system and the BMC.

The BMC has a very weak ARM processor and not much onboard flash for 
firmware. It is much better if you do 2 different payloads already.

Besides, on ARM systems the board bringup part (what Coreboot was born 
for) is done by a bootROM (read-only memory inside the ARM SoC, you 
can't do anything to this). Then it loads a bootloader from the device's 
flash memory.
This bootloader then does some more initalization, and then that loads a 
linux kernel written on raw flash or something like that and executes it.
 From there the Linux kernel takes over.

For the AST2400 the bootloader is uboot, and the openbmc project has the 
source to compile this part too so you can have a fully open system 
https://github.com/openbmc/u-boot/commit/f03ebaa6c2aefc49c0fdd6bdca51c666ba52663a

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

Re: [coreboot] ast2400 / ast2500

[Alberto Bursi]

What's the point?

Coreboot is not supposed to be used as BMC firmware.

If you want open BMC firmware you need to look for OpenBMC project, that 
supports Aspeed BMC chips and provides all features a BMC firmware 
should provide. https://github.com/openbmc/openbmc


On 10/21/2017 04:00 AM, Tirumalesh wrote:
> Thanks for the information.
>
> As I understand correctly, the main support is for x86 only. So if we 
> want to run coreboot as the only firmware, we have to do it our self.
>
> Thanks,
> Tirumalesh
>
> On Fri, Oct 20, 2017 at 6:42 PM, taii...@gmx.com  > wrote:
>> On 10/20/2017 03:04 PM, Tirumalesh wrote: > Thanks for the reply, it 
>> is somewhat strange though. > > It means no server board runs fully 
>> with coreboot as firmware for both c86 and BMC. > > If this is not 
>> the case, what kind of bmc is used by all the supported boards, all 
>> of them are using different firmware for bmc and x86? As tim said the 
>> KGPE-D16 and KCMA-D8 have a fully open source libre init process on 
>> coreboot and support the libre OpenBMC for the AST BMC chip There 
>> aren't any other coreboot boards that support a BMC, and the only 
>> other device that has both fully open source firmware/init and an 
>> open source BMC off the shelf is the TALOS 2. Coreboot itself 
>> couldn't be ran on a BMC chip, well I suppose one could port it but 
>> there really wouldn't be a point to that as that isn't what it was 
>> designed for. PS welcome to the list :D 
>
>

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

Re: [coreboot] Coreboot ECC support in Asrock IMB-A180-H

[Alberto Bursi]

On 09/10/2017 09:49 PM, Piotr Król wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
>
>
> On 09/10/2017 01:04 PM, Kyösti Mälkki wrote:
>
> Hi Kyösti, Alberto,
>
>> At this very moment apu2/apu3 4GB models are marketed without ECC
>> support. Latest available binaryPI build (which contains a fix for
>> ECC) is otherwise not compatible. You can thank AMD for not even
>> allowing their commercial customers, who have access to said PI
>> sources under NDA, to distribute fixed builds.
> We planned get back to ECC issue in coming month by exercising 2 ideas
> from forum [1]:
>
> 1. Mentioned by Kyösti usage of UEFI payload and MemTest86 v7 Pro
> Edition. I already started work on payload [2] and have ability to
> boot to UEFI shell, but now working storage drivers yet.
>
> 2. Use rowhammer_test mentioned in last post [1].
>
> But it looks I completely forget mentioned bug. I assume above
> scenarios will not work in light of mentioned bug ?
>
> We know which version of AGESA breaks apu2/3. It is [3]. We tried to
> disable graphics in various ways, but nothing helps.
>
> @Kyösti, maybe it is related to PspMboxBiosCmdDramInfo and
> PspMboxBiosCmdExitBootServices commands and PSP support in coreboot ?
>
>
> [1]
> http://pcengines.info/forums/?page=post=E35B5D34-262B-480E-9887-F7F2A
> 292E02F=DF5ACB70-99C4-4C61-AFA6-4C0E0DB05B2A=2
> [2] https://github.com/3mdeb/edk2/tree/apu2-uefi
> [3]
> https://review.coreboot.org/cgit/blobs.git/commit/?id=95b80508d9ba26350b
> 7e699decd47074f480a2f2
>
> - -- 
> Piotr Król
> Embedded Systems Consultant
> https://3mdeb.com | @3mdeb_com
>
Thanks for your efforts!

A quick-and-dirty way of causing bitflips is overclocking RAM.
Once RAM starts becoming unstable, there will be bitflips and the ECC 
will log errors.
The results of this test can't say if the ECC catched *all* bitflips, or 
just some, but will at least show if it works at all.
This was used to get some proof that Ryzen ECC was working [1].

The only other ways of testing ECC RAM is to have dedicated hardware for 
that, modified DIMMs with a switch or masking tape that interrupts some 
contacts (or shorting to the ground if it is all soldered like yours).
I would trust the hardware method better, as the system can't lie as it 
theoretically can with ECC injection, and you don't need to rely on 
Memtest or whatever other software doing a good job.

1. 
http://www.hardwarecanucks.com/forum/hardware-canucks-reviews/75030-ecc-memory-amds-ryzen-deep-dive-4.html

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

Re: [coreboot] Coreboot ECC support in Asrock IMB-A180-H

[Alberto Bursi]

On 09/07/2017 01:24 PM, Kyösti Mälkki wrote:
> On Thu, Sep 7, 2017 at 1:40 PM, Nico Huber <nic...@gmx.de> wrote:
>> Hello Alberto,
>>
>>   On 09/06/2017 09:30 PM, Alberto Bursi wrote:
>>> I've stumbled upon a Asrock IMB-A180-H board (a eKabini-based
>>> "industrial" mini-itx motherboard) on ebay and since it is supported by
>>> Coreboot I was considering about purchasing it.
>>>
>>> The APU onboard supports ECC ram (ECC so-dimms are kinda rare but I can
>>> find them), while of course the Asrock site does not say anything about
>>> ECC support (how unexpected).
>> it's rather unlikely that a board supports it when the manufacturer
>> doesn't mention it. ECC support needs additional traces on the main-
>> board (as the bus is 72 bits wide instead of 64 bits). So just having
>> compatible chips doesn't suffice.
>>
> See JEDEC Module 4.20.18 vs 4.20.21 standards.
>
> SODIMM 204-pin socket pinout for 64bit non-ECC vs 72bit ECC is already
> different.
> Some ground pins have been sacrificed to fit those extra ECC bits in the 
> socket.
> In other words: no amount of open source will give you ECC SO-DIMM support 
> when
> PCB was designed otherwise.
>
> That board is one of eKabini reference desings, schematics check tells me ECC
> pins of the APU SOC part are not connected.
>
> Kyösti

Thanks a lot for the information! :)
I had some suspicions about socket/board support too as I think also 
DIMMs have the same issue.

Since I really wanted ECC capability, I'll probably get a PCEngines APU 
with 4GB of RAM, which was designed for ECC and seems to have it enabled 
in their stock firmware (coreboot-based) from the feedback I saw.
 From the schematics https://pcengines.ch/schema/apu2c.pdf it seems they 
have one screen port connected to a pinout on the board, although stock 
firmware disables it to use less power. Can do without screen too if I 
can't hack it, it's main usage will be network infrastructure anyway. 
Was just a nice bonus.

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

Re: [coreboot] INT 13, real mode, block write commands and coreboot

[Alberto Bursi]

On 08/09/2017 04:42, taii...@gmx.com wrote:
> AFAIK the more higher performance beagleboards such as the X15 have 
> native pci-e devices for sata, esata, ethernet etc.
>
> I would suggest a more free device such as a BeagleBoard, the RPI 
> foundation only likes open source when it is convenient with them 
> (side question - how come so many laymen think it is an open source 
> hardware?)
>
> If you get a RPI for a long term project you're eventually going to 
> run in to issues when support ends and the blobs no longer work with 
> new distros/kernels.
>

you probably missed the info that Broadcom there is an open driver for 
VC4 made by Eric Anholt (is also in Mesa mainline), which was hired by 
Broadcom years ago and is now also making VC5 driver (next gen of that GPU).

Currently the only thing needed by Raspi (1, 2, 3) is the firmware blob 
for booting and board initialization (running on bare metal in the GPU 
part of the SoC), that will still work fine in the future.

So Raspi has now upstream support for everything (also its own wifi chip 
is supported, don't know about bluetooth but would be surprising if it 
doesn't).

It took them like 4 years of lying about it being "open source", but now 
it is.

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

Re: [coreboot] Coreboot ECC support in Asrock IMB-A180-H

[Alberto Bursi]

On 09/06/2017 09:30 PM, Alberto Bursi wrote:
> I've stumbled upon a Asrock IMB-A180-H board (a eKabini-based
> "industrial" mini-itx motherboard) on ebay and since it is supported by
> Coreboot I was considering about purchasing it.
>
> The APU onboard supports ECC ram (ECC so-dimms are kinda rare but I can
> find them), while of course the Asrock site does not say anything about
> ECC support (how unexpected).
>
> I was wondering if Coreboot can enable ECC ram support on this board,
> and how to do so (I can read the docs on my own for the rest).
>
> I cc'ed this email to Martin Roth because while googling I found his
> personal page in the coreboot wiki, and there he states he has 2 Asrock
> IMB-A180 (same board with one HDMI and one LVDS port instead of 2 HDMI
> ports), so he might know this board better.
>
> -Alberto
>

Sent too soon, now it has a proper subject line.

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

[coreboot] (no subject)

[Alberto Bursi]

I've stumbled upon a Asrock IMB-A180-H board (a eKabini-based 
"industrial" mini-itx motherboard) on ebay and since it is supported by 
Coreboot I was considering about purchasing it.

The APU onboard supports ECC ram (ECC so-dimms are kinda rare but I can 
find them), while of course the Asrock site does not say anything about 
ECC support (how unexpected).

I was wondering if Coreboot can enable ECC ram support on this board, 
and how to do so (I can read the docs on my own for the rest).

I cc'ed this email to Martin Roth because while googling I found his 
personal page in the coreboot wiki, and there he states he has 2 Asrock 
IMB-A180 (same board with one HDMI and one LVDS port instead of 2 HDMI 
ports), so he might know this board better.

-Alberto

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

Re: [coreboot] util/cbfstool in coreboot master

[Alberto Bursi]

On 21/08/2017 11:36, Patrick Georgi via coreboot wrote:
> That's sad. The only fix I see is to take down the mirror.
>
>
> Patrick

How about adding a few lines in readme aimed at github users?

The README is most likely the first thing most sane perople read before 
compiling, or if there are issues.

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

Re: [coreboot] DIY Laptop with a desktop board

[Alberto Bursi]

On 08/07/2017 11:55 PM, taii...@gmx.com wrote:
> I am considering creating a DIY laptop that can fit an ATX board with 
> a 35W CPU - such as KCMA-D8 with a EE series opteron.
>
> Has anyone here done this before? are there some potential gotchas I 
> haven't thought of? making a custom "1U" case with a screen and 
> keyboard doesn't seem that difficult in theory - I would use a minibox 
> ATX plug PSU for power with the round laptop style ac adapter plug for 
> it.
>
> Potential Issues:
> Battery (are there any off the shelf models? probably sold as an 
> integrated ups or w/e) I suppose I can live without one as I am hardly 
> ever away from an outlet.
> Graphics (riser + fan shroud to help remove hot air? the integrated 
> graphics are terrible on these boards)
> Keyboard (for the "beta" I would machine a custom case for a usb 
> laptop style keyboard)
> Lack of a dock connection (but this could be fixed via external PCI-e 
> and an enclosure such as the ones from Cyclone Systems - or a PCI-e to 
> expresscard card.)
>
> Am I nuts for wanting to do this? it seems like the only way to get 
> mobile freedom/performance. If I do it would anyone be interested in 
> buying one with a modest markup?
>
>

There are some industrial atx or microatx + screen cases afaik,
  this for example http://rackmountmart.com/html/ppc1006.html

and many slim cases that can be used for that already (screens not 
included) from silverstone and others, for Console-like PCs. And 
portable screens apparently are a thing on Amazon.

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

Re: [coreboot] What do each of the letters B...? , L...? , O...? , B...? represent in the acronym BLOB ?

[Alberto Bursi]

Binary large Object, but it seems like a backronym (someone tried to 
create an acronym with a word used already)

https://en.wikipedia.org/wiki/Binary_large_object


On 31/05/2017 09:57, Don Saklad wrote:
> What do each of the letters B...? , L...? , O...? , B...? represent in
> the acronym BLOB ?
>
>
>Paul Menzel  writes:
>> [1:multipart/signed Hide]
>> [1/1:text/plain Hide]
>> Dear coreboot folks,
>> I am looking for a new portable device available in Europe.
>> Is it true, that the Acer Chromebook R 13 [1], is the only current BLOB
>> free device? The device currently costs 400 €. Is MediaTek “a good
>> citizen”, that means, do they provide datasheets and work on drivers?
>> The Samsung Chromebook Plus/Pro with RK3399 [2] are only available in
>> the USA, right?
>> Thanks,
>> Paul
>> [1] https://www.acer.com/ac/en/US/content/series/acerchromebookr13
>> [2] 
> https://chromeunboxed.com/samsung-chromebook-pros-processor-rk3399-gets-benchmarked-and-it-is-fast/
>> [1/2:application/pgp-signature Show Save:signature.asc (195B)]
>> [2:text/plain Hide]
>

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