Dear coreboot folks,
TLDR; If coreboot wants to *make use of the undefined baviour sanitizer
(UBSAN)* a solution needs to be found for left shift errors like in `1
<< 31`, where the sign bit is ignored. The proposal is to adapt the
code accordingly, that means `1U << 31`, although it’s not so pretty.
=== Longer version ===
Trying an image built with the undefined behavior sanitizer (UBSAN) for
the ASRock E350M1, it stops with the error below.
```
runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
```
Please find the code below.
```
$ nl -ba ./src/southbridge/amd/cimx/sb800/ramtop.c | tail -11
41 {
42 u32 xdata = 0;
43 int xnvram_pos = 0xf8, xi;
44 for (xi = 0; xi < 4; xi++) {
45 outb(xnvram_pos, BIOSRAM_INDEX);
46 xdata &= ~(0xff << (xi * 8));
47 xdata |= inb(BIOSRAM_DATA) << (xi *8);
48 xnvram_pos++;
49 }
50 return xdata;
51 }
```
The reason is, that the integer is not big enough to hold the left
shift in `~(0xff << (xi * 8)) with `xi = 3``.
That caused me to look more into such things, and GCC and Clang are
able to find quite some of these issues during compile time. GCC needs
`-Wshift-overflow=2` [1][2]. Right now, that warning is disabled for
Clang for example.
Please find the documentation from GCC (`man gcc`) below.
> -Wshift-overflow
> -Wshift-overflow=n
> Warn about left shift overflows. This warning is enabled by default in C99 and C++11 modes (and newer).
>
> -Wshift-overflow=1
> This is the warning level of -Wshift-overflow and is enabled by default in C99 and C++11 modes (and newer). This warning level does not warn about left-shifting 1 into the sign bit.
> (However, in C, such an overflow is still rejected in contexts where an integer constant expression is required.)
>
> -Wshift-overflow=2
> This warning level also warns about left-shifting 1 into the sign bit, unless C++14 mode is active.
That brings up a lot of problems mostly for `1 << 31` used quite a lot
in the coreboot code base.
The question is, how to deal with these. Julius commented quite
pointedly [2].
> Everyone likes to write (1 << x), and having to change them all to
> (1U << x) would not be that great for readability. But making this
> different based on whether it touches bit 31 or not is also super
> inconsistent. I think if this warning is benign, I'd be more inclined
> to just disable it.
I’d really like to *enable as much warnings* as possible to let the
build tools *catch as much errors as possible*, and having to adapt the
code to work with this is in my opinion worth the effort. If we wanted
to work around it by for example ignoring constant shift errors, we
would probably need to adapt the UBSAN for GCC and Clang, and add a new
switch also.
So, I propose to only add the type specifier in the cases, where an
error is thrown. That’s stylistically not so pretty, but would be easy
to implement, as the build tools would find the affected places without
problems, and those can be changed then.
In addtion to the already pushed change-sets, I would submit a patch
fixing all `1 << 31` and `3 << 30` occurrences, and separate change-
sets for the rest. After that, the warning can be enabled for the whole
code base.
What do you think, and what other options do you see?
Kind regards,
Paul
[1] https://review.coreboot.org/#/c/coreboot/+/23360/
[2] https://review.coreboot.org/#/c/coreboot/+/23361/
Hi Rafael,
I have a X230, but this has never happened to me before. Sorry :-( .
Have you tried unplugging, waiting 10 seconds and plugging the CMOS
battery cable and trying to boot afterwards?
Also disconnect the laptop battery during this procedure.
Regards,
- Eli
On 16/02/18 13:03, Rafael Machado wrote:
> Hi everyone
>
> Since here are the most skilled professions I've seeing I believe
> someone can help me.
>
> I have a Lenovo x230, and I'll would like to install coreboot in it to
> start to understand how it works, and in future start to help the
> community, as soon as I have the knowledge for that.
>
> Last week I did a test that makes my progress stop.
>
> Just for fun, and to check how the commercial bios works, I connected
> a postcard on the wireless slot (as far as I know this is a pcie slot).
> I already did that with other notebooks I have and nothing wrong happened.
>
> The problem is that this time, with this x230, after I connected the
> postcard and turned the system on, the system stopped to boot. And the
> post card does not stop at a specific post code.
> What happens now, is that every time I turn the system on, the battery
> led blinks 3 times, being two blinks followed by a 1 second stop and
> after that the last blink, and the system reboots.
>
> The post card I'm using is this:
> https://www.ebay.com/itm/3in1-Mini-PCI-E-PCI-LPC-Tester-PC-Desktop-Diagno...
>
> So my questions are:
>
> -Does someone believe this postcard could have bricked the system? (Why?)
> -Any idea about how to solve that?
>
> My next test will be to write a coreboot build at this system using
> buspirate, but since I'll only have time for this next week, I would
> like to have some things to think about, this is why I sent this
> e-mail before doing the coreboot flash test.
>
> Any comment will be helpful.
>
> Thanks and Regards
> Rafael R. Machado
>
>
Hi,
Le vendredi 09 février 2018 à 14:33 -0500, Youness Alaoui a écrit :
> On Tue, Feb 6, 2018 at 4:41 AM, Mike Banon <mikebdp2(a)gmail.com>
> wrote:
> > Thank you very much for telling about EC-1.75 project!
> > http://dev.laptop.org/git/users/rsmith/ec-1.75/tree/?h=3930-A1
> > Maybe some of its' elements could be borrowed for Origami
> > if the hardware is similar? (haven't compared the datasheets)
>
> There will probably be some things in common. I don't know how much
> of
> ec-1.75 is good enough to be reused though, or if it's maintainable,
> etc.. but yes, it could be a good starting point.
There is indeed a lot in common with that code, but the code itself is
not structured and organized at all so reusing the codebase makes very
little sense. I mostly use this code for reference and it has already
proven useful (e.g. for special trickery that has to be implemented
when going to low power mode).
> > @ Youness and Marty :
> >
> > Proprietary firmware of KB9012 explicitly disables EDI - ENE Debug
> > Interface
> > (the protocol used to access the internal memory of KB9012) unless
> > pin
> > 42 is grounded
> > _before_ powering the KB9012 controller ! Maybe its the same with
> > your
> > another KB ?
> > If you ground that pin (not necessarily 42, your KB's pin number
> > could
> > be different)
> > to put your EC into debug mode, maybe then you could successfully
> > read/write it ?
> >
> > Here is the full description of my successful KB9012 hardware
> > flashing setup
> > through the keyboard port using a flex cable with soldered wires:
> > 0.5mm pitch
> > makes it hard to solder directly to keyboard port, and also I like
> > flex cable solution
> > because its much faster to remove/insert a cable than to
> > solder/desolder the wires
> >
> > http://dangerousprototypes.com/docs/Flashing_KB9012_with_Bus_Pirate
> >
> > ^^^ Had to unite three grounds ( programmer's, mainboard's and
> > KB9012's 42 pin )
> > to make it work
> >
> > Currently we are actively working on the inclusion of KB9012
> > flashing support
> > to the official flashrom - but its already possible via the
> > unofficial patches.
> > Changes 23258 - 23263 at the https://review.coreboot.org/#/q/projec
> > t:flashrom
Note that the patches have been merged at this point, so ENE EDI
support in flashrom is now ready. I am also wondering about using
libflashrom to write an EDI debugger (since, after all, EDI has access
to the whole external memory).
> > I haven't compared the datasheets of KB9012 and your KB, so I don't
> > know
> > if they are using exactly the same debug interface or it is
> > slightly different
> > (please check if there are differences, maybe you'll have to write
> > some code)
> >
> > I trust hardware flashing more than the software, especially your
> > current AMI BIOS setup
> > which isn't free software. Maybe the direct hardware flashing is
> > also
> > possible for you
>
> 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.
> > 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!
Cheers,
Paul
> > On Mon, Feb 5, 2018 at 9:47 PM, Youness Alaoui
> > <kakaroto(a)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.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
> > > <hanetzer(a)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(a)coreboot.org
> > > > https://mail.coreboot.org/mailman/listinfo/coreboot
> > >
> > > --
> > > coreboot mailing list: coreboot(a)coreboot.org
> > > https://mail.coreboot.org/mailman/listinfo/coreboot
> >
> > --
> > coreboot mailing list: coreboot(a)coreboot.org
> > https://mail.coreboot.org/mailman/listinfo/coreboot
--
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/
Hi everyone
Since here are the most skilled professions I've seeing I believe someone
can help me.
I have a Lenovo x230, and I'll would like to install coreboot in it to
start to understand how it works, and in future start to help the
community, as soon as I have the knowledge for that.
Last week I did a test that makes my progress stop.
Just for fun, and to check how the commercial bios works, I connected a
postcard on the wireless slot (as far as I know this is a pcie slot).
I already did that with other notebooks I have and nothing wrong happened.
The problem is that this time, with this x230, after I connected the
postcard and turned the system on, the system stopped to boot. And the post
card does not stop at a specific post code.
What happens now, is that every time I turn the system on, the battery led
blinks 3 times, being two blinks followed by a 1 second stop and after that
the last blink, and the system reboots.
The post card I'm using is this:
https://www.ebay.com/itm/3in1-Mini-PCI-E-PCI-LPC-Tester-PC-Desktop-Diagno...
So my questions are:
-Does someone believe this postcard could have bricked the system? (Why?)
-Any idea about how to solve that?
My next test will be to write a coreboot build at this system using
buspirate, but since I'll only have time for this next week, I would like
to have some things to think about, this is why I sent this e-mail before
doing the coreboot flash test.
Any comment will be helpful.
Thanks and Regards
Rafael R. Machado
Hi,
I've upgraded my coreboot to tag 4.7. As a payload I use SeaBIOS. I want to use the new feature of serial communication from SeaBIOS. The issue I have is that there's only serial output (meaning I can see the SeaBIOS menu on serial), but pressing any key on keyboard via serial doesn't do anything - I can only control SeaBIOS via keyboard plugged directly to the board, not via serial.
Does anyone have the same issue? I use AsRock E350M1 board. I didn't create a custum SeaBIOS config, I just use the default one.
--
________________________
/ Accordion, n.: \
| |
\ A bagpipe with pleats. /
------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
I am contemplating the purchase of an ASUS PIKE for my KGPE-D16 and I
was wondering if anyone here knows if it is possible to externally
re-flash them.
I notice a SOIC-8 chip on the front of the card and I imagine the
firmware is there, does it entail simply hooking up a test clip and
using flashrom as one would with a motherboard?
....20% chance the manufacturers utility performs some type of secret
sauce that is required for it to function.
When cross compiling inteltool with musl-libc the <sys/io.h> header
is not included due to this test in inteltool.h:
#if defined(__GLIBC__)
#include <sys/io.h>
#endif
Unfortunately I'm not sure what the right test is here, since
the musl libc team is opposed to having a __MUSL__ define:
http://openwall.com/lists/musl/2013/03/29/13
--
Trammell
On 02/14/2018 01:40 AM, Gergely Kiss wrote:
> Maybe the best way to see this is to try virtualizing some hardware?
Coreboot AGESA used on AM1 doesn't support IOMMU :[ and of course the
default bios doesn't either. There is no IOMMU device in lspci/dmesg so
passing hardware doesn't work.
I know other coreboot AGESA fam16 platforms support it so I imagine it
can't be that difficult for someone to add, but I do not have the skills
to do this especially without the documentation.
This would be a nice little embedded server board if it had IOMMU.
Thanks for your information!
Has anyone figured out if the AM1 platform has IOMMU? the OEM bios on
the AM1ML has an option for it but it doesn't work.
The lack of that is really disappointing.
I am also unable to locate the spec sheets for the AM1 platform that
would confirm this.
