No hint, anyone?
On Wed, Dec 02, 2009 at 03:44:15PM +0100, Daniel Mack wrote:
On Wed, Dec 02, 2009 at 02:59:01PM +0100, Peter Stuge wrote:
Daniel Mack wrote:
the effect is harder to trigger when booting from an external LPC
flash emulator (in contrast to coreboot flashed to the internal
Hi Ron,
thanks for your answer.
On Fri, Dec 04, 2009 at 09:03:14AM -0800, ron minnich wrote:
On Fri, Dec 4, 2009 at 8:47 AM, Daniel Mack dan...@caiaq.de wrote:
No hint, anyone?
Just about every time I had this problem on my geodes it was a problem
with dram. Just about every time. It's
I'm sure this has been discussed on this list already, but I couldn't
find a comprehensive statement in the archives yet. If there is one, I
would be happy to be pointed there.
It seems that the coreboot-v3 tree has now been obsoleted by coreboot
and hasn't seen any update anymore since August
(sorry I can't post a proper reply message, I picked that up from the
archives)
Nathan Williams nathan at traverse.com.au wrote:
I am suspicious that the reset problem only occurs when I'm using a
laptop hard drive off the 44pin IDE connector on our board. I have tried
booting with a 3.5
On Wed, Dec 02, 2009 at 02:59:01PM +0100, Peter Stuge wrote:
Daniel Mack wrote:
the effect is harder to trigger when booting from an external LPC
flash emulator (in contrast to coreboot flashed to the internal
LPC).
Then you could experiment with a few different flash chips.
PC
On Tue, Oct 06, 2009 at 02:49:08AM +0200, Daniel Mack wrote:
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
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 too
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
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
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 OHCI code
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
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 some
On Wed, Sep 23, 2009 at 01:25:21PM -0400, Tom Sylla wrote:
On Wed, Sep 23, 2009 at 1:10 PM, Daniel Mack dan...@caiaq.de 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
Here comes a set of six patches to support OHCI controllers in
libpayload.
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
This is needed by the OHCI stack.
Signed-off-by: Daniel Mack dan...@caiaq.de
---
drivers/usb/usb.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/usb.c b/drivers/usb/usb.c
index 4a0dbad..c08de54 100644
--- a/drivers/usb/usb.c
+++ b/drivers/usb/usb.c
Signed-off-by: Daniel Mack dan...@caiaq.de
---
include/usb/usb.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/usb/usb.h b/include/usb/usb.h
index c3c5f19..95cbdae 100644
--- a/include/usb/usb.h
+++ b/include/usb/usb.h
@@ -29,6 +29,7 @@
#ifndef __USB_H
Signed-off-by: Daniel Mack dan...@caiaq.de
---
include/i386/arch/endian.h| 11 +++
include/powerpc/arch/endian.h | 14 --
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/include/i386/arch/endian.h b/include/i386/arch/endian.h
index a50ac1f..743787f
Signed-off-by: Daniel Mack dan...@caiaq.de
---
drivers/usb/ohci_dbg.c | 297
1 files changed, 297 insertions(+), 0 deletions(-)
create mode 100644 drivers/usb/ohci_dbg.c
diff --git a/drivers/usb/ohci_dbg.c b/drivers/usb/ohci_dbg.c
new file mode
, but heavily cleaned up and
adopted to the libpayload USB stack API.
It is not tested for endianess but currently works on LE machines only.
Thanks to Leandro Dorilex for his initial work on this.
Signed-off-by: Daniel Mack dan...@caiaq.de
Thanks-to: Leandro Dorilex ldori...@gmail.com
On Mon, Oct 05, 2009 at 10:44:42AM +0800, Daniel Mack wrote:
Here comes a set of six patches to support OHCI controllers in
libpayload.
Forgot to mention that the last upstream commit was r4499.
Daniel
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo
On Wed, Sep 23, 2009 at 06:03:38AM +0200, Daniel Mack wrote:
On Tue, Sep 22, 2009 at 01:56:53PM +0200, Peter Stuge wrote:
Check out the 5536 data book on Atomic Bit Programming and/or look
at the Linux LED driver for reference. To program the GPIOs you have
to follow the algorithm
On Wed, Sep 23, 2009 at 11:43:02AM +0200, Stefan Reinauer wrote:
Daniel Mack wrote:
buildrom does not currently build filo due to a missing include path.
This fixes it.
---
Index: Makefile
===
--- Makefile
the machine to reboot.
Below is a fix for that.
Signed-off-by: Daniel Mack dan...@caiaq.de
Index: fs/fsys_ext2fs.c
===
--- fs/fsys_ext2fs.c(revision 105)
+++ fs/fsys_ext2fs.c(working copy)
@@ -253,10 +253,18 @@
((char *)((char
On Wed, Sep 23, 2009 at 06:04:57PM +0200, Peter Stuge wrote:
Myles Watson wrote:
Also, when booting Linux, the LED driver does not work with
coreboot for me.
The issue is that the driver is using a hard coded base address
rather than finding out what is actually programmed into
Hi,
I'm developing on a CS5536 based board (ALIX.2D) and I'm trying to get
access to the GPIO registers in order to set the LEDs on bootup.
However, I seem to miss an mandatory point when trying so. As a quick
hack, I added these lines to the end of southbridge_init() in
buildrom does not currently build filo due to a missing include path.
This fixes it.
---
Index: Makefile
===
--- Makefile(revision 94)
+++ Makefile(working copy)
@@ -76,7 +76,7 @@
LIBGCC = $(shell $(CC) $(CFLAGS)
On Tue, Sep 22, 2009 at 01:56:53PM +0200, Peter Stuge wrote:
Daniel Mack wrote:
I'm developing on a CS5536 based board (ALIX.2D) and I'm trying to
get access to the GPIO registers in order to set the LEDs on
bootup.
Check out the 5536 data book on Atomic Bit Programming and/or look
27 matches
Mail list logo
