Hi Cheng,
On 25.07.2016 04:33, cheng yichen wrote:
> Hi all
>
> After i follow kontron/ktqm77 setting. I can't solve the issue.
> I try to change iqr(for com1) to 5 or 6. but system can't print linux
> message and minicom is not workable.
Can you confirm that you see the full coreboot log on you
Hi Cheng,
On 22.07.2016 12:14, cheng yichen wrote:
> Hi all
>
> My platform is braswell SOC with W83627dhg superIO. In post stage I can get
> debug message over w83627 uart1(3f8/irq4). but after boot to linux, uart
> port is not woarkable. I test the function by minicom but I can't receive
> and
On 07.06.2016 16:40, Patrick Rudolph wrote:
> On 2016-06-06 09:58 PM, ron minnich wrote:
>> On Mon, Jun 6, 2016 at 12:52 PM Patrick Rudolph
>> wrote:
>>
>>> To summarize:
>>> The easy way is to use 2G.
>>> The preferred way would be to mimic mrc behaviour and reboot after
>>> finding the correct s
On 08.06.2016 04:26, Naveed Ghori wrote:
> Thanks Nico,
> What options should I be looking to tune? 3Gig should be fine as that
> is what I have seen in another product.
>
This depends heavily on the used hardware platform. I don't think all of
them have an option in coreboot. But it might be just
Hello Naveed,
On 07.06.2016 07:21, Naveed Ghori wrote:
> But I should still see 4GB without any patch. Right?
no, I'm afraid not.
> Windows only see 1.92GB as “Installed Memory (RAM)” in Control Panel->System.
This is correct as the 4GiB address space is not only used for RAM but
shared with othe
On 06.06.2016 23:40, Kyösti Mälkki wrote:
> On Mon, Jun 6, 2016 at 10:36 PM, ron minnich wrote:
>> I'm getting the sense here that reasonably modern CPUs can easily handle the
>> 2G hole. From what I've seen, it would not cause trouble for older CPUs
>> because they're most likely to be in small s
Hi Daniel,
On 03.05.2016 00:47, Daniel Kulesz via coreboot wrote:
> Hi all,
>
> On Mon, 2 May 2016 13:16:15 +0200
> Nico Huber wrote:
>> Regarding C3/C4 support, AFAIK, we implemented it fully but it just
>> didn't work on the system we originally ported coreboot
3, 0x02, 300,
{ ACPI_ADDRESS_SPACE_FIXED, 1, 2, { 1 }, 0x20, 0 }
},
for C3 or
{
/* acpi C3 / cpu C4 */
3, 0x02, 300,
{ ACPI_ADDRESS_SPACE_FIXED, 1, 2, { 1 }, 0x30, 0 }
},
for C4. You can not have all of them
On 01.05.2016 21:40, Daniel Kulesz wrote:
> Hi again,
>
> I did some more experiments with the vendor BIOS and made the following
> observations:
>
> - disabling "cpu power management" makes the idle consumption raise to 12,8W
Is this 12.8W compared to 7.5W (i.e. with lowest backlight)?
> - disa
On 01.05.2016 15:30, Daniel Kulesz wrote:
> Hi Nico,
>
>> On 01.05.2016 12:26, Daniel Kulesz via coreboot wrote:
>>> Coreboot with idle=poll: 15,8W
>>> Coreboot running "stress": 37,2W
>> well, this is what I would expect from the specs.
>>
>>> Vendor BIOS with idle=poll: 15W
>>> Vendor BIOS with
Hi Daniel,
On 01.05.2016 12:26, Daniel Kulesz via coreboot wrote:
> Coreboot with idle=poll: 15,8W
> Coreboot running "stress": 37,2W
well, this is what I would expect from the specs.
> Vendor BIOS with idle=poll: 15W
> Vendor BIOS with intel_pstate=disabled: 10W
> Vendor BIOS running "stress": 2
Hi Daniel,
first thing: We never got to the deepest processor sleep states (C3, C4)
when we originally ported coreboot for the GM45 chipset. But we didn't
see a difference in power consumption back then on the Roda/RK9.
On 01.05.2016 00:55, Daniel Kulesz via coreboot wrote:
> No tweaking with pow
6346 bytes (865
>> KB)@0x0]; too big?
> This is indicates a 865K image. How is that supposed to fit?
you also stripped:
fallback/payload 0x1b140payload 769955
I guess he means that a fresh build with a bigger (865KiB instead of
752KiB) payload fails.
Nico
--
M.
n't know how to change the offsets. Some might not be chosen
arbitrarily at all. But maybe there is another simple option: Did you
already try to increase the size of your CBFS (CONFIG_CBFS_SIZE)? It
may be as large as the "bios" partition of your flash chip.
Hope that helps,
Nico
On 08.02.2016 12:10, Patrick Georgi via coreboot wrote:
> 2016-02-04 10:35 GMT+01:00 Patrick Georgi :
>> during the review of some commits that are in the process of being
>> upstreamed from Chrome OS, people noticed that chipset drivers like to
>> define their own TRUE/FALSE defines (sometimes pre
On 04.02.2016 10:35, Patrick Georgi via coreboot wrote:
> I think we should seek uniformity here: decide on some style,
> recommend it, clean up the tree to match, and help people stay
> consistent through lint tests.
That's a good idea.
> 2. BIT16 vs BIT(16) vs (1 << 16) vs 0x1
> I don't thin
On 04.02.2016 22:25, Patrick Georgi via coreboot wrote:
> 2016-02-04 22:22 GMT+01:00 Martin Roth :
>> I don't think we need redefinitions of TRUE/FALSE
> We have no canonical definitions for TRUE/FALSE right now.
> Contributions that use them (for whatever reason) tend to bring local
> copies, and
On 12.11.2015 04:37, Patrick 'P. J.' McDermott wrote:
> On 2015-11-11 16:50, Nico Huber wrote:
>> 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
Hi,
had a look at your logs:
On 11.11.2015 00:49, Patrick 'P. J.' McDermott wrote:
> These systems fail to resume in one of the following ways:
>
> * S3 resume (indicated by the SLP_TYP bit) is detected, SLP_TYP is
> cleared, DRAM receive-enable calibration fails with a timing
> under/
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 (roda/rk
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
don'
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
On 23.10.2015 21:54, Aaron Durbin wrote:
> On Fri, Oct 23, 2015 at 2:43 PM, Carl-Daniel Hailfinger
> wrote:
>> On 23.10.2015 21:15, Martin Roth wrote:
>>> I like what I understand Nico's proposal to be: Store the SPD data as
>>> a c struct with all of the different JEDEC fields broken out. it
>>>
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. We
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 at
Am 16.04.2015 15:12, schrieb gerrit code review:
> From Nico Huber :
>
> 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 it
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
Am 28.08.2015 17:51, schrieb Patrick Georgi:
> 2015-08-28 17:35 GMT+02:00 Nico Huber :
>> 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,
al problem 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 A
. bootloaders 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 /
. bootloaders 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 /
comes 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
On 14. Oktober 2014 01:26:37 MESZ, Peter Stuge 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
Hi,
looks like I don't have an account for the coreboot wiki, yet.
Well, at least I don't remember, and can't find any stale email...
Nico
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
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 refact
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 8414d3c0b407d9afc6a2446dba3ca358da2c
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
> Date: Thu Oct 10 12:44:11 2013 -0500
>
> xcompile: always use -m
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
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
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 s
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
latt
quot; model there are no problems, everything works well with VGA
> Bios.
>
> Thank you
> Best regards, Dmitry Bagryanskiy.
>
--
M. Sc. Nico Huber
Berater, SINA-Softwareentwicklung
Public Sector
secunet Security Networks AG
Tel.: +49-201-5454-3635, Fax: +49-201-54
0x001c03e1);
> GEN*_DEC should not be set to com* 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 po
d what you 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-2
gation. I
can't currently work 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
Maybe you should also try to reset your 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
Me
t the RK9 is most 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
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
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
Dear coreboot folks,
I'm looking forward to write a port for my Ivy Bridge desktop system based
on this board: Intel DH77EB (codenamed Eb Lake, [1]). It comes with the H77
platform controller hub (PCH) and a Winbond W83677HG super I/O chip (build
by Nuvoton as NCT6775F, [2]). I'm using it with a C
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
>>>
Hello Paul,
Am 27.03.2013 14:04, schrieb Paul Menzel:
> Dear coreboot folks,
>
>
> using latest master
>
> commit 3cc0d1eb3f611cb7bf0e45d8ccdb0c84f54f54dc
> Author: David Hendricks
> Date: Tue Mar 26 16:28:21 2013 -0700
>
> exynos5250: assign RAM
>
> 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
801 - 855 of 855 matches
Mail list logo
