On Thu, Jul 03, 2008 at 03:16:34AM +0200, Carl-Daniel Hailfinger wrote:
How do you feel about configure?
Well, the configure scripts i've seen in the past are completely
unreadable hideous blobs.
Yeah, they're generated by autoconf, from a pretty readable
configure.in file.
Just to be
#105: flashrom: add documentation files (ChangeLog etc) that need to be in the
release
+---
Reporter: stuge| Owner: somebody
Type: enhancement |Status: new
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
we tested the untested flash chip Winbond W25x80 with flashrom revision 3407.
Reading and Erasing the chip went okay, but we encountered an error on writing
back the previously read image. Please see the below output for further
information:
Hi Björn,
On Thu, Jul 03, 2008 at 11:38:12AM +0200, Gerhart, Bjoern wrote:
we tested the untested flash chip Winbond W25x80 with flashrom
revision 3407. Reading and Erasing the chip went okay,
Great!
but we encountered an error on writing back the previously read
image. Please see the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Peter,
thanks for your fast response.
On Thu Jul 3 12:19:21 CEST 2008, Peter Stuge wrote:
I've attached a kludge fix to disable
the offending code to the ticket:
http://tracker.coreboot.org/trac/coreboot/ticket/102
With this workaround the
Here's an old USB Debug Port presentation that may be useful to
those new to the concept:
http://www.usb.org/developers/presentations/pres0602/john_keys.pdf
Is the NET20DC really the only USB Debug Device available? I tried
searching for others, but didn't find any.
I think the
Hi Björn,
could you please test the attached patch as well? It's the final fix I
hope to commit.
Thanks!
Regards,
Carl-Daniel
Index: flashrom-tmp1/layout.c
===
--- flashrom-tmp1/layout.c (Revision 3407)
+++
#102: flashrom: coreboot ROM image file identification heuristic is broken
-+--
Reporter: stuge | Owner: somebody
Type: defect|Status: new
Priority:
#102: flashrom: coreboot ROM image file identification heuristic is broken
-+--
Reporter: stuge | Owner: somebody
Type: defect|Status: new
Priority:
Hello! (Duplicated message.)
Okay. Thank you folks for breaking down the complexity of this issue. I
didn't want to go into the complexity of that logic area that the parts are
wearing as I've been given to understand from reading the message traffic on
the Linux-USB regarding gadgets that this is
Improve coreboot image detection heuristic in flashrom. It's not
absolutely perfect, but the likelihood of this check to fail is
0.013 (1.3*10^-26) which is good enough for me.
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
Index: flashrom-tmp1/layout.c
#102: flashrom: coreboot ROM image file identification heuristic is broken
-+--
Reporter: stuge | Owner: somebody
Type: defect|Status: closed
On Thu, Jul 3, 2008 at 8:45 AM, Joseph Smith [EMAIL PROTECTED] wrote:
Well it looks like in the pdf presentation above they have a Serial-USB
debugger. It looks like a development board though because there are a
bunch of unnecessary stuff on it. I'm thinking a Serial-USB debugger is
the way
Hi Björn,
thanks for testing and confirming this. The patch has been committed to
the flashrom tree and everything should work out of the box for you.
We are very happy to see vendors use flashrom. If there are any
remaining issues, please tell us.
Best Regards,
Carl-Daniel
--
coreboot mailing
Hi Carl-Daniel,
at the moment we are in evaluation phase of flashrom. We test it on our
different mainboards and flash chips to check if it meets our needs, before it
comes to operation at the customer's side.
I'll tell you if we encounter further issues.
Best Ragards
Björn
-Original
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Tom Sylla
Sent: Thursday, July 03, 2008 10:56 AM
To: Joseph Smith
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; c-
[EMAIL PROTECTED]; coreboot@coreboot.org
Subject: Re: [coreboot] USB debug cables and
Kevin,
I must be missing something, because my boot fails with this message
on my s2892:
[...]
move mptable from 0x20 to 0xfc00, size 0xdff03e0
That message should never occur if one were to apply the patch in the
email from the url above. Basically, the mptabling moving should
Author: stuge
Date: 2008-07-03 18:54:05 +0200 (Thu, 03 Jul 2008)
New Revision: 3409
Modified:
trunk/util/flashrom/flashchips.c
Log:
flashrom: Winbond W25x80 TEST_OK PROBE READ ERASE WRITE
Per test report from Bj?\195?\182rn Gerhart. Thanks!
Signed-off-by: Peter Stuge [EMAIL PROTECTED]
Hi Björn,
On Thu, Jul 03, 2008 at 01:36:11PM +0200, Gerhart, Bjoern wrote:
I've attached a kludge fix to disable
the offending code to the ticket:
http://tracker.coreboot.org/trac/coreboot/ticket/102
With this workaround the write attempt works successfully (see
below), so in my
On Thu, Jul 03, 2008 at 11:41:10AM +0200, Peter Stuge wrote:
Yeah, they're generated by autoconf, from a pretty readable
configure.in file.
Just to be clear, I am not advocating autoconf+automake. I don't
think we need that.
Ack.
On Thu, Jul 03, 2008 at 01:48:33AM -0400, Corey Osgood
Hi,
On Sat, Jun 28, 2008 at 07:43:18PM +0200, Hannes Hegewald wrote:
hey, here's the 'lspci -tvnn', 'superiotool -dV', 'flashrom -V', getpir
and /proc/cpu output for the Neoware EON 4000S board/Thin Client.
Thanks a lot!
I've almost finished a new target for the Neoware Eon 4000s, but some
On Thu, Jul 03, 2008 at 08:45:15AM -0400, Joseph Smith wrote:
I'm thinking a Serial-USB debugger is the way to go
Ok. Keep in mind that the serial port will probably not be able to
handle full speed data from the debugged target. I'm not sure what
the transfer overhead is, but I expect the debug
#105: flashrom: add documentation files (ChangeLog etc) that need to be in the
release
+---
Reporter: stuge| Owner: somebody
Type: enhancement |Status: new
On 03.07.2008 18:46, Peter Stuge wrote:
On Thu, Jul 03, 2008 at 04:28:54PM +0200, Carl-Daniel Hailfinger wrote:
+if ((*walk) == 0 || ((*walk) 0x3ff) != 0 || *walk size ||
+*(walk - 1) size || *(walk - 2) size ||
+(!isprint((const char *)(bios + size - *(walk
#102: flashrom: coreboot ROM image file identification heuristic is broken
-+--
Reporter: stuge | Owner: somebody
Type: defect|Status: reopened
Priority: major
On Thu, Jul 03, 2008 at 04:47:57PM +0200, Carl-Daniel Hailfinger wrote:
New iteration.
- Clean up Geode companion chip CS5536 code.
- Eliminate a few redundant dev_find_pci_device() calls.
- Fix a compile warning intruduced in r689.
This should be an equivalence transformation.
Build
On Thu, Jul 3, 2008 at 10:53 AM, Peter Stuge [EMAIL PROTECTED] wrote:
I'm thinking per PCI-device in each component rather than per
component?
We've had this discussion before. It's a tough call: finer granularity
vs. having lots of fiddly files. That said, your idea is attractive. I
am very
On Thu, Jul 03, 2008 at 11:00:49AM -0700, ron minnich wrote:
I'm thinking per PCI-device in each component rather than per
component?
We've had this discussion before. It's a tough call: finer granularity
vs. having lots of fiddly files.
Not neccessarily more files though - primarily more
On 03.07.2008 20:00, ron minnich wrote:
On Thu, Jul 3, 2008 at 10:53 AM, Peter Stuge [EMAIL PROTECTED] wrote:
I'm thinking per PCI-device in each component rather than per
component?
We've had this discussion before. It's a tough call: finer granularity
vs. having lots of fiddly
Author: uwe
Date: 2008-07-03 20:58:58 +0200 (Thu, 03 Jul 2008)
New Revision: 3410
Modified:
trunk/util/flashrom/flashchips.c
Log:
Mark the SST SST49LF040 as OK (tested by me), all operations (trivial).
Signed-off-by: Uwe Hermann [EMAIL PROTECTED]
Acked-by: Uwe Hermann [EMAIL PROTECTED]
On Thu, Jul 3, 2008 at 11:17 AM, Carl-Daniel Hailfinger
Thanks! Can I have an Ack from you as well?
It just so happens I have a special price on Acks today.
Acked-by: Ronald G. Minnich [EMAIL PROTECTED]
ron
--
coreboot mailing list
coreboot@coreboot.org
#103: flashrom: Don't exit() after successful erase operation
-+--
Reporter: stuge | Owner: stuge
Type: defect|Status: new
Priority: major |
On Thu, Jul 03, 2008 at 09:26:44PM +0200, [EMAIL PROTECTED] wrote:
Author: uwe
..
- {AMIC Technology,A25L40P, AMIC_ID,AMIC_A25L40P,
512,256,TEST_OK_PREW, probe_spi_rdid4,
spi_chip_erase_c7, spi_chip_write, spi_chip_read},
-
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Peter Stuge
Sent: Thursday, July 03, 2008 1:19 PM
To: coreboot@coreboot.org
Subject: Re: [coreboot] USB debug cables and emulation
On Thu, Jul 03, 2008 at 08:45:15AM -0400, Joseph Smith wrote:
I'm
On 03.07.2008 21:34, ron minnich wrote:
On Thu, Jul 3, 2008 at 11:17 AM, Carl-Daniel Hailfinger
Thanks! Can I have an Ack from you as well?
It just so happens I have a special price on Acks today.
OK, I'll buy you a pizza next time we meet.
Acked-by: Ronald G. Minnich [EMAIL
On 03.07.2008 21:42, Joseph Smith wrote:
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Peter Stuge
Sent: Thursday, July 03, 2008 1:19 PM
To: coreboot@coreboot.org
Subject: Re: [coreboot] USB debug cables and emulation
On Thu, Jul 03, 2008 at
This patch changes the name of LegacyBIOS to SeaBIOS, everywhere but the git
URL, which hasn't been updated yet. It also updates the hardcode.diff patch
now that the memory value is read from the coreboot tables, and fixes the
handling of that patch.
Thanks,
Myles
Signed-off-by: Myles Watson
This patch changes the name of LegacyBIOS to SeaBIOS, everywhere but the
git
URL, which hasn't been updated yet. It also updates the hardcode.diff
patch
now that the memory value is read from the coreboot tables, and fixes the
handling of that patch.
Thanks,
Myles
Signed-off-by:
On Thu, Jul 3, 2008 at 3:48 PM, Jordan Crouse [EMAIL PROTECTED] wrote:
On 03/07/08 15:43 -0600, Myles Watson wrote:
This patch changes the name of LegacyBIOS to SeaBIOS, everywhere but the git
URL, which hasn't been updated yet. It also updates the hardcode.diff patch
now that the memory
I'm not sure if it's buildrom's fault or SeaBIOS's, but the build
fails for me with this error:
make[1]: P: Command not found
It's actually a symptom that $(CPP) isn't being set. When I add these
lines in SeaBIOS's Makefile, it goes away.
ifeq ($(CPP),)
CPP=$(CC) -E
endif
Where should it get
Carl-Daniel Hailfinger wrote:
Absolutely. The ultimate goal is to kill dev_find_pci_device completely.
We have a really nice device model and we should not work around it with
v2-style code.
This will not always be possible, because devices have interactions.
Example:
function
#100: flashrom: Change start/end -s and -e to -S and -E, and change erase -E to
-e.
+---
Reporter: stuge| Owner: somebody
Type: enhancement |Status: new
On 03.07.2008 23:58, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
Absolutely. The ultimate goal is to kill dev_find_pci_device completely.
We have a really nice device model and we should not work around it with
v2-style code.
This will not always be possible, because devices have
Others have pretty much replied with what I was trying to point out,
but here are a couple more comments:
On Thu, Jul 3, 2008 at 12:28 PM, Joseph Smith [EMAIL PROTECTED] wrote:
I guess you don't get it. I am not doing it to mass produce and sell at a
lower cost. I don't really care about any
#104: flashrom: Change flash drivers to never erase data before writing
-+--
Reporter: stuge | Owner: somebody
Type: defect|Status: new
Priority: major |
Kevin,
I didn't have my windows CD handy, so I tried several Linux install
CDs, but I can't get them to boot on my s2892. They boot fine in qemu
with SeaBIOS.
As far as I can tell I configured it like you did.
CONFIG_COREBOOT 1
CONFIG_DEBUG_LEVEL 6
CONFIG_DEBUG_SERIAL 1
CONFIG_FLOPPY_SUPPORT 0
On Thu, Jul 03, 2008 at 11:58:59PM +0200, Stefan Reinauer wrote:
Absolutely. The ultimate goal is to kill dev_find_pci_device
completely.
This will not always be possible, because devices have interactions.
Example:
function setup_link_between_a_and_b:
- Set bit X in device A
- Set
So - comes down to why you want to do it. :)
Well, I wanted to take this as a opportunity to learn the in's and out's of
USB especially USB 2.0 (EHCI). If I make a cool debugging device along the
way, then great :-)
But I get the point, It will probably end up costing me an arm and a leg to
do
On Fri, 04 Jul 2008 01:21:19 +0200, Stefan Reinauer [EMAIL PROTECTED]
wrote:
Joseph Smith wrote:
Also I really want to learn USB for coreboot payload purposes. Did
anyone
realize with all these different payloads we have none of them support
USB
completely?? Filo is the only one that
- Improve VPCI hiding debug message and add doxygen comments.
- Replace a hand-crafted open-coded VPCI hiding sequence.
Build tested on all relevant targets.
Signed-off-by: Carl-Daniel Hailfinger [EMAIL PROTECTED]
Index: LinuxBIOSv3-cs5536cleanup/southbridge/amd/cs5536/cs5536.c
Good News!
I just had my first donation to the Set-Top-Linux/Thomson IP1000/coreboot
cause:-)
This guy really really wants me to get the TV-Out going on the Thomson
IP1000, so he donated some $$ to the cause.
Kinda cool I thought. Well I'm going on vacation next week, but when I come
back I will
build tested. Let's get some run tests back before we commit.
ron
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
On Fri, Jul 04, 2008 at 03:44:18AM +0200, Patrick Georgi wrote:
For UHCI:
..
For OHCI:
..
For EHCI:
- figure out how to gain control over a device from the USB1
controller (that will somehow interact with the USB1 driver)
Some comments, hopefully helpful:
USB1 devices on the EHCI root hub
53 matches
Mail list logo
