[coreboot] Re: sources about coreboot devicetree

[Ivan Ivanov]

Hi! What is the purpose of your research? Are you trying to install
coreboot to any platform that you own, or that's a purely "academical"
interest from your side?

чт, 13 июл. 2023 г. в 16:51, bejjeh315--- via coreboot :
>
> Hi
> I want to fully understand the structure of coreboot devicetree and to be 
> able to make chenges, but I couldn't find much resources, only two pages 
> helped me some.. my first question is about resources to learn this..
>
> My second, there are other videos and things talking about devicetree in 
> linux (which I know is different from the corebootie one), do you think 
> reading these ones is helpful for me? or for example learning ASL helps? I'm 
> a newbie in the hardware...
> ___
> 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

[coreboot] Re: regarding virtualization support in coreboot

[Ivan Ivanov]

Hi there, Ritul!

> Does coreboot support virtualization features like SVM, AMD SEV, hard level 
> virtualization SR-IOV?

It depends on a particular board. I.e. before the (unjust IMHO)
removal of G505S laptop from coreboot, it had a full support of IOMMU
and other advanced low-level virtualization features

чт, 6 июл. 2023 г. в 13:36, ritul guru :
>
> Hi,
> Does coreboot support virtualization features like SVM, AMD SEV, hard level 
> virtualization SR-IOV?
>
>
> Thanks & Regards
> Ritul Guru
>
> ___
> 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

[coreboot] Recent commit c202be7 ( payloads/external/LinuxBoot: Clean up ) breaks " make clean "

[Ivan Ivanov]

Good day, friends! After getting this recent commit, doing " make
clean " is not possible in a coreboot directory - I get this error
now:

~/coreboot$ make clean
/bin/sh: 1: go: not found
/bin/sh: 1: go: not found
/bin/sh: 1: [: -eq: unexpected operator

Looks like there's a problem in some script

Best regards,
Ivan Ivanov
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot - Intel NUC

[Ivan Ivanov]

Sell this hardware with a crappy Intel BIOS, and use this money to buy
a coreboot-supported hardware - preferably, AMD-based. Problem solved!

вт, 7 мар. 2023 г. в 21:59, Sandro :
>
> Hello,
>
> I am contacting you to ask for your opinion.
>
> Weeks ago I bought an Intel NUC 11 N5105 (BNUC11ATKC40002 ).
> Since this board does not have any SATA port, I thought that I could use a 
> SilverStone SST-ECS07 connected to the M.2 slot.
>
> When I try to set up the sata adapter connected to my main PC ( ASUS 
> Mainboard ROG Crosshair VIII Hero WI-FI), I have no problems seeing the 
> drives and their partitions As soon as I try the same but in the NUC, 
> then the drives are not found..lots of problems booting, and most of the 
> time I am not even able to enter the original Intel BIOS.
>
> I reached the Intel discord server and I was able to get some feedback from a 
> NUC team member.
> You can see the communication with him at:
> https://discord.com/channels/554824368740630529/1076245516406493195
>
> He was able to confirm the same issues on his side, that it is a problem with 
> this specific model BIOS. And that on other models it works.
>
> Sadly, he also gave me no realistic hopes of receiving a BIOS fix from Intel.
>
> Since I cannot return the products back I am really sad to have just wasted 
> lots of money on these things and not being able to use them.
>
> This is when I came in contact with Coreboot this gave me a small light 
> of hope
>
> Since I really do not know anything about this subject, neither if this would 
> work on this specific motherboard. I decided to ask for some opinions 
> from you.
>
> Hopefully you could give me some good news :)
>
> Thank you very much and I wish you a good day.
>
> Best regards,
> Sandro
>
>
>
>
>
>
> ___
> 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

[coreboot] AMD Lenovo G505S : default screen when using a MiniPCIe-to-PCIe discrete GPU ?

[Ivan Ivanov]

Good day! My friend - also a G505S coreboot'er! - is using the "G505S
discrete GPU" not-merged-yet patch series from
https://review.coreboot.org/c/coreboot/+/58745 , which successfully
get a G505S discrete GPU working (). However, trying to get a better
GPU performance, he's connected an external discrete AMD RX470 GPU to
this laptop's MiniPCIe port (originally meant for WiFi module) using a
MiniPCIe-to-PCIe adapter. So his G505S has three GPUs: internal
integrated HD-8650G, internal discrete (HD-8570M or R5-M230) and
external discrete.

For unknown reasons, G505S coreboot choses this external discrete GPU
as a primary video output, ignoring the laptop's screen. Please, could
you advise where in coreboot we could set up the default video output
priority for this AMD AGESA board? Any idea where to dig?

Best regards,
Ivan
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Fwd: Refactoring duplicate Embedded Controller code

[Ivan Ivanov]

G505S has KB9012 chip on board,  I can guarantee this.  However, maybe
KB9012 is a bit similar to the older chips, and  just the internal 128KB
memory and some features got added.  If you'd look at KB9012 dataset
available online,  I think it had a comparison table of KB9012 vs some
older chip. Hope this helps!

пт, 8 апр. 2022 г., 16:46 Abel Briggs :

> Yes, I was looking at the G505S and its EC when considering these patches.
>
> The situation with the EC in the G505S seems a bit odd. The EC is named
> `ene932`, but there are several commits in the codebase which reference the
> chip as a KB9012. The KB9012 datasheet, however, reference the ENE930
> series chips as the predecessor chip to the KB9010 series.
>
> The S230U has a KB9012 and the Compal firmware seems to have a similar
> `OperationRegion` layout to the firmware in the `ene932`, but the EC query
> values are completely different. The S230U basically defines its own EC in
> its mainboard tree and only uses the `ene932` code for its helper I/O space
> functions.
>
> If anyone has a G505S or its vendor documentation to check that the chip
> on the board is really an ENE930 series, I think that would help clear this
> up.
>
> This is something I was considering trying to refactor as well, by giving
> the S230U its own `ec/` common code. However, I would probably throw that
> patch in with my mainboard's patchset (Lenovo Edge E530), since otherwise
> the S230U would be the only user of that code.
>
> --
> *From:* Ivan Ivanov 
> *Sent:* Friday, April 8, 2022, 4:38 AM
> *To:* Abel Briggs 
> *Cc:* coreboot@coreboot.org 
> *Subject:* Re: [coreboot] Refactoring duplicate Embedded Controller code
>
> If this could help you, coreboot-supported Lenovo G505S also has EC KB9012
>
> чт, 7 апр. 2022 г. в 06:44, Abel Briggs :
> >
> > Hello,
> >
> > I was looking at the code and ACPI for a number of different embedded
> > controllers while adding support for a Lenovo mainboard.
> > The mainboard in question has an EC nearly identical to the Twist S230U
> > (Compal KB9012), so I planned to factor out the S230U's EC code/ACPI
> > into its own chip.
> >
> > While doing this, I noticed there were several duplicate functions
> > across the `ec/` directory, so I'd like to potentially submit some
> > patches to clean them up. However, I'm not sure of the best way to
> > go about this.
> >
> > The following is what I currently have in mind:
> >
> > - Removing most individual `ec_write_cmd()`
> >   and similar functions andreplacing calls with their respective
> `ec/acpi/ec.c` library functions
> > - Removing individual `kbc_` polling functions and sharing the ones
> defined
> >   in `drivers/pc80/keyboard.c`
> >   - Should public library functions for sending and receiving data from
> > a PC80 keyboard controller be defined in the PC80 driver and exported
> > in `include/pc80/keyboard.h`?
> >   - We already have `send_keyboard()` there,
> > which sends a command and receives data - would it be good to add
> > individual functions for those operations as well?
> >
> > Any suggestions or recommendations would be appreciated. I looked for
> > guidelines on suggested code organization in the docs/commit history/
> > mailing list, but came up mostly empty-handed.
> >
> > Thanks!
> >
> > ___
> > 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

[coreboot] Re: Refactoring duplicate Embedded Controller code

[Ivan Ivanov]

If this could help you, coreboot-supported Lenovo G505S also has EC KB9012

чт, 7 апр. 2022 г. в 06:44, Abel Briggs :
>
> Hello,
>
> I was looking at the code and ACPI for a number of different embedded
> controllers while adding support for a Lenovo mainboard.
> The mainboard in question has an EC nearly identical to the Twist S230U
> (Compal KB9012), so I planned to factor out the S230U's EC code/ACPI
> into its own chip.
>
> While doing this, I noticed there were several duplicate functions
> across the `ec/` directory, so I'd like to potentially submit some
> patches to clean them up. However, I'm not sure of the best way to
> go about this.
>
> The following is what I currently have in mind:
>
> - Removing most individual `ec_write_cmd()`
>   and similar functions andreplacing calls with their respective 
> `ec/acpi/ec.c` library functions
> - Removing individual `kbc_` polling functions and sharing the ones defined
>   in `drivers/pc80/keyboard.c`
>   - Should public library functions for sending and receiving data from
> a PC80 keyboard controller be defined in the PC80 driver and exported
> in `include/pc80/keyboard.h`?
>   - We already have `send_keyboard()` there,
> which sends a command and receives data - would it be good to add
> individual functions for those operations as well?
>
> Any suggestions or recommendations would be appreciated. I looked for
> guidelines on suggested code organization in the docs/commit history/
> mailing list, but came up mostly empty-handed.
>
> Thanks!
>
> ___
> 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

[coreboot] Re: Oled switch chipset support

[Ivan Ivanov]

Wow, I didn't know there's a coreboot for Nintendo! Why you guys
didn't even try to commit this source code to the official coreboot
repository? Please, could you share a link to the "coreboot for
nintendo" forked repository, as well as let us know what chipset this
Mariko is using? This will help us to answer your questions about the
possibility of coreboot on Mariko rev of Nintendo Switch

чт, 3 мар. 2022 г. в 14:37, Adolf Hitler via coreboot :
>
>
> So its my understanding that mariko and above boards of nintendo switch have 
> issues with coreboot but the revisions below do not; are there any plans to 
> support the new chipset in the oled switches so we can have the same internal 
> reach as older switches?
>
> Sent from Yahoo Mail for iPhone
> ___
> 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

[coreboot] Re: Sublime Text Syntax Highlighting

[Ivan Ivanov]

Unfortunately it seems that Sublime Text isn't opensource, - and there
are so many open source text editors out there, why focus on
Sublime...

вт, 14 дек. 2021 г. в 20:18, Raul Rangel via coreboot :
>
> Hey all,
> If you use Sublime Text, I wanted to point out the [Coreboot
> Syntax](https://packagecontrol.io/packages/Coreboot%20syntax) package.
> It includes Device Tree support and I recently added ASL support. Let
> me know if you encounter any strange highlighting issues.
>
> Raul
> ___
> 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

[coreboot] Re: How to maintain AGESA-based ports long-term?

[Ivan Ivanov]

Thank you, these seem to be good points. However, in regards to:

> If you have any hope of open-source coreboot for newer platforms, you 
> shouldn't make it harder for coreboot to advance.

Where to advance? Are there any "newer platforms" that are as worthy
as the "older platforms":
1) as secure: no Intel ME / AMD PSP "security" co-processors, which
are seen as harmful to real security by many ;
2) as affordable: the older devices are possible to get used for like
$100-$200. Meanwhile - because of Boot Guard etc. - the "newer
platforms" are unlikely to have coreboot without vendor's involvement,
who will gladly charge a big extra for "coreboot support".
3) as available: these generic consumer electronics, which have been
shipped with a proprietary UEFI but got coreboot support later, have a
huge numbers all over the world - compared to the quite limited
availability of newer coreboot platforms.

Sorry, I don't see any "newer platforms" which would match the "older
platforms" on these critically-important points.
So it doesn't seem reasonable to drop the "crappy code" of "older
platforms" in favor of the "beautiful code" of "newer platforms", if
they could never become as worthy.

Well, maybe some corporation sees their newer platform as "more
worthy" - despite it's losing on all 3 points above and there are
blobs-over-blobs. But they can't speak for the community of opensource
hobbyists all over the world, people like you and me. And pleasing the
corporations by easing their "burden" - while dropping the "older
platforms" which are more worthy - doesn't seem wise, at least to
me...

ср, 1 дек. 2021 г. в 14:26, Nico Huber :
>
> On 01.12.21 11:28, Ivan Ivanov wrote:
> > Good thing about what I've suggested - "different places for v3 and v4
> > allocators" - is that it's (almost?) already done ;-)
>
> It would mean a constant burden for the project. The resource allocation
> is kind of the heart of coreboot's ramstage, it's strongly tied to our
> devicetree model. Many changes in that area would have to be done twice,
> and changes to the older code are more expensive than changes to the
> newer, cleaner code (there were reasons to rewrite it!). Also, we'd be
> either constantly looking for testers for changes to the old code, or
> risk to break it which is why branching is so much cheaper for the
> community as a whole. Basically, what you are asking is that people who
> want to advance coreboot in that area should work twice as hard (mostly
> in their limited spare time).
>
> Trust me, it's infeasible. You can't talk people into maintaining some-
> thing for you when you ask them to work on something very pesky for
> free.
>
> Maybe worth to mention again: The platforms that don't work with the v4
> allocator don't work because their code is broken. It's subtle bugs that
> were not visible with the v3 allocator by coincidence. You're also as-
> king to keep the code buggy.
>
> Nico
>
> PS. If you have any hope of open-source coreboot for newer platforms,
> you shouldn't make it harder for coreboot to advance.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to maintain AGESA-based ports long-term?

[Ivan Ivanov]

Good thing about what I've suggested - "different places for v3 and v4
allocators" - is that it's (almost?) already done ;-)

вт, 30 нояб. 2021 г. в 20:12, David Hendricks :
>
> On Tue, Nov 30, 2021 at 6:54 AM Ivan Ivanov  wrote:
> >
> > Personally I don't see any reason for branching, if 99% of the rest of
> > coreboot code (payloads etc.) is compatible. This will only get us
> > outdated for these components on this branch, which otherwise could
> > (and should) be kept simultaneously up-to-date to get the latest
> > goodies. So, just make two folders: 1 - resource allocator v3, 2 -
> > resource allocator v4, and access either v3 or v4 from outside
> > depending on your board selection.
>
> This can work, however it depends on how much other code is impacted.
> A good example of this is the new SMM module loader introduced
> recently to accommodate CPUs with >32 threads (CB:43684). It was
> merged with "v2" in the filename so that work could continue on newer
> server CPUs while the original loader was still in use everywhere
> else. After some time spent testing it, the "v2" module loader became
> the default and "v2" was dropped from the name (CB:51528).
>
> In that case the code was isolated and the newer version was
> essentially a drop-in replacement. But even then, there was at least
> one known case where something broke (CB:52765). For something like
> the resource allocator I would expect a lot more dependencies on other
> parts of the tree. This can turn into a big and difficult-to-debug
> mess if code beyond the resource allocator has different behaviors
> depending on which version is being used.
>
> tl;dr: What you suggest is possible, but cost and benefit need to be
> considered and the cost can be very high if other parts of the
> codebase are impacted.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: How to maintain AGESA-based ports long-term?

[Ivan Ivanov]

Personally I don't see any reason for branching, if 99% of the rest of
coreboot code (payloads etc.) is compatible. This will only get us
outdated for these components on this branch, which otherwise could
(and should) be kept simultaneously up-to-date to get the latest
goodies. So, just make two folders: 1 - resource allocator v3, 2 -
resource allocator v4, and access either v3 or v4 from outside
depending on your board selection.

пн, 29 нояб. 2021 г. в 18:53, Nico Huber :
>
> On 29.11.21 15:58, awokd wrote:
> > Nico Huber:
> >> On 29.11.21 14:49, awokd wrote:
> 
>  Branching
>  -
>  I know some people are easily offended by the thought, but I want to
>  mention it anyway as it seems to me like a cheap solution for the com-
>  munity as a whole. We could maintain platforms on separate branches.
> >>>
> >>> Is this different than the status quo?
> >>
> >> Yes, these ports wouldn't hold the master branch back anymore.
> >
> > Meant the status quo approach of deprecating boards and leaving to an
> > older branch. I think you are saying it would be a named branch instead.
> >
>
> Well, if I wanted to maintain a branch I would make it dedicated to
> these specific ports. That would probably be easier to maintain than
> a release branch that covers all ports of the given time. Also, it
> seems to me that leaving things on an anonymous release branch provides
> too much hope that somebody else will do the work ;)
>
> Nico
> ___
> 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

[coreboot] Re: DIP8 flash programming for development

[Ivan Ivanov]

Hi friends, if you are serious about CH341A - get a version with a
green PCB board, it's more likely to give you 3.3V (instead of the
erroneous 5V which the bugged version of black CH341A could be
giving). And just in case, verify the output pins with a multimeter,
to see it's really a 3.3V...
Also, why do you need a test clip at all? If your board has DIP8 flash
chip, most likely it's inside a socket - and possible to remove using
a PLCC / DIP8 remover, to directly plug into the "flashrom-supported"
programmer like CH341A.
> flash emulator like the Dediprog EM100
That's very interesting, never heard of it :) Although they are quite expensive

сб, 27 нояб. 2021 г. в 21:39, Angel Pons :
>
> Hi Pedro,
>
> On Fri, Nov 26, 2021 at 11:02 PM Pedro Erencia  wrote:
> >
> > Hi,
> >
> > I'm thinking about porting coreboot to a FM2A88X Extreme4+ board. This 
> > board has a DIP8 flash with a socket and I wondered what would be the best 
> > way to do an efficient development cycle. Ideally, I suppose that the best 
> > option would be to use a clip test and a CH341A, but all the clips that I 
> > found are SOIC/SOP. Should I buy a SOIC clip and an adapter from SOIC to 
> > DIP? I've seen those adapters, but I'm not sure if they will fit well in 
> > the mobo DIP8 socket.
>
> I wouldn't recommend a CH341A for the same reasons Nico explained, and
> would suggest the same alternatives.
>
> I've done a lot of development on the Asrock B85M Pro4 (a completely
> different board, but also has a socketed DIP8 flash chip) and, for me,
> the most efficient development cycle is to use a flash emulator like
> the Dediprog EM100. However, flash emulators aren't cheap. Before I
> had the EM100, I simply moved the flash chip back and forth by hand,
> from the mainboard to a breadboard wired to a CJMCU FT2232HL mini
> module (external programmer) and viceversa. I added another DIP8
> socket between the flash chip and the mainboard's socket, so that I
> could easily and quickly remove and replace the flash chip.
>
> > Aside from the mechanical question, I'd appreciate any advice about the 
> > safety of externally programming the board. I don't have the schematics and 
> > I wonder if there could be any risk of damaging the board.
>
> If you remove the flash chip from the mainboard to reflash it, it's
> practically impossible to damage the board.
>
> > Cheers.
> >
> > ___
> > coreboot mailing list -- coreboot@coreboot.org
> > To unsubscribe send an email to coreboot-le...@coreboot.org
>
> Best regards,
> Angel
> ___
> 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

[coreboot] Re: [Events] Talk about coreboot on POWER + vBeer online party!

[Ivan Ivanov]

seems there's just a few hours before the first event! will try to
join you today

пн, 1 февр. 2021 г. в 22:38, Mike Banon :
>
> Dear friends,
>
> Next Thursday __4th Feb at 3PM GMT__ , 3mdeb invites you to talk about
> the POWER9 support in coreboot opensource BIOS -
> https://meet.google.com/xsy-ocfw-exm . You are going to learn: 1)
> great benefits a coreboot will deliver to POWER-based PCs; 2) our
> progress and interesting challenges we are facing; 3) unique features
> of Dasharo coreboot-based firmware.
>
> Also, soon we are having a vBeer online party! Will be happy to
> discuss the open/libre firmwares (coreboot, Dasharo, etc.), related
> hardwares and other nice embedded things you have in mind. Please visit
> http://live.evenea.com/3mdeb-vbeer at 18th Feb 3PM GMT to have some
> fun with us.
>
> --
> Best regards, Mike Banon
> Open Source Community Manager of 3mdeb - https://3mdeb.com/
> ___
> 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

[coreboot] Re: [flashrom] Re: Operating Systems for coreboot/flashrom/etc?

[Ivan Ivanov]

You need to 1) get a .bin file somewhere (BIOS ROM) - either from the
owner that has the same laptop, or from your laptop's company. 2) get
a test clip like SOIC8 , to attach to a BIOS chip without soldering
and flash it

пн, 12 окт. 2020 г. в 09:15, Miraz Shuvra :
>
> Hello sir ,
>
> I need a little bit help
>
> I accidentally corrupted bios of my laptop during bios update
> ...before it blackout... i saw the txt .." searching for bios firmware ... 
> bios firmware not found "
>
> I baught a ch341A usb bios programming device ...
> I think a .bin file may bring my laptop back to life.
>
> My laptop ran with ami bios
> The bios chip is 25Q80DVS IG 1646
>
> Can you pls help me anyway.
>
> On Wed, Sep 30, 2020, 1:49 AM Clay Daniels  wrote:
>>
>> I am a big FreeBSD fan, and also run NetBSD on an older machine. Haven't 
>> used much Linux lately but installed Ubuntu to get a lspci for flashrom use. 
>> Ubuntu is fine, but does not have superiotool available as best I see. 
>> Looking back to FreeBSD I found superiotool just where I expected, as a port 
>> to be compiled under sysutils. Works fine, but still never finds my hidden 
>> bios I will call "SPI1" for lack of a better name.
>>
>> Anyway, I keep looking for more tools, and have an extra disk drive for 
>> another OS if anyone has any good suggestions?
>>
>> Right now I'm in Ubuntu, listening to the coreboot & flashrom freenode IRC 
>> channels. Quite a lot goes on there if you catch it right. Some real sharp 
>> guys.
>>
>> Clay
>> ___
>> flashrom mailing list -- flash...@flashrom.org
>> To unsubscribe send an email to flashrom-le...@flashrom.org
>
> ___
> flashrom mailing list -- flash...@flashrom.org
> To unsubscribe send an email to flashrom-le...@flashrom.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Some notes about NBFreq / MemFreq on amd (pre-ryzen)

[Ivan Ivanov]

Relative ratio between the NorthBridge Frequency :and: Memory
Frequency - has to be 1.25 : 1 or bigger for proper operation. NBFreq
can be lowered to allow more OC (overclocking) margin for the memory,
or higher to boost the memory performance. When XMP mode enabled - the
CPU ratio, BCLK freq and memory parameters will be optimized
automatically.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Support for enterprise class server hardware?

[Ivan Ivanov]

There are also ASUS KGPE-D16 server with two AMD Opterons (up to 16
core each) and up to 192 GB RAM - it also doesn't have Intel ME or AMD
PSP. Although it has been dropped from coreboot, so you'll have to
install a slightly older version of it

ср, 9 сент. 2020 г. в 19:55, Rocky Phagura via coreboot :
>
> David,
> DeltaLake and Tiogapass are the 2 most recent Xeon based platforms that have 
> Coreboot support. They are OCP platforms.
>
>
> -Original Message-
> From: Lars Hochstetter 
> Sent: Sunday, September 6, 2020 8:32 AM
> To: coreboot@coreboot.org
> Subject: [coreboot] Re: Support for enterprise class server hardware?
>
> Hi David,
>
> checkout these links:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__coreboot.org_status_board-2Dstatus.html=DwICAg=5VD0RTtNlTh3ycd41b3MUw=kJTYmJzGfig89KcZsuYGrA=iUQgqmRxn2awCUXSIU426JqTMeOLvQwKC1vy8v822j4=3KDu0YhprW_LJVCsUIsSkTG_9AH7CglAFfysTmnw2Mo=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__doc.coreboot.org_mainboard_index.html=DwICAg=5VD0RTtNlTh3ycd41b3MUw=kJTYmJzGfig89KcZsuYGrA=iUQgqmRxn2awCUXSIU426JqTMeOLvQwKC1vy8v822j4=xTm3S8Bse2QCZhFcoG4kqkd22x08fN7AALWlqJ-d0Tc=
>
> They provide an overview on supported hardware.
>
> Regards
>
> lhochstetter
>
> On 06/09/2020 16:29, David West wrote:
> > I am interested in whether coreboot works with server hardware like 
> > PowerEdge servers, Proliant servers, etc. If so, is there a support matrix?
> >
> > Sent from my iPhone
> > ___
> > 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
> ___
> 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

[coreboot] Re: Some problems with graphic display when using coreboot + seabios.

[Ivan Ivanov]

>
> Personally, given that it's 2020, I'd not bother with legacy-installed
> OSes (or SeaBIOS) outside of use with emulation or if a special use
> case demands it. Esp given that it's easy enough to migrate Windows
> from legacy to UEFI.
>

UEFI is such an abomination that using SeaBIOS may be the sanest
option even in 2030.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Quick Boot: A Guide for Embedded Firmware Developers, 2nd Edition

[Ivan Ivanov]

Finally we found this great rare book after many hours of searching,
and would like to share it with you friends. Hope you would find it
interesting. Enjoy!

https://github.com/informer2016/Quick_Boot-_A_Guide_for_Embedded_Firmware_Developers-_2nd_Edition

Wish you all the best, and thank you so much for your kind help
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] G505S (coreboot AMD no-PSP laptop) being sold for a good price, 40 mins left

[Ivan Ivanov]

Mike found a good condition G505S with top A10-5750M CPU preinstalled,
being sold for a good price:

https://www.ebay.com/itm/LENOVO-G505S-LAPTOP-WINDOWS-10-AMD-A10-WEBCAM-4GB-500GB-15-6-HDMI-GRADE-C-14414/264479816991

Initially we wanted to share this link with our friend, but sadly he
is not online in the moment and unlikely to come in time, so now
sharing with everyone! Hopefully it could end up in the hands of a
fellow coreboot'er. Please tell others if you'd like to bid, to avoid
a bidding war between each other ;-)
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Are AMD CPUs as researched as Intel ones (was Re: New Intel microcode release for migiating ZOMBIELOAD FALLOUT AND OTHERS)

[Ivan Ivanov]

Yes, the people are checking AMD as well, and discovered the
AMD-specific vulnerabilities at their PSP Platform (IN)Security
Processor. Luckily almost all the coreboot-supported AMD computers -
with the exception of some PC Engines boards if I'm not mistaken -
don't have a PSP, so not affected.

ср, 15 мая 2019 г. в 18:50, Nico Huber :
>
> On 15.05.19 17:37, Ivan Ivanov wrote:
> > Hi Nico, when someone finds a vulnerability at Intel, people do a good
> > digging for a similar vulnerability at AMD.
>
> I don't doubt it. But did somebody try to find AMD-specific vulnera-
> bilities? Checking if somebody else did the same errors is not the same
> as checking if they did their own.
>
> Nico
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Are AMD CPUs as researched as Intel ones (was Re: New Intel microcode release for migiating ZOMBIELOAD FALLOUT AND OTHERS)

[Ivan Ivanov]

Hi Nico, when someone finds a vulnerability at Intel, people do a good
digging for a similar vulnerability at AMD. And so far, if I haven't
missed something, it has been discovered that AMD shares only a few
variants of Spectre together with Intel, while all the other vulns
seem to be Intel-specific. Judging by the lack of other findings, I
believe that AMD is more secure - perhaps because they haven't used
such a "speedhacks"...

ср, 15 мая 2019 г. в 18:23, Nico Huber :
>
> Hi Ivan,
>
> On 15.05.19 17:11, Ivan Ivanov wrote:
> > Funny vuln names! Luckily AMD (as usual?) is not affected... As
> > someone wrote at the forums, a hidden price for Intel higher
> > performance is a holey pants, just for 120 fps in games instead of 110
> > :P Neglecting security for the purpose of performing slightly better
> > by skipping various checks inside CPU to improve the latencies, - is
> > both unfair competition and scamming a consumer, since eventually he's
> > getting significantly less performance than what he paid for
>
> I'm curious. Did you do or know somebody who did as much research on AMD
> processors, as was necessary to find these vulnerabilities? If not, how
> can you make such comparisons?
>
> Nico
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: New Intel microcode release for migiating ZOMBIELOAD FALLOUT AND OTHERS

[Ivan Ivanov]

Funny vuln names! Luckily AMD (as usual?) is not affected... As
someone wrote at the forums, a hidden price for Intel higher
performance is a holey pants, just for 120 fps in games instead of 110
:P Neglecting security for the purpose of performing slightly better
by skipping various checks inside CPU to improve the latencies, - is
both unfair competition and scamming a consumer, since eventually he's
getting significantly less performance than what he paid for

ср, 15 мая 2019 г. в 18:09, Kinky Nekoboi :
>
> atm i have no gitaccount for that.
>
> here is it from the Debian non-free Repo:
>
> http://security.debian.org/debian-security/pool/updates/non-free/i/intel-microcode/intel-microcode_3.20190514.1~deb9u1.tar.xz
>
> I dont know how to make this usable / fit it in coreboots blob format
>
> Am 15.05.19 um 17:02 schrieb Nico Huber:
> > On 15.05.19 16:43, Kinky Nekoboi wrote:
> >> Someone should push them to coreboot.
> >
> > Agreed, can you do that?
> >
> >>
> >> Debian already has them.
> >
> > or alternatively, could you provide an upstream URL, please.
> >
> > Nico
> > ___
> > 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
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Bios problem. Will not boot

[Ivan Ivanov]

Glad to help! By the way, once I even encountered a rare case - with
Windows XP - where simply upgrading the proprietary UEFI caused
Windows to bluescreen :P maybe that could've been fixed, but I didn't
have Internet to look up the solution for this problem so had to
reinstall XP. Luckily that has never happened to me with a more modern
Windows like 7, and currently I prefer to run Windows in a virtual
machine: aside from a few unusual tasks where a direct access is
really required -- like upgrading the firmware of MicroSD card reader
or resetting the controller of USB flash drive with a windows-only
proprietary tool to get it working -- this Windows virtual machine is
sufficient for the majority of tasks at almost-native performance.

Best regards,
Ivan

пн, 15 апр. 2019 г. в 22:59, Enkelena Haxhiu :
>
> Yes, that is the case.
>
> Thanks a lot for your help Ivan. I will deffinately  try this.
>
> Best,
> Enkelena
>
> On Mon, Apr 15, 2019, 2:24 PM Ivan Ivanov  wrote:
>>
>> Enkelena , If I am understanding it correctly, you have installed
>> Windows on this new HDD using another computer with another
>> motherboard. Windows is much more fragile to those "PC switches" than
>> Linux, and often the Windows users have to do a clean installation of
>> Windows when they have simply changed the motherboard to another type
>> (e.g. after the old one got broken) - either because it refuses to
>> boot at all or there are significant problems like the bluescreens.
>> So, I believe that your problem is caused by Windows, and if you will
>> simply reinstall Windows on this new HDD - while it is plugged into
>> the same coreboot computer you're planning to use it with - then your
>> problems will be resolved.
>>
>> вс, 14 апр. 2019 г. в 19:40, Enkelena Haxhiu :
>> >
>> > Hi Matt,
>> >
>> > I am using seabios.
>> >
>> >
>> > On Sun, Apr 14, 2019, 6:27 PM Matt B  wrote:
>> >>
>> >> Out of curiosity, what payload are you using?
>> >>
>> >> -Matthew
>> >>
>> >> On Sun, Apr 14, 2019 at 8:22 AM Enkelena Haxhiu  
>> >> wrote:
>> >>>
>> >>> I am using lenovo thinkpad x230. It has Linux on its ssd, Debian to be 
>> >>> precise.
>> >>>
>> >>> You are saying that just because the new hdd has windows, its not 
>> >>> booting on it?
>> >>>
>> >>> Regards,
>> >>> Enkelena
>> >>>
>> >>> On Sun, Apr 14, 2019, 2:02 PM Ivan Ivanov  wrote:
>> >>>>
>> >>>> I think you'll need to reinstall your Windows in any case, especially
>> >>>> if you've installed it using another PC. This is not a coreboot
>> >>>> problem, more like a Windows problem, and going back from glorious
>> >>>> opensource coreboot to heretical proprietary UEFI won't fix the things
>> >>>> ;-) Also, you haven't even told us what coreboot-supported computer
>> >>>> you are using...
>> >>>>
>> >>>> вс, 14 апр. 2019 г. в 14:50, Enkelena Haxhiu :
>> >>>> >
>> >>>> > Hi everyone,
>> >>>> >
>> >>>> > I have a problem.
>> >>>> >
>> >>>> > I had flashed my bios last year into coreboot by a raspberry pi.
>> >>>> > Now, I changed the hard disk of that laptop, and put another one with 
>> >>>> > windows on it, but it does not boot there.
>> >>>> > Every key that I press it gets me to booting from hard disk, and 
>> >>>> > again the process repeats.
>> >>>> >
>> >>>> > Is there any way I can fix it?
>> >>>> >
>> >>>> > What do you think if I put again the last disk and boot into that to 
>> >>>> > make it start
>> >>>> > normally and then download files to flash the bios into lenovo's 
>> >>>> > default bios?
>> >>>> > Will this work?
>> >>>> >
>> >>>> > Regards,
>> >>>> > Enkelena
>> >>>> >
>> >>>> > ___
>> >>>> > 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
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Bios problem. Will not boot

[Ivan Ivanov]

Enkelena , If I am understanding it correctly, you have installed
Windows on this new HDD using another computer with another
motherboard. Windows is much more fragile to those "PC switches" than
Linux, and often the Windows users have to do a clean installation of
Windows when they have simply changed the motherboard to another type
(e.g. after the old one got broken) - either because it refuses to
boot at all or there are significant problems like the bluescreens.
So, I believe that your problem is caused by Windows, and if you will
simply reinstall Windows on this new HDD - while it is plugged into
the same coreboot computer you're planning to use it with - then your
problems will be resolved.

вс, 14 апр. 2019 г. в 19:40, Enkelena Haxhiu :
>
> Hi Matt,
>
> I am using seabios.
>
>
> On Sun, Apr 14, 2019, 6:27 PM Matt B  wrote:
>>
>> Out of curiosity, what payload are you using?
>>
>> -Matthew
>>
>> On Sun, Apr 14, 2019 at 8:22 AM Enkelena Haxhiu  wrote:
>>>
>>> I am using lenovo thinkpad x230. It has Linux on its ssd, Debian to be 
>>> precise.
>>>
>>> You are saying that just because the new hdd has windows, its not booting 
>>> on it?
>>>
>>> Regards,
>>> Enkelena
>>>
>>> On Sun, Apr 14, 2019, 2:02 PM Ivan Ivanov  wrote:
>>>>
>>>> I think you'll need to reinstall your Windows in any case, especially
>>>> if you've installed it using another PC. This is not a coreboot
>>>> problem, more like a Windows problem, and going back from glorious
>>>> opensource coreboot to heretical proprietary UEFI won't fix the things
>>>> ;-) Also, you haven't even told us what coreboot-supported computer
>>>> you are using...
>>>>
>>>> вс, 14 апр. 2019 г. в 14:50, Enkelena Haxhiu :
>>>> >
>>>> > Hi everyone,
>>>> >
>>>> > I have a problem.
>>>> >
>>>> > I had flashed my bios last year into coreboot by a raspberry pi.
>>>> > Now, I changed the hard disk of that laptop, and put another one with 
>>>> > windows on it, but it does not boot there.
>>>> > Every key that I press it gets me to booting from hard disk, and again 
>>>> > the process repeats.
>>>> >
>>>> > Is there any way I can fix it?
>>>> >
>>>> > What do you think if I put again the last disk and boot into that to 
>>>> > make it start
>>>> > normally and then download files to flash the bios into lenovo's default 
>>>> > bios?
>>>> > Will this work?
>>>> >
>>>> > Regards,
>>>> > Enkelena
>>>> >
>>>> > ___
>>>> > 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
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Bios problem. Will not boot

[Ivan Ivanov]

I think you'll need to reinstall your Windows in any case, especially
if you've installed it using another PC. This is not a coreboot
problem, more like a Windows problem, and going back from glorious
opensource coreboot to heretical proprietary UEFI won't fix the things
;-) Also, you haven't even told us what coreboot-supported computer
you are using...

вс, 14 апр. 2019 г. в 14:50, Enkelena Haxhiu :
>
> Hi everyone,
>
> I have a problem.
>
> I had flashed my bios last year into coreboot by a raspberry pi.
> Now, I changed the hard disk of that laptop, and put another one with windows 
> on it, but it does not boot there.
> Every key that I press it gets me to booting from hard disk, and again the 
> process repeats.
>
> Is there any way I can fix it?
>
> What do you think if I put again the last disk and boot into that to make it 
> start
> normally and then download files to flash the bios into lenovo's default bios?
> Will this work?
>
> Regards,
> Enkelena
>
> ___
> 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

[coreboot] G505S - slightly different Voltages at integrated HD 8650G iGPU AtomBIOS ?

[Ivan Ivanov]

Interesting discovery about the AtomBIOS files at " g505s-atombios "
repository - https://github.com/g505s-opensource-researcher/g505s-atombios
:

While there was the same "clean" proprietary UEFI image flashed both
to "G505S with HD 8570M" and to "G505S with R5 M230" before the
AtomBIOS extraction, their AtomBIOSes for _ integrated HD 8650G _
turned out as slightly different! (see sha256)

So I made their full disassembly with this AtomDis tool -
https://cgit.freedesktop.org/~mhopf/AtomDis/ , and compared, diff
results here - https://pastebin.com/eewzswnD . As you could see from
these diff results, for some reason "G505S R5 version" sets a slightly
higher voltages for its' integrated GPU :

compared to "G505S HD version" it is 1.8% - 3.2% higher if these 0x3e
/ 0x40 / 0x6e / 0x70 values are linear and 0x0 = 0 volts.
(usNBP0Voltage / usNBP1Voltage / usVoltageID )

What do you think: would it be okay to use the integrated VGA BIOS
obtained from "G505S R5 version" for "G505S HD version" ?
This voltage difference seems small enough and the integrated GPU is
the same part after all ---> I think that it should be fine.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Microcode in ROM is not loaded with X60s

[Ivan Ivanov]

Good day Masanori,

Please tell, do you observe the same results with more fresh Linux
distributions?
It is known that Debian usually contains the outdated packages and
some of the problems there - may have already been fixed.
Try running something like the latest Void Linux (very nice fast
unique Linux distro without SystemD and really fresh packages,
e.g. it has Linux kernel 4.19 and intel-ucode20180807 package) - maybe
without the installation but just as a LiveUSB.
Here is how to install a package there, e.g. that microcode package
above - https://voidlinux.org/usage/xbps/#xbps-install1

While suggesting the instructions above I am assuming that you have
already made sure that your coreboot
has indeed checked out the 3rdparty/blobs repository where the blobs
are residing. If not, please check the output of

ls -al ./path_to_your_coreboot/3rdparty/blobs

Best regards,
Ivan Ivanov

вс, 24 февр. 2019 г. в 21:53, Masanori Ogino :
>
> Dear Coreboot developers,
>
> I installed Coreboot with ThinkPad X60s and Debian 9 and they run
> successfully, but I observe a weird behavior.
>
> Even though I had enabled blob for microcode update, the system seems
> to run without it. I saw the following message in dmesg:
> (I think this is not fatal since this is related to temperature
> monitoring, though.)
>
> > coretemp: Errata AE18 not fixed, update BIOS or microcode of the CPU!
>
> For comparison, I had installed `intel-microcode` package to the
> system and then the message disappeared.
>
> Is this intended behavior, misconfiguration, or a real bug?
>
> For reference, I uploaded the content of /proc/cpuinfo before and
> after the installation of `intel-microcode` package:
> https://gist.github.com/omasanori/4a1316bd78d95069f287431f5bd3a176
>
> Also, I uploaded a report to board-status:
> https://review.coreboot.org/cgit/board-status.git/commit/?id=af91ae4946fec9e4d7ec1045376834e231630cea
>
> (I had also tried to install FreeBSD 12.0 and OpenBSD 6.4 but both of
> their installers failed to boot just after the kernel is loaded and
> located. I am not sure if this is related to this or not.)
>
> Best regards,
> Masanori
>
> --
> Masanori Ogino
> ___
> 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

[coreboot] Re: VBIOS/VBT in Coreboot

[Ivan Ivanov]

Tianocore, being a standard UEFI, is vulnerable to UEFI-targeting
malware whose functionality is based on UEFI architecture.
"Traditional" payloads are not UEFI - and therefore are not vulnerable
to UEFI-targeting malware. It does not take a genius to realize that.
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: VBIOS/VBT in Coreboot

[Ivan Ivanov]

Sorry if that's off-topic, but by using a Tianocore payload you could
be exposing yourself to the new UEFI-targeting NSA-grade malware. Of
course the coreboot is more secure when paired with more traditional
payloads. But I don't know about your setup, maybe the security is not
your primary concern...
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Random System Freezes

[Ivan Ivanov]

Hi Nekoboi, the Intel-based X220 and AMD-based F2a85m are very
different, so I suspect your freezing problem to be directly related
to Debian. Switch your distro to something better, Debian really went
downhill in the recent years. Maybe something like Void Linux or
Artix? Or just MX Linux if you would like a Debian-based distro that
actually got more popular than Debian according to Distrowatch - and
also doesn't have systemd :)

пн, 11 февр. 2019 г. в 13:34, Kinky Nekoboi :
>
> Anybody having FUN with random system Freezes with coreboot 4.9?
>
>  Experienced some in the Last days on.
>
> my X220
>
> and F2a85m board
>
> both with Debian Buster/ +Cinnamon
>
> best regards
>
> ___
> 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

[coreboot] Re: AMDFlaws

[Ivan Ivanov]

Hi Shawn, thank you for the message! Luckily almost all the
coreboot-supported AMD boards don't contain the PSP inside their CPUs
- maybe because PSP got added to AMD much later than ME got added to
Intel. Only a few AMD boards, starting with "late 16h" architecture
(early 16h is fine) have the PSP inside. "With PSP +
coreboot-supported" : could remember only some of newer PC Engines
boards. Some examples: I have Lenovo G505S laptop - it has powerful
quadcore CPU and supports 16GB RAM, but it is AMD 15h architecture, so
no PSP there. ASUS KGPE-D16 powerful server with two AMD opterons (up
to 16 cores each) - also no PSP. So, as you see, this "PSP problem" is
not critical yet for AMD coreboot users. But of course it is important
and thank you for raising the awareness and sharing this interesting
presentation. Although maybe it'd have been better if such
presentations were released later by their authors, because now AMD
could patch these PSP flaws to make it stronger and harder to
jailbreak :P

чт, 7 февр. 2019 г. в 09:13, Shawn :
>
> https://storage.googleapis.com/wzukusers/user-28822230/documents/5c5b3fd28b669cTWPzwo/AMDFlaws%20Lecture%20Slides.pdf
>
> PSP is so powerful just like ME/SPS on Intel chipset. AMD user might
> need a similar tool like me_cleaner? psp_cleaner?
>
> --
> GNU powered it...
> GPL protect it...
> God blessing it...
>
> regards
> Shawn
> ___
> 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

[coreboot] Re: SecureBoot Keys

[Ivan Ivanov]

Secureboot stuff is horrible abomination and is not needed at coreboot.
If you need Secureboot you could use countless of proprietary UEFI boards.
Please take a look at coreboot's vboot - it is verified boot for
better security!

пт, 8 февр. 2019 г. в 12:16, galla rao :
>
> Hi All,
>
> Good Morning!
>
> would like to know from coreboot community a query on Secureboot keys!
>
> Is there a standard way to add SECUREBOOT keys into coreboot build process?
>
> Typically to sign & authenticate any UEFI application or OS loader, Keys need 
> to be enrolled into BIOS.
>
> Shed some knowledge, if not available can we create a standard mechanism to
> integrate the keys into build process through CONFIG options
>
> Regards
> Ranga
> ___
> 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

[coreboot] Affordable SOIC8 SMT sockets for BIOS chips (15pcs / 36E + cheeap shipping)

[Ivan Ivanov]

Just sharing our pleasant experience and nice find :) These SOIC8 SMT
sockets for BIOS chips are too expensive at AliExpress (don't know
why) - and to order them directly from Dediprog is economically
inefficient because last time I checked they offered only overpriced
express shipping - the cost of which is comparable to the price of
sockets themselves! - But we are patient people and don't want to
overpay that much for shipping regardless of its' speed.

So we decided to order from this EU-based "The LAB eShop" :
https://www.thelabeshop.com/en/Programmer-Emulators/SPI-Flash-Programmers/Accessories/Dediprog-SPI-Flash-Socket-8-Pin/
They are asking 36E (41US) for 15pcs sockets. Dediprog's price is 30US
for 15pcs sockets, but "thanks" to their overpriced express shipping:
"thelabeshop" prices are more affordable if you need just the sockets
- they have an ordinary cheap post shipping method available with a
tracking number, for 5 or 6.

Although our first package has been lost, they kindly sent it again
without any extra fees and this time it got delivered :) All 15 pcs
sockets have these rectangular plastic caps and were reliably packet
in a plastic ribbon to protect their fragile pins and for more
convenience. If you need some photos we could share.

What is also great about this "thelabeshop" is that, like aliexpress,
they don't require you to use paypal (paypal adds unnecessary extra
fees and has a horrible ethics / customer service). Payment could be
done by a credit card. So if you need these rare SOIC8 sockets,
"thelabeshop" price seems to be the most affordable. They also have
SOIC16 sockets, although their expensive 58E price seems to be a
mistake and maybe they could lower it for you if you would contact
them - type "SOK-SPI-16W" at their search field if you are interested.
And to find SOIC8, write "SOK-SPI-8W".

These sockets could be very useful for routers or laptop motherboards,
although you need a steady hand or ask professional to install them
for you.

Best regards,
Ivan Ivanov
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Upgrade the 12 years old LZMA libraries - should we do it?

[Ivan Ivanov]

Igor Pavlov (7z/LZMA SDK author) told me a few months ago that
> Decompression speed for lzma:
> lzma sdk 18.03 C code - about +120% speed increase from 4.42.
> lzma sdk 18.03 asm-x64 code - about +180% speed increase from 4.42.
Although he didn't mention any compression ratio changes, maybe
because they're not big enough,
this such a huge speed increase alone should be a good reason to
upgrade these LZMA libraries.

ср, 4 апр. 2018 г. в 11:19, Carl-Daniel Hailfinger
:
>
> Hi Ivan,
>
> On 03.04.2018 20:03, Ivan Ivanov wrote:
> > I have noticed that both coreboot and seabios are using the very old
> > versions of LZMA SDK.
>
> True. I introduced the lzma code in coreboot (back when it was called
> LinuxBIOS) when we were working on OLPC XO-1 support.
>
>
> > If we will upgrade our LZMA libraries from the
> > outdated-by-12-years 4.42 to the current version 18.04 , speed and
> > compression ratio should improve and maybe a few bugs will be fixed.
>
> Do you have any numbers for this? An improved compression ratio and
> improved speed would be nice indeed, but how does the size of the
> decompression code change? If the decompression code grows more than the
> size reduction from better compression, it would be a net loss. A
> significantly reduced decompression speed would also be a problem.
> Decompression speed would have to be measured both for stream
> decompression (i.e. the decompressor gets the compressed data in
> single-byte or multibyte chunks) as well as full-size decompression
> (i.e. the decompressor can access all compressed data at once). We also
> have to make sure that stream decompression still works after the change.
>
>
> > Do you think it should be done, or you are OK with using such an
> > outdated version?
>
> A size benefit for the resulting image is a good reason to switch.
>
> Regards,
> Carl-Daniel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Configuration for Thinkpad T530

[Ivan Ivanov]

Please don't forget to CC the coreboot mailing list. You could
determine the chip's layout by looking on it: it has a dot near CS
pin. As for cable/clip and programmer, check "Flashing BIOS chip with
Bus Pirate" article at dangerous prototypes forums: it has a good
review of SOIC8 test clips and also compatible with CH341A programmer.
I'm quoting your message below, hope someone would help you with
Intel-related questions

вт, 22 янв. 2019 г. в 00:53, Yannik Catalinac :
>
> Hello guys,
>
> thanks for the answers!
>
> >although I've never flashed t530 to me it seems pretty obvious:
> >usually you connect your 8 wires to SPI flash chip and doing the
> >flashing, but this time you'll connect 7 wires like usual to your
> >programmer, but 8th CS wire to programmers VCC instead of programmers
> >CS, and that programmers CS will be connected to CS of another chip
>
> The first problem is I don't know the layout of the first chip and especially 
> of the second chip.
> I could assume it depending on other boards I found on the internet/coreboot 
> wiki but I'm not 100% sure for the T530. Where do I find the layout of the 
> two chips of the T530?
>
> Second problem is how do I connect the second chip with the SPI programmer? I 
> know which pins to connect, but I mean what cable/clip etc. do I need? What 
> hardware do I need to buy?
>
> Greetings
>
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Testing modernizing patches on ASUS KGPE-D16. (was Re: Asus KGPE-D16 with latest coreboot errors with Unsupported Hardware on Qubes 4 install missing IOMMU?)

[Ivan Ivanov]

Sorry for a late reply, but have you tried repairing/replacing the
chips (capacitors?) on the bottom of your G34 cpu?

чт, 20 дек. 2018 г. в 00:29, taii...@gmx.com :
>
> On 12/18/2018 01:56 PM, Daniel Kulesz via coreboot wrote:
> > Hi folks,
> >
> > is there a branch that has all the outstanding KGPE-D16 changes merged? I 
> > will be happy to test, but I feat I won't find the time to test all those 
> > fixes each in a separate branch. Also some specification of what tests need 
> > to be conducted would help.
> >
> > The outstanding KGPE-D16 bugs on my personal list are boot failures that 
> > require to turn off/on AC
>
> I have the same issue :[ there is no real cause in the serial logs that
> I can find I wondered if it was because the chips on the bottom of my
> g34 cpu are damaged somewhat. I would really like to find out why.
>
> I suggest to use the reset button instead so your hard drives don't have
> to start/stop so much that is if your case has one you can connect the
> header.
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Coreboot doesn't POST on ASUS KCMA-D8

[Ivan Ivanov]

Hi Sean, libreboot is always behind coreboot regarding the commits, so
RAM compatibility could vary because of some breaking commit that
happened after the latest libreboot release but before the latest
coreboot. So of course it would break at the next libreboot release as
well. You could prevent this by searching for this commit using
dichotomy method (e.g. just 10 tries to find at the range of 2^10 =
1024 commits) and tell us if you'd find it
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Configuration for Thinkpad T530

[Ivan Ivanov]

>
> The xHCI controller firmware and the Lenovo g505s you mention are 
> AMD-specific stuff, which does not apply to the Intel chipset on the Thinkpad 
> T530 (it should work out-of-the-box).
>

Hi Angel, I completely agree with you and of course understand that
g505s info is not appropriate for t530 situation . By this + wifi
ath9k example I just meant there are some controllers which don't need
the non-free closed source firmware to do something

Best regards,
Ivan
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Configuration for Thinkpad T530

[Ivan Ivanov]

> I'm not sure if such a card exists. There are WiFi cards with free
> OS drivers (e.g. ath9k), but I would expect them to run some sort of
> firmware, too

according to wikipedia this ath9k family of WiFi controllers have both
drivers and firmware as opensource. About USB controller, I didn't add
xhci firmware image to my g505s coreboot and all the usb ports are
working fine although at usb2 mode - so it seems to me that at least
some controllers could function without a firmware, just that
functionality could be degraded without one

> Just to be sure, is the following a good way for flashing coreboot?

Maybe yes, although personally I'd have started with the largest
amount of blobs and if it works then I did everything correctly and
could try decreasing their quantity. This way you'd now if you're
going the correct way right from the beginning, meanwhile your way is
maybe more ethical but less confidence

> Could you please explain that to me in more detail?
although I've never flashed t530 to me it seems pretty obvious:
usually you connect your 8 wires to SPI flash chip and doing the
flashing, but this time you'll connect 7 wires like usual to your
programmer, but 8th CS wire to programmers VCC instead of programmers
CS, and that programmers CS will be connected to CS of another chip
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Configuration for Thinkpad T530

[Ivan Ivanov]

tldr :P ...just kidding friend ;) here are some replies

> 3.19 [*] Add gigabit ethernet firmware
> # If I read correctly I need that for internet connection and this bianry 
> has just some configuration in it and no excecutable?
That means your Ethernet controller needs a closed source proprietary
firmware in order to function.
> So this should be not a privacy concerning thing?
Being a closed source this firmware may contain the backdoors or help
the backdoor-like functionality of intel me. So yes, this is a privacy
concerning thing.

> 4.2 Display ---> Framebuffer mode (Legacy VGA text mode)
> # I have no idea what to choose here
If you don't know about some setting, just leave it default - usually
the defaults are correct, although may be not the best setting.
Write down the questionable options somewhere, and if there'd be some
problems with your coreboot then you'd know where to dig.
In addition, you might check other people's config at coreboot board
status reports for your motherboard.

> 4.6 (0x) Override PCI Subsystem Vendor ID
> # What?!
> 4.7 (0x) Override PCI Subsystem Device ID
> # And again: What?!

That probably means if those IDs are different at your specific board
you could force them to something different.
But better leave them default if you don't have a better idea for them.

> # I'm not sure if I need a VGA Option ROM. In which cases I need it? What 
> disadvantage do I have if I do not integrate a VGA Option
> ROM? Will I see GRUB when I boot Linux? How could you value that binary in 
> case of privacy and security?

Without a binary option rom you may experience some glitches, some
people can't see GRUB although maybe this info is outdated and such
problems have been fixed at the latest coreboot. So, like with any
other binary blob, you need to check if you could live without it, and
only add if you can't.

> 4.11 [*] Add a Video Bios Table (VBT) binary to CBFS
> # Same questions as for the VGA BIOS image
same answer ;)

> 5.6 (0x0) UART's PCI bus, device, function address
> # What is that? What I have to insert?
if you don't plan to debug your coreboot with UART (and your laptop
probably doesn't have a physical UART) don't need to change anything
there

> 5.9 [*] Support Intel PCI-e WiFi adapters
> # If enabled, will this include a binary in the coreboot image?
no but it will include some workaround for buggy intel wifi
controllers that will increase the size of your coreboot image by a
few KB . if you don't use intel wifi, dont enable it

> 6.2 Trusted Platform Module ---> [*] Deactivate TPM
> # I disabled it because of security/privacy reasons. Any disadvantages 
> when I disable it?
if you don't plan to use TPM functionality (which maybe couldn't be
trusted because it's closed source soft/hardware) then yes disable it

> 7.8 Default console log level (0: EMERG) --->
> # I read that this should decrease boot time. What disadvantages do I 
> have with this setting?

that after your coreboot boots its' log will be mostly empty and you
can't see any useful messages at CBMEM console, e.g. which could have
been useful if you're debugging some functionality or preparing a bug
report

> POST code questions
> # What?

like any other bios, coreboot prints some post codes at various
booting stages, and you could even insert more prints to coreboot
source code if you don't have any other debug methods. E.g. there are
some MiniPCIe adapters like Compal MiniPCIe, which are used to display
0xYZ hexadecimal POST code at double 8-segment screen

Hope that helps :)
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Please suggest a AM3/AM3+ motherboard which is supported by Coreboot when32GB of RAM installed

[Ivan Ivanov]

I can't say about those AM3 boards but my coreboot'ed AMD Lenovo G505S
is working fine with 16GB DDR3 installed. Maybe you could check if
they have a similar CPU architecture (G505S A10-5750M is Richland) and
also check the similarity of their FCH aka "southbridges" (G505S has
Bolton M3), while waiting for a more helpful answer from someone more
knowledgeable (+ could check if their board_status reports contain a
kernel log where you could check the size of installed RAM)

чт, 3 янв. 2019 г. в 21:30, :
>
> Hello,
>
> I have found that following boards are indicated as supported:
>
> Version:1.0 StartHTML:000105 EndHTML:025498 StartFragment:020391 
> EndFragment:025458
>
> ASUS M4A785-M WIP...   AMD Fam10hAMD RS780/SB700  
> ITE™ IT8712F AMD Athlon™ 64 / FX / X2  Socket AM3/AM2(+)DIP8  
> SPI Y Y —
>
> ASUS M4A785T-M  OK...  AMD Fam10hAMD RS780/SB700  
> ITE™ IT8712F AMD Athlon™ 64 / FX / X2  Socket AM3  DIP8  
> SPI Y Y —
>
> ASUS M4A78-EM OK...  AMD Fam10hAMD RS780/SB700  
> ITE™ IT8712F AMD Athlon™ 64 / FX / X2  Socket AM3/AM2(+)DIP8  
> SPI Y Y —
>
> ASUS M5A88-VOK...  AMD Fam10hAMD 880G/850 ITE™ 
> IT8721F AMD Athlon™Phenom™Sempron™ 64 / FX / X2   Socket AM3/AM3+ 
>DIP8  SPI Y Y —
>
> GIGABYTE   GA-MA785GMT-UD2H OK...  AMD Fam10hAMD 785G / SB710 
> ITE IT8718F AMD Phenom™ II / Athlon™ II  Socket AM3   
> ????—
>
> GIGABYTE   GA-MA78GM-US2H   OK  AMD Fam10hAMD 780G / 
> SB700 ITE IT8718F AMD Phenom™ / Athlon™ / Sempron™   Socket 
> AM2+????—
>
>
>
>
> And actually most of them missing any info on the status page and somewhere 
> is info like:
> The boards works only with less than 4GB of RAM, if installed more then it 
> does not boot Linux.
>
> You can see that some AMD 16GB boards support 32GB two with 4x8GB modules:
>
> https://www.overclockers.com/forums/showthread.php/698565-Can-i-use-8GB-DDR3-single-module-with-Biostar-TA785-G3
>
> http://www.tomshardware.com/answers/id-1714859/asus-m5a88-evo-ram.html
>
> But these are 32GBs with their original BIOSes.
>
> What about 16GB or 32GB with a Coreboot flashed on these boards?
> Did anyone tested and used such config with 16GB or 32GB DDR3 RAM?
>
> Kind Regards,
> Alex
>
> ___
> 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

[coreboot] Re: coreboot is under attack? many access problems recently, need to check that sources haven't been tampered

[Ivan Ivanov]

Thank you very much Patrick! For a moment I was afraid that old good
"pipermail" disappeared, huge thanks to you for leaving it there. And
beautiful new shiny "hyperkitty" UI, really nice looking! Awesome NY
present :D Happy New Year dear friend ;)

BR,
Ivan

пн, 31 дек. 2018 г. в 19:56, Carl-Daniel Hailfinger
:
>
> Dear Ivan,
>
> Patrick Georgi did all the work, he deserves all the thanks.
>
> Best regards,
> Carl-Daniel
>
> On 31.12.2018 17:48, Ivan Ivanov wrote:
> > Dear Carl-Daniel, thank you very much for your assuring reply, and for
> > keeping the old "pipermail" mailing list archive because it is much
> > easier to wget and browse with links text browser. Happy coming New
> > Year ! ;-)
> >
> > Best regards,
> > Ivan
> >
> > пн, 31 дек. 2018 г. в 19:40, Carl-Daniel Hailfinger
> > :
> >> On 31.12.2018 12:34, Ivan Ivanov wrote:
> >>> Had a lot of access problems recently, both to coreboot website and
> >>> its' repositories. Was it a DDoS attack? How to make sure that the
> >>> sources at review coreboot repository haven't been modified during
> >>> this event?
> >> No need to worry. There was a scheduled server migration (better
> >> hardware) and the mailing list software was updated as well. This took
> >> quite a lot of resources. Things should be a lot snappier now.
> >>
> >> For details, see the following message:
> >>
> >> Date: Tue, 25 Dec 2018 00:40:41 +0100
> >> Message-ID: 
> >> 
> >> Subject: [coreboot] mailing list changes
> >>
> >> Regards,
> >> Carl-Daniel
> >>
> > ___
> > 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

[coreboot] Re: Update on Asus KGPE-D16 with coreboot 4.6 and Qubes 4

[Ivan Ivanov]

Hi Pete, what if this "Intel Optane problem" is not Qubes specific and
it's just this SSD (?) is faulty. Do you have any warranty left to RMA
and try a different Optane, or even better - take a completely
different SSD to avoid supporting Intel corporation with your money,
funding the next generation of ME-like backdoors.

Ivan

пн, 31 дек. 2018 г. в 15:26, petecb via coreboot :
>
> Hi,
>
> Season's greetings to everyone! :-)
>
> I've been able to get my Asus KGPE-D16 running with coreboot 4.6 and Qubes 4 
> and I'm pleased to report it has been nice and stable over the holiday 
> period, save for a few minor issues.
>
> Suspend works fine on a fresh install of Qubes 4, however applying the latest 
> updates then stops this from working. (It goes in to suspend but does not 
> resume properly). I'm assuming this is now a Qubes issue.
>
> My Intel Optane 900p NVME drive does not work reliably with Qubes 4. It 
> initially appears fine but anywhere between 4-12 hours after boot the system 
> will panic and switch to a read-only file system - you can't run any commands 
> without an "Input/Output Error" even in Dom 0. The only course of action when 
> this is encountered appears to be a hard reset. Unsurprisingly, getting any 
> kind of logs about what is actually happening has proven fruitless so far :-(
>
> I have therefore switched to a normal SATA drive for the last week and this 
> has been nice and stable. I suspect my best course of action to get a higher 
> performing filesystem is to move to 4 SATA SSDs in RAID 10. If anyone has any 
> other suggestions to get faster drive access with this platform (particularly 
> good random read/write performance for using lots of concurrent VMs in Qubes) 
> or possible approaches to fix my NVME drive issue, they would be much 
> appreciated.
>
> My only other minor issue at the moment is lack of fan control. If I run 
> "sudo pwmconfig" in dom0 I get the message "There are no pwm-capable sensor 
> modules installed". I suspect I need to enable some additional modules, so if 
> anyone can provide me some explicit directions on how to do this, it would 
> again be much appreciated.
>
> Kind regards,
>
> Pete
> ___
> 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

[coreboot] Re: coreboot is under attack? many access problems recently, need to check that sources haven't been tampered

[Ivan Ivanov]

Dear Carl-Daniel, thank you very much for your assuring reply, and for
keeping the old "pipermail" mailing list archive because it is much
easier to wget and browse with links text browser. Happy coming New
Year ! ;-)

Best regards,
Ivan

пн, 31 дек. 2018 г. в 19:40, Carl-Daniel Hailfinger
:
>
> On 31.12.2018 12:34, Ivan Ivanov wrote:
> > Had a lot of access problems recently, both to coreboot website and
> > its' repositories. Was it a DDoS attack? How to make sure that the
> > sources at review coreboot repository haven't been modified during
> > this event?
>
> No need to worry. There was a scheduled server migration (better
> hardware) and the mailing list software was updated as well. This took
> quite a lot of resources. Things should be a lot snappier now.
>
> For details, see the following message:
>
> Date: Tue, 25 Dec 2018 00:40:41 +0100
> Message-ID: 
> 
> Subject: [coreboot] mailing list changes
>
> Regards,
> Carl-Daniel
>
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] coreboot is under attack? many access problems recently, need to check that sources haven't been tampered

[Ivan Ivanov]

Had a lot of access problems recently, both to coreboot website and
its' repositories. Was it a DDoS attack? How to make sure that the
sources at review coreboot repository haven't been modified during
this event?

Best regards,
Ivan
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

Re: [coreboot] Asus Chromebox Panther: no HW RNG?

[Ivan Ivanov]

Sorry but I think that relying on Intel RNG is a _Terrible_ idea
regarding the security and not sure you should be pursuing it. If you
really want a hardware RNG that is also secure, why not take a look at
some USB dongles like FST-01 or Librem key? Here is a ( sadly deleted
recently! ) Wikipedia comparison page -
https://web.archive.org/web/20180812092012/https://en.wikipedia.org/wiki/Comparison_of_hardware_random_number_generators
- You can check it to find the best price/performance USB TRNG dongle
which is also open hardware

Best regards,
Ivan Ivanov
вт, 27 нояб. 2018 г. в 22:50, Grant Grundler :
>
> On Tue, Nov 27, 2018 at 4:10 AM Nico Huber  wrote:
> >
> > Hi Grant,
> >
> > I don't know how it is supposed to work on Haswell, but can give you
> > some pointers anyway.
> >
> > tl;dr I don't think you are looking for a PCI device.
>
> If  intel-rng support is required, a PCI device will be advertised
> because of how the linux kernel binds PCI devices to drivers. See
> "alias" field of "modinfo intel-rng" as an example.
>
> One of the search results pointed at a response that said "load
> intel-rng driver" as the solution to this problem... that's the only
> reason I'm exploring this path.
>
> > Am 27.11.18 um 08:11 schrieb Grant Grundler:
> > > Asus Chromebox (Panther) with Celeron 2995U processor is supposed to
> > > have a HW Random Number Generator:
> > >
> > > https://ark.intel.com/products/75608/Intel-Celeron-Processor-2955U-2M-Cache-1-40-GHz-
> > >
> > > (Intel calls it Secure Key)
> > >
> > > But "modprobe intel-rng" is failing with "No such device" (Debian
> > > 4.18.0-2-amd64 kernel).
> >
> > This driver is for very old Firmware Hub (FWH) hardware which would
> > be controlled through the LPC PCI device. You have such a PCI device
> > (00:1f.0) but there's no FWH to be expect with Haswell.
>
> Hrm. OK. But that would explain why intel-rng driver only binds with
> PCI devices.
>
> > What you are probably looking for is the RDRAND instruction. I don't
> > know if it can be controlled by the firmware, but would check first if
> > your OS is prepared to make use of it.
>
> Linux kernel has supported RDRAND for a long time. There is even a
> public debate about *excluding* RDRAND use since some people were
> hypothesizing that RDRAND was "compromised" by Intel so "goverment
> agencies" could break encrypted traffic which used RDRAND exclusively
> to generate encryption keys. Linux kernel does NOT exclusively use
> RDRAND and Ted Tyso made compelling arguments that RDRAND would still
> add "entropy" to key generation.
>
> What I don't know is how linux figures out it can or should use
> RDRAND. RDRAND appears to be a "CPU feature":
>
> arch/x86/include/asm/cpufeatures.h:#define X86_FEATURE_RDRAND
> ( 4*32+30) /* RDRAND instruction */
>
> And as notedin original email, Intel says this CPU (Celeron 2995U)
> supports "Secure Key" which is the new marketing name for HW RNG
> support (could be only via RDRAND now).
>
>
> > > Why do I care about HW RNG?
> > > Because of this:
> > > ...
> > > [8.560270] r8169 :01:00.0 enp1s0: link up
> > > [8.560287] IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0: link becomes ready
> > > [19039.712644] random: crng init done
> > > [19039.712649] random: 7 urandom warning(s) missed due to ratelimiting
> > > [19044.485625] wlp2s0: authenticate with ...
> > > ...
> > >
> > > Yes, several *hours* until the crng was initialized and then
> > > wpa_supplicant could start talking on WIFI. :(
> > >
> > > The length of the delay varies...shortest was 7 minutes.
> >
> > Well, even without a hardware rng, I wouldn't expect that.
>
> Exactly. I didn't either. My NUC5 completes typically in 3 second from
> the time the kernel is loaded. But this is a different CPU (Intel Core
> i5 6260) and completely different firmware (If Coreboot was available
> for this, I'd prefer Coreboot).
>
> >  With antennas
> > available, I would say after 10s for the paranoid there should be enough
> > entropy available. But that's probably just how I'd do OS development
> > (and depends on what the wifi driver can do).
>
> I don't know if the kernel has access to any radios (or antennas)
> until the 80211 link is brought up... which in turn won't happen until
> wpa_supplicant is running. So something else is wrong here. My
> suspicion is still on Coreboot not providing something that tells the
> linux kernel a quick method to generate random numbers.
>
> I saw Matt DeVillier's response as well and I'll follow up once I've
> updated the SeaBIOS firmware, installed rng-tools5, and determined
> which CPU features are advertised by both Panther and NUC CPUs. For
> some reason my "phone home" (SSH) is getting rejected right now. :(
>
> cheers,
> grant
>
> > Nico
>
> --
> 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 rootkit (lojax)

[Ivan Ivanov]

> that's a pretty myopic view of coreboot and its users; coreboot
> supports 2 different UEFI payloads, which are used by both individual
> and commercial entities.

It is nice to hear there are possible alternatives ; to be honest I
don't know about their "marketshare" amoung the coreboot users. From
my point of view as a user (reading mailing lists etc.) it seemed like
the majority of coreboot users are using SeaBIOS and the majority of
libreboot users are using GRUB. Although, its' quite likely that at
the same time the majority of ChromeBook+coreboot users are really
running UEFI payload, thanks to your customized coreboot builds where
you are using it (learned about your work after a quick search)

P.S. sorry it seems I bumped an old thread and now I feel guilty

Ivan
вт, 20 нояб. 2018 г. в 18:07, Matt DeVillier :
>
> On Tue, Nov 20, 2018 at 8:20 AM Ivan Ivanov  wrote:
> >
> > Thank you for the info! However we are not affected thanks to
> > coreboot's default payload being SeaBIOS. If anything, these "uefi
> > rootkit" news could be used to promote the coreboot(+SeaBIOS) project
> > to wider audiences
>
> that's a pretty myopic view of coreboot and its users; coreboot
> supports 2 different UEFI payloads, which are used by both individual
> and commercial entities.
>
> >
> > Ivan
> >
> > >
> > > hi all! :)
> > >
> > > ive just found this, and thought that it can be valuable info for the
> > > people around:
> > >
> > > https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/
> > >
> > > (i hope it wont disturb anyone here, as its near to be offtopic)
> > >
> > > all the bests for all of you! :)
> > >
> > > --
> > > 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 mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] uefi rootkit (lojax)

[Ivan Ivanov]

Thank you for the info! However we are not affected thanks to
coreboot's default payload being SeaBIOS. If anything, these "uefi
rootkit" news could be used to promote the coreboot(+SeaBIOS) project
to wider audiences

Ivan

>
> hi all! :)
>
> ive just found this, and thought that it can be valuable info for the
> people around:
>
> https://www.welivesecurity.com/2018/09/27/lojax-first-uefi-rootkit-found-wild-courtesy-sednit-group/
>
> (i hope it wont disturb anyone here, as its near to be offtopic)
>
> all the bests for all of you! :)
>
> --
> 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] USB 2.0 EHCI debug dongle doesn't print logs (at Lenovo G505S)

[Ivan Ivanov]

Thank you very much for your help, Nico! Enabling CONFIG_CONSOLE_USB
indeed got FT232H working! :-) I wonder why CONFIG_CONSOLE_USB isn't
enabled by default if CONFIG_USBDEBUG is enabled... Maybe this default
behaviour should be changed?

P.S. works even together with CONFIG_USBDEBUG_IN_ROMSTAGE

2018-09-30 14:23 GMT+03:00, Nico Huber :
> Hi Ivan,
>
> On 9/28/18 11:50 PM, Ivan Ivanov wrote:
>> Thank you for spkmodem comments, now I'm trying out a more reliable
>> way - FT232H dongle - to extract the logs from AMD Lenovo G505S. I
>> plug it into the correct port - USB 2.0 at laptop's right side.
>> However it doesn't print anything except this short test message:
>> --- /* Perform a small write. */
>> --- ret = dbgp_bulk_write_x([DBGP_CONSOLE_EPOUT], "USB\r\n", 5);
>> -- line 322 of ./coreboot/src/drivers/usb/gadget.c
>>
>> Thinking that it breaks during the relocation from romstage to
>> ramstage (migrate_ehci_debug function at ehci_debug.c ?) , I disabled
>> CONFIG_USBDEBUG_IN_ROMSTAGE - but the results are the same: only "USB"
>> message. I could see
>> --- dprintk(BIOS_INFO, "Test write done\n");
>> -- line 328 of ./coreboot/src/drivers/usb/gadget.c
>> at cbmem logs, but even that doesn't get copied to FT232H output.
>
> the purpose of dprintk() here is to only print when EHCI debug is _not_
> activated yet. Otherwise the code trying to print something would be
> called recursively. But it might actually work at this early point,
> with proper configuration (see below).
>
>>
>> Please could you take a look at my coreboot .config and cbmem logs,
>> what if this FT232H dongle doesn't get selected as console output for
>> some reason? CONFIG_CONSOLE_CBMEM is still enabled, but maybe I should
>> disable it?
>
> You are missing CONFIG_CONSOLE_USB.
>
> Nico
>

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

[coreboot] USB 2.0 EHCI debug dongle doesn't print logs (at Lenovo G505S)

[Ivan Ivanov]

Thank you for spkmodem comments, now I'm trying out a more reliable
way - FT232H dongle - to extract the logs from AMD Lenovo G505S. I
plug it into the correct port - USB 2.0 at laptop's right side.
However it doesn't print anything except this short test message:
--- /* Perform a small write. */
--- ret = dbgp_bulk_write_x([DBGP_CONSOLE_EPOUT], "USB\r\n", 5);
-- line 322 of ./coreboot/src/drivers/usb/gadget.c

Thinking that it breaks during the relocation from romstage to
ramstage (migrate_ehci_debug function at ehci_debug.c ?) , I disabled
CONFIG_USBDEBUG_IN_ROMSTAGE - but the results are the same: only "USB"
message. I could see
--- dprintk(BIOS_INFO, "Test write done\n");
-- line 328 of ./coreboot/src/drivers/usb/gadget.c
at cbmem logs, but even that doesn't get copied to FT232H output.

Please could you take a look at my coreboot .config and cbmem logs,
what if this FT232H dongle doesn't get selected as console output for
some reason? CONFIG_CONSOLE_CBMEM is still enabled, but maybe I should
disable it?

Best regards,
Ivan Ivanov


dongle_coreboot.memmap
Description: Binary data


coreboot-4.8-1577-ge072247e6e-dirty Sat Sep 22 00:41:45 UTC 2018 romstage starting...
APIC 00: CPU Family_Model = 00610f31

APIC 00: ** Enter AmdInitReset [00020007]
Fch OEM config in INIT RESET
AmdInitReset() returned AGESA_SUCCESS
APIC 00: Heap in LocalCache (2) at 0x0040
APIC 00: ** Exit  AmdInitReset [00020007]

APIC 00: ** Enter AmdInitEarly [00020002]
AmdInitEarly() returned AGESA_SUCCESS
APIC 00: Heap in LocalCache (2) at 0x0040
APIC 00: ** Exit  AmdInitEarly [00020002]

APIC 00: ** Enter AmdInitPost [00020006]
-READING SPD---
iobase: 0x0B00, SmbusSlave: 0x00A0, count: 128

-FINISHED READING SPD---
-READING SPD---
iobase: 0x0B00, SmbusSlave: 0x00A2, count: 128

-FINISHED READING SPD---
AmdInitPost() returned AGESA_SUCCESS
APIC 00: Heap in TempMem (3) at 0x000b
APIC 00: ** Exit  AmdInitPost [00020006]
CBMEM:
IMD: root @ b000 254 entries.
IMD: root @ bfffec00 62 entries.
MTRR Range: Start=0 End=8000 (Size 8000)
MTRR Range: Start=8000 End=c000 (Size 4000)
MTRR Range: Start=ffc0 End=0 (Size 40)
CBFS: 'Master Header Locator' located CBFS at [200:3fffc0)
CBFS: Locating 'fallback/postcar'
CBFS: Checking offset 0
CBFS: File @ offset 0 size 20
CBFS:  Unmatched 'cbfs master header' at 0
CBFS: Checking offset 80
CBFS: File @ offset 80 size 2cc
CBFS:  Unmatched 'config' at 80
CBFS: Checking offset 3c0
CBFS: File @ offset 3c0 size 246
CBFS:  Unmatched 'revision' at 3c0
CBFS: Checking offset 640
CBFS: File @ offset 640 size 48c
CBFS:  Unmatched 'cmos_layout.bin' at 640
CBFS: Checking offset b40
CBFS: File @ offset b40 size f200
CBFS:  Unmatched 'pci1002,990b.rom' at b40
CBFS: Checking offset fdc0
CBFS: File @ offset fdc0 size 3418
CBFS: Found @ offset fdc0 size 3418
Decompressing stage fallback/postcar @ 0xbff5cfc0 (29168 bytes)
Loading module at bff5d000 with entry bff5d000. filesize: 0x3310 memsize: 0x71b0
Processing 43 relocs. Offset value of 0xbdf5d000


coreboot-4.8-1577-ge072247e6e-dirty Sat Sep 22 00:41:45 UTC 2018 ramstage starting...
Capability: type 0x01 @ 0xc0
Capability: type 0x01 @ 0xc0
Capability: type 0x05 @ 0xd0
Capability: type 0x0a @ 0xe4
ehci_bar: 0xfef0 debug_offset 0xe0
debug_port: 1
n_ports:5
PORTSC #1: 3000
PORTSC #2: 3000
PORTSC #3: 3000
PORTSC #4: 3000
PORTSC #5: 3000
EHCI controller reset successfully.
EHCI started.
EHCI done waiting for port.
EHCI debug port enabled.
dbgp:  start (@   1,1) ctrl=5438
dbgp: status (@   1,1) ctrl=5418 pids=00d2c32d ret=8
dbgp:buf: 00 05 7f 00 00 00 00 00
dbgp:  start (@   1,1) ctrl=5420
dbgp: status (@   1,1) ctrl=5400 pids=004b4b69 ret=0
EHCI debug device renamed to 127.
dbgp:  start (@   1,1) ctrl=5438
dbgp: status (@   1,1) ctrl=5418 pids=00d2c32d ret=8
dbgp:buf: 00 09 01 00 00 00 00 00
dbgp:  start (@   1,1) ctrl=5420
dbgp: status (@   1,1) ctrl=5400 pids=004b4b69 ret=0
dbgp:  start (@   1,1) ctrl=5438
dbgp: status (@   1,1) ctrl=5418 pids=00d2c32d ret=8
dbgp:buf: 40 0b 00 00 01 00 00 00
dbgp:  start (@   1,1) ctrl=5420
dbgp: status (@   1,1) ctrl=5400 pids=004b4b69 ret=0
dbgp:  start (@   1,1) ctrl=5438
dbgp: status (@   1,1) ctrl=5418 pids=00d2c32d ret=8
dbgp:buf: 40 03 68 c0 01 02 00 00
dbgp:  start (@   1,1) ctrl=5420
dbgp: status (@   1,1) ctrl=5400 pids=004b4b69 ret=0
dbgp:  start (@   1,1) ctrl=5438
dbgp: status (@   1,1) ctrl=5418 pids=00d2c32d ret=8
dbgp:buf: 40 04 08 00 01 00 00 00
dbgp:  start (@   1,1) ctrl=5420
dbgp: status (@   1,1) ctrl=5400 pids=004b4b69 ret=0
dbgp:  start (@   1,1) ctrl=5438
dbgp: status (@   1,1) ctrl=5418 pids=00d2c32d ret=8
dbgp:buf: 40 02 00 00 01 00 00 00
dbgp:  start (@   1,1) ctrl=5420
dbgp: status (@   1,1) ctr

[coreboot] Lenovo G505S - spkmodem console sound, is correct? Please listen and tell

[Ivan Ivanov]

Good day! We are debugging a custom config of G505S coreboot which
currently can't boot beyond SeaBIOS to any Linux: kernel gets stuck at
the early booting stages regardless of its' parameters. So we can't
access cbmem console, and are exploring the alternative console output
options. One of them is spkmodem - console output through this G505S
laptop's speakers. But we can't decode any symbols of its' output with
spkmodem-recv, regardless of the options we use, or whether we're
trying parec or arecord to achieve that.

I suspect: despite that the "PC Speaker"-style beeping output is
working fine at this laptop/speakers while we are using Linux or even
some very simple OS like FreeDOS or Kolibri - that coreboot's spkmodem
might be buggy at G505S laptop, since there are only a few distinct
beeps (a couple of them are long enough to be visible at Soundcloud's
waveform) - everything else sounds like maybe an encrypted message but
could be just garbage (far from being similar to some morse code)

If you've ever heard the spkmodem output, please could you try to
decode this stuff if its' easy for you, or at least to tell if it
sounds OK or not? Its the first ~4 minutes of like 30 minutes log
output, then the sounds stop:

just play - https://soundcloud.com/qma-ster/g505s-spkmodem
download - https://www.sendspace.com/file/y2j15y

Best regards,
Ivan

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

Re: [coreboot] UEFI Payload update

[Ivan Ivanov]

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

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

[Ivan Ivanov]

Maybe it just AMD's microcode versioning got messed up and this is
indeed the latest microcode despite its' lower number, but the only
way to check it - is to test both microcodes for their degree of
vulnerability to the Spectres. It does not make much sense to release
an outdated microcode, assuming its' not an accidental mistake by AMD
- so I hope that AMD guy would notice your messages

Ivan

2018-05-27 13:17 GMT+03:00 Mike Banon :
> Hi Rudolf,
>
> Please could you try contacting this AMD person again, regarding the
> problems with this recent microcode update? Because it looks like he
> noticed your messages since he at least tried to fix, but haven't
> noticed mine for some reason (regarding the lack of updated 16h
> microcode; why only 15h and 17h are being updated while 16h is
> forgotten - I could not understand, and this is relevant since there
> are some coreboot-supporting 16h boards)
>
> Best regards,
> Mike Banon
>
> On Sat, May 26, 2018 at 7:13 PM, Rudolf Marek  wrote:
>> Hi again,
>>
>> Dne 23.5.2018 v 21:52 Rudolf Marek napsal(a):
>>> For some reason this firmware update deletes microcode for Trinity CPUs, I 
>>> tried to contact the person who commit this
>>> without any luck. As I have previously written the github page has even 
>>> newer microcode.
>>
>> This was fixed, however the old (same) microcode was provided again.
>>
>> Thanks
>> Rudolf
>>
>>
>>
>>
>> --
>> 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 mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] DDR1 K8 boot broken too (was: Re: PC Engines apu2 boot regression)

[Ivan Ivanov]

 Just noticed your another message. Reposting it just in case it
didn't reach Jonathan:

Kyösti Mälkki wrote:

Right.. I ack the no-go.

Try if DEBUG_CAR=y (could be in menuconfig) works before/after the
regression commit.

My guess is it fails in cpu/amd/car/post_cache_as_ram.c:101, that's
about the first place where car_get_var() goes wrong on systems with
LATE_CBMEM_INIT. IMHO it should not even have built when there is any
CAR_GLOBAL symbol present.

I would rather not see any EARLY_CBMEM_INIT or LATE_CBMEM_INIT tests
added to the tree today. Those K8 were meant to be left behind last
October. Once they are all removed from master, fixing those "*.c"
includes and CAR migration can bring your board back...

2018-05-08 11:37 GMT+03:00 Ivan Ivanov <qmaster...@gmail.com>:
> Sadly it turned out that didn't help to Jonathan:
>
> I'm skeptical this will address my issue on msi/ms7135, as it's a
> Socket 754 board that only single-core CPU packages are available for.
> Nevertheless, I'll give this change a try.
>
> Indeed, it does not fix the issue I'm having.
>
>
> 2018-05-06 8:22 GMT+03:00 Kyösti Mälkki <kyosti.mal...@gmail.com>:
>> On Fri, May 4, 2018 at 7:25 PM, Aaron Durbin via coreboot
>> <coreboot@coreboot.org> wrote:
>>> On Fri, May 4, 2018 at 10:01 AM, Jonathan A. Kollasch
>>> <jakll...@kollasch.net> wrote:
>>>> On Fri, May 04, 2018 at 05:23:40PM +0200, Piotr Król wrote:
>>>>> Hi Aaron,
>>>>> I tried to boot PC Engines apu2 on recent master branch and discovered
>>>>> that it not boot. Bisection points to:
>>>>>
>>>>> 60320182d011 console: only allow console messages after initialization
>>>>>
>>>>> It is hard to believe that this change cause AGESA reset loop, but I
>>>>> checked 3 times. After applying above commit I end up with loop:
>>>>
>>>> I see a similar romstage boot loop starting with this commit on
>>>> msi/ms7135 (K8N Neo3), a DDR1 K8 board.
>>>
>>> I think it's the AMD boards and their weird config. CAR_GLOBAL is
>>> used, but apparently these boards fail if accessing CAR_GLOBAL at the
>>> wrong time? If you have log diffs w/ and w/o the patch it'd help with
>>> root cause.
>>>
>>
>> Jonathan, try this: https://review.coreboot.org/c/coreboot/+/26120
>>
>> Kyösti
>>
>> --
>> 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] DDR1 K8 boot broken too (was: Re: PC Engines apu2 boot regression)

[Ivan Ivanov]

Sadly it turned out that didn't help to Jonathan:

I'm skeptical this will address my issue on msi/ms7135, as it's a
Socket 754 board that only single-core CPU packages are available for.
Nevertheless, I'll give this change a try.

Indeed, it does not fix the issue I'm having.


2018-05-06 8:22 GMT+03:00 Kyösti Mälkki :
> On Fri, May 4, 2018 at 7:25 PM, Aaron Durbin via coreboot
>  wrote:
>> On Fri, May 4, 2018 at 10:01 AM, Jonathan A. Kollasch
>>  wrote:
>>> On Fri, May 04, 2018 at 05:23:40PM +0200, Piotr Król wrote:
 Hi Aaron,
 I tried to boot PC Engines apu2 on recent master branch and discovered
 that it not boot. Bisection points to:

 60320182d011 console: only allow console messages after initialization

 It is hard to believe that this change cause AGESA reset loop, but I
 checked 3 times. After applying above commit I end up with loop:
>>>
>>> I see a similar romstage boot loop starting with this commit on
>>> msi/ms7135 (K8N Neo3), a DDR1 K8 board.
>>
>> I think it's the AMD boards and their weird config. CAR_GLOBAL is
>> used, but apparently these boards fail if accessing CAR_GLOBAL at the
>> wrong time? If you have log diffs w/ and w/o the patch it'd help with
>> root cause.
>>
>
> Jonathan, try this: https://review.coreboot.org/c/coreboot/+/26120
>
> Kyösti
>
> --
> 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] Thread derailment

[Ivan Ivanov]

Regarding the FSP-S thread - sorry, but I did not see any derailment.
The whole thread - 'Why do we have FSP-S' - is about "why we should
have more blobs when we already have enough?" And its understandable
that some people got upset while seeing how coreboot is slowly turning
from being almost completely open source to the big collection of blobs
launching each other. Hopefully this reply would not get me removed...

Best regards,
Ivan Ivanov

2018-05-01 19:07 GMT+03:00 ron minnich <rminn...@gmail.com>:
> We've had to remove people from the list before, and I suppose at some point
> it might have to happen again. Nobody likes this option. Sometimes there is
> no choice.
>
> I agree that on a technical discussion list there's no place for abusive
> language. We're all trying to do the best we can in a non-ideal world.
>
> ron
>
> On Tue, May 1, 2018 at 9:03 AM David Hendricks <david.hendri...@gmail.com>
> wrote:
>>
>> Hello all,
>> Recently I've noticed an uptick in threads going off-topic. While some
>> noise should be expected on an open source mailing list, I think it's become
>> very counterproductive in many recent cases. A good example is the FSP-S
>> thread going on where we see clear examples of people interjecting with
>> non-technical diatribes and disrespecting developers, corporate
>> contributors, and coreboot itself in violation of the existing community
>> standards (https://coreboot.org/Code_of_Conduct).
>>
>> Most of this is perpetrated by a very small handful of individuals who
>> have not contributed anything to the codebase, so I think the current
>> problem could be dealt with easily. It might also be worth adding something
>> about keeping threads on-topic and focused on technology in the Code of
>> Conduct.
>>
>> Another option would be to have a developer-only mailing list, but I think
>> it's best to try and keep things open to the community at large even if that
>> means ejecting the most disruptive members.
>>
>> Thoughts?
>> --
>> 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 mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Why do we have FSP-S

[Ivan Ivanov]

I think, by "The Right Direction" he meant having the open source code
instead of FSP-S blobs.
'Why do we have FSP-S' - I have the same question. Why this code must
be kept closed, Intel?
Open source is always better than closed, and your major competitor -
AMD - would not be able
to use your source code - not just because of the licenses, but
because your CPUs are so different

2018-05-02 10:45 GMT+03:00 Duncan :
> Hello Zoran,
>
> Zoran Stojsavljevic:
>>> Our recommendation for some time has been a mix -- arm64 client devices
>>> (laptops, tablets, etc.) and ppc64el servers.  With those two, you can
>>> replace x86 entirely if you don't have proprietary software in your
>>> environment.
>>
>> With all due respect, this is the discussion about Coreboot going into
>> The Right Direction! This is what I actually aimed for. :-)
>>
>
> Please clarify what "The Right Direction" is. You have confused me, as I
> thought the thread was about 'Why do we have FSP-S'.
>
>
> --
> 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] When does AMD release the fam15 spectre microcode updates?

[Ivan Ivanov]

If I understood all this correctly, the updated microcodes should be
forcing the CPU to do these MSR writes (or the low level action which
stands behind them) by default. So that, when you got this updated
microcode on your CPU, its already fixed and no further operations are
necessary!

At the moment both me and Mike have sent many letters to AMD (example
provided below, you could use its parts as well). Have not received
any good reply yet (only one reply, with a stupid link to spectre v2
description page and without any files attached) - but we are trying
hard and hope to eventually reach a smart person at AMD who could help
us...

By the way, these microcodes from platomav github page - are from
february/march, and I believe they do not contain a spectre v2 fix. So
we hope to either eventually get these microcodes from AMD, or to
somehow extract them from a super bloated Win10 update, or to try to
extract them from the updated BIOSes of other companies when they come
out

===
1) go to amd support page and open a ticket form
2) set company as "coreboot" or "coreboot BIOS"
Subject: Updated microcode for coreboot BIOS devs
We, the coreboot BIOS developers, have not received any microcode
updates from AMD (aimed towards patching the spectre v2
vulnerability). AMD sent these updated microcode binaries to many
motherboard and BIOS development companies, but forgot to send these
files to us at coreboot! Could you please provide a standalone
download of your updated microcode binaries, to make it possible for
us to include them to our coreboot BIOS running on AMD platforms ? We
will appreciate if you will share these updated microcode binaries
with us - maybe together with SHA-256 or SHA-512 hashes of these files
or GnuPG signatures to ensure the security of transaction Best
regards, Ivan Ivanov, coreboot BIOS firmware engineer

P.S. Although, ideally these new updated microcodes should be
committed tokernel/git/firmware/linux-firmware.git repository -->
directory called
"amd-ucode" .Currently it contains the following files:
microcode_amd.bin ,microcode_amd.bin.asc , microcode_amd_fam15h.bin
,microcode_amd_fam15h.bin.asc , microcode_amd_fam16h.bin
,microcode_amd_fam16h.bin.asc .They have been last updated at 2015/16
year, and we would like to see them updated again

2018-04-25 4:02 GMT+03:00 awokd via coreboot <coreboot@coreboot.org>:
> On Tue, April 24, 2018 11:31 pm, Nico Huber wrote:
>> On 25.04.2018 00:18, taii...@gmx.com wrote:
>
>>> I can't believe everyone else is so nonchalant about all this
>>> considering how important it is I still haven't figured out how to update
>>> the microcode on any of my computers - no guides I have found actually
>>> work and no distros have the new microcode for intel or amd despite it
>>> having been months.
>
> I'm not nonchalant, but I'm not entirely sure what to do with those patch
> files and was hoping to see a new amd microcode 15h bin with them
> incorporated.
>
>> I can't believe everybody is so nonchalant about Rowhammer but many
>> people make a big thing out of the comparatively tiny Spectre problem.
>>
>>>
>>> For the best security one should have both the new microcode and the
>>> lfence msr?
>>
>> Not for the best but for any security, you have to understand first that
>> both options only change something if your software is prepared to uti-
>> lize them. First update your software, then check what it needs / what the
>> developers expect (the new microcode I'd guess).
>
> If I remember the earlier discussion right on that lfence msr, the OS can
> also set it so although it would be nice if coreboot did as well, it's not
> required?
>
>
> --
> 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] Upgrade the 12 years old LZMA libraries - should we do it?

[Ivan Ivanov]

I have noticed that both coreboot and seabios are using the very old
versions of LZMA SDK. If we will upgrade our LZMA libraries from the
outdated-by-12-years 4.42 to the current version 18.04 , speed and
compression ratio should improve and maybe a few bugs will be fixed.
Do you think it should be done, or you are OK with using such an
outdated version?

Best regards,
Ivan Ivanov aka qmastery

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

[Ivan Ivanov]

 > If I compare the Lenovo X230 to Lenovo G505s this looks like a step
back: the G505s is targeted at another audience that Lenovo ThinkPad
Users. It looks to me like an entry level desktop, which is also very
bulky (without the additional performance of a W540).
> CPU comparison X230 CPU vs G505s
> AMD_A6-Series_for_Notebooks_A6-5350M_vs_Intel_Core_i5_Mobile_i5-3360M_(BGA)
> Also the G505s has less cores/no HT

Sorry, but what are you comparing with? G505S is a laptop, not a
desktop. and G505S laptop has been sold with different CPUs (which are
removable),
as well as at least three motherboard versions! ( only integrated GPU
/ integrated + HD 8570M discrete / integrated + R5 M230 discrete )

That A6-5350M cpu you have been comparing to - could be found at the
very low end version of G505S, and this A6 is probably not even
supported by coreboot
Most (if not all) of G505S+coreboot owners here - have A10-5750M AMD
CPU which is a powerful quad core CPU with functional virtualization,
not 2 core weak A6-5350M

So, this link should have been
http://www.cpu-world.com/Compare/815/AMD_A10-Series_for_Notebooks_A10-5750M_vs_Intel_Core_i5_Mobile_i5-3360M_(BGA).html

Looks like the performance of A10-5750M (G505S cpu) and i5-3360M (X230
cpu) is almost the same,
but now we should substract 5-30% or even more from i5-3360M
benchmarks - because the Meltdown vulnerability, for which this
horrible "5-30% or even more slowdown patch" is required ---> is Intel
specific vulnerability ( cpu_insecure , as reported by Linux kernel )

And... "thanks" to Intel Meltdown, the results are suddenly very
favorable for A10-5750M CPU, and for G505S in general

Best regards,
Ivan Ivanov

2018-01-11 8:34 GMT+03:00 [799] via coreboot <coreboot@coreboot.org>:
> Hello,
>
> Off-topic:
> Top-posted as Protonmail Android App is still unable to correctly use inline
> answers without correct quote layout/line breaks. Bug has been reported
> months ago :-/
>
> Taiidan wrote:
>
> "(...) CPU'swithout a fix there will
> be only one coreboot compatible laptop with open source hardware
> initiation that is remotely secure (...)"
>
> Currently I am using two laptops for my work setup:
> A 12.5" Lenovo X230 and a 15.x" Lenovo W540 both machines are running with
> Qubes OS 4rc3 and 16GB RAM. The W540 is a Dual-Boot system with Win10, the
> x230 is running Coreboot.
>
> Honestly I am shocked and angry if there will be no Intel Updates for the
> X230 and W540.
> On the other hand, if I am running Qubes and Coreboot, wouldn't this reduce
> the risk of Meltdown/Spectre attacks as Coreboot will protect me against
> remote attacks (stripped down AMT/Intel ME) and Qubes might reduce the
> attack surface as I am using several VMs and DVMs for browsing?
>
> If I compare the Lenovo X230 to Lenovo G505s this looks like a step back:
> the G505s is targeted at another audience that Lenovo ThinkPad Users. It
> looks to me like an entry level desktop, which is also very bulky (without
> the additional performance of a W540).
>
> CPU comparison X230 CPU vs G505s
> http://www.cpu-world.com/Compare/725/AMD_A6-Series_for_Notebooks_A6-5350M_vs_Intel_Core_i5_Mobile_i5-3360M_(BGA).html
>
> Also the G505s has less cores/no HT
>
> Frustration. Can't "we" build one or maybe two crowd founded secure Laptops
> (12", 15.x") with reasonable specs, good keyboard, hardware kill switches,
> internal wan (kill-switchable)?
> I can't think that choice is limited in 2018 to only 1 (in words "one")
> laptop modell, which is no nearly 5 years old (08/2013).
>
> Brave new world.
>
> [799]
>
>
>
>
> Gesendet von ProtonMail mobile
>
>
>
>  Original-Nachricht 
>
> An 11. Jan. 2018, 03:55, taii...@gmx.com schrieb:
>
>
> 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'swithout 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.
>
>
> --
> 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 mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] [flashrom] [announce] flashrom 1.0

[Ivan Ivanov]

Hi Nico,

Please tell - are there any real reasons why the Paul Kocialkowski's
KB9012 support patches
still cannot be merged? It is very discouraging - after 2 years of
waiting to not see them at 1.0
Is there any way to get these patches merged, and maybe re-tag the
flashrom 1.0 release ?

Best regards,
Ivan Ivanov

2017-12-30 23:49 GMT+03:00 Ivan Ivanov <qmaster...@gmail.com>:
> Hi Nico, please could you also merge the KB9012 patches by Paul Kocialkowski :
>
> https://patchwork.coreboot.org/patch/4412/
> https://patchwork.coreboot.org/patch/4413/
> https://patchwork.coreboot.org/patch/4414/
>
> It is ridiculous how these patches are still not merged , after almost
> 2 years... :P
> These patches are adding the support for KB9012 reading / writing,
> the only open source flashing solution for these embedded controllers
>
> Merging these patches could accelerate the development of Origami EC
> libre firmware,
> please do it
>
> Best regards,
> Ivan Ivanov
>

2018-01-03 0:50 GMT+03:00 Nico Huber <nic...@gmx.de>:
> Hi folks,
>
> flashrom-1.0 is out! finally. It's not a very big version step in terms
> of changes, but it was about time and we thought with the switch over to
> Git it's the right moment for 1.0.
>
> Here are the release notes:
> https://flashrom.org/Flashrom/1.0
>
> If you don't use Git, you can find a tarball here:
> https://download.flashrom.org/releases/flashrom-1.0.tar.bz2
>
> Thanks to everybody supporting flashrom and this release in particular.
>
> Nico
>
> ___
> flashrom mailing list
> flash...@flashrom.org
> https://mail.coreboot.org/mailman/listinfo/flashrom

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

Re: [coreboot] G505s with Coreboot unable to run any version of Qubes

[Ivan Ivanov]

Hi Emil, thank you very much for your report.
Regarding Qubes 3.2 : at the Qubes HCL list I wrote:

"after Qubes R3.2 installation it cant boot - cant reach GRUB Boot Menu
because MBR (or GRUB) is corrupted. Use grub2-install to fix it (read more)
Everything else is OK "

https://groups.google.com/forum/#!msg/qubes-users/TS1zfKZ7q8w/JQFkVF4xBgAJ

If you fix your GRUB as described ^^^ you may be able to finally boot Qubes 3.2
Please test it and let me know the results

Live 3.1 was buggy, full 3.1 would have worked. Haven't tested 4.0 -
can't speak about it

Best regards,
Ivan

2017-12-28 1:19 GMT+03:00 Emil Novik via coreboot :
> Hey, I'm having some heavy trouble getting my laptop to run Qubes and I
> first thought I was having issues with the OS. But after digging into the
> logs I managed to get(crashes too early during boot to get any persistent
> logs, had to write most by hand) it feels more like an issue with my
> Coreboot built.
>
> So there are the details :
> - G505s with integrated HD 8650G + discrete R5 M230 graphics.
> - Coreboot 4.6-2477-g6ab3edac3c-dirty with processor microcode patch
> (change-ID: Ibbfee47ce1d5081640d6924e2b12f5213a7fcadb).
> - Runs Debian Stretch fine.
> - Fails to start Qubes 3.2 / 4.0 rc3 / Live 3.1.
> - I added the vgabios.rom for the integrated card with menuconfig and the
> one for the discrete card with cbfstool.
> - Coreboot.rom, .config and full make output as attachment.
>
>
> Some more error data I gathered from coreinfo's Bootlog :
>
> Failed to enable LTR for dev = PCI: 01:00.0
> Failed to enable LTR for dev = PCI: 02:00.0
> ...
> I2C: 01:50 missing read_resources
> I2C: 01:51 missing read_resources
> PNP: 00ff.1 missing read_resources
> ...
> Warning: Can't write PCI_INTR 0xC00/0xC01 registers because
> 'mainboard_picr_data' or 'mainboard_intr_data' tables are NULL
> Warning: Can't write PCI IRQ assignments because 'mainboard_pirq_data'
> structure does not exist
> ...
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/Common/CommonReturns.c', line 187
> ASSERTION ERROR: file
> 'src/vendorcode/amd/agesa/f15tn/Proc/CPU/cpuGeneralServices.c', line 776
> ...
> Manufacturer: ef
> SF: Detected W25Q32 with sector size 0x1000, total 0x40
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> Manufacturer: ef
> SF: Detected W25Q32 with sector size 0x1000, total 0x40
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> ASSERTION ERROR: file 'src/drivers/spi/spi_flash.c', line 425
> ASSERTION ERROR: file 'src/drivers/amd/agesa/state_machine.c', line 309
> ...
> EEPROM not found
> EEPROM not found
> EEPROM not found
> EEPROM not found
> EEPROM not found
> EEPROM not found
> EEPROM not found
> ...
> I2C: 01:50 (unknown)
> I2C: 01:51 (unknown)
> ...
> APIC: 11 (unknown)
> APIC: 12 (unknown)
> APIC: 13 (unknown)
> PCI: 01:00.0 (unknown)
> PCI: 02:00.0 (unknown)
> PNP: 00ff.0 (unknown)
>
>
> "..." are parts I didn't write down as they didn't show any obvious
> errors(but I'm bad at seeing them) and it would take me a lng time to
> write down the full 

[coreboot] Public Notepad for coreboot 4.7 release

[Ivan Ivanov]

Hi Paul, only now I noticed this public notepad for 4.7 coreboot release notes:

[1] https://pads.ccc.de/s7c2eXetAu

Last revision - 8 days ago, hope more people will notice this notepad now.
I will be contributing to it

Best regards,
Ivan


2017-12-21 11:23 GMT+03:00 Paul Menzel :
> Dear coreboot folks,
>
>
> Martin said, that the missing/unwritten release notes are the reason
> holding up the coreboot 4.7 release.
>
> Could the maintainers, developers, and users please jump in and help
> write them. Please use the pad [1]. Some coreboot folks already
> contributed. Big thank you to them.
>
> Also, thanks to the now mostly great and elaborate commit messages, the
> release notes should really just give a broad overview. The detail can
> then be looked up.
>
> Additionally, can you think of the something that has to be adapted by
> someone switching from coreboot 4.6 to coreboot 4.7?
>
>
> Thanks,
>
> Paul
>
>
> [1] https://pads.ccc.de/s7c2eXetAu
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"> 

  https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif;
alt="" width="46" height="29" style="width: 46px; height: 29px;"
/>
Без вирусов. https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank" style="color: #4453ea;">www.avast.ru




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

Re: [coreboot] Depthcharge License

[Ivan Ivanov]

This commit got merged and the Depthcharge now should have the
requested license files
at its root directory. Dear friend, please let us learn about your
device once it is released,
maybe some of the coreboot developers would want to get your device -
to use, and possibly help

Best regards,
Ivan Ivanov

2017-12-21 21:34 GMT+03:00 Aaron Durbin via coreboot <coreboot@coreboot.org>:
> https://chromium-review.googlesource.com/c/chromiumos/platform/depthcharge/+/837589
>
> On Thu, Dec 21, 2017 at 11:14 AM, <ttu...@codeaurora.org> wrote:
>>
>> On 2017-12-19 09:53, David Hendricks wrote:
>>>
>>> To be fair, it appears that many source files refer to a non-existent
>>> LICENSE file. Someone on the CrOS team should probably just add the
>>> LICENSE file for depthcharge and/or contact mal@ to see how the
>>> license info is being collected these days (e.g. for
>>> chrome://os-credits [3]).
>>>
>>
>> Thanks for the input on the DC licensing, and because lawyers are involved
>> I need to ask a direct question.
>> Can a Depthcharge maintainer (anybody who has +2 gerrit authority would
>> suffice) state on this thread
>> that the Depthcharge project license is GPLv2 (or later)?
>>
>> I know this feels redundant and that the question has been asked and
>> answered, I'm just trying
>> to satisfy our internal legal group.
>>
>> Per David's point above, this direct question would not be required to
>> satisfy the lawyers
>> if a top-level COPYING or LICENSE file is added to Depthcharge.  Which I
>> will be happy to
>> add once I'm able to start contributing to the project.
>> Cheers,
>> T.mike
>>
>>> On Tue, Dec 19, 2017 at 9:19 AM, ron minnich <rminn...@gmail.com>
>>> wrote:
>>>
>>>> Is there even a question? Looks like aaron just answered the
>>>> original question, which boils down to Read The Source?
>>>>
>>>> On Tue, Dec 19, 2017 at 7:58 AM Aaron Durbin via coreboot
>>>> <coreboot@coreboot.org> wrote:
>>>>
>>>> On Tue, Dec 19, 2017 at 8:03 AM, <ttu...@codeaurora.org> wrote:
>>>> On 2017-12-15 13:39, ttu...@codeaurora.org wrote:
>>>> Preparing to mirror the coreboot.org [1] requires us to vet the
>>>> various
>>>> licenses, etc.
>>>>
>>>> There doesn't appear to be a LICENSE or COPYING file in the
>>>> Depthcharge tree.
>>>>
>>>> My understanding is that Depthcharge is licensed GPLv2 (or later).
>>>>
>>>> How would I confirm this with an online source?
>>>>
>>>> Cheers,
>>>> T.mike
>>>>
>>>> Should this query be posted on Chromium list rather than Coreboot
>>>> list?
>>>
>>>
>>> Probably. The files in the depthcharge repository  have licenses at
>>> the top of each file. They are GPLv2.
>>>
>>>> Cheers,
>>>> T.mike
>>>>
>>>> --
>>>> coreboot mailing list: coreboot@coreboot.org
>>>> https://mail.coreboot.org/mailman/listinfo/coreboot [2]
>>>
>>>  --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://mail.coreboot.org/mailman/listinfo/coreboot [2]
>>> --
>>> coreboot mailing list: coreboot@coreboot.org
>>> https://mail.coreboot.org/mailman/listinfo/coreboot [2]
>>>
>>>
>>>
>>> Links:
>>> --
>>> [1] http://coreboot.org
>>> [2] https://mail.coreboot.org/mailman/listinfo/coreboot
>>> [3] https://www.chromium.org/chromium-os/licenses
>
>
>
> --
> 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] How to properly conform with GPLv2 for Coreboot and SeaBIOS on an embedded system

[Ivan Ivanov]

Good day, Ian!

Perhaps it is a good idea to look what another responsible company did
at the same situation

The TP-Link company is using the GPLv2-licensed source code for the
firmware of their routers,
and they include a small paper printed mini-book ---> which contains
two major things:
1) the complete text of GNU GPLv2 license
2) an explanation that the complete firmware source code could be
obtained from TP-Link website:
http://www.tp-link.com/us/support/gpl-code-center

But it seems that in your situation you could not include such a mini-book,
because it could be lost before it reaches the eventual user of your device
and also - these are additional expenses to print such mini-books

However there are two excellent alternative solutions :

1ST SOLUTION :

1) Modify the SeaBIOS source code, so that - while booting - it will
print a two-line message
at the bottom of screen, something like "The source code of this BIOS
is GNU GPLv2 licensed,
for more info - press "ESC" and then a letter corresponding to
"FreeDOS with GNU GPLv2 texts" boot entry

2) Download a FreeDOS floppy, remove an installer from it (not
needed!) and add two text files to this image:
*) your "mini-book" in txt format with GNU GPLv2 license text and a
link to your sources
*) similar "mini-book" but for FreeDOS - with a license for FreeDOS
and a link to its sources

3) Add this virtual floppy to the completed coreboot+SeaBIOS build
while using the LZMA compression
using a simple command like this:

./coreboot/build/cbfstool ./coreboot/build/coreboot.rom add -f
./FreeDOS.img -n floppyimg/FreeDOS_with_GNU_GPLv2_texts.lzma -t raw -c
lzma

and then it will be shown as "FreeDOS with GNU GPLv2 texts" boot entry
at SeaBIOS boot menu.

Good thing is that even if the user makes some edits to license using
a text editor -
these changes will be temporary and will disappear after a user
reboots your device

When LZMA compression is used, FreeDOS floppy takes about 714 KB -
twice less than its original 1440 KB size

However, if thats still too large for you, instead of FreeDOS you
could use any other floppy based OS
which meets these two requirements:
*) Contains a text editor / text displayer as the means to show the
license texts to the user.
*) That OS is licensed by GNU GPLv2 or less restrictive license

So, if you don't like FreeDOS you could use something like MikeOS:
*) this floppy MikeOS is licensed by BSD-like license
*) it compresses significantly better than FreeDOS: to just 54 KB,
and even better if you remove some games/demos from it

2ND SOLUTION:

Similar to 1ST, but - instead of using a floppy based OS - you could
directly modify the SeaBIOS source code
to include a fake boot entry - which, when selected, instead of
booting any device will start showing
your mini-book page by page and its possible to scroll pages or move
back/forward between them

I wrote a patch to SeaBIOS which sadly didn't got accepted, you could
obtain it here:
https://mail.coreboot.org/pipermail/seabios/2017-June/011416.html
[SeaBIOS] [PATCH] boot: boot menu up to 35 devices with letters and
possible pages

Without this patch the SeaBIOS supports just 9 or 10 boot entries,
but with this patch - 35 boot entries, and its possible to switch the pages
between the first 18 entries and last 17 entries

You can borrow this paging code and modify it to display the pages of
your mini-book
with license texts and explanation that sources are easily available
from your website

Actually it would be much better if you will be able to contribute the
sources for your device
to the official coreboot repositories:
1) it will be more convenient both for you and your users to have the
latest coreboot updates
2) other coreboot users will clearly see that your device is supported
and would want to get it

Please ask if any questions, we could come up with a lot of good ideas
of how it could be done.
Also it will be great to learn about your product once its released,
maybe some of coreboot developers
would want to get your device - and this could probably give some
additional support from community

Best regards,
Ivan Ivanov


  https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif;
alt="" width="46" height="29" style="width: 46px; height: 29px;"
/>
Без вирусов. https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank" style="color: #4453ea;">www.avast.ru




2017-12-24 9:46 GMT+03:00 Lewis, Ian (Microstar Laboratories)
<ile...@mstarlabs.com>:
> I am looking at using a processor module that initializes using Coreboot and
> SeaBIOS to make an embedded hardware product. Assumin

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

[Ivan Ivanov]

Sadly the ARM processor also have the ME-like backdoor (called "TrustZone).
And even MIPS is going this road soon (check out the "MIPS OmniShield" news).

Could it be the requirement of US Government - for all the consumer
CPU to have backdoors ?
My last hopes are on POWER 9 and RISC V now ; meanwhile sticking to
the AMD pre-PSP tech

Best regards,
Ivan Ivanov


2017-12-23 15:08 GMT+03:00 Alberto Bursi <alberto.bu...@outlook.it>:
>
>
> 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

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

Re: [coreboot] cbfstool without cloning the whole repository? Use script for <2M download

[Ivan Ivanov]

It looks like there were two typos in this wonderful script :
missing " \ " at the end of two " --execute robots=off " lines
Other than that, this script is still working. Below is a fixed copy,

if you sometimes need cbfstool without cloning the whole coreboot
you may try it out:

### SCRIPT BEGIN ###

wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
--user-agent="Mozilla/5.0" --execute robots=off \
https://review.coreboot.org/cgit/coreboot.git/plain/util/cbfstool/

wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
--user-agent="Mozilla/5.0" --execute robots=off \
https://review.coreboot.org/cgit/coreboot.git/plain/src/commonlib/ \
--exclude-directories=/cgit/coreboot.git/plain/src/commonlib/storage/ \
--reject=configstring.c,iobuf.c,cbmem_id.h,configstring.h,coreboot_tables.h,\
fmap_serialized.h,iobuf.h,sd_mmc_ctrlr.h,sdhci.h,stdlib.h,storage.h,\
timestamp_serialized.h

wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
--user-agent="Mozilla/5.0" --execute robots=off \
https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/edk2/uefi_2.4/

wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
--user-agent="Mozilla/5.0" --execute robots=off \
https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/fsp/fsp1_1/IntelFspPkg/Include/FspInfoHeader.h

wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
--user-agent="Mozilla/5.0" --execute robots=off \
--directory-prefix=./3rdparty/vboot/ \
https://review.coreboot.org/cgit/vboot.git/plain/firmware/2lib/ \
--reject=2api.c,2crc8.c,2hmac.c,2misc.c,2nvstorage.c,2rsa.c,2secdata.c,\
2secdatak.c,2stub.c,2tpm_bootmode.c,2crc8.h,2hmac.h,2misc.h,\
2nvstorage_fields.h,2nvstorage.h,2rsa.h,2secdata.h,2tpm_bootmode.h

wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
--user-agent="Mozilla/5.0" --execute robots=off \
--directory-prefix=./3rdparty/vboot/ \
https://review.coreboot.org/cgit/vboot.git/plain/firmware/include/vb2_api.h

cd ./util/cbfstool/

make all

### SCRIPT END ###

2017-07-12 1:53 GMT+03:00 Ivan Ivanov <qmaster...@gmail.com>:
> Dear friends, sometimes you need to do a few operations with
> coreboot.rom (e.g. update its' payload) without changing
> coreboot.rom's main code. If you have bad Internet connection or just
> want to quickly get the latest version of cbfstool without cloning the
> whole coreboot/vboot repositories - my bash script below will really
> help you!
>
> It downloads only the files required for the successful compilation of
> cbfstool  - whole ./util/cbfstool directory (93 files, ~1,3M size) and
> all the dependencies:
> ./src/commonlib - 20 files, ~152K
> ./src/vendorcode/intel/edk2/uefi_2.4/ - 26 files, 272K
> ./src/vendorcode/intel/fsp/fsp1_1/IntelFspPkg/Include/FspInfoHeader.h - ~4K
>
> ((( I don't understand what Intel is doing here, but I can't build
> without these files! )))
>
> ./3rdparty/vboot/firmware/2lib/ - 17 files, 170K
> ./3rdparty/vboot/firmware/include/vb2_api.h - ~1K
>
> In total, its 158 files and just 1.9M - less than 2M !
> And it builds OK. Hope it will be useful for you ;-)
>
> ### SCRIPT BEGIN ###
>
> wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
> --user-agent="Mozilla/5.0" --execute robots=off \
> https://review.coreboot.org/cgit/coreboot.git/plain/util/cbfstool/
>
> wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
> --user-agent="Mozilla/5.0" --execute robots=off \
> https://review.coreboot.org/cgit/coreboot.git/plain/src/commonlib/ \
> --exclude-directories=/cgit/coreboot.git/plain/src/commonlib/storage/ \
> --reject=configstring.c,iobuf.c,cbmem_id.h,configstring.h,coreboot_tables.h,\
> fmap_serialized.h,iobuf.h,sd_mmc_ctrlr.h,sdhci.h,stdlib.h,storage.h,\
> timestamp_serialized.h
>
> wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
> --user-agent="Mozilla/5.0" --execute robots=off \
> https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/edk2/uefi_2.4/
>
> wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
> --user-agent="Mozilla/5.0" --execute robots=off \
> https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/fsp/fsp1_1/IntelFspPkg/Include/FspInfoHeader.h
>
> wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
> --user-agent="Mozilla/5.0" --execute robots=off
> --directory-prefix=./3rdparty/vboot/ \
> https://review.coreboot.org/cgit/vboot.git/plain/firmware/2lib/ \
> --reject=2api.c,2crc8.c,2hmac.c,2misc.c,2nvstorage.c,2rsa.c,2secdata.c,\
> 2secdatak.c,2stub.c,2tpm_bootmode.c,2crc8.h,2hmac.h,2misc.h,\
> 2nvstorage_fields.h,2nvstorage.h,2rsa.h,2secdata.h,2tpm_bootmode.h
&g

Re: [coreboot] Lenovo G505s AMD Hardware Virtualization

[Ivan Ivanov]

awokd, could you please answer some questions:

1) From where you got that 0x06001119 microcode patch?
Is it a trusted source of a microcode? (hope its directly from AMD)

2) Is there any way to determine that 0x06001119 is really the latest microcode?
Or there could be more recent versions available?

Best regards,
Ivan Ivanov

2017-12-12 6:21 GMT+03:00 taii...@gmx.com <taii...@gmx.com>:
> Congratulations for following through on the investigation :D
>
> I am not sure how to do a commit, but I hope you are able to find out as you
> will have helped a lot of people.
>
> I am pleased with myself for noticing that the lack of microcode updates was
> the issue - as the CPU is similar to a piledriver not a bulldozer it
> requires microcode for IOMMU.
>
> I do not have the technical documents for that chipset and I do not know how
> to change the PCI regs but I am sure the USB controllers support FLR
> considering the nearly identical SR56xx chipsets usb controllers do - I will
> look in to this further.
>
>
> --
> 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] Coreboot Bios Compatibility

[Ivan Ivanov]

Good day Raziel, when there is a question about whether a particular
hardware supports coreboot or not, the first thing you could do is to
look through this page :
https://www.coreboot.org/Supported_Motherboards (no GA-MA790GP-DS4H
there). If there is no entry for your motherboard at this page, next
you could git clone the coreboot source code from
http://review.coreboot.org/coreboot/ and do "make menuconfig" command
in the directory with coreboot sources, then go to Mainboard , choose
your Mainboard Vendor ( Gigabyte ) and then check if it is possible to
select your mainboard model - no GA-MA790GP-DS4H also, but there are
GA-MA785GM-US2H / GA-MA785GMT-UD2H / GA-MA78GM-US2H with a somewhat
similar model number. Now, if you don't see your motherboard there,
you may either to simply buy a motherboard from Supported Motherboards
list, or - maybe try to port a coreboot to your motherboard,
especially if its quite similar to the already-supported motherboard.
E.g. check if those GA-MA785 motherboards have the same chipset as
your GA-MA790. If your motherboard contains the components that are
already supported by coreboot, your chances of getting coreboot on
this motherboard are significantly increasing. Please look through
this page for more info -
https://www.coreboot.org/Motherboard_Porting_Guide - and ask if you
need to clarify something. To overclock you probably need to dive deep
into coreboot sources (luckily its in C not assembly) and maybe also
check the OS overclocking tools such as turionpowercontrol for AMD
CPUs which works under Linux. Also,
https://www.coreboot.org/Build_HOWTO Best regards , Ivan Ivanov

2017-12-03 17:14 GMT+03:00 Raziel in Shambles <noneofur2...@gmail.com>:
> Hello,
>
>
> i'd like to know if it is possible to flash the coreboot bios to my mobo.
>
> If so might i also burden you for a brief tutorial, aside from the one
> provided on coreboot.org, on
>
> how to actually build this bios (f.e. does it need to be i386 or x64, howto
> configure the payload,
>
> is overclocking a possibility etc.).
>
>
> thx in advance
>
>
> Step 1:
>
> see Step 5
>
> Step 2:
>
> see attach
>
> Step 3:
>
> see attach
>
> Step 4:
>
> see attach
>
> Step 5:
>
> https://www.gigabyte.com/Motherboard/GA-MA790GP-DS4H-rev-10#sp
>
>
>
> --
> 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] freebsd

[Ivan Ivanov]

Yes, FreeBSD is my primary OS at my coreboot'ed machine at the moment.
I got a bit disappointed at Linux recent developments and decided to switch

Best regards,
Ivan Ivanov

2017-12-03 14:35 GMT+03:00 ingegneriafore...@alice.it
<ingegneriafore...@alice.it>:
> Hello guys,
>
> I apologize with you for the strange question.
>
> Can you tell me if some of you uses coreboot with the Freebsd Operating
> system on its machine ?
>
> Thanks in advance.
>
> Vincenzo.
>
>
> Forensic Consultant
> Tribunale di Lecce
>
> Studio: Strada di Garibaldi - Contrada Paradisi
> 73010 Lequile (LE)
>
> cell: 339.7968555
> skype: vincenzo.di_salvo
>
> --
> 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] Lenovo G505s AMD Hardware Virtualization

[Ivan Ivanov]

Hi awokd, are you sure that your HVM is correctly installed / has a
correct config ?
Because: you may have heard about Qubes OS - excellent OS which is based on Xen,
has the same and even stronger security than Xen in some cases, and it
is working perfectly
at Lenovo G505S laptop with coreboot installed

Please go to Qubes HCL hardware compatibility list page -
https://www.qubes-os.org/hcl/ ,
and look at G505S report for Qubes R3.2 version - both HVM and IOMMU
and even SLAT :
all these hardware virtualization functions are working perfectly.

also please read this message:
https://groups.google.com/forum/#!msg/qubes-users/TS1zfKZ7q8w/JQFkVF4xBgAJ
it contains a link to a forum post with attachments, not just .config
but also the coreboot G505S binaries
which have been tested with Qubes OS
(yes they have been done almost 1 year ago, outdated, but they contain
some nice extra stuff)

about 0 bytes cpu_microcode_blob.bin - if you look at the memory map
of 1 year old coreboot G505S build,
(provided below), there is no microcode. My guess is that no microcode
is needed for A10-5750M APU,
it is Richland architecture which is pretty refined, not even sure if
the microcode updates exist for this one -
please tell me if I'm wrong here

Performing operation on 'COREBOOT' region...
Name   Offset Type Size
cbfs master header 0x0cbfs header  32
apu/amdfw  0x80   raw  4096
fallback/romstage  0x10c0 stage300588
fallback/ramstage  0x4a780stage111690
config 0x65c40raw  478
revision   0x65e80raw  575
cmos_layout.bin0x66100cmos_layout  1392
pci1002,990b.rom   0x666c0optionrom61952
fallback/dsdt.aml  0x75940raw  9004
img/coreinfo   0x77cc0payload  101048
img/nvramcui   0x907c0payload  140636
fallback/payload   0xb2d80payload  62953
payload_config 0xc23c0raw  1543
payload_revision   0xc2a00raw  238
img/tint   0xc2b40payload  93928
img/memtest0xd9a80payload  180268
img/filo.lzma  0x105b00   payload  110829
floppyimg/kolibri.lzma 0x120c40   raw  1254336
(1474560 after LZMA decompression)
(empty)0x253080   null 1755288
bootblock  0x3ff940   bootblock1408




2017-11-28 15:48 GMT+03:00 awokd :
> Have been struggling for the past couple months to get Xen hardware
> virtualization working on this Corebooted laptop. Paravirtualized VMs
> work, but whenever I start a fully virtualized VM (HVM) it hard freezes
> the entire system- no keyboard or mouse response. No related output is
> showing in any logs, maybe because it's freezing too fast.
>
> I'm not entirely sure if this is a Coreboot or Xen issue so I'm trying to
> rule out Coreboot. Would anyone on the list be able to provide a known
> good G505s Coreboot .config that is working with fully hardware
> virtualized VMs, preferably under Xen 4.8.2 or another recent version? KVM
> or ESXi might be OK too; should also let me narrow down the problem
> domain.
>
> One odd thing found from boot logs is:
>
> [6.744165] microcode: CPU0: patch_level=0x
> [6.744205] microcode: CPU1: patch_level=0x
> [6.744220] microcode: CPU2: patch_level=0x
> [6.744227] microcode: CPU3: patch_level=0x
> [6.744290] microcode: Microcode Update Driver: v2.01
>
> and the cpu_microcode_blob is 0 bytes even though I set the menuconfig
> options:
>
> CONFIG_USE_BLOBS=y
> CONFIG_CPU_MICROCODE_CBFS_GENERATE=y
>
> Name   Offset Type   Size   Comp
> cbfs master header 0x0cbfs header32 none
> cpu_microcode_blob.bin 0x80   microcode   0 none
> fallback/ramstage  0x100  stage  129898 none
> payload_revision   0x1fcc0raw   239 none
> (empty)0x1fe00null  152 none
> apu/amdfw  0x1fec0raw131072 none
> fallback/romstage  0x3ff00stage  320844 none
> config 0x8e4c0raw   528 none
> revision   0x8e740raw   568 none
> cmos_layout.bin0x8e9c0cmos_layout  1164 none
> pci1002,990b.rom   0x8eec0optionrom   61952 none
> fallback/postcar   0x9e140stage   13268 none
> fallback/dsdt.aml  0xa1580raw  9435 none
> img/coreinfo   0xa3ac0payload102264 none
> img/nvramcui   0xbca80payload141596 none

[coreboot] cbfstool without cloning the whole repository? Use script for <2M download

[Ivan Ivanov]

Dear friends, sometimes you need to do a few operations with
coreboot.rom (e.g. update its' payload) without changing
coreboot.rom's main code. If you have bad Internet connection or just
want to quickly get the latest version of cbfstool without cloning the
whole coreboot/vboot repositories - my bash script below will really
help you!

It downloads only the files required for the successful compilation of
cbfstool  - whole ./util/cbfstool directory (93 files, ~1,3M size) and
all the dependencies:
./src/commonlib - 20 files, ~152K
./src/vendorcode/intel/edk2/uefi_2.4/ - 26 files, 272K
./src/vendorcode/intel/fsp/fsp1_1/IntelFspPkg/Include/FspInfoHeader.h - ~4K

((( I don't understand what Intel is doing here, but I can't build
without these files! )))

./3rdparty/vboot/firmware/2lib/ - 17 files, 170K
./3rdparty/vboot/firmware/include/vb2_api.h - ~1K

In total, its 158 files and just 1.9M - less than 2M !
And it builds OK. Hope it will be useful for you ;-)

### SCRIPT BEGIN ###

wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
--user-agent="Mozilla/5.0" --execute robots=off \
https://review.coreboot.org/cgit/coreboot.git/plain/util/cbfstool/

wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
--user-agent="Mozilla/5.0" --execute robots=off \
https://review.coreboot.org/cgit/coreboot.git/plain/src/commonlib/ \
--exclude-directories=/cgit/coreboot.git/plain/src/commonlib/storage/ \
--reject=configstring.c,iobuf.c,cbmem_id.h,configstring.h,coreboot_tables.h,\
fmap_serialized.h,iobuf.h,sd_mmc_ctrlr.h,sdhci.h,stdlib.h,storage.h,\
timestamp_serialized.h

wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
--user-agent="Mozilla/5.0" --execute robots=off \
https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/edk2/uefi_2.4/

wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
--user-agent="Mozilla/5.0" --execute robots=off \
https://review.coreboot.org/cgit/coreboot.git/plain/src/vendorcode/intel/fsp/fsp1_1/IntelFspPkg/Include/FspInfoHeader.h

wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
--user-agent="Mozilla/5.0" --execute robots=off
--directory-prefix=./3rdparty/vboot/ \
https://review.coreboot.org/cgit/vboot.git/plain/firmware/2lib/ \
--reject=2api.c,2crc8.c,2hmac.c,2misc.c,2nvstorage.c,2rsa.c,2secdata.c,\
2secdatak.c,2stub.c,2tpm_bootmode.c,2crc8.h,2hmac.h,2misc.h,\
2nvstorage_fields.h,2nvstorage.h,2rsa.h,2secdata.h,2tpm_bootmode.h

wget --recursive --no-parent --no-host-directories --cut-dirs=3 \
--user-agent="Mozilla/5.0" --execute robots=off
--directory-prefix=./3rdparty/vboot/ \
https://review.coreboot.org/cgit/vboot.git/plain/firmware/include/vb2_api.h

cd ./util/cbfstool/

make all

### SCRIPT END ###

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

[coreboot] AMD Lenovo G505S = ok ! Please share your reports for other boards, especially Unknown status

[Ivan Ivanov]

Dear friends,

as I see by this mailing list: there are enough people using AMD
Lenovo G505S notebook but nobody has submitted a report since october
2016... I just rebuilt coreboot, tested and it boots ok - here is my
new full report :

https://review.coreboot.org/cgit/board-status.git/log/lenovo/g505s

But there are a lot of boards which have been without new reports for
a long time, or even without any reports at all! (status "Unknown") :P
If you have any of such boards, please submit a report: it may be very
helpful to other people, especially coreboot beginners who are making
their first purchase decision about the coreboot hardware. Instruction
how to produce and share your reports - could be seen at the beginning
of "Supported Motherboards" page:

https://www.coreboot.org/Supported_Motherboards

For the successful execution of ./util/board_status/board_status.sh
script make sure that your utils such as cbmem and cbfstool - have
been successfully compiled. If you still have some trouble: open that
board_status.sh script, check how it works and maybe make some edits
or extract the commands to execute them separately (while keeping in
mind the environmental variables)

After you successfully submit, your report will be added to
board_status repository and should be visible at
Supported_Motherboards page, just wait until the 2nd minute of next
hour then refresh a page. And maybe there will be new coreboot users
with this board, thanks to your activities

Best regards,
Ivan Ivanov

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

Re: [coreboot] FILO 0.6.0 payload bootloader - Bug Reports!

[Ivan Ivanov]

Maybe a problem is 1TB size of my hard drive? (because FILO doesn't
work even with a small /boot partition)
FILO uses libpayload storage drivers, and surprisingly - by default,
STORAGE_64BIT_LBA option is disabled at

./coreboot/payloads/libpayload/drivers/storage/Kconfig
...
config STORAGE_64BIT_LBA
bool "Use 64-bit integers to address sectors"
depends on STORAGE
default n
help
  If this is selected, sectors will be addressed by an 64-bit integer.
  Select this to support LBA-48 for ATA drives.

LBA-48 is must have for the hard drives above 137 GB, why is it still
disabled? Looks like nobody using FILO for a long time, thats why no
SATA messages and no LBA-48 by default

Thank you very much for your workaround about cross-compiling, now I
could compile FILO on x86_64 OS. But sadly there is a big new problem,
probably related to the updated gcc-6.3.0 (even with coreboot's
gcc-6.3.0) :

While booting, FILO "freezes" while relocating: ./filo/x86/segment.c ,
void relocate(void) . After enabling debug configs and inserting some
additional print messages, could clearly see that this assembly is a
problem:

__asm__ __volatile__("rep; movsb\n\t"/* copy everything */
 "lgdt %3\n\t"
 "ljmp %4, $1f\n1:\t"
 "movw %5, %%ds\n\t"
 "movw %5, %%es\n\t"
 "movw %5, %%fs\n\t"
 "movw %5, %%gs\n\t"
 "movw %5, %%ss\n":"="(d0), "="(d1),
 "="(d2)
 :"m"(gdtarg), "n"(RELOC_CS),
 "q"((unsigned short) RELOC_DS), "0"(&_start),
 "1"(new_base), "2"(prog_size));

Initially I thought that maybe my OS version of gcc-6.3.0 compiler
compiles this assembly incorrectly. But there is the same problem even
when I try using the coreboot's "pure" GCC and other "pure" coreboot's
tools

Then I thought - maybe a problem is optimization? FILO has -Os
optimization, I replaced it with -O0 to disable (also had to remove
"inline" for three functions at ./filo/fs/mini_inflate.c . -O0
increases size from previous ~110K to about 460K, but if you use LZMA
compression while adding to coreboot - it becomes just ~120K so not
problem to use

But this does not solve a problem - it still stucks at this assembly,
while half year ago - when I compiled it on x86 OS with older
compilers it didn't stuck while booting on the same hardware. Sadly I
dont have time to find out what is the last compiler version that
worked. If everyone uses GRUB and nobody is trying to use FILO except
me, I will live without FILO as well :P

Best regards,
Ivan Ivanov







Very interesting, why it is not enabled by default, because L

2017-06-14 1:13 GMT+03:00 Nico Huber <nic...@gmx.de>:
> Hello Ivan,
>
> On 13.06.2017 23:51, Ivan Ivanov wrote:
>> Sadly "filo> kernel hda1:/vmlinuz" doesnt work as well: gives
>> Disk read error dev=1 drive=0 sector=0
>
> this sounds much like the drive wasn't detected at all, not 100% sure
> though. If you enabled the libpayload AHCI driver, it should show
> detected drives on the console (only a short moment if you enabled
> the GRUB interface). A serial log would help or if that's not pos-
> sible, you can disable the GRUB interface to see the output, IIRC.
>
>>
>> Error 15: File not found
>>
>> My current situation seems like a standard use case:
>> 1) ext2 boot partition at /dev/sda1 (or which is called "hda1" in this case),
>> size of which is 1GB and it is at DOS-partitioned MBR hard drive
>
> It could also be the size of the filesystem. IIRC, I've run into pro-
> blems with bigger partitions too, but ignored them because our OS uses
> small boot partitions. You could try the same partitioning and file
> system in QEMU.
>
>> 2) vmlinuz is at hda1:/vmlinuz , initrd is at hda1:/initrd
>>
>> But so far I am unable to even load a kernel.
>> Either I am doing something very wrong or there is a fundamental
>> problem with FILO which makes it useless outside of QEMU and maybe a
>> couple of IDE legacy systems which is really sad if indeed the
>> case :P
>>
>> By the way, when I run "probe" command it tells:
>> IDE channel 0 not found
>> IDE channel 0 not found
>> IDE channel 1 not found
>> IDE channel 1 not found
>> IDE channel 2 not found
>> IDE channel 2 not found
>> IDE channel 3 not found
>> IDE channel 3 not found
>>
>> No word about SATA, but maybe this is a correct behaviour? or not?
>
> It is expected behaviour. We've integrated the libpayload storage
> driver with little love, it just works for the file-system backend.
>
> Nico
>

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

Re: [coreboot] FILO 0.6.0 payload bootloader - Bug Reports!

[Ivan Ivanov]

Sadly "filo> kernel hda1:/vmlinuz" doesnt work as well: gives
Disk read error dev=1 drive=0 sector=0

Error 15: File not found

My current situation seems like a standard use case:
1) ext2 boot partition at /dev/sda1 (or which is called "hda1" in this case),
size of which is 1GB and it is at DOS-partitioned MBR hard drive
2) vmlinuz is at hda1:/vmlinuz , initrd is at hda1:/initrd

But so far I am unable to even load a kernel.
Either I am doing something very wrong or there is a fundamental
problem with FILO which makes it useless outside of QEMU and maybe a
couple of IDE legacy systems which is really sad if indeed the
case :P

By the way, when I run "probe" command it tells:
IDE channel 0 not found
IDE channel 0 not found
IDE channel 1 not found
IDE channel 1 not found
IDE channel 2 not found
IDE channel 2 not found
IDE channel 3 not found
IDE channel 3 not found

No word about SATA, but maybe this is a correct behaviour? or not?
Please tell me what extra info do you need, and I will try my best to
extract and provide it

Best regards,
Ivan Ivanov aka qmastery

2017-06-13 20:40 GMT+03:00 Stefan Reinauer <reina...@google.com>:
>
>
> On Tue, Jun 13, 2017 at 10:33 AM Ivan Ivanov <qmaster...@gmail.com> wrote:
>>
>> === If you have some ideas about one or more of FILO problems, please tell
>> ===
>>
>> %%% 1st problem - FILO is impossible to build on the modern x86_64
>> system (Ubuntu 16.04.2 LTS with gcc 5.4.0) :
>> ...
>>   CC  build/x86/context.o
>>   AS  build/x86/switch.S.o
>> /bin/sh: 1: --32: not found
>> Makefile:177: error while executing receipt for target
>> «/home/owner/filo/build/x86/switch.S.o»
>> make: *** [/home/owner/filo/build/x86/switch.S.o] Error 127
>>
>> No matter what crosscompiling stuff I am trying or what edits I do to
>> Makefile - it always fails with this error. However it compiles fine
>> at the 32-bit version of the same OS with the same versions of
>> packages except for a different architecture
>>
>> FILO is probably the only payload which has this problem - and this is
>> indeed a major problem, because all the major Linux distributions are
>> abandoning 32-bit soon. To fix this error, most likely the edits of
>> Makefile are needed, but sadly looks like my skills are not enough to
>> fix it (spent the whole day without a success) ...
>
>
> Look at the xcompile script. It seems to not detect your assembler
> correctly.
>
> Your xcompile output should look like this:
>
> ~/git/filo/ > sh util/xcompile/xcompile
> # x86 TARCH_SEARCH=  /git/filo/util/crossgcc/xgcc/bin/i386-elf-
> i386-elf- /git/filo/util/crossgcc/xgcc/bin/i386-eabi- i386-eabi-
> /git/filo/util/crossgcc/xgcc/bin/x86_64-elf- x86_64-elf-
> /git/filo/util/crossgcc/xgcc/bin/x86_64-eabi- x86_64-eabi-
> # elf32-i386 toolchain (i386-elf-gcc)
> CC_i386:=i386-elf-gcc  -Wno-unused-but-set-variable  -Wa,--divide
> -fno-stack-protector -Wl,--build-id=none -fuse-ld=bfd  -march=i686
> AS_i386:=i386-elf-as
> LD_i386:=i386-elf-ld.bfd
> NM_i386:=i386-elf-nm
> OBJCOPY_i386:=i386-elf-objcopy
> OBJDUMP_i386:=i386-elf-objdump
> READELF_i386:=i386-elf-readelf
> STRIP_i386:=i386-elf-strip
> AR_i386:=i386-elf-ar
>
> # arm TARCH_SEARCH=  /git/filo/util/crossgcc/xgcc/bin/armv7a-elf-
> armv7a-elf- /git/filo/util/crossgcc/xgcc/bin/armv7a-eabi- armv7a-eabi-
> Warning: no suitable GCC for arm.
> IASL:=iasl
>
> # native toolchain
> HOSTCC:=gcc
>
>
>
>>
>> %%% 2nd problem: There are only three "tested" SATA controllers in
>> FILO built-in "approved" list - and FILO does not even try to
>> initialize the not-listed controllers, despite that the attempt could
>> have been successful if tried! By default, FILO just outputs "ahci:
>> Not using untested SATA controller" message, without any option for a
>> user to try forcing its usage... The only currently available
>> workaround for this is to manually edit
>> *./coreboot/payloads/libpayload/drivers/storage/ahci.c * and  remove
>> two " #if
>> IS_ENABLED(CONFIG_LP_STORAGE_AHCI_ONLY_TESTED) ... #endif " parts,
>>
>
> Just disable CONFIG_LP_STORAGE_AHCI_ONLY_TESTED in your libpayload config.
>
>
>>
>> %%% 3rd problem: while trying to access hard drive with commands like
>> filo> kernel hda:/vmlinuz I am getting the following errors:
>>
>> Disk read error dev=1 drive=0 sector=0
>> Disk read error dev=1 drive=0 sector=2
>> Disk read error dev=1 drive=0 sector=2
>> Disk read error dev=1 drive=0 sector=128
>> Disk read error dev=1 drive=0 sector=16
>> Disk read error dev=1 drive=0 se

[coreboot] FILO 0.6.0 payload bootloader - Bug Reports!

[Ivan Ivanov]

=== If you have some ideas about one or more of FILO problems, please tell ===

%%% 1st problem - FILO is impossible to build on the modern x86_64
system (Ubuntu 16.04.2 LTS with gcc 5.4.0) :
...
  CC  build/x86/context.o
  AS  build/x86/switch.S.o
/bin/sh: 1: --32: not found
Makefile:177: error while executing receipt for target
«/home/owner/filo/build/x86/switch.S.o»
make: *** [/home/owner/filo/build/x86/switch.S.o] Error 127

No matter what crosscompiling stuff I am trying or what edits I do to
Makefile - it always fails with this error. However it compiles fine
at the 32-bit version of the same OS with the same versions of
packages except for a different architecture

FILO is probably the only payload which has this problem - and this is
indeed a major problem, because all the major Linux distributions are
abandoning 32-bit soon. To fix this error, most likely the edits of
Makefile are needed, but sadly looks like my skills are not enough to
fix it (spent the whole day without a success) ...

%%% 2nd problem: There are only three "tested" SATA controllers in
FILO built-in "approved" list - and FILO does not even try to
initialize the not-listed controllers, despite that the attempt could
have been successful if tried! By default, FILO just outputs "ahci:
Not using untested SATA controller" message, without any option for a
user to try forcing its usage... The only currently available
workaround for this is to manually edit
*./coreboot/payloads/libpayload/drivers/storage/ahci.c * and  remove
two " #if
IS_ENABLED(CONFIG_LP_STORAGE_AHCI_ONLY_TESTED) ... #endif " parts,

%%% 3rd problem: while trying to access hard drive with commands like
filo> kernel hda:/vmlinuz I am getting the following errors:

Disk read error dev=1 drive=0 sector=0
Disk read error dev=1 drive=0 sector=2
Disk read error dev=1 drive=0 sector=2
Disk read error dev=1 drive=0 sector=128
Disk read error dev=1 drive=0 sector=16
Disk read error dev=1 drive=0 sector=64
Disk read error dev=1 drive=0 sector=0
Disk read error dev=1 drive=0 sector=64
Disk read error dev=1 drive=0 sector=0
Disk read error dev=1 drive=0 sector=0
Unknown filesystem type.

Error 15: File not found.

Is there any workaround for this? Or maybe I am using the wrong
commands? If so, please tell - what are the correct FILO real-hardware
commands for trying to boot a Linux kernel thats stored on FAT16
partition at the beginning of DOS-partitioned MBR hard drive? Or this
is a problem with my hardware?

Best regards,
qmastery

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