Re: [coreboot] [LinuxBoot] FOSDEM 2019 deadline today

[Paul Kocialkowski]

Hi,

Le vendredi 02 novembre 2018 à 22:59 +0100, Carl-Daniel Hailfinger a
écrit :
> In that case, I'd also like to point you to the deadline for submitting
> main track talks which is tomorrow(!).
> https://fosdem.org/2019/news/2018-08-10-call-for-participation/
> Having a coreboot/LinuxBoot talk there would be awesome. Ron/David,
> could you submit something or do you have someone in mind who can do that?
> 
> There's also lightning talks, deadline is a bit later.

I just submitted the CFP for the hardware enablement devroom at FOSDEM.
Submissions related to coreboot and associated projects can definitely
be in the scope of the devroom, so feel free to submit talks!

Our submission deadline is December 1st, so there is still some time
ahead.

Cheers,

Paul

> OK, I'm submitting a request for a stand. I need a backup contact for
> the stand. Who is willing to do that? AFAICS we can still change the
> backup contact later if life happens.
> 
> Regards,
> Carl-Daniel
> 
> On 02.11.2018 20:48, David Hendricks wrote:
> > 
> > On Fri, Nov 2, 2018 at 9:15 AM 'Ron Minnich' via linuxboot
> > mailto:linuxb...@googlegroups.com>> wrote:
> > 
> > I"m leaning to yes, by which I mean if you do it, I'll show up.
> > 
> > I can't believe I said that.
> > On Fri, Nov 2, 2018 at 7:20 AM Carl-Daniel Hailfinger
> >  > > wrote:
> > >
> > > Hi!
> > >
> > > FOSDEM next year will be on 2 & 3 February 2019.
> > > The deadline for applying for a stand is today.
> > > Do we want a coreboot/flashrom/LinuxBoot stand/booth?
> > 
> > 
> > Same as what Ron said. I think someone from FB can be there to talk
> > about coreboot/LinuxBoot stuff and perhaps bring some hardware to demo.
> > 
> > 
> 
> 


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] FOSDEM 2019 Hardware Enablement Devroom Call for Participation

[Paul Kocialkowski]

Hi,

The Hardware Enablement devroom is back for a second year at FOSDEM!
It will take place on Sunday 3 February 2019.

# Call for Participation

We are opening the call for participation to our devroom, with the
deadline for talk proposals set to Saturday 1 December 2018.

# Devroom Scope

This devroom covers topics related to hardware support and enablement
with free software. It includes the following topics:
* peripheral/controller firmwares
* boot software
* kernel drivers and hardware interfaces
* hardware-related adaptation in operating systems
* tools for firmware flashing
* tools for low-level development

Despite this large scope, the focus of the devroom is set on
highlighting the technical aspects of the hardware and its enablement
in free projects, rather than the specific applications and use cases
that benefit from it. We also want to avoid purely commercial vague
talks with marketing content, which leave little place to technical
aspects.

This year, we are looking to particularly highlighting free software
outside of the operating system boundaries, especially with boot
software as well as controller and peripheral firmwares.

# Talk Format

Since no Embedded devroom is taking place this year (and our devroom
also covers embedded devices), we are expecting a significant number of
submissions.

In order to cover as much ground as we can, a new talk will be
scheduled every half-hour, so accepted talks will follow this format:

 20 minutes for the talk
+ 5 minutes for questions
+ 5 minutes for speaker setup

We ask speakers to be present in the room before their talk so that
speaker setup can go smoothly.

# Submission

Talks that fit in our devroom's scope can be submitted to the FOSDEM
Pentabarf interface at https://penta.fosdem.org/submission/FOSDEM19

We encourage reusing accounts from previous years instead of creating
new ones:
* lost password: https://penta.fosdem.org/user/forgot_password
* new Account: https://penta.fosdem.org/user/new_account/FOSDEM19

Here are a few guidelines when submitting a talk:
* select the Hardware Enablement devroom as track
* include an abstract for every submission and optionally a full
  description
* make sure your contact details are up to date

# Video

Talks will be streamed live during the event and recorded. They will be
available under a Creative Commons Attribution (BY) license later.

# Contact

For more information or questions about the devroom and this CFP, feel
free to email hardware-devroom-manager at fosdem.org

We're looking forward to lots of interesting proposals and hoping to
see you all in Brussels at the event!

Cheers,

Paul for the Hardware Enablement devroom


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Paul Kocialkowski]

Hi,

Le vendredi 16 février 2018 à 14:09 -0500, Youness Alaoui a écrit :
> > > Sure, you can trust hardware flashing more than software flashing,
> > > but
> > > I really need software flashing. If it was just for me, yeah, I
> > > could
> > > fiddle with it to flash it by hardware for my personal needs, but
> > > when
> > > it's about deploying it to all our customer base, that's another
> > > story, the only solution is software flashing. Obviously, it would
> > > have to work in coreboot, so whatever coreboot is doing wrong (or
> > > AMI
> > > is doing right.. my guess is that it's probably something with the
> > > EC
> > > ACPI code), we'd have to figure that out first in order to get the
> > > read/write support.
> > 
> > Either way, since the EC firmware resides in the SPI flash, it'll be
> > no
> > issue to reflash it both by software and hardware.
> 
> On the librems, the EC firmware resides in a separate 64KB SPI flash,
> it's not shared with the bios, and I haven't found a way to access it.

Is it really only 64 KiB? The chip definitely supports more and it seems
a bit small to fit the whole firmware.

> The 'ectool' is able to read it (ram idx reads if i remember
> correctly) but it only worked with AMI BIOS. So there will definitely
> be some work to be done there. You probably know a lot more about this
> already, like what this 'ram idx' is, and why it didn't work in
> coreboot, or if it's possible to read/write the flash using this EDI
> interface, etc...
> 
> > 
> > > > Latest status update for Origami-EC firmware:
> > > > https://www.mail-archive.com/coreboot@coreboot.org/msg50646.html
> > > 
> > > Thanks! Good to see the status update on that.
> > 
> > In order to kickstart the development of the Origami-EC firmware, I
> > am
> > designing evaluation boards for both the KB9012 and the KB3930 that
> > will expose most of the I/O ports with headers, LEDs, buttons,
> > connectors, etc. The design is done with KiCAD and will be released
> > under the GPLv3+ as part of the Origami-EC project. I am also
> > preparing
> > a debug board to reflash the EC on the G505s from the keyboard
> > connector.
> > 
> > There is also ongoing work on the emulator and the SerialICE-like
> > library for relatying and tracing I/O on the device via UART. Also,
> > note that the emulator can now emulate a virtual console so it's
> > already possible to build and interract with the firmware!
> > 
> 
> That's some really great news. A dev board will definitely be useful
> for testing/debugging/developing Origami-EC!
> 
> > Cheers,
> > 
> > Paul
> > 
> > > > On Mon, Feb 5, 2018 at 9:47 PM, Youness Alaoui
> > > > <kakar...@kakaroto.homelinux.net> wrote:
> > > > > Hi Marty,
> > > > > 
> > > > > Unfortunately, the EC firmware on the Librems is not open and
> > > > > we
> > > > > have
> > > > > someone working on that aspect, but with everything we have to
> > > > > handle,
> > > > > I think it's only being done part time.
> > > > > We found something similar to you with the private submodule
> > > > > for
> > > > > the
> > > > > PS/2 module on the OLPC code.
> > > > > More specifically :
> > > > > http://lists.laptop.org/pipermail/openec/2011-January/000158.h
> > > > > tml
> > > > > And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=393
> > > > > 0-A
> > > > > 1
> > > > > 
> > > > > I had opened a ticket a while ago here :
> > > > > https://tracker.pureos.net/T178 which mentions Origami-EC. I
> > > > > don't
> > > > > know the status of that project, maybe you can contact the
> > > > > developer
> > > > > (Paul Kocialkowski) and see where he's at with his development
> > > > > of
> > > > > that
> > > > > project (which, I need to mention, hasn't been publicly
> > > > > launched
> > > > > yet,
> > > > > as far as I know) and he might benefit from your help if you
> > > > > are
> > > > > interested in doing that.
> > > > > The last time we spoke he said :
> > > > > "The OLPC code is nowhere close to usable on any other
> > > > > platform.
> > > > > Additionally, it is 

Re: [coreboot] ENE KB3940Q-A1 embedded controller custom firmware

[Paul Kocialkowski]

roto.homelinux.net> wrote:
> > > Hi Marty,
> > > 
> > > Unfortunately, the EC firmware on the Librems is not open and we
> > > have
> > > someone working on that aspect, but with everything we have to
> > > handle,
> > > I think it's only being done part time.
> > > We found something similar to you with the private submodule for
> > > the
> > > PS/2 module on the OLPC code.
> > > More specifically :
> > > http://lists.laptop.org/pipermail/openec/2011-January/000158.html
> > > And http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A
> > > 1
> > > 
> > > I had opened a ticket a while ago here :
> > > https://tracker.pureos.net/T178 which mentions Origami-EC. I
> > > don't
> > > know the status of that project, maybe you can contact the
> > > developer
> > > (Paul Kocialkowski) and see where he's at with his development of
> > > that
> > > project (which, I need to mention, hasn't been publicly launched
> > > yet,
> > > as far as I know) and he might benefit from your help if you are
> > > interested in doing that.
> > > The last time we spoke he said :
> > > "The OLPC code is nowhere close to usable on any other platform.
> > > Additionally, it is so poorly written that I don't think it is a
> > > suitable codebase for any future development. On the other hand,
> > > my
> > > Origami-EC project (that I will publicly launch soon) should
> > > provide a
> > > flexible codebase to add support for new devices."
> > > 
> > > Note that the tracker ticket above is quite outdated, we know how
> > > to
> > > dump the EC (the problem was that it can't be done via hardware
> > > because the EC is on the same power rail as the 64KB flash chip,
> > > so
> > > when we power the flash via hardware, the EC boots and takes
> > > control
> > > of the SPI lines) but for some reason, we could only dump it via
> > > software (using ectool) through the AMI BIOS firmware, with
> > > coreboot,
> > > we only get 0xFF returned, I don't believe we had time to
> > > investigate
> > > the cause for that.
> > > 
> > > Sorry for not having any better news for you, but I hope this
> > > helps a
> > > little you at least.
> > > 
> > > Good luck,
> > > Youness.
> > > 
> > > 
> > > On Fri, Feb 2, 2018 at 10:17 AM, Marty E. Plummer
> > > <hanet...@startmail.com> wrote:
> > > > Greetings,
> > > > 
> > > > Currently working on a port for the hp g7-2247us laptop, which
> > > > features
> > > > an ene kb3940q ec, which hopefully should be very similar to
> > > > the kb3930
> > > > ec, which has a datasheet available to the public in a few
> > > > places.
> > > > 
> > > > Said similar ec is used in some OLPC devices, as well as some
> > > > purism
> > > > devices, and I was hoping someone in the list would have some
> > > > contacts
> > > > with those guys so as to be able to use their ec firmware as a
> > > > bit of a
> > > > reference design, but the OLPC ec firmware repo has a 'private'
> > > > submodule which I cannot access and I simply cannot find a repo
> > > > for the
> > > > purism ec firmware to reference.
> > > > 
> > > > Any assistance you could provide on this matter would be
> > > > greatly
> > > > appreciated.
> > > > 
> > > > Marty E. Plummer
> > > > 
> > > > --
> > > > 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
-- 
Paul Kocialkowski, developer of free digital technology and hardware
support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Paul Kocialkowski]

Hi,

Le mercredi 03 janvier 2018 à 15:34 +0300, Ivan Ivanov a écrit :
> 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 ?

We have been discussing about the future of these patches and they
cannot be accepted as-is today. Mostly, Nico was worried that issuing
SPI commands for the EDI protocol might cause some chips to misbehave if
these commands have another signification. I think this is a valid
concern.

We agreed that one way to solve this would be to create groups for
probing, e.g. one with jedec-compliant chips (default) and one for ene
chips, so that only one group is probbed at the same time.

I did not have the time to implement this idea yet, so it will block
kb9012 inclusion for now. If you'd like to go ahead and implement this
feature, I'd be happy to review your patches!

Cheers,

Paul

> 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
-- 
Paul Kocialkowski, developer of free digital technology and hardware
support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Embedded Controller (EC)

[Paul Kocialkowski]

Le samedi 09 décembre 2017 à 14:21 -0500, taii...@gmx.com a écrit :
> On 12/09/2017 09:22 AM, Paul Kocialkowski wrote:
> 
> > The project is still in an early development stage and is not
> > functional
> > as-is. Some I/O features are currently supported on the G505s and
> > can be
> > used thought the command line via UART.
> > 
> > I will be launching dedicated ressources for this project at some
> > point
> > in the (hopefully) near future. In the meantime, contributions are
> > welcome!
> 
> Cool! I wish you luck on this project - an open source EC would be 
> really great for the G505S as it is one of the last best owner 
> controlled non-ME/PSP x86-64 laptops, it also has an IOMMU!

Ideally, having the G505s supported by native code in coreboot (without
using AGESA) and a free EC would be really awesome!

There is definitely potential in this laptop to get a modern x86 well-
supported by free boot software!

> I am however getting a "400 - Invalid action parameter" when
> attempting to visit the project page.

The source code is hosted at:
http://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary

which should work most of the time.

Cheers,

-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Embedded Controller (EC)

[Paul Kocialkowski]

Hi,

Le vendredi 01 décembre 2017 à 16:07 +0300, Аладышев Константин a
écrit :
> 2) How stable and flexible are projects about open EC firmware? Is it
> possible to adapt these projects for my custom motherboard?
> 
> I'm talking about:
> - Chromium Embedded Controller:
> http://www.chromium.org/chromium-os/ec-development
> - Origami-EC: https://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=sum
> mary

I gave a presentation about the current status of the Origami-EC project
at ECC in Bochum this year! You can find the slides at:
https://ecc2017.coreboot.org/uploads/talk/presentation/51/origami-ec-status-update-g505s.pdf

The project is still in an early development stage and is not functional
as-is. Some I/O features are currently supported on the G505s and can be
used thought the command line via UART.

I will be launching dedicated ressources for this project at some point
in the (hopefully) near future. In the meantime, contributions are
welcome!

Cheers,

-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Re : FOSDEM Hardware Enablement Devroom

[Paul Kocialkowski]

Hi,

Le lundi 13 novembre 2017 à 11:57 +0100, Paul Kocialkowski a écrit :
> A Hardware Enablement devroom will be taking place at FOSDEM this
> year, on Sunday 10 December 2017. This newly-created devroom is the
> result of 3 proposals that were merged together. It is co-organized by
> several individuals.

As it was pointed out on the Replicant mailing list, the devroom is
actually taking place on the Sunday  4 February 2018, not on december
2018.

> The devroom covers all aspects related to hardware enablement and
> support with free software, including aspects related to boot
> software,
> firmwares, drivers and userspace tools and adaptation.
> 
> Proposals for talks related to these topics are welcome and can be
> submitted until Sunday 26 November 2017 via the pentabarf interface.
> Short talks are encouraged over longer ones in order to cover a wide
> range of topics.
> 
> The announcement for the devroom, that contains all the useful
> information, was published at:
> https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html
> 
> Cheers and see you at FOSDEM!

Cheers,

-- 
Paul Kocialkowski, developer of free digital technology and hardware
support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] FOSDEM Hardware Enablement Devroom

[Paul Kocialkowski]

A Hardware Enablement devroom will be taking place at FOSDEM this year,
on Sunday 10 December 2017. This newly-created devroom is the result of
3 proposals that were merged together. It is co-organized by several
individuals.

The devroom covers all aspects related to hardware enablement and
support with free software, including aspects related to boot software,
firmwares, drivers and userspace tools and adaptation.

Proposals for talks related to these topics are welcome and can be
submitted until Sunday 26 November 2017 via the pentabarf interface.
Short talks are encouraged over longer ones in order to cover a wide
range of topics.

The announcement for the devroom, that contains all the useful
information, was published at:
https://lists.fosdem.org/pipermail/fosdem/2017-October/002649.html

Cheers and see you at FOSDEM!

-- 
Paul Kocialkowski, developer of free digital technology and hardware
support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to work with Chrome EC? (was: Successful build with GCC 7.2 and IASL 20170831 for coreboot 4.7)

[Paul Kocialkowski]

Hi,

Le lundi 02 octobre 2017 à 13:47 -0700, Vadim Bendebury a écrit :
> the entry threshold is a big high, but I am sure the Chome OS EC team would
> appreciate your contributions.

Actually, I have been contributing to various Chromium OS project over the years
and never had to setup the whole cros environment.

Not only is it possible to build the software outside of the cros build system
(e.g. such as it's done in the coreboot build system directly or through my
build system[0]), but it's also possible to send patches for review without it.

The Chromium Review Gerrit[1] works pretty much like the coreboot one, except
that it may use https and a cookie rather than ssh and a pubkey for pushing. So
once the account is setup on Gerrit (requires a Google account AFAIK), you can
simply push to projects like that:

git push https://chromium-review.googlesource.com/chromiumos/platform/ec 
master:refs/for/master

And that usually works well for me. Just keep in mind that you need to include
custom tags, such as Change-Id, TEST= and BUG= in the commit message.

Cheers,

Paul

[0]: https://git.code.paulk.fr/gitweb/?p=libettereboot.git;a=summary
[1]: https://chromium-review.googlesource.com/

> On Mon, Oct 2, 2017 at 12:04 AM, Paul Menzel <paulepan...@users.sourceforge.ne
> t> wrote:
> > Dear coreboot folks,
> > 
> > 
> > GCC 7.2 found several issues in the Chromium EC code base, like #770209
> > [4], and I prepared  patches, but unfortunately, I do not know how to
> > push them for review.
> > 
> > 1. The instructions don’t work for me [5]. I can’t find the manifest
> > file, which seems to be required by the utility `repo`.
> > 
> > 2. Also, in the preferences menu of the Google Chromium review system,
> > I cannot find a way to upload my SSH key.
> > 
> > 3. Is there a mailing list for the Chromium Embedded Controller
> > development?
> > 
> > 
> > Thanks,
> > 
> > Paul
> > 
> > 
> > [4] https://bugs.chromium.org/p/chromium/issues/detail?id=770209
> > [5] https://dev.chromium.org/chromium-os/ec-development
> > [6] https://chromium-review.googlesource.com/admin/projects/chromiumos/platf
> > orm/ec,access
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > https://mail.coreboot.org/mailman/listinfo/coreboot
> 
> 
-- 
Paul Kocialkowski, developer of free digital technology and hardware support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Unable to build futility on 32-bit userspace

[Paul Kocialkowski]

Hi,

Le jeudi 31 août 2017 à 16:32 -0700, Julius Werner a écrit :
> FWIW, there should be no reason to build crossystem as part of
> coreboot's compile-time utilities at all. crossystem is a helper meant
> to run on the target device (the one that uses vboot-enabled
> firmware), it doesn't make any sense to have it on the build machine.
> We should fix the Makefiles so that they don't even pull this in, so
> that coreboot can also be built on architectures that crossystem
> doesn't support at all (e.g. SPARC or whatever). futility itself just
> does some crypto stuff and should have no architecture-specific
> components.

I totally agree with this, so I've submitted a patch to vboot in that
direction. It fixes the Makefile to make futility independent from the
crossystem parts:

https://chromium-review.googlesource.com/c/chromiumos/platform/vboot_reference/+/25

Happy code review!

-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Unable to build futility on 32-bit userspace

[Paul Kocialkowski]

Hi again,

Le jeudi 31 août 2017 à 09:30 +0300, Paul Kocialkowski a écrit :
> Le jeudi 31 août 2017 à 08:13 +0200, Paul Menzel a écrit :
> > I haven’t tested this yet with a 64-bit userspace, but assume that
> > works. Does somebody have a fix?
> 
> Yeah sure, I'll craft one and submit it to upstream vboot soon.

It's up at: https://chromium-review.googlesource.com/#/c/645086/

Googlers, feel free to review :)

Cheers,

-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Unable to build futility on 32-bit userspace

[Paul Kocialkowski]

Hi,

Le jeudi 31 août 2017 à 08:13 +0200, Paul Menzel a écrit :
> Dear coreboot folks,
> 
> 
> Trying to run `make test-abuild` on my system with a 32-bit userspace,
> it looks like quite some boards require the program futility from
> `util/futility`, but that fails to build with the error below.
> 
> ```
> /dev/shm/coreboot/util/futility(master) $ git describe
> 4.6-1292-g5bf3457bc4
> /dev/shm/coreboot/util/futility(master) $ LANG= make
> MAKE   futility/build/futility/futility
> unset CFLAGS LDFLAGS; make -C /dev/shm/coreboot/3rdparty/vboot \
>   BUILD=/dev/shm/coreboot/util/futility/build \
>   CC="cc" \
>   V= \
>   /dev/shm/coreboot/util/futility/build/futility/futility
> make[1]: Entering directory '/dev/shm/coreboot/3rdparty/vboot'
> CCfutility/futility.o
> CCfutility/cmd_dump_fmap.o
> CCfutility/cmd_gbb_utility.o
> CCfutility/misc.o
> CCfutility/ryu_root_header.o
> CCfutility/cmd_bdb.o
> CCfutility/cmd_create.o
> CCfutility/cmd_dump_kernel_config.o
> CCfutility/cmd_load_fmap.o
> CCfutility/cmd_pcr.o
> CCfutility/cmd_show.o
> CCfutility/cmd_sign.o
> CCfutility/cmd_validate_rec_mrc.o
> CCfutility/cmd_vbutil_firmware.o
> CCfutility/cmd_vbutil_kernel.o
> CCfutility/cmd_vbutil_key.o
> CCfutility/cmd_vbutil_keyblock.o
> CCfutility/file_type.o
> CCfutility/file_type_bios.o
> CCfutility/file_type_rwsig.o
> CCfutility/file_type_usbpd1.o
> CCfutility/vb1_helper.o
> CCfutility/vb2_helper.o
> CCfutility/bdb_helper.o
> GEN   gen/futility_cmds.c
> CCgen/futility_cmds.o
> CCcgpt/cgpt_create.o
> CCcgpt/cgpt_add.o
> CCcgpt/cgpt_boot.o
> CCcgpt/cgpt_show.o
> CCcgpt/cgpt_repair.o
> CCcgpt/cgpt_prioritize.o
> CCcgpt/cgpt_common.o
> CCfutility/dump_kernel_config_lib.o
> make[1]: *** No rule to make target
> '/dev/shm/coreboot/util/futility/build/host/arch/i686/lib/crossystem_a
> rch.o', needed by
> '/dev/shm/coreboot/util/futility/build/libvboot_util.a'.  Stop.
> make[1]: Leaving directory '/dev/shm/coreboot/3rdparty/vboot'
> Makefile.inc:4: recipe for target
> '/dev/shm/coreboot/util/futility/build/futility/futility' failed
> make: *** [/dev/shm/coreboot/util/futility/build/futility/futility]
> Error 2
> ```
> 
> I haven’t tested this yet with a 64-bit userspace, but assume that
> works. Does somebody have a fix?

Yeah sure, I'll craft one and submit it to upstream vboot soon.

-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Hi-DPI displays and showing text information for kevin in depthcharge

[Paul Kocialkowski]

Le dimanche 23 juillet 2017 à 16:21 +0300, Paul Kocialkowski a écrit :
> Le lundi 17 juillet 2017 à 22:11 +0200, Patrick Georgi via coreboot a
> écrit :
> > I wouldn't scale at compile time (as said, storage constrained
> > payloads might not be happy about that).
> > 
> > I wouldn't scale each character up on each access though (we won't
> > hardware accelerate the scaling, and yes, that does get slow -
> > framebuffers aren't always the fastest type of memory and that way
> > the
> > access pattern is the same set of memcpy()s as for any other huge
> > font, so we won't need to deal with "fast fonts" and "slow fonts"
> > beyond basic geometry characteristics), but synthesize a new font in
> > the regular font table at init-time and then use it like any pre-
> > existing font (just that it happened to be added after load).
> 
> As it turns out, no scaling in memory is required, either at build
> time
> or run time. This is thanks to the fact that the font is coded with
> each
> bit representing a filled or blank pixel, so the font has to be
> accessed
> bit-by-bit to draw it. I simply modified the access logic to use a
> scale
> factor and I don't think it will impact performance much (that's still
> two extra divisions for each pixel though).
> 
> The changes are up for review at:
> https://review.coreboot.org/#/c/20708/
> https://review.coreboot.org/#/c/20709/
> https://review.coreboot.org/#/c/20710/
> 
> Thanks everyone for the feedback and happy review!

I forgot to mention: I tested this on kevin (with and without scaling)
and the result looks great!

> > 2017-07-17 21:47 GMT+02:00 Julius Werner <jwer...@chromium.org>:
> > > I agree with most of what Patrick said, I think dynamic scaling to
> > > integer multiples may be best. Scaling the font up at compile-time
> > > seems like unnecessary bloat to the binary (although I'm not sure,
> > > how big are these fonts?). If you do want to include them at
> > > compile
> > > time, you may as well include a real larger font rather than just
> > > a
> > > scaled one.
-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Hi-DPI displays and showing text information for kevin in depthcharge

[Paul Kocialkowski]

Le lundi 17 juillet 2017 à 22:11 +0200, Patrick Georgi via coreboot a
écrit :
> I wouldn't scale at compile time (as said, storage constrained
> payloads might not be happy about that).
> 
> I wouldn't scale each character up on each access though (we won't
> hardware accelerate the scaling, and yes, that does get slow -
> framebuffers aren't always the fastest type of memory and that way the
> access pattern is the same set of memcpy()s as for any other huge
> font, so we won't need to deal with "fast fonts" and "slow fonts"
> beyond basic geometry characteristics), but synthesize a new font in
> the regular font table at init-time and then use it like any pre-
> existing font (just that it happened to be added after load).

As it turns out, no scaling in memory is required, either at build time
or run time. This is thanks to the fact that the font is coded with each
bit representing a filled or blank pixel, so the font has to be accessed
bit-by-bit to draw it. I simply modified the access logic to use a scale
factor and I don't think it will impact performance much (that's still
two extra divisions for each pixel though).

The changes are up for review at:
https://review.coreboot.org/#/c/20708/
https://review.coreboot.org/#/c/20709/
https://review.coreboot.org/#/c/20710/

Thanks everyone for the feedback and happy review!

> 2017-07-17 21:47 GMT+02:00 Julius Werner <jwer...@chromium.org>:
> > I agree with most of what Patrick said, I think dynamic scaling to
> > integer multiples may be best. Scaling the font up at compile-time
> > seems like unnecessary bloat to the binary (although I'm not sure,
> > how big are these fonts?). If you do want to include them at compile
> > time, you may as well include a real larger font rather than just a
> > scaled one.
-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] for Lenovo G505S owners: AtomBIOS ROMs (discrete too!), binaries, datasheets...

[Paul Kocialkowski]

Le dimanche 16 juillet 2017 à 15:31 +0300, Mike Banon a écrit :
> Replacing #!/bin/sh with #!/bin/bash also works! Although maybe its a
> good idea to still do this hex-to-dec numbers conversion if it results
> in more portable code

I think it works just fine with bash. As long as the tool is targeted at
bash and not POSIX shell, portability shouldn't be an issue.

> > Also if you attach the UART to it, you will get a functional console
> > 
> 
> Could you please tell which USB-to-UART adapter you are using while
> connecting to JP3 port ? And what is your connectivity diagram: are
> you connecting just 2 and 3 wires (EC_TX and EC_RX) or 1 and 4 also (
> +3VALW and GND ) ?

Any 3.3V USB-UART bridge should do. I think I'm using a pl2303 at the
moment, but I'm sure any other will work as well.

What you need to connect is only EC_TX <-> RX, EC_RX <-> TX and GND <->
GND. Do not connect the 3.3V rails together!

> I'm going to get 10 pcs of 4P FPC connectors (such as these for $1 -
> https://www.aliexpress.com/item/Cloukeu-10Pcs-FPC-Connector-socket-FFC
> -1-0MM-Drawer-Bottom-Contact-type-4-5-6-7/32814560472.html
> ) to solder one of them to JP3 UART port - just in case I couldn't get
> UART from a port of MiniPCI-E diagnostic card
> 
> Will cut a spare FPC 30P 1.0mm pitch keyboard-like flex cable to get a
> 4P one. This connection will allow to easily attach/detach the UART
> without soldering/desoldering it each time ; meanwhile I'll have to
> use something like a Morse code for these leds :)

Yeah that's a good way to go. I've just soldered dupont cables to my
device because I only use it as a dev unit.

What I want to implement next in Origami-EC is charger and battery
support, but I didn't have enough free time to dive into the
implementation of it.

Cheers,

Paul

> On Sun, Jul 16, 2017 at 11:26 AM, Paul Kocialkowski <cont...@paulk.fr>
> wrote:
> > Le dimanche 16 juillet 2017 à 11:10 +0300, Mike Banon a écrit :
> > > Hi Paul, here is my proposed fix for ./origami-ec/tools/segments
> > > to
> > > make it more portable across the different bash versions :
> > 
> > I think the problem is that you are not using bash in this case. The
> > script has /bin/sh as shebang, but it's really written in bash (with
> > non-POSIX extensions). Given the number of non-POSIX things that I'm
> > using in there, it's probably easier to just switch:
> > #!/bin/sh
> > to
> > #!/bin/bash
> > 
> > Could you try that and report back?
> > 
> > > 1) replace
> > > 
> > > if (( $size > $size_limit ))
> > > 
> > > with
> > > 
> > > if [ $(printf "%d" ${size}) -gt $(printf "%d" ${size_limit}) ]
> > > 
> > > 2) replace
> > > 
> > > if (( $offset < $map ))
> > > 
> > > with
> > > 
> > > if [ $(printf "%d" ${offset}) -lt $(printf "%d" ${map}) ]
> > > 
> > > After these changes the hexadecimal numbers are converted to
> > > decimal
> > > before the comparison. Now this script works OK and the whole
> > > build
> > > completes without any error
> > > 
> > > I have tested your firmware at my G505S, the LEDs are working ;-)
> > > and
> > > are changing their state if I press a button.
> > 
> > Cool! You may also want to close and open the lid ;)
> > 
> > Also if you attach the UART to it, you will get a functional
> > console.
> > 
> > > Maybe its a good idea to launch this project publicly by creating
> > > a
> > > mirror at GitHub, so that the people could easily commit the pull
> > > requests and send their comments - and then the merged pull
> > > requests
> > > could be synchronized with your home repository at
> > > git.code.paulk.fr ?
> > > What do you think about this idea?
> > 
> > I already have very specific plans about launching the project
> > publicly
> > (that do not involve using github). I am working hard on that. In
> > order
> > to drag some interest in the project at the time it is launched, I
> > would
> > ask that you don't spread big news about it yet. I'd really like to
> > keep
> > it semi-public for now.
> > 
> > Also I strongly prefer to do code review via dedicated mailing
> > lists,
> > with text patches instead of web interfaces (that really do not fit
> > well
> > with my workflow).
> > 
> > Thanks for your suggestions and interest in the project!
> > 
> > Cheers,
> > 
> > Paul
> > 
> > > On Sat, J

Re: [coreboot] (depthcharge, vboot) Difficulties booting on Chromebook

[Paul Kocialkowski]

On Tue, 2017-07-18 at 08:49 +0100, Linus Heckemann wrote:
> Hi Paul, thanks for your reply.
> 
> On 18/07/17 08:28, Paul Kocialkowski wrote:
> > Hi,
> > 
> > On Tue, 2017-07-18 at 07:24 +0100, Linus Heckemann wrote:
> > > I've been following the instructions for getting Debian running on
> > > an
> > > Asus C201 Chromebook[1]. This has been going well, mostly, except
> > > that
> > > when I try to actually boot it (power on and press Ctrl-U) I am
> > > greeted
> > > by a loud and low-pitched beep and not much else. Any ideas as to
> > > what
> > > I
> > > may be missing?
> > 
> > That probably means that your boot medium was not setup correctly.
> > Perhaps the Debian instructions are either incorrect or incomplete.
> 
> Do you know of any "known-to-work" instructions for setting up a
> non-chrome OS boot medium that I could compare my setup to or try
> using
> instead? Or a way to get more helpful information than a beep from
> depthcharge?

I have a cros-medium-setup script that does that:
https://git.code.paulk.fr/gitweb/?p=libettereboot.git;a=blob;f=projects/cros-scripts/install/cros-medium-setup;h=1865ae36de14aafc610a5e8a81e45e8fed0ee343;hb=HEAD

You could try to run the paritions action and then cat a known good
kernel image to the first partition. Alternatively, you can use my whole
build system:
http://git.code.paulk.fr/gitweb/?p=libettereboot.git;a=summary
to build a cros kernel and install it to the storage:
./libreboot download linux-cros
./libreboot cook linux-cros veyron
./libreboot cook cros-scripts
cd install/cros-scripts/
./cros-kernel-prepare pack ../linux-cros-veyron usb
./cros-medium-setup partitions /dev/sdfoo
./cros-medium-setup kernel /dev/sdfoo ../linux-cros-veyron usb

That will however take a while to complete. I'm not providing binary
releases at this point (or any official documentation, really).

Maybe reading these scripts can help you figure out what is going wrong
with your setup.

> > > Relevant stuff:
> > > 
> > > # crossystem | grep dev_boot
> > > dev_boot_usb   = 1   # Enable developer mode boot from
> > > USB/SD
> > > (writable)
> > > dev_boot_legacy= 0   # Enable developer mode boot Legacy
> > > OSes
> > > (writable)
> > > dev_boot_signed_only   = 0   # Enable developer mode boot only
> > > from
> > > official kernels (writable)
> > > 
> > > I've uploaded an image of the SD card resulting from the
> > > instructions
> > > (208M, 2G uncompressed) at [2].
> > > 
> > > Best regards
> > > Linus
> > > 
> > > 
> > > [1]: https://wiki.debian.org/InstallingDebianOn/Asus/C201
> > > [2]: https://sphalerite.org/chromebook-debian-boot-sd.img.gz
> 
> 
-- 
Paul Kocialkowski,

developer of free digital technology and hardware support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

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

Re: [coreboot] (depthcharge, vboot) Difficulties booting on Chromebook

[Paul Kocialkowski]

Hi,

On Tue, 2017-07-18 at 07:24 +0100, Linus Heckemann wrote:
> I've been following the instructions for getting Debian running on an
> Asus C201 Chromebook[1]. This has been going well, mostly, except that
> when I try to actually boot it (power on and press Ctrl-U) I am
> greeted
> by a loud and low-pitched beep and not much else. Any ideas as to what
> I
> may be missing?

That probably means that your boot medium was not setup correctly.
Perhaps the Debian instructions are either incorrect or incomplete.

> Relevant stuff:
> 
> # crossystem | grep dev_boot
> dev_boot_usb   = 1   # Enable developer mode boot from USB/SD
> (writable)
> dev_boot_legacy= 0   # Enable developer mode boot Legacy OSes
> (writable)
> dev_boot_signed_only   = 0   # Enable developer mode boot only from
> official kernels (writable)
> 
> I've uploaded an image of the SD card resulting from the instructions
> (208M, 2G uncompressed) at [2].
> 
> Best regards
> Linus
> 
> 
> [1]: https://wiki.debian.org/InstallingDebianOn/Asus/C201
> [2]: https://sphalerite.org/chromebook-debian-boot-sd.img.gz

-- 
Paul Kocialkowski,

developer of free digital technology and hardware support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

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

Re: [coreboot] Hi-DPI displays and showing text information for kevin in depthcharge

[Paul Kocialkowski]

Le lundi 17 juillet 2017 à 10:55 +0200, Patrick Georgi a écrit :
> 2017-07-16 11:32 GMT+02:00 Paul Kocialkowski <cont...@paulk.fr>:
> > So I am wondering what the best way to solve this would be. I see a
> > few
> > options:
> > * Having larger fonts for hi-dpi displays
> 
> I'd go with that. Plus, maybe, a function to select the right font
> given a few constraints (display resolution, desired terminal grid
> size)
> 
> There are a bunch of font options with higher resolutions in the Linux
> sources (lib/fonts) that could be lifted into libpayload.

Sounds reasonable enough!

> > * Scaling the font to reach a particular DPI (e.g. based on the
> > physical
> > screen size reported from the EDID)
> 
> This could be a reasonable fallback (eg in case payloads are storage
> constrained and can't ship x fonts, or if even the largest font is
> intolerably small).
> Going for integer multiples (and statically generating the fonts in
> the internal format, registering it just like any shipped font) should
> be good enough.
> No need for any fancy scaling algo either, just duplicate the pixels
> in all directions.

Yeah, that would totally do.

> > * Reducing the resolution, by optionally providing a preferred one
> > from
> > the config
> 
> Besides the potential dependency on resolution in later stages that
> you mentioned, the panel may or may not work well with a lower
> resolution, or might just show the same tiny pixels - just fewer of
> them with a nice, shiny, black border.

Hehe, that is a very good point. This approach is too device-dependent
anyways.

I'll wait for more feedback before starting the work on this (I have a
lot on my plate anyway so this probably won't be a priority for some
time).

If anyone else feels like starting an implementation, I'd be overly
grateful though!

Cheers,

-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

[coreboot] Hi-DPI displays and showing text information for kevin in depthcharge

[Paul Kocialkowski]

I am using upstream coreboot with top-of-tree depthcharge and vboot on
kevin (Chromebook Plus from Samsung) and I've patched depthcharge[0] to
display text messages instead of looking up bitmaps in the GBB/cbfs.

I noticed that corebootfb is using[1] a fixed 8x16 font for showing text
there. In addition, the RK3399 eDP code will always go with the
"recommended resolution" from the EDID, which is the highest one.

The result of this is that the displayed text looks really small on-
screen, which does not really provide a great user experience.

So I am wondering what the best way to solve this would be. I see a few
options:
* Having larger fonts for hi-dpi displays
* Scaling the font to reach a particular DPI (e.g. based on the physical
screen size reported from the EDID)
* Reducing the resolution, by optionally providing a preferred one from
the config

Among these, which ones do you think is the way to go? I think the
question is also whether we want a generic way to handle this or to do
it per-device (and also keep in mind that not every device has EDID
available, but may have a single hardcoded resolution, which could still
superseded by the suggested config option).

I like the idea of reducing the resolution. It may however also break
compatibility with e.g. ChromeOS that expects the framebuffer to be set
at the max resolution by coreboot.

[0]: 
http://git.code.paulk.fr/gitweb/?p=libettereboot.git;a=tree;f=projects/depthcharge/patches;h=dd17766e4b5217456f1d8ae20619a08bd34e9be4;hb=HEAD
[1]: 
https://review.coreboot.org/cgit/coreboot.git/tree/payloads/libpayload/drivers/video/corebootfb.c#n124

Cheers,

-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] for Lenovo G505S owners: AtomBIOS ROMs (discrete too!), binaries, datasheets...

[Paul Kocialkowski]

Le dimanche 16 juillet 2017 à 11:10 +0300, Mike Banon a écrit :
> Hi Paul, here is my proposed fix for ./origami-ec/tools/segments to
> make it more portable across the different bash versions :

I think the problem is that you are not using bash in this case. The
script has /bin/sh as shebang, but it's really written in bash (with
non-POSIX extensions). Given the number of non-POSIX things that I'm
using in there, it's probably easier to just switch:
#!/bin/sh
to
#!/bin/bash

Could you try that and report back?

> 1) replace
> 
> if (( $size > $size_limit ))
> 
> with
> 
> if [ $(printf "%d" ${size}) -gt $(printf "%d" ${size_limit}) ]
> 
> 2) replace
> 
> if (( $offset < $map ))
> 
> with
> 
> if [ $(printf "%d" ${offset}) -lt $(printf "%d" ${map}) ]
> 
> After these changes the hexadecimal numbers are converted to decimal
> before the comparison. Now this script works OK and the whole build
> completes without any error
> 
> I have tested your firmware at my G505S, the LEDs are working ;-) and
> are changing their state if I press a button.

Cool! You may also want to close and open the lid ;)

Also if you attach the UART to it, you will get a functional console.

> Maybe its a good idea to launch this project publicly by creating a
> mirror at GitHub, so that the people could easily commit the pull
> requests and send their comments - and then the merged pull requests
> could be synchronized with your home repository at git.code.paulk.fr ?
> What do you think about this idea?

I already have very specific plans about launching the project publicly
(that do not involve using github). I am working hard on that. In order
to drag some interest in the project at the time it is launched, I would
ask that you don't spread big news about it yet. I'd really like to keep
it semi-public for now.

Also I strongly prefer to do code review via dedicated mailing lists,
with text patches instead of web interfaces (that really do not fit well
with my workflow).

Thanks for your suggestions and interest in the project!

Cheers,

Paul

> On Sat, Jul 15, 2017 at 6:58 PM, Paul Kocialkowski <cont...@paulk.fr>
> wrote:
> > Hey,
> > 
> > Le samedi 15 juillet 2017 à 16:53 +0300, Mike Banon a écrit :
> > > Dear Damien, thank you for your interest!
> > > 
> > > These repositories are not raising G505S free-as-in-freedom level,
> > > just trying to improve the things: e.g. make a discrete GPU
> > > working
> > > and erase serial IDs from EC KB9012 proprietary firmware. To
> > > clarify:
> > > 
> > > 1) g505s-atombios : contains the AtomBIOS ROMs for discrete GPU of
> > > G505S.
> > > AFAIK nobody has successfully extracted these discrete ROMs
> > > before!
> > > If your G505S had integrated GPU only you couldn't benefited from
> > > them,
> > > but my G505S has a discrete GPU also - which does not work with
> > > coreboot.
> > > And I really hope that having two AtomBIOS ROMs inside
> > > coreboot.rom
> > > (integrated + discrete, e.g. both pci1002,990b.rom and
> > > pci1002,6663.rom )
> > > will help me to make this discrete GPU working. Going to test it
> > > soon
> > > :D
> > > 
> > > 2) g505s-proprietary : contains the motherboard's LA-A091P and EC
> > > KB9012
> > > keyboard controller datasheets, and Lenovo's Hardware Maintenance
> > > Manual
> > > (sometimes helps to find the replacement parts, such as the new
> > > screws)
> > > Of course many of us already had these files, but it also contains
> > > a
> > > clean EC KB9012 ROM - extracted directly from BIOS updating
> > > software!
> > > Compared to what is flashed at G505S by default, this clean ROM
> > > doesn't
> > > have any IDs, therefore flashing it slightly improves your
> > > anonymity
> > > 
> > > > It would be good to get this chipset working with Timothy's
> > > > non-AGESA ram init, which I was working on at an earlier time
> > > > but
> > > > got
> > > > stuck and ran out of time.
> > > 
> > > Please tell, have you uploaded your unfinished work somewhere?
> > > 
> > > > I believe the EC has been done too by Paul
> > > 
> > > Thank you very much for this information! Do you know whether
> > > it has been 100% completed and G505S boots with it, by a chance?
> > > 
> > > http://git.code.paulk.fr/gitweb/?p=origami-ec.git;a=summary
> > > 
> > > I am getting a few problems while trying to build:

Re: [coreboot] for Lenovo G505S owners: AtomBIOS ROMs (discrete too!), binaries, datasheets...

[Paul Kocialkowski]

EX-15-G500S-S500-Z510-US-laptop-
> keyboard/1945098518.html
> 
> 3) bottom cover, $14 -
> https://www.aliexpress.com/item/New-For-Lenovo-G500S-G505S-Bottom-RAM-
> HDD-Hard-Drive-Cover-Door-balck/32819067218.html
> 
> + new thermal paste and some 100% alcohol for disinfection,
> then could put SSD and 16 GB of RAM there for a beast machine ;)
> 
> > I'm not sure if you are allowed to redistribute proprietary
> > roms/datasheets
> 
> It depends on your location - different countries have different laws.
> At my place I am allowed to use and even distribute them for not-
> commercial
> purposes (e.g. reverse engineering or just a hobby), at some other
> places
> the people are allowed to download these files but aren't allowed to
> share
> 
> Sadly some countries have very strict copyright laws, e.g. at USA I
> would
> have had to wait 75 years :P Many (if not all) GitHub servers are at
> USA
> jurisdiction, but they can't sue me - only to take down my
> repositories,
> which I could easily re-upload to GitHub again or to somewhere else...
> 
> However, these datasheets have been at GitHub for almost a year
> ( https://github.com/mikebdp2/kb9012-g505s-official ) and still
> available!
> 
> Probably because these datasheets aren't like a game or a movie
> (when the manufacturer is losing money if someone else is distributing
> it)
> in reality - nobody cares if you are distributing them. Multiple times
> I
> have honestly tried to contact both Compal and ENE asking them if they
> don't mind me sharing the datasheets, but they have never replied to
> me
> 
> Good luck to your projects,
> Mike Banon
> 
> On Sat, Jul 15, 2017 at 6:24 AM, Damien Zammit <dam...@zamaudio.com>
> wrote:
> > Dear Mike,
> > 
> > I am not sure what this is all about, but we already ported the
> > G505s to
> > coreboot.I believe the EC has been done too by Paul,
> > so the only thing remaining apart from the hardest part (ram init)
> > would
> > be the vga init, (which Alex already did 95% for this particular
> > hardware).  I no longer have the laptop hardware with me so this is
> > going to be problematic for me to do much work on it in the near
> > future.
> > 
> > By the way, I'm not sure if you are allowed to redistribute
> > proprietary
> > roms/datasheets, but IANAL.
> > 
> > I wish you luck,
> > 
> > Damien
> > 
> > On 15/07/17 07:48, Mike Banon wrote:
> > > Good day! Together with my friend Ivan we have opened a new GitHub
> > > page,
> > > 
> > > https://github.com/g505s-opensource-researcher
> > > 
> > > and created 3 repositories there:
> > > 
> > > 1) g505s-atombios
> > > AMD AtomBIOS video bios releases for G505S Integrated HD-8650G and
> > > discrete HD-8570M / R5-M230 GPUs
> > > 
> > > 2) g505s-proprietary
> > > Proprietary stuff: InsydeH20 closed source BIOS files, documents,
> > > binaries and datasheets for G505S
> > > 
> > > Their files were described at our previous messages:
> > > 
> > > https://mail.coreboot.org/pipermail/coreboot/2017-July/084660.html
> > > https://mail.coreboot.org/pipermail/coreboot/2017-July/084671.html
> > > https://mail.coreboot.org/pipermail/coreboot/2017-June/084569.html
> > > 
> > > All the SHA-256 checksums are available at sha256sum.txt text
> > > files
> > > 
> > > Also, we are going to set up 3) a bit later:
> > > 
> > > 3) g505s-coreboot
> > > coreboot open source BIOS releases for AMD-based Lenovo G505S
> > > laptop
> > > with A10-5750M quad core APU
> > > 
> > > "3)" could be especially useful for the people who just recently
> > > became interested at coreboot/SeaBIOS projects - and would like to
> > > quickly test on their G505S laptop because of the official BIOS
> > > shortcomings (WiFi whitelist / poor thermal management)
> > > 
> > > By the way, there were two typos at Ivan's cbfstool.sh script -
> > > two
> > > missing "\" characters at the end of line. g505s-atombios
> > > repository
> > > has a working version
> > > 
> > > Have the great weekends and happy hacking ;-)
> > > 
> > > Wish you all the best,
> > > Mike Banon
> > > 
-- 
Paul Kocialkowski,

developer of free digital technology and hardware support.

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] make crossgcc-i386 : ubsan.c error (with fix!) for GCC

[Paul Kocialkowski]

On Sun, 2017-06-04 at 22:49 +, qma ster wrote:
> Good day! While building the coreboot's toolchain by using GCC 7.1.1
> version, I am getting the following error:
> 
> ubsan.c:1474:23: error: ISO C++ forbids comparison between pointer and
> integer [-fpermissive]
>|| xloc.file == '\0' || xloc.file[0] == '\xff'
> 
> The fix is very simple - just open
> ./util/crossgcc/gcc-6.3.0/gcc/ubsan.c and change
> 
>|| xloc.file == '\0' || xloc.file[0] == '\xff'
> 
> to
> 
>|| xloc.file[0] == '\0' || xloc.file[0] == '\xff'
> 
> Found this solution here -
> https://patchwork.openembedded.org/patch/138884/ . Would be great if
> you could somehow import it to your code

Submitted to gerrit as https://review.coreboot.org/#/c/20103/

Cheers!

-- 
Paul Kocialkowski, developer of free digital technology and hardware support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

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

Re: [coreboot] Current, BLOB free laptop available Europe?

[Paul Kocialkowski]

Hey,

Le lundi 05 juin 2017 à 18:20 +0300, Mike Banon a écrit :
> actually Lenovo G505S has more freedom in some relations, if compared
> to Chromebook R13 : for example, G505S does not require blobs for WiFi
> and Bluetooth if you replace its' preinstalled Broadcom half size mini
> PCI-e card with Atheros AR9462 (which has 2.4 GHz + 5 GHz + Bluetooth
> and is top-of-the-line ath9k card) and its' price is just $8-$10 with
> free shipping included ;)

Well, I don't think that Wi-Fi is really a big deal compared to having
coprocessors that can only run proprietary software, in addition to proprietary
graphics init along with a proprietary EC.

You can easily use an external ath9k_htc USB dongle on CrOS devices instead of
the internal one, which solves the Wi-Fi situation easily.

There's hope for the G505s though and I truly hope it can get close to the
current freedom status of ARM CrOS devices! (And I'm still working hard to
improve the EC situation.)

>  also there are some great technical
> opportunities which chromebooks do not have - e.g. you could replace
> WiFi mini pci-e card with double SATA ports RAID card, or you can
> install 16 GB of RAM because G505S RAM is not soldered ! Still could
> get G505S in good condition at many USA / European markets, e.g.
> yesterday at eBay I saw G505S based at USA which costs just $95, also
> UK-based in nearly mint condition ;) Also there are a lot of spare
> parts available, which helps to ensure the long lifetime of this great
> performance quad core laptop ( Chromebook is not even close at
> performance, as far as I know )

Yeah, those are definitely nice technical features (but they're not freedom-
related)! I also have a bit of a hard time with devices I can't replace broken
parts for, because they're all soldered onto the same board!

Cheers,

Paul

> On Wed, May 31, 2017 at 11:03 AM, Paul Kocialkowski <cont...@paulk.fr> wrote:
> > Hi,
> > 
> > Le mardi 23 mai 2017 à 08:54 +0200, Paul Menzel a écrit :
> > > I am looking for a new portable device available in Europe.
> > > 
> > > Is it true, that the Acer Chromebook R 13 [1], is the only current BLOB
> > > free device? The device currently costs 400 €. Is MediaTek “a good
> > > citizen”, that means, do they provide datasheets and work on drivers?
> > 
> > The Chromebook R13 (elm) is very close to being able to boot without non-
> > free
> > blobs. The only remaining blobs are the MT8173 PCM firmwares[0] in ARM
> > Trusted
> > Firmware. I am working hard to liberate them and I'm very confident that it
> > will
> > happen pretty soon.
> > 
> > However, note that the kernel will require blobs for features such as:
> > * hardware video decoding
> > * Wi-Fi and bluetooth
> > * GPU support
> > 
> > I'm also not sure about the status of the PD (USB type-C controller) chip.
> > It
> > might also be running a proprietary firmware (maybe someone from the CrOS
> > team
> > can clarify this).
> > 
> > Also, note that as usual with laptops, there are lots of other non-free
> > components around that are preinstalled on the device, such as the webcam
> > firmware.
> > 
> > Note that ARMv7 CrOS devices (mainly RK3288 and Tegra K1) can also boot
> > blobless
> > and generally require less kernel blobs too. They also have much better
> > upstream
> > Linux support than the ARMv8 ones (which are more recent). For instance, I'm
> > running a mainline kernel on the Tegra K1 nyans, which is quite usable
> > despite
> > some issues that I have left to fix. There's also a very high chance that
> > the
> > GPU will work with nouveau and free firmwares eventually (I'll be working
> > with
> > nouveau developers to try and make this happen).
> > 
> > > The Samsung Chromebook Plus/Pro with RK3399 [2] are only available in
> > > the USA, right?
> > 
> > I am not aware of it being available in Europe. However, if you're fine with
> > a
> > qwerty layout, they work just as well in Europe ;)
> > 
> > RK3399 can currently already boot blobless but also requires kernel blobs.
> > However, it seems that the boot is currently broken with coreboot master and
> > ToT
> > depthcharge and vboot (I'll be investigating this soon).
> > 
> > Also, the Chromebook Plus (kevin) does have a free software PD firmware.
> > 
> > Finally, note that the Chromebook Pro is an Intel x86 device, so probably
> > not
> > very interesting given what you're looking for.
> > 
> > Cheers,
> > 
> > [0]: https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/m
> > ediatek/mt

Re: [coreboot] make crossgcc-i386 : ubsan.c error (with fix!) for GCC

[Paul Kocialkowski]

Hi,

Le dimanche 04 juin 2017 à 22:49 +, qma ster a écrit :
> Good day! While building the coreboot's toolchain by using GCC 7.1.1
> version, I am getting the following error:

[…]

> Found this solution here -
> https://patchwork.openembedded.org/patch/138884/ . Would be great if
> you could somehow import it to your code

I've had the very same issue when building crossgcc today.

Would you like to make a patch to coreboot for that? If not, I'll probably end
up doing it soon.

Cheers,

-- 
Paul Kocialkowski, developer of free digital technology and hardware support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Paul Kocialkowski]

Le mercredi 31 mai 2017 à 03:57 -0400, Don Saklad a écrit :
> What do each of the letters B...? , L...? , O...? , B...? represent in
> the acronym BLOB ?

See https://www.openbsd.org/lyrics.html#39 ;)

Cheers,

>   Paul Menzel <paulepan...@users.sourceforge.net> writes:
>   > [1:multipart/signed Hide]
>   > [1/1:text/plain Hide]
>   > Dear coreboot folks,
>   > I am looking for a new portable device available in Europe.
>   > Is it true, that the Acer Chromebook R 13 [1], is the only current BLOB
>   > free device? The device currently costs 400 €. Is MediaTek “a good
>   > citizen”, that means, do they provide datasheets and work on drivers?
>   > The Samsung Chromebook Plus/Pro with RK3399 [2] are only available in
>   > the USA, right?
>   > Thanks,
>   > Paul
>   > [1] https://www.acer.com/ac/en/US/content/series/acerchromebookr13
>   > [2] https://chromeunboxed.com/samsung-chromebook-pros-processor-rk3399-get
> s-benchmarked-and-it-is-fast/
>   > [1/2:application/pgp-signature Show Save:signature.asc (195B)]
>   > [2:text/plain Hide]
> 
-- 
Paul Kocialkowski, developer of free digital technology and hardware support

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Minifree Libreboot D16 server/workstation launched

[Paul Kocialkowski]

Le samedi 07 janvier 2017 à 22:14 -0500, taii...@gmx.com a écrit :
> Ah thanks for the info, I had thought all IBM POWER8 systems had open 
> firmware :(
> So to confirm, the more reasonably priced S812LC for 4.8K doesn't have 
> it? What a shame.

The S812LC (codename Habanero) has OpenPOWER support but doesn't have OpenBMC
support yet, so you can boot the CPU(s) with free software but the BMC can only
use the non-free system it has preinstalled sofar.

It's not impossible that Habanero support gets added to OpenBMC in the future,
but it's hard to say when and if it's going to happen.

Cheers,

-- 
Paul Kocialkowski, developer of free digital technology at the lower levels

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] FOSDEM 2017

[Paul Kocialkowski]

Hi,

Le vendredi 19 août 2016 à 15:57 +0200, Carl-Daniel Hailfinger a écrit :
> Do we want to have a full developer room, a talk or just a stand?

I see that the wiki indicates there will be a Coreboot table this year !

As I'll try to come to FOSDEM again this year, I thought I could help with the
Coreboot stand. I could bring a bunch of CrOS devices running (upstream)
Coreboot and various tools (programmers, clips, etc) and maybe a G505s too.

Are other people interested in helping with the stand? Perhaps we should start
coordinating since FOSDEM isn't that very far away now.

Also, I was wondering about next year: perhaps it would make sense to organize a
low-level developer room, oriented towards topics such as boot software
(including Coreboot, Libreboot, U-Boot, OpenPOWER, etc) as well as hardware-
support aspects in Linux and standalone firmware (such as EC). It seems that
what came closest to it in the past years (and this one included) is the
Embedded devroom, which isn't really a good fit, so it feels like FOSDEM is
missing out on these topics each year.

What do you think of the idea?

Cheers!

-- 
Paul Kocialkowski, developer of free digital technology at the lower levels

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] How to add Medion AKOYA S2013 (google/veyron_jaq)

[Paul Kocialkowski]

Hi,

Le dimanche 07 août 2016 à 15:50 +0200, Paul Menzel via coreboot a écrit :
> I got the Rockchip RK3288 based Google Chromebook Medion AKOYA S2013
> which is or is based on the google/veyron_jaq board.
> 
> In the tree, there is currently the Haier Chromebook 11, also based on
> `google/veyron_jaq`. `src/mainboard/google/veyron/Kconfig.name`
> contains:
> 
>   5 config BOARD_GOOGLE_VEYRON_JAQ
>   6   bool "Haier Chromebook 11 (Veyron_Jaq)"
>   7   select BOARD_GOOGLE_VEYRON
>   8   select SYSTEM_TYPE_LAPTOP
> 
> How can the Medion AKOYA S2013 be added, so that it is available in the
> list? Just add it to the description as it’s the same board?

I don't think that's a reasonable way to go in the long term. Veyron boards are
used in lots of different devices. For the record, here is a list of these
devices:

* Medion Akoya S2013, codename veyron_jaq
* True IDC Chromebook 11, codename veyron_jaq
* Xolo Chromebook, codename veyron_jaq
* Haier Chromebook 11, codename veyron_jaq
* NComputing Chromebook CX100, codename veyron_jerry
* eduGear Chromebook K Series, codename veyron_jerry
* CTL J2 / J4 Chromebook for Education, codename veyron_jerry
* HiSense Chromebook 11, codename veyron_jerry
* Poin2 Chromebook 11, codename veyron_jerry
* Asus Chromebit CS10, codename veyron_mickey
* MEDION Chromebook S2015, codename veyron_mighty
* Chromebook PCM-116E, codename veyron_mighty
* Lumos Education Chromebook, codename veyron_mighty
* Viglen Chromebook 11, codename veyron_mighty
* Sector 5 E1 Rugged Chromebook, codename veyron_mighty
* eduGear Chromebook M Series, codename veyron_mighty
* Nexian Chromebook 11.6-inch, codename veyron_mighty
* Haier Chromebook 11e, codename veyron_mighty
* ASUS Chromebook Flip C100PA, codename veyron_minnie
* ASUS Chromebook C201, codename veyron_speedy

So it's clearly not doable to include all the names in the Kconfig description
when the board is shared across devices.

Note that the Kconfig option relates to the board name, not the device name, so
I don't think putting the device name in there makes a lot of sense. It's a
common practice when the board itself doesn't really have a name, but when it
does, I'd rather have it instead of the device name in there (at all). CrOS
devices are remarkable occurrences of this situation.

I always thought it was somewhat confusing to talk about boards instead of
devices. Maybe it's time to resolve the confusion, for instance by adding a
separate Kconfig option for each device, that would select the right board?

I don't expect that end users know what board they should use: instead, they
know what device they have.

Otherwise, we could provide a table associating devices and boards on the wiki.

What do you think?

-- 
Paul Kocialkowski, developer of low-level free software for embedded devices

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ARM Trusted Firmware build issue

[Paul Kocialkowski]

Hey,

Le mercredi 03 août 2016 à 09:18 -0600, Martin Roth a écrit :
>   I'll get that patch tested and replace the current patch with it if it
> works.

I just did over the week-end (building elm, but obviously couldn't test on the
device) and the patch proposed by upstream solves the issue as well. It was
merged in binutils in the meantime:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7ea12e5c3ad54da440c08f32da09534e63e515ca

I'll update the patch we have in crossgcc ASAP.

Thanks!

> On Tue, Aug 2, 2016 at 9:51 AM, Paul Kocialkowski <cont...@paulk.fr> wrote:
> > 
> > Le mercredi 20 juillet 2016 à 19:33 -0700, Stefan Reinauer a écrit :
> > > 
> > > Martin produced a binutils fix for the issue. Whether the binutils
> > > people will find it to be the "right" fix is still to be found out, but
> > > it seems to allow compiling the latest, unmodified ARM TF.
> > 
> > Upstream just answered with a comprehensive description of what is happening
> > and
> > a patch to solve the issue, at:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=20364
> > 
> > Could someone try that and report back (either here directly on the tracker)
> > whether it solves the issue? There's a chance this fix will be accepted
> > upstream
> > if it works.
> > 
> > Cheers,
> > 
> > --
> > Paul Kocialkowski, developer of low-level free software for embedded devices
> > 
> > Website: https://www.paulk.fr/
> > Coding blog: https://code.paulk.fr/
> > Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
> 

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ARM Trusted Firmware build issue

[Paul Kocialkowski]

Le mercredi 20 juillet 2016 à 19:33 -0700, Stefan Reinauer a écrit :
> Martin produced a binutils fix for the issue. Whether the binutils 
> people will find it to be the "right" fix is still to be found out, but 
> it seems to allow compiling the latest, unmodified ARM TF.

Upstream just answered with a comprehensive description of what is happening and
a patch to solve the issue, at:
https://sourceware.org/bugzilla/show_bug.cgi?id=20364

Could someone try that and report back (either here directly on the tracker)
whether it solves the issue? There's a chance this fix will be accepted upstream
if it works.

Cheers,

-- 
Paul Kocialkowski, developer of low-level free software for embedded devices

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Building Coreboot on ARM

[Paul Kocialkowski]

Just a quick announcement to let the community know that it is now possible to
build Coreboot on ARM (including building the toolchain).

I was able to produce bit-to-bit identical images from an x86 laptop and an ARM
laptop, which I find pretty cool!

This way, it's also possible to build Coreboot for an ARM-supported device on
that same device.

Cheers,
-- 
Paul Kocialkowski, developer of low-level free software for embedded devices

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] ARM Trusted Firmware build issue

[Paul Kocialkowski]

Le mercredi 13 juillet 2016 à 12:47 -0600, Martin Roth a écrit :
> Ok, I tested updating the code from '.align x,0' to '.align x'.  This
> updates the padding from 0x00 to nop instructions, and does work with
> GAS 2.26.
> 
> I've submitted a pull request for the arm-trusted-firmware repo:
> https://github.com/ARM-software/arm-trusted-firmware/pull/664

The discussion about the bug on the ATF github tracker seemed to indicate that
ARM was not willing to solve things this way:
https://github.com/ARM-software/tf-issues/issues/401

(I should have mentioned it the email too, instead of just in the GAS bug
report, in case you missed it.)

I hope your pull request will be enough leverage to make them accept this
solution!

> Martin
> 
> On Wed, Jul 13, 2016 at 9:14 AM, Paul Kocialkowski <cont...@paulk.fr> wrote:
> > Hi,
> > 
> > Le mercredi 13 juillet 2016 à 08:57 -0600, Martin Roth a écrit :
> > >   Thanks for posting about this.  I've spent some time looking into
> > > this as well, but in my usual fashion, I didn't communicate what I
> > > found in a responsible fashion.  Here's what I posted in a code
> > > review:
> > 
> > Looks like I didn't search long enough to find this ;)
> > 
> > > > The current binutils (2.26) is failing to build the current arm-trusted-
> > > > firmware.
> > > > This wasn't caught because the jenkins builders haven't been updated to
> > > > the
> > > > latest build tools. I tested the new release of binutils (2.26.1) and
> > > > the
> > > > update
> > > > didn't help my build. There's a patch that should fix the issue - See
> > > > this
> > > > thread for an explanation of the issue and the patch:
> > > > 
> > > > https://www.mail-archive.com/linaro-toolchain%40lists.linaro.org/msg0568
> > > > 5.ht
> > > > ml
> > > > 
> > > > Unfortunately, a different change went into 2.26.1 at that location, so
> > > > this
> > > > patch
> > > > doesn't directly apply.
> > > 
> > > For some reason, I didn't directly test that patch with 2.26 to see if
> > > it actually worked - I tried adding it in to 2.26.1, which did not
> > > help.  I'll test it with 2.26 today, and add the patch into the
> > > toolchain build if it works.
> > 
> > From what I understood, that patch only allows the build to work when
> > removing
> > the extra 0 to .align (so using ".align x" instead of ".align x, 0"). And it
> > was
> > indeed crafted for an older GAS version. For 2.26, it doesn't apply either
> > and a
> > similar fix was already included, so the workaround above does work.
> > 
> > But again, we can't easily patch ATF…
> > 
> > > We can't roll the entire toolchain back to binutils 2.25 because of
> > > the RISC-V work.
> > 
> > Indeed.
> > 
> > > Is it reasonable to roll back to binutils 2.25 for just the ARM toolchain
> > > builds?
> > 
> > Someone should definitely try that, I have no idea whether it's a good idea
> > off-
> > hand. If anyone does, please speak up :)
> > 
> > I'm running out of time these days, but if nobody else does it, I'll
> > probably
> > have a go at it this week-end.
> > 
> > > And then I need to update the toolchains on the builders and figure
> > > out how to keep them up-to-date so this doesn't happen again.
> > 
> > That would be nice!
> > 
> > > Sorry I didn't post this directly to the mailing list earlier.
> > 
> > No problem, it was fun to dig into it. Also, since the affected devices are
> > not
> > public, I guess it doesn't really bother anyone. I just happened to look at
> > it
> > when submitting a crossgcc change, which comes out as unstable because of
> > this
> > issue, but that's about it.
> > 
> > Cheers,
> > 
> > Paul
> > 
> > > On Wed, Jul 13, 2016 at 2:35 AM, Paul Kocialkowski <cont...@paulk.fr>
> > > wrote:
> > > > We spent some time yesterday evening on IRC investigating why the ARM
> > > > Trusted
> > > > Firmware (ATF) doesn't build with the current toolchain from coreboot's
> > > > crossgcc.
> > > > 
> > > > It turns out it is a complex issue on the assembler's side. I have
> > > > opened a
> > > > bug
> > > > upstream about it, with all the details we could find:
> > > > https://sourceware.org/bugzilla/show_bug.cgi?id=20

Re: [coreboot] ARM Trusted Firmware build issue

[Paul Kocialkowski]

Hi,

Le mercredi 13 juillet 2016 à 08:57 -0600, Martin Roth a écrit :
>   Thanks for posting about this.  I've spent some time looking into
> this as well, but in my usual fashion, I didn't communicate what I
> found in a responsible fashion.  Here's what I posted in a code
> review:

Looks like I didn't search long enough to find this ;)

> > The current binutils (2.26) is failing to build the current arm-trusted-
> > firmware.
> > This wasn't caught because the jenkins builders haven't been updated to the
> > latest build tools. I tested the new release of binutils (2.26.1) and the
> > update
> > didn't help my build. There's a patch that should fix the issue - See this
> > thread for an explanation of the issue and the patch:
> > 
> > https://www.mail-archive.com/linaro-toolchain%40lists.linaro.org/msg05685.ht
> > ml
> > 
> > Unfortunately, a different change went into 2.26.1 at that location, so this
> > patch
> > doesn't directly apply.
> 
> For some reason, I didn't directly test that patch with 2.26 to see if
> it actually worked - I tried adding it in to 2.26.1, which did not
> help.  I'll test it with 2.26 today, and add the patch into the
> toolchain build if it works.

From what I understood, that patch only allows the build to work when removing
the extra 0 to .align (so using ".align x" instead of ".align x, 0"). And it was
indeed crafted for an older GAS version. For 2.26, it doesn't apply either and a
similar fix was already included, so the workaround above does work.

But again, we can't easily patch ATF…

> We can't roll the entire toolchain back to binutils 2.25 because of
> the RISC-V work.

Indeed.

> Is it reasonable to roll back to binutils 2.25 for just the ARM toolchain
> builds?

Someone should definitely try that, I have no idea whether it's a good idea off-
hand. If anyone does, please speak up :)

I'm running out of time these days, but if nobody else does it, I'll probably
have a go at it this week-end.

> And then I need to update the toolchains on the builders and figure
> out how to keep them up-to-date so this doesn't happen again.

That would be nice!

> Sorry I didn't post this directly to the mailing list earlier.

No problem, it was fun to dig into it. Also, since the affected devices are not
public, I guess it doesn't really bother anyone. I just happened to look at it
when submitting a crossgcc change, which comes out as unstable because of this
issue, but that's about it.

Cheers,

Paul

> On Wed, Jul 13, 2016 at 2:35 AM, Paul Kocialkowski <cont...@paulk.fr> wrote:
> > We spent some time yesterday evening on IRC investigating why the ARM
> > Trusted
> > Firmware (ATF) doesn't build with the current toolchain from coreboot's
> > crossgcc.
> > 
> > It turns out it is a complex issue on the assembler's side. I have opened a
> > bug
> > upstream about it, with all the details we could find:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=20364
> > 
> > This regression was introduced with binutils 2.26. To get the build going in
> > the
> > short term, we could either downgrade binutils back to 2.25 (if it still
> > meets
> > all dependencies from other tools) or patch ATF to replace the ".align x, 0"
> > directives to ".align x" in include/common/asm_macros.S (not sure this is a
> > possibility).
> > 
> > Cheers,
> > 
> > -- Paul Kocialkowski, developer of low-level free software for embedded
> > devices
> > 
> > Website: https://www.paulk.fr/
> > Coding blog: https://code.paulk.fr/
> > Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/
> > --
> > coreboot mailing list: coreboot@coreboot.org
> > https://www.coreboot.org/mailman/listinfo/coreboot

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] ARM Trusted Firmware build issue

[Paul Kocialkowski]

We spent some time yesterday evening on IRC investigating why the ARM Trusted
Firmware (ATF) doesn't build with the current toolchain from coreboot's
crossgcc.

It turns out it is a complex issue on the assembler's side. I have opened a bug
upstream about it, with all the details we could find:
https://sourceware.org/bugzilla/show_bug.cgi?id=20364

This regression was introduced with binutils 2.26. To get the build going in the
short term, we could either downgrade binutils back to 2.25 (if it still meets
all dependencies from other tools) or patch ATF to replace the ".align x, 0"
directives to ".align x" in include/common/asm_macros.S (not sure this is a
possibility).

Cheers,

-- Paul Kocialkowski, developer of low-level free software for embedded devices

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot 4.4 release coming soon

[Paul Kocialkowski]

Le vendredi 22 avril 2016 à 15:36 +0200, Paul Kocialkowski a écrit :
> With those patches applied, the display is mangled on depthcharge as seen
> on: http://download.paulk.fr/coreboot/nyan_big/nyan_big-display.jpg

This was reported as https://ticket.coreboot.org/issues/50 and fixed by https://
review.coreboot.org/#/c/14564/

It would be nice to include this before the release!

-- 
Paul Kocialkowski, low-level free software developer on embedded devices

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/

signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
https://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot 4.4 release coming soon

[Paul Kocialkowski]

Here is a status report for the chromebooks I'm using:

* veyron_speedy

Boots fine with today's HEAD on a standard use case. However, my particular use
case requires https://review.coreboot.org/#/c/14472/ which is trivial.

* nyan_big

Building with CHROMEOS requires https://review.coreboot.org/#/c/14474/ otherwise
it hangs at bootblock.

Merging the libpayload config before the release would also be nice: https://rev
iew.coreboot.org/#/c/14472/

With those patches applied, the display is mangled on depthcharge as seen on: ht
tp://download.paulk.fr/coreboot/nyan_big/nyan_big-display.jpg

A boot log is attached to this email. It would be useful if someone else could
try and let me know whether they can duplicate the issue.

I'm unsure the issue comes from coreboot, depthcharge or my modifications to
depthcharge and vboot.

The repositories I'm using are:
http://git.code.paulk.fr/gitweb/?p=coreboot.git;a=summary
http://git.code.paulk.fr/gitweb/?p=depthcharge.git;a=summary
http://git.code.paulk.fr/gitweb/?p=vboot.git;a=summary

with branch libreboot-next

Cheers,
-- 
Paul Kocialkowski, low-level free software developer on embedded devices

Website: https://www.paulk.fr/
Coding blog: https://code.paulk.fr/
Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/coreboot-4.3-808-gcd77f2f-dirty Fri Apr 22 09:12:53 UTC 2016 bootblock 
starting...
SF: Detected W25Q32DW with sector size 0x1000, total 0x40
CBFS @ 2 size e
CBFS: 'Master Header Locator' located CBFS at [2:10)
CBFS: Locating 'fallback/romstage'
CBFS: Found @ offset 80 size 6a52
Ungating power partition 0.
Power gate toggle request accepted.
Ungated power partition 0.
Ungating power partition 15.
Ungated power partition 15.
Ungating power partition 14.
Power gate toggle request accepted.
Ungated power partition 14.


coreboot-4.3-808-gcd77f2f-dirty Fri Apr 22 09:12:53 UTC 2016 romstage 
starting...
Exception handlers installed.
get_sdram_config: RAMCODE=4
Initializing SDRAM of type 2 with 792000KHz
sdram_size_mb: Total SDRAM (MB): 4096
LPAE Translation tables are @ 4000
Mapping address range [0x:0x8000) as uncached
Mapping address range [0x4000:0x4010) as writeback
Mapping address range [0x8000:0x) as writeback
Mapping address range [0x9000:0x9020) as uncached
Setting address range [0x:0x0010) as unmapped
CBMEM:
IMD: root @ fdfff000 254 entries.
IMD: root @ fdffec00 62 entries.
SF: Detected W25Q32DW with sector size 0x1000, total 0x40
CBFS @ 2 size e
CBFS: 'Master Header Locator' located CBFS at [2:10)
CBFS: Locating 'fallback/ramstage'
CBFS: Found @ offset 6b40 size ac26
oreboot-4.3-808-gcd77f2f-dirty Fri Apr 22 09:12:53 UTC 2016 ramstage starting...
sdram_size_mb: Total SDRAM (MB): 4096
SF: Detected W25Q32DW with sector size 0x1000, total 0x40
FMAP: Found "FLASH" version 1.1 at 10.
FMAP: base = 0 size = 40 #areas = 21
FMAP: area RO_VPD found @ 1f (65536 bytes)
WARNING: RO_VPD is uninitialized or empty.
FMAP: area RW_VPD found @ 2f8000 (32768 bytes)
WARNING: RW_VPD is uninitialized or empty.
Exception handlers installed.
BS: BS_PRE_DEVICE times (us): entry 1 run 0 exit 0
BS: BS_DEV_INIT_CHIPS times (us): entry 0 run 1 exit 1
Enumerating buses...
Show all devs... Before device enumeration.
Root Device: enabled 1
CPU_CLUSTER: 0: enabled 1
Compare with tree...
Root Device: enabled 1
 CPU_CLUSTER: 0: enabled 1
Root Device scanning...
root_dev_scan_bus for Root Device
CPU_CLUSTER: 0 enabled
root_dev_scan_bus for Root Device done
scan_bus: scanning of bus Root Device took 10761 usecs
done
BS: BS_DEV_ENUMERATE times (us): entry 1 run 32806 exit 0
Allocating resources...
Reading resources...
Root Device read_resources bus 0 link: 0
Root Device read_resources bus 0 link: 0 done
Done reading resources.
Show resources in subtree (Root Device)...After reading.
 Root Device child on link 0 CPU_CLUSTER: 0
  CPU_CLUSTER: 0
Setting resources...
Root Device assign_resources, bus 0 link: 0
Root Device assign_resources, bus 0 link: 0
Done setting resources.
Show resources in subtree (Root Device)...After assigning values.
 Root Device child on link 0 CPU_CLUSTER: 0
  CPU_CLUSTER: 0
Done allocating resources.
BS: BS_DEV_RESOURCES times (us): entry 0 run 50080 exit 0
Enabling resources...
done.
BS: BS_DEV_ENABLE times (us): entry 1 run 2609 exit 1
Initializing devices...
Root Device init ...
USB controller @ 7d00 set up with UTMI+ PHY
USB controller @ 7d008000 set up with UTMI+ PHY
SF: Detected W25Q32DW with sector size 0x1000, total 0x40
FMAP: area RW_ELOG found @ 27c000 (16384 bytes)
ELOG: FLASH @0x80218440 [SPI 0x0027c000]
ELOG: area is 4096 bytes, full threshold 3834, shrink size 1024
ELOG: Event(17) added with size 13
out: cmd=0x87: 03 32 87 00 00 00 04 00 00 40 00 00 
in-header: 03 d5 00 00 04 00 00 00 
in-data: 04 20 00 00 
out: cmd=0x17: 03 9c 17 00 01 00 14 00 00 00 00 00 04 2e 21 80 05 00 00 00 b1 
b0 82 d4 7d 89 20 80 
in-

Re: [coreboot] FOSDEM deadlines now!

[Paul Kocialkowski]

Le mercredi 30 décembre 2015 à 12:36 +0100, Paul Kocialkowski a écrit :
> Hi,
> 
> Le samedi 31 octobre 2015 à 10:41 +0100, Paul Kocialkowski a écrit :
> > Le mardi 20 octobre 2015 à 23:20 +0200, Carl-Daniel Hailfinger a écrit :
> > > we obviously want to participate in FOSDEM.
> > > https://fosdem.org/2016/news/2015-09-24-call-for-participation/
> > > 
> > > ACT NOW!
> > > 
> > > Some deadlines already expired. Some can still be managed.
> > > 
> > > Main track talks: Deadline 2015-10-30 (10 days left)
> > > One hour of entertainment, huge audience.
> > > Anyone up for the challenge?
> > 
> > I have submitted a talk proposal about liberating modern computers, and
> > will of course be talking about Coreboot there.
> 
> Sadly, the talk was rejected and it's too late to apply for one in a
> developer room. I'm a bit unsure whether I'll come to FOSDEM at all, but
> if I do, I'll be sure to come by and hang around the Coreboot booth!

Quick status update: I got a lightning talk in at the last minute,
entitled "The road to liberating software at the lower levels":
https://fosdem.org/2016/schedule/event/liberating_software/

It'll be very generic, but expect some examples about the C201
Chromebook and about running code on the kb9012 embedded controller!

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: https://www.replicant.us/
Blog: https://blog.replicant.us/
Wiki/tracker/forums: https://redmine.replicant.us/



signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] FOSDEM deadlines now!

[Paul Kocialkowski]

Hi,

Le samedi 31 octobre 2015 à 10:41 +0100, Paul Kocialkowski a écrit :
> Le mardi 20 octobre 2015 à 23:20 +0200, Carl-Daniel Hailfinger a écrit :
> > we obviously want to participate in FOSDEM.
> > https://fosdem.org/2016/news/2015-09-24-call-for-participation/
> > 
> > ACT NOW!
> > 
> > Some deadlines already expired. Some can still be managed.
> > 
> > Main track talks: Deadline 2015-10-30 (10 days left)
> > One hour of entertainment, huge audience.
> > Anyone up for the challenge?
> 
> I have submitted a talk proposal about liberating modern computers, and
> will of course be talking about Coreboot there.

Sadly, the talk was rejected and it's too late to apply for one in a
developer room. I'm a bit unsure whether I'll come to FOSDEM at all, but
if I do, I'll be sure to come by and hang around the Coreboot booth!

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: https://www.replicant.us/
Blog: https://blog.replicant.us/
Wiki/tracker/forums: https://redmine.replicant.us/



signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] FOSDEM deadlines now!

[Paul Kocialkowski]

Hi,

Le mardi 20 octobre 2015 à 23:20 +0200, Carl-Daniel Hailfinger a écrit :
> we obviously want to participate in FOSDEM.
> https://fosdem.org/2016/news/2015-09-24-call-for-participation/
> 
> ACT NOW!
> 
> Some deadlines already expired. Some can still be managed.
> 
> Main track talks: Deadline 2015-10-30 (10 days left)
> One hour of entertainment, huge audience.
> Anyone up for the challenge?

I have submitted a talk proposal about liberating modern computers, and
will of course be talking about Coreboot there. Not everything I'm
mentioning in the talk was properly documented at this point (especially
regarding work on the KB9012 EC), but I hope to correct that before the
event!

Liberating (modern) computers from the ground up: a tale of Libreboot,
Chromebooks and EC

Abstract:

Most of the computers we use daily are relying on proprietary software
at the lower levels. This includes the bootloader (previously known as
BIOS), firmwares running on various microcontrollers inside peripherals
and controllers and even microcodes inside processors. However, some
devices and platforms perform better than others when it comes to
software freedom at these levels: some are supported by free
bootloaders, such as U-Boot and Coreboot. Thus, it becomes less of a
stretch to liberate those devices, which is also crucial for privacy and
security.

Chromebooks are such good targets, since they ship with Coreboot and a
free embedded controller firmware. While some models still require
proprietary pieces here and there, a few can actually boot up with only
free software and are now supported by Libreboot, the fully free
distribution of Coreboot. In addition, they implement a robust security
model that, for once, does not conflict with the user's interest.

On the other hand, a few recent AMD devices also show real potential for
free software, with possible areas of work for freeing them at the low
levels. In particular, freeing the software running on such an AMD
laptop's embedded controller is currently work in progress, with all the
tools needed in hands.

Description:

Starting from a personal use case, this talk will first draw a general
overview of the current status of free software support at the lower
levels of modern computers, especially bootloaders, firmwares running
inside chips and microcodes, with a particular emphasis on embedded
devices. The common limitations when freeing these devices will be
highlighted, along with the examples of recent Intel and AMD platforms
and how they compare to different kinds of embedded systems on a chip.

With the overall picture of the situation a mind, the rest of the talk
will focus on a few examples of modern computers that were picked up
based on a personal use case and show potential for running with free
software at the lower levels. This will highlight what was already
achieved at this point, what is work in progress and what would be
doable in the future.

The first interesting devices that will be mentioned are Chromebooks,
with mention of how they usually perform better that most other modern
computers when it comes to free software. While not all Chromebooks are
good candidates for running a fully free bootloader (depending on the
platform they're using), a few of them are, such as the C201 Chromebook
(by Asus) that is now supported by Libreboot. This talk will highlight
all the challenges encountered when adding support for this Chromebook
to Libreboot and what is next for liberating it. Other potential
Chromebooks that would be worth supporting in Libreboot will also be
mentioned.

Still guided by a personal incentive, two modern computers, the G505s
laptop (by Lenovo) and the F2A85-M (PRO) mainboard (by Asus) will be
highlighted as they use an AMD platform that shows some potential for
freedom, whereas modern Intel platforms appear to be fatally flawed.
While the road to running those computers in freedom appears to be long,
if not fatally obstructed, there are still some areas of work.

In particular, the road to freeing the G505s's KB9012 embedded
controller will be presented in details, with an emphasis on the
incentive behind it and security considerations regarding embedded
controllers. This last part will show how it was possible to gather
information on the platform, implement access to its internal flash
externally, grab an UART serial port, solder standalone boards for tests
and execute code on the device, up to blinking a LED!

> Stands: Deadline 2015-11-13 (24 days left)
> I can send in the proposal if I'm not going to be alone there.
> How many tables do we want for our stand/booth(s)?
> Who is coming?

I will definitely be around at FOSDEM, not sure I should have a seat at
the table at this point (I'm still pretty new to the community), but I'd
be happy to come by!

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mo

[coreboot] Moving forward with armv7: Word-sized/half-word-sized memory operations for 32/16 bit read/write

[Paul Kocialkowski]

For nearly a month, a few people (includign myself) have been arguing
over http://review.coreboot.org/#/c/11698/

So far, we've investigated two solutions:
* inline assembly
* __builtin_assume_aligned builtin

Each solution has its pros and cons, I'm not going to move that
discussion here.

However, I would like to suggest another solution: reverting the
toolchain built by crossgcc-arm to GCC 4.9.0, where everything works
fine. That would only be for ARM, since GCC 4.9.0 apparently breaks
RISC-V support and wasn't reported to misbehave on other architectures.

I wish to use the toolchain for rebuilding the cros EC firmware
(especially important for libreboot) and GCC 5.2.0 is causing run-time
errors that are apparently not even of the same nature as the problem
discussed in code review.

Would this be an agreeable solution until everything is sorted out in
gcc upstream?

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: https://www.replicant.us/
Blog: https://blog.replicant.us/
Wiki/tracker/forums: https://redmine.replicant.us/



signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Adding Coreboot support to the F2A85-M PRO mainboard

[Paul Kocialkowski]

The Asus F2A85-M and F2A85-M LE boards are currently supported in
Coreboot. However, as the wiki[0] page emphasis, the F2A85-M PRO version
of the board is the more widely available one.

A few weeks ago, GNUtoo (CC-ed) and I decided to get one each and add
Coreboot support to those. It looks like the main difference between the
F2A85-M and the F2A85-M PRO is the Super I/O, according to the wiki[0].

A year ago, Alec Ari (CC-ed) submitted support for that Super I/O, his
code[1] was not merged and eventually, Matt DeVillier (CC-ed) added
support for that chip (but apparently missing early serial support).

I wonder if either Alec or Matt have the F2A85-M PRO in hands and
whether they did write code to support the board, as the wiki[0]
suggests. If so, it would be useful to send it as-is so that I could
have a base to add support for the board.

Otherwise, I will start from scratch, using the F2A85-M code as a
base.

Note that I'm new to working on low-level on x86 hardware (but I'm used
to ARM hardware), so I may need some pointers here and there to get this
done properly.

Generally speaking, any help regarding that board is welcome!

Thanks!

[0]: http://www.coreboot.org/Board:asus/f2a85-m#F2A85_series_status
[1]: http://review.coreboot.org/#/c/4589/
[2]: http://review.coreboot.org/#/c/10232/

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot meeting @chaos communication camp

[Paul Kocialkowski]

Le mardi 04 août 2015 à 04:48 +0200, Alexander Couzens a écrit :
 some people will visit the chaos communication camp this year.
 I'll be around for coreboot hacking and give some people a
 introduction into coreboot. I've started a etherpad for (hardware)
 organisation.
 Who brings what or can bring?!
 
 https://pads.ccc.de/coreboot-camp-2015

Hey there, I've added myself to the pad, despite being (very) new to
Coreboot development. To introduce myself shortly, I've been working on
freeing embedded devices for a while now, I'm the current lead developer
of Replicant, the fully free version of Android. Some time ago, I've
decided to take things to the next step by freeing device's bootloaders,
so I've spent some time porting U-Boot to the LG Optimus Black phone[0]
and contributing to the sunxi (Allwinner) port.

In the meantime, I've also been evaluating embedded devices for freedom
and I maintain a comparison of single-board computers on the FSF
website[1]. Recently, I've become very interested in Chromebooks and
I've decided to work on the recent ARM ones, starting with the C201
(that I'll bring to camp) and port them to Libreboot, since they can
boot with only free software (well, except for the bootrom, as usual).
The idea is to make it painless to have a free and secure (thanks to the
Chromium OS security model) bootloader.

I also run Coreboot on a Lenovo G505s, I plan on improving the port and
most importantly I have started the work to free its embedded controller
(a KB9012). I'm not as far along as lynxis, but it would be great to
talk about it together!

In addition, I have an Asus F2A85-M PRO around, which is similar to the
F2A85-M that is already supported by Coreboot. I plan on porting
Coreboot to it for daily use, but I couldn't get around doing it before
CCCamp.

Sadly, I didn't have time to document all those (recent) projects, I'll
certainly get around doing it after camp.

So I'd be very glad to meet Coreboot developers at CCCamp!

[0]:
http://code.paulk.fr/article20/a-hacker-s-journey-freeing-a-phone-from-the-ground-up-first-part
[1]: http://www.fsf.org/resources/hw/single-board-computers

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] coreboot meeting @chaos communication camp

[Paul Kocialkowski]

Le mercredi 12 août 2015 à 00:00 +0200, Alexander Couzens a écrit :
 I'm looking forward to meet you.
 At the moment we only have a small /tmp table in the BER village,
 in the big yellow tipi tent. On the table lies some thinkpads ;).

It shouldn't be so hard to spot you there then! I arrive on Thursday
afternoon, so I'll probably come and say hi at some point that day.

Are there any talks or workshops related to Coreboot planned?

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot

[coreboot] Porting Libreboot to the C201 Chromebook (veyron_speedy)

[Paul Kocialkowski]

Over the past week or so, I've been working to get Libreboot running on
the latest ARM Chromebook: the C201, manufactured by Asus (codename
veyron_speedy). The laptop is running with a RK3288 SoC and ships with
Google's version of Coreboot preinstalled. It should require no
proprietary code nor any proprietary firmware load or microcode update
to boot, thus it would be a good fit for Libreboot, as a fully free
distribution of Coreboot.

In addition to that, the device's embedded controller (that handles
aspects of power management as well as the keyboard and a few other
things) is a microcontroller that is also running free software: the
free embedded controller firmware from Google.

Aside from that, it has a soldered Wi-Fi/bluetooth BCM4354 chip (cannot
be removed) that has a free driver but requires to load a proprietary
firmware on the chip. However, it is easy to work around that issue and
not use that chip at all, e.g. using an ath9k_htc dongle on one of the
two USB ports.

The GPU is a Mali T764, on which Luc has been doing some early work to
have free software support for it. It is uncertain[0] how long it will
take to have an usable free replacement for it, but now that there is
that hardware available, free graphics for Mali T GPUs would mean having
a recent laptop running fully free software, down to the firmware level,
without losing any major hardware feature, something that has hardly
ever been achieved yet. Thus, I believe it is of the utmost importance
to back Luc up on this, even if big players like ARM are trying hard to
make Lima not happen and to make it difficult for Luc to keep going.

Another aspect that I still have to look at in-depth is the ability to
use hardware video encoding/decoding. The RK3288 has an auxiliary
processor for that task, but it is unclear whether it can be used with
free software or not, though the first indications that I've gathered
are positive.

At this point, I've been able to boot up Debian on the device, and the
xfce4 interface is quite usable. It even runs big programs like
Iceweasel/Firefox and LibreOffice without inconveniences.

However, it cannot run desktop environments that depend on GL
acceleration, such as gnome-shell, which is a shame since those would be
a good fit for it. The CPU is simply too slow for offering a decent
experience with software rendering (llvmpipe).

Overall, I truly hope this device creates an incentive to free the last
remaining parts that can only work with proprietary software to this
day. Its potential would be huge, especially since it's a good fit for
travellers. With the security model inherited from Chromium OS, this
would be one of the safest laptops to be used by journalists or
activists. If Tails was to be ported to it, it would become easy to have
a secure and anonymous setup.

I have successfully fixed and compiled Coreboot and all the necessary
bits and pieces for the C201, so I'll be spending the next few days
sending patches, discussing how to integrate it to Libreboot and getting
the actual work done.

I also plan on documenting all my findings (especially things like how
to access UART, how to remove the SPI flash's write protect, how to
reflash it externally, etc) on my coding blog, for now.

Cheers!

References:
[0]: http://libv.livejournal.com/27461.html

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/


signature.asc
Description: This is a digitally signed message part
-- 
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot