Daniel Mack wrote:
> http://lkml.org/lkml/2009/10/5/426
>
> Works fine here - let's see what the maintainers say.
gpio_base should maybe be 16 bit.
I'm not sure if strchr() can be assumed to work with '\0'.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mai
Author: stuge
Date: 2009-10-06 05:10:00 +0200 (Tue, 06 Oct 2009)
New Revision: 107
Modified:
trunk/filo/main/filo.c
Log:
Fix build with CONFIG_AUTOBOOT_DELAY=0
ESC is always checked, so print the prompt even if there's no delay.
Modified: trunk/filo/main/filo.c
==
On Wed, Sep 23, 2009 at 01:25:21PM -0400, Tom Sylla wrote:
> On Wed, Sep 23, 2009 at 1:10 PM, Daniel Mack wrote:
> > Could you outline which steps would need to be taken in order to find
> > out the correct address to use? Any maybe a way to sany detect the
> > precence of that function on the boa
On Mon, Oct 05, 2009 at 02:15:16PM +0200, Peter Stuge wrote:
> Daniel Mack wrote:
> > I can't change the license as I'm not the author of the original
> > sources.
>
> You could try contacting the author, assuming you yourself would be
> comfortable using BSD for your work, if they are.
There are
Hello!
Am I too late to comment?
I am willing to go either way regarding an appropriate method. Both methods
actually do work for me.
For example I was able to check out the utility programs using the method
Uwe proposed in a later e-mail concerning what can happen, and I've also
managed to update
On 10/05/2009 03:57 PM, Joseph Smith wrote:
Hello,
I keep getting stuck running the crossgcc shell script. It keeps getting
stuck on GDB, complaining about no make rule for "install" and then exits.
Attached is the log, any ideas?
Got it, needed ncurses-devel.
--
Thanks,
Joseph Smith
Set-Top-
Am Montag, den 05.10.2009, 20:46 +0800 schrieb feng shu:
> is it mean than the v3 will dispear after its features merge back into
> v2 and the default is v2 in long time?
That's the plan, yes.
Regards,
Patrick Georgi
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailm
Carl-Daniel Hailfinger wrote:
> On 05.10.2009 16:07, Stefan Reinauer wrote:
>
>> Hi,
>>
>> we're happy to release coreboot® support for another Kontron embedded
>> mainboard: The Kontron KT690/mITX
>>
>> http://us.kontron.com/products/boards+and+mezzanines/embedded+motherboards/miniitx+motherboa
#131: New flashrom motherboard support
+---
Reporter: anonymous| Owner: somebody
Type: enhancement |Status: closed
Priority: trivial | Milestone: flashrom
On 05.10.2009 15:51, Anthony Liguori wrote:
> Carl-Daniel Hailfinger wrote:
>> What about SeaBIOS + CSM (based on DUET)?
>
> That's not quite the same thing.
>
> In EFI, CSM is a specification that defines how to port a legacy BIOS
> such that it runs as basically an EFI module providing the old le
On 05.10.2009 16:07, Stefan Reinauer wrote:
> Hi,
>
> we're happy to release coreboot® support for another Kontron embedded
> mainboard: The Kontron KT690/mITX
>
> http://us.kontron.com/products/boards+and+mezzanines/embedded+motherboards/miniitx+motherboards/kt690mitx.html
>
> This patch adds (ini
Carl-Daniel Hailfinger wrote:
> On 05.10.2009 14:56, Stefan Reinauer wrote:
>
>> Peter Stuge wrote:
>>
>>
another course of action (eg. moving the tools into the coreboot v2
repository, so everyone gets them),
>>> No - please don't do that. W
<>--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Author: uwe
Date: 2009-10-05 15:55:28 +0200 (Mon, 05 Oct 2009)
New Revision: 4726
Modified:
trunk/coreboot-v2/Makefile
trunk/coreboot-v2/src/Kconfig
Log:
Backport facility to specify a local coreboot version suffix from v3.
Tested on QEMU.
Signed-off-by: Uwe Hermann
Acked-by: Uwe Hermann
On 05.10.2009 15:03, Anthony Liguori wrote:
> Stefan Reinauer wrote:
>> Anthony Liguori wrote:
>>
>>> Patrick Georgi wrote:
>>>
With coreboot, seabios and Duet, it should be reasonably simple to
provide a single BIOS image that selects (based on nvram - ie.
configuration) which
Patrick Georgi wrote:
Am Sonntag, den 04.10.2009, 14:31 -0500 schrieb Anthony Liguori:
I don't know enough about EFI, but my concern is that down the road,
hardware devices will start to exist that require EFI because they
implement EFI modules and not legacy option ROMs. In order to suppor
Stefan Reinauer wrote:
> > No - please don't do that. We're trying to make them separate, not
> > put them back in again.
>
> For the following utilities it does not make sense to keep them
> separate:
>
> * nvramtool
> * superiotool
> * getpir
> * mptable
> * inteltool
> * ectool
> and maybe als
On 05.10.2009 14:56, Stefan Reinauer wrote:
> Peter Stuge wrote:
>
>>> another course of action (eg. moving the tools into the coreboot v2
>>> repository, so everyone gets them),
>>>
>>>
>> No - please don't do that. We're trying to make them separate, not
>> put them back in again.
Stefan Reinauer wrote:
Anthony Liguori wrote:
Patrick Georgi wrote:
With coreboot, seabios and Duet, it should be reasonably simple to
provide a single BIOS image that selects (based on nvram - ie.
configuration) which interface to provide: PCBIOS or UEFI.
That isn't terribly
Author: oxygene
Date: 2009-10-05 14:58:48 +0200 (Mon, 05 Oct 2009)
New Revision: 4725
Modified:
trunk/coreboot-v2/util/
Log:
Remove svn:externals that pull in all kinds of useful tools that
are not needed for building coreboot.
The website tells you where to get them individually.
Signed-off-
Peter Stuge wrote:
>> another course of action (eg. moving the tools into the coreboot v2
>> repository, so everyone gets them),
>>
>
> No - please don't do that. We're trying to make them separate, not
> put them back in again.
>
>
For the following utilities it does not make sense to kee
Carl-Daniel Hailfinger wrote:
> On 05.10.2009 13:58, Stefan Reinauer wrote:
>
>> Without these fixes the w83627dhg driver (which is currently not used by any
>> mainboard in the tree) does neither compile nor work.
>>
>> Signed-off-by: Stefan Reinauer
>>
>>
>
> Can't break anything, fix
On Mon, Oct 05, 2009 at 02:27:51PM +0200, Peter Stuge wrote:
> Patrick Georgi wrote:
> > after a quick poll on IRC on what to do with the svn:externals in util/,
> > we pretty much agreed that removing them is the way to go.
>
> Acked-by: Peter Stuge
Acked-by: Uwe Hermann
> > another course
Hello every:
I find some words in coreboot wiki:
>coreboot v3 was an experimental development tree of coreboot which should not
>be used anymore (there are only very few >exceptions)! Most features from v3
>are gradually being merged back into v2.
is it mean than the v3 will dispear after its
Patrick Georgi wrote:
> after a quick poll on IRC on what to do with the svn:externals in util/,
> we pretty much agreed that removing them is the way to go.
Acked-by: Peter Stuge
> another course of action (eg. moving the tools into the coreboot v2
> repository, so everyone gets them),
No - p
Daniel Mack wrote:
> I can't change the license as I'm not the author of the original
> sources.
You could try contacting the author, assuming you yourself would be
comfortable using BSD for your work, if they are.
> Up to you to decide then :)
libpayload must stay BSD.. My guess is that your w
Author: stepan
Date: 2009-10-05 14:08:37 +0200 (Mon, 05 Oct 2009)
New Revision: 4724
Modified:
trunk/coreboot-v2/src/superio/winbond/w83627dhg/superio.c
trunk/coreboot-v2/src/superio/winbond/w83627dhg/w83627dhg.h
Log:
Without these fixes the w83627dhg driver (which is currently not used by a
On 05.10.2009 14:04, Stefan Reinauer wrote:
> Patrick Georgi wrote:
>
>> Hi,
>>
>> after a quick poll on IRC on what to do with the svn:externals in util/,
>> we pretty much agreed that removing them is the way to go.
>>
>> People who need those tools can still fetch them at the original
>> loca
Patrick Georgi wrote:
> Hi,
>
> after a quick poll on IRC on what to do with the svn:externals in util/,
> we pretty much agreed that removing them is the way to go.
>
> People who need those tools can still fetch them at the original
> location in the repository, and already checked out trees will
On 05.10.2009 13:58, Stefan Reinauer wrote:
> Without these fixes the w83627dhg driver (which is currently not used by any
> mainboard in the tree) does neither compile nor work.
>
> Signed-off-by: Stefan Reinauer
>
Can't break anything, fixes stuff for you. Clear winner.
Acked-by: Carl-Daniel
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: i...@coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
Without these fixes
Hi,
after a quick poll on IRC on what to do with the svn:externals in util/,
we pretty much agreed that removing them is the way to go.
People who need those tools can still fetch them at the original
location in the repository, and already checked out trees will continue
to carry those directori
Joseph Smith wrote:
> I will test this out as soon as I can get crossgcc to work (I think I am
> having hardware issues with the Linux box I am using right now). I wish we
> had a SerailICE svn repo for these fixes (even a private one), Stefan???
>
>
We have a private one.
Stefan
--
The wo
On Sun, 04 Oct 2009 21:40:48 +0200, Rudolf Marek
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all
>
> During the weekend train trips I managed to get serialICE 1.2 working
with
> the
> XMM stack (in qemu).
>
> There were some gotchas:
>
> #1 missing SSE enable
> #2 missin
Author: stepan
Date: 2009-10-05 12:23:36 +0200 (Mon, 05 Oct 2009)
New Revision: 4723
Modified:
trunk/util/msrtool/darwin.c
Log:
fix building on Linux again, working around crude runtime OS detection.
Signed-off-by: Stefan Reinauer
Acked-by: Stefan Reinauer
Modified: trunk/util/msrtool/dar
When developing the OHCI stack, I stumbled over two things in the
libpayload USB stack which I didn't want to leave unmentioned.
1. The MSC driver issues BULK messages to its devices with 0 bytes in
length. That is, in fact, a vliad operation according to the USB
standard, but mass storage devices
On Mon, Oct 05, 2009 at 10:56:07AM +0200, Carl-Daniel Hailfinger wrote:
> On 05.10.2009 10:45, Daniel Mack wrote:
> > On Mon, Oct 05, 2009 at 10:30:39AM +0200, Patrick Georgi wrote:
> >
> >> If so, I'd assume that's the primary user of USB functionality in
> >> libpayload, and we could stuff the
On 05.10.2009 10:45, Daniel Mack wrote:
> On Mon, Oct 05, 2009 at 10:30:39AM +0200, Patrick Georgi wrote:
>
>> If so, I'd assume that's the primary user of USB functionality in
>> libpayload, and we could stuff the OHCI code there - but using the
>> libpayload interfaces, so the code changes wer
On Mon, Oct 05, 2009 at 10:30:39AM +0200, Patrick Georgi wrote:
> Am Montag, den 05.10.2009, 10:23 +0200 schrieb Daniel Mack:
> > Ok, I can't judge that. And I can't change the license as I'm not the
> > author of the original sources. Up to you to decide then :)
> Just curious, what are you using
Am Montag, den 05.10.2009, 10:23 +0200 schrieb Daniel Mack:
> Ok, I can't judge that. And I can't change the license as I'm not the
> author of the original sources. Up to you to decide then :)
Just curious, what are you using libpayload for, FILO?
If so, I'd assume that's the primary user of USB
On Mon, Oct 05, 2009 at 10:14:19AM +0200, Patrick Georgi wrote:
> Am Montag, den 05.10.2009, 09:55 +0200 schrieb Daniel Mack:
> > The code is derived from GPL'ed sources, so it's GPL, yes. But quoting
> > from the LICENSES file:
> >
> > The copyright on libpayload is owned by various individual
Am Montag, den 05.10.2009, 09:55 +0200 schrieb Daniel Mack:
> The code is derived from GPL'ed sources, so it's GPL, yes. But quoting
> from the LICENSES file:
>
> The copyright on libpayload is owned by various individual developers
> and/or companies. Please check the individual source files
On Mon, Oct 05, 2009 at 09:51:22AM +0200, Patrick Georgi wrote:
> Am Montag, den 05.10.2009, 10:44 +0800 schrieb Daniel Mack:
> > This work was originally started by Leandro Dorilex and we worked
> > together on this. However, his first approach to develop everything from
> > scratch was a little t
Am Montag, den 05.10.2009, 10:44 +0800 schrieb Daniel Mack:
> This work was originally started by Leandro Dorilex and we worked
> together on this. However, his first approach to develop everything from
> scratch was a little too ambitious and so we decided to take an existing
> stack from U-Boot (
44 matches
Mail list logo
