Hi,
On 11.11.2015 00:49, Patrick 'P. J.' McDermott wrote:
> I've been looking into S3 resume on GM45 mainboards, which often fails
> in rather interesting ways.
Well, the S3 support wasn't really tested during GM45 development. Maybe
it's just plainly broken. My development system at work
Hi Andrei,
your patch looks good generally, but the check is off by one. It's
obvious, we want to have sane checking there. Reading from a random
address can cause trouble and 0x is not the only offending
address.
On x86, the cbfs is mapped right below the 4GiB line. Current machines
On 23.10.2015 18:32, Martin Roth wrote:
>> So, is there a third option that I'm missing? Other opinions?
The third option would be a plain text format which is easy to parse
but still covers the spec well.
>
> I'd say that we should store the SPDs as binaries - these are easy to
> use
Hi all,
On 23.10.2015 17:23, Patrick Georgi wrote:
> I see essentially two ways out of this, before we can start reducing
> duplication across the tree in that area:
> [...]
Neither of your options tackles the real problem. That is: We have
interfaces that use binary SPD data. It's just stupid.
On 24.10.2015 00:37, Alex G. wrote:
> On 10/23/2015 01:59 PM, Nico Huber wrote:
>> Thanks for the support. One remark: I would really prefer serializing
>> during runtime
>
> Why waste runtime cycles (and code space) doing something you can
> already do at build time?
I
Am 16.04.2015 15:12, schrieb gerrit code review:
> From Nico Huber <nic...@gmx.de>:
>
> Nico Huber has posted comments on this change.
>
> Change subject: coreboot_table: don't add CMOS checksum twice.
> ..
On 29.08.2015 14:09, Peter Stuge wrote:
ron minnich wrote:
and I still think it belongs in the tree.
No way.
This is a library of device drivers. It has no place whatsoever as a
subdirectory lost somewhere in the already too big coreboot repository.
libsparkhw needs to live in its own
On 29.08.2015 21:58, ron minnich wrote:
If people feel strongly enough about this then we can do an external repo
for now.
Either way around, we would have to learn how to best integrate SPARK
code in coreboot. There would still be some steps to go from linking
with an adalib, to SPARK beeing a
and such, and of course our own
products where the code stems from).
We have discussed the licensing and will push this under GPLv2 + later
if there are no reasonable concerns.
Nico
--
M. Sc. Nico Huber
Senior Berater SINA-Softwareentwicklung
Netzwerk- Client-Sicherheit / Network Client Security
and such, and of course our own
products where the code stems from).
We have discussed the licensing and will push this under GPLv2 + later
if there are no reasonable concerns.
Nico
--
M. Sc. Nico Huber
Senior Berater SINA-Softwareentwicklung
Netzwerk- Client-Sicherheit / Network Client Security
was that libpayload resides in
it's own repository. But having simple device drivers in it's own place
seems to be a good idea, for me.
Anyway, I'll push it next week (I guess) when the code got cleared.
Nico
ron
On Fri, Aug 28, 2015 at 4:55 AM Nico Huber nico.hu...@secunet.com wrote:
Am 21.08.2015
Am 28.08.2015 17:51, schrieb Patrick Georgi:
2015-08-28 17:35 GMT+02:00 Nico Huber nico.hu...@secunet.com:
I don't know if the real problem was that libpayload resides in
it's own repository.
libpayload still shares a repo with coreboot. There were ideas to
separate them, but that never
the disclaimer: Supporting the upstreaming of this code
may result in further development in Ada (currently I only have simple
device drivers in mind). I hereby wash my hands of any damage that may
arise from that :P
Nico
--
M. Sc. Nico Huber
Senior Berater SINA-Softwareentwicklung
Netzwerk- Client
On 14. Oktober 2014 01:26:37 MESZ, Peter Stuge pe...@stuge.se wrote:
Nico Huber wrote:
I had first success with my pomona clip, today. Sadly, the mobo does
not have any UART,
What board is it?
A Haswell ThinkPad (T440s).
so I'll finally have to switch to something more advanced.
Is LPC
Hi folks,
I had first success with my pomona clip, today. Sadly, the mobo does
not have any UART, so I'll finally have to switch to something more
advanced. I've a high-speed ftdi usb adapter board that can be used
as USB debug device, but this will need some code changes along with
some
Hello Vipin,
Can you please suggest a solution and let me know why CONFIG_USB is removed
from my .config
The prefix for libpayload's configurations options changed to CONFIG_LP_,
lately. The last commit for FILO (60d45fc) tried to fix it, but seems to
have missed some options. So CONFIG_USB is
On 12.10.2014 18:21, Vipin Gahlaut wrote:
Logs for the problem I am getting repeatedly at run time
change on port 1
fullspeed device
first get_descriptor(DT_DEV) failed
set_address failed
That's exactly what I observed on a kontron/986lcd-m (i945) with low-
speed devices connected to the
Hi folks,
something seems wrong with this one:
On 25.08.2014 23:33, ger...@coreboot.org wrote:
the following patch was just integrated into master:
commit 8414d3c0b407d9afc6a2446dba3ca358da2c7bb6
Author: Aaron Durbin adur...@chromium.org
Date: Thu Oct 10 12:44:11 2013 -0500
On 12.10.2014 22:45, Peter Stuge wrote:
Nico Huber wrote:
something seems wrong with this one:
On 25.08.2014 23:33, ger...@coreboot.org wrote:
the following patch was just integrated into master:
commit 8414d3c0b407d9afc6a2446dba3ca358da2c7bb6
Author: Aaron Durbin adur...@chromium.org
Date
Hi folks,
I haven't followed the previous discussion on this matter, so one
question: Is this a coreboot issue? If this noise doesn't occur with
the vendor firmware, has anybody checked if coreboot uses the same
power management timing settings? (e.g. C4-TIMING_CNT, see [1], there
might be more
On 18.04.2014 16:49, ron minnich wrote:
Can somebody give me a sanity check? I can't see the error with the macro.
I won't say too much here -- just take a look. I'm not convinced the
code is wrong.
Well, I'm convinced :P
Have a closer look at the placement of the space. It was next to the
Bagryanskiy.
--
M. Sc. Nico Huber
Berater, SINA-Softwareentwicklung
Public Sector
secunet Security Networks AG
Tel.: +49-201-5454-3635, Fax: +49-201-5454-1325
E-Mail: nico.hu...@secunet.com
Mergenthalerallee 77, 65760 Eschborn, Deutschland
www.secunet.com
are doing.
Current code sets this to 0x000c0601, bits 16, 17 are reserved and bit
20 should IIRC only help with addresses from 0x610 to 0x61f.
Nico
--
M. Sc. Nico Huber
Berater, SINA-Softwareentwicklung
Public Sector
secunet Security Networks AG
Tel.: +49-201-5454-3635, Fax: +49-201-5454-1325
E-Mail
* ports. Instead there are dedicated
bits for enabling decode of serial port ranges. Consult southbridge
documentation.
There are only dedicated settings for two COM ports. Looks like Dmitry
wants to enable a 3rd and 4th port.
Nico
--
M. Sc. Nico Huber
Berater, SINA-Softwareentwicklung
Public
on this, but if you like to bisect the problem:
I guess, commit 11a7db3 should be a working starting point.
Kind regards,
Nico
--
M. Sc. Nico Huber
Berater, SINA-Softwareentwicklung
Public Sector
secunet Security Networks AG
Tel.: +49-201-5454-3635, Fax: +49-201-5454-1325
E-Mail: nico.hu
likely not
what you want, being a 6kg ruggedized notebook.
ps: I did the same about the Getac P470 with the same results: nobody seems
to sell it.
I'd wonder if it's still sold.
Nico
Thank in advance,
ms
[1] http://roda-mildef.com/products/rugged-notebooks/rk9/
--
M. Sc. Nico Huber
coreboot checkout
or even a fresh checkout if you did any changes.
Nico
--
M. Sc. Nico Huber
Berater, SINA-Softwareentwicklung
Public Sector
secunet Security Networks AG
Tel.: +49-201-5454-3635, Fax: +49-201-5454-1325
E-Mail: nico.hu...@secunet.com
Mergenthalerallee 77, 65760 Eschborn
Am 25.06.2013 23:08, schrieb Dmitry Bagryanskiy:
Hello Dmitry,
My processor type is Intel Core 2 Duo P8400, socket mFCPGA479M
IIRC, I've seen at least one RK9 with this CPU running coreboot.
Looking through your log files, I didn't find anything suspicious.
I'll try to check if current upstream
Am 25.06.2013 14:07, schrieb Dmitry Bagryanskiy:
Hello Dmitry,
welcome to the coreboot mailing list.
Could you please help me to solve some problems?
Laptop: Roda RK9
Socket: mPGA479M
The problem is that when loading coreboot, Unsupported FSB clock is
written in the debug and the circuit
Hello Paul,
Am 02.04.2013 11:12, schrieb Paul Menzel:
Am Sonntag, den 31.03.2013, 21:10 +0200 schrieb Paul Menzel:
Am Samstag, den 30.03.2013, 19:57 +0100 schrieb Nico Huber:
I'm looking forward to write a port for my Ivy Bridge desktop system based
on this board: Intel DH77EB (codenamed
Dear Paul,
Am 28.03.2013 12:37, schrieb Paul Menzel:
Am Mittwoch, den 27.03.2013, 20:49 +0100 schrieb Nico Huber:
Am 27.03.2013 14:04, schrieb Paul Menzel:
Dear coreboot folks,
using latest master
commit 3cc0d1eb3f611cb7bf0e45d8ccdb0c84f54f54dc
Author: David Hendricks
Hello Paul,
Am 27.03.2013 14:04, schrieb Paul Menzel:
Dear coreboot folks,
using latest master
commit 3cc0d1eb3f611cb7bf0e45d8ccdb0c84f54f54dc
Author: David Hendricks dhend...@chromium.org
Date: Tue Mar 26 16:28:21 2013 -0700
exynos5250:
I'm unable to get the USB keyboard to work in payloads.
I'm using it with libpayload, and configured libpayload to enable
the USB_HID, USB_OHCI, USB_EHCI, USB_UHCI, USB_XHCI drivers.
I call usb_initialize() in the early part of my payload.
Calls to usbhid_havechar() just return 0.
When
801 - 833 of 833 matches
Mail list logo
