Hi
sorry for confusion I've tested flashing again - this time with original BIOS
chip (SST49LF004A/B) and I was able to write without problems.
Phil
On Wednesday 29 November 2006 15:22, Ward Vandewege wrote:
Hi Philipp,
Out of curiosity, have you managed in-board flashing with flashrom?
Author: uwe
Date: 2006-12-01 10:41:11 +0100 (Fri, 01 Dec 2006)
New Revision: 2512
Modified:
trunk/LinuxBIOSv2/src/superio/ite/it8661f/chip.h
trunk/LinuxBIOSv2/src/superio/ite/it8661f/it8661f_early_serial.c
trunk/LinuxBIOSv2/src/superio/ite/it8661f/superio.c
* Bari Ari [EMAIL PROTECTED] [061201 02:56]:
Lu, Yinghai wrote:
There should not work as USB debug device. I guess.
Lack of Linux support seems to be the problem.
I've pulled a couple apart and they use the PLX or Maxim USB controllers
with a small micro to pass the data back and
On Fri, Dec 01, 2006 at 11:14:44AM +0100, Stefan Reinauer wrote:
* Bari Ari [EMAIL PROTECTED] [061201 02:56]:
Lu, Yinghai wrote:
There should not work as USB debug device. I guess.
Lack of Linux support seems to be the problem.
I've pulled a couple apart and they use the PLX or
On Thu, Nov 30, 2006 at 02:44:59PM -0800, Lu, Yinghai wrote:
I'm trying to get one.
This is the one Stefan has, that I took apart in Hamburg:
http://www.plxtech.com/products/NET2000/NET20DC/default.asp
They call it a cable, which is silly, but it does the right thing.
//Peter
--
linuxbios
On Thu, Nov 30, 2006 at 04:53:39PM -0800, Lu, Yinghai wrote:
With USB serial console enabled in kernel and console=ttyUSB0, only
can get boot message very late.
From usbcore: registered new interface driver ftdi_sio. Before that
only some lines in buffer.
Yeah. The debug device is only useful
Tom Sylla wrote:
Another idea, there has been a lot of talk about homebrew LPC ROM
emulators. It would not be much more work to make the emulator into a
generic LPC analyzer. You could have it catch regular serial, or you
could just have print_debug spew bytes to a specified I/O location.
On Thu, Nov 30, 2006 at 07:44:47PM -0600, Bari Ari wrote:
Someone could fab these however as a 2 sided pcb with only the
SMBus signals for next to nothing in cost.
I looked into this yesterday.
The place I normally order prototype boards from (Olimex) don't stock
any 1.2mm laminate.
The place
On Fri, Dec 01, 2006 at 01:26:31PM +0200, Indrek Kruusa wrote:
For current Thincan (artecgroup/dbe61) development we are using our
own designed dongles:
http://208.109.65.208/products/hardware-products/programmable-lpc-dongle.html
Very nice!
- LPC connector (the cable shouldn't be longer
* Peter Stuge [EMAIL PROTECTED] [061201 11:36]:
I sent a probably-working program to the list a while back that uses
libusb to access the host end of the device. It only handles reads
from the target. I'll add it to trac.
Stefan, you're in a unique position to test my code and Eric's code
On Fri, Dec 01, 2006 at 01:26:31PM +0200, Indrek Kruusa wrote:
- chosen flash bank is seen as 1MB at boot, switched to 4MB mode by
LinuxBIOS.
Can you explain how this works in more detail? Do you know if
chipsets usually support 1MB?
//Peter
--
linuxbios mailing list
linuxbios@linuxbios.org
#57: libusb host program for PLX NET20DC debug device
-+--
Reporter: stuge | Owner: somebody
Type: enhancement| Status: new
Priority: major |
#57: libusb host program for PLX NET20DC debug device
+---
Reporter: stuge| Owner: somebody
Type: enhancement |Status: new
Priority: major|
On Fri, Dec 01, 2006 at 09:24:11AM +0100, Philipp Degler wrote:
sorry for confusion I've tested flashing again - this time with original BIOS
chip (SST49LF004A/B) and I was able to write without problems.
Great. Is your gpio-unlock code in the tree yet?
Thanks,
Ward.
--
Ward Vandewege
Peter Stuge wrote:
On Fri, Dec 01, 2006 at 01:26:31PM +0200, Indrek Kruusa wrote:
- chosen flash bank is seen as 1MB at boot, switched to 4MB mode by
LinuxBIOS.
Can you explain how this works in more detail? Do you know if
chipsets usually support 1MB?
I can't help here,
Peter Stuge wrote:
On Fri, Dec 01, 2006 at 01:26:31PM +0200, Indrek Kruusa wrote:
- Altera Cyclone FPGA as the control part
Do you think it would be possible to make a firmware for the FPGA
that also does reads-make-a-write and can signal them back to the
Linux host?
I'v
Peter Stuge wrote:
On Fri, Dec 01, 2006 at 01:26:31PM +0200, Indrek Kruusa wrote:
For current Thincan (artecgroup/dbe61) development we are using our
own designed dongles:
http://208.109.65.208/products/hardware-products/programmable-lpc-dongle.html
Very nice!
- LPC
On Fri, Dec 01, 2006 at 04:01:54PM +0200, Indrek Kruusa wrote:
Is that EUR90 or USD90? Either way I agree - it's a good price!
Hey, this is quite a wrong price (my information was outdated). The
latest information from marketing department:
- for current dongle and for current revision the
#57: libusb host program for PLX NET20DC debug device
+---
Reporter: stuge| Owner: somebody
Type: enhancement |Status: new
Priority: major|
Hi,
since the romcc builtin preprocessor silently eats lines of code,
can we just use the gcc preprocessor (cpp) before calling romcc as
a workaround?
Is there a reason romcc has its own preprocessor?
Stefan
--
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761
Peter Stuge wrote:
On Fri, Dec 01, 2006 at 04:01:54PM +0200, Indrek Kruusa wrote:
Is that EUR90 or USD90? Either way I agree - it's a good price!
Hey, this is quite a wrong price (my information was outdated). The
latest information from marketing department:
- for current dongle
On 12/1/06, Peter Stuge [EMAIL PROTECTED] wrote:
On Thu, Nov 30, 2006 at 07:44:47PM -0600, Bari Ari wrote:
Someone could fab these however as a 2 sided pcb with only the
SMBus signals for next to nothing in cost.
I looked into this yesterday.
The place I normally order prototype boards
Did you check the digitallogic board in V1 that uses 440bx? It used to work ...
ron
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
hi
On Friday 01 December 2006 13:32, Ward Vandewege wrote:
On Fri, Dec 01, 2006 at 09:24:11AM +0100, Philipp Degler wrote:
sorry for confusion I've tested flashing again - this time with original
BIOS chip (SST49LF004A/B) and I was able to write without problems.
Great. Is your
Is there a equivalent of a snapshot repository for v1 (like
http://snapshots.linuxbios.org is for v2) ?
_
Geef jouw Hotmail kleur met Windows Live Mail! Stap nu over!
On Fri, Dec 01, 2006 at 09:10:08AM -0700, ron minnich wrote:
This is pretty special-purpose though. Perhaps time would be better
spent on the LPC thingy, since they can be used for testing too.
I am missing something here. If we have enough of PCI up to do
SPD-USB, I would bet that we have
* Idwer Vollering [EMAIL PROTECTED] [061201 18:48]:
Is there a equivalent of a snapshot repository for v1 (like
http://snapshots.linuxbios.org is for v2) ?
Not really. Since v1 is not actively developed anymore, it is just
sitting in the svn repository.
You can download the latest snapshot
* Peter Stuge [EMAIL PROTECTED] [061201 19:16]:
The assumption was that not much needs to happen before the SPD I2C
bus is accessible by the CPU - is that valid?
Since you need I2C, you need to get parts of the south bridge working.
So, its basically the same amount of work as with the USB
On Fri, Dec 01, 2006 at 10:14:46AM -0800, Lu, Yinghai wrote:
To my understanding, You don't need to waiting for Eric's code.
I can rewrite code to do the same, but if he has working
proof-of-concept there's no point in duplicating work.
You can use the cable on two system without debug port
The two debug devices in the cable are different?
YH
--
linuxbios mailing list
linuxbios@linuxbios.org
http://www.openbios.org/mailman/listinfo/linuxbios
On Fri, Dec 01, 2006 at 07:28:53PM +0100, Stefan Reinauer wrote:
* Peter Stuge [EMAIL PROTECTED] [061201 19:16]:
The assumption was that not much needs to happen before the SPD I2C
bus is accessible by the CPU - is that valid?
Since you need I2C, you need to get parts of the south
On Fri, Dec 01, 2006 at 10:36:46AM -0800, Lu, Yinghai wrote:
The two debug devices in the cable are different?
Yes. The PLX NET20DC device I looked at in Hamburg is asymmetric.
This is also consistent with the Debug Device Functional Device
Specification. If you are familiar with USB, please
* Peter Stuge [EMAIL PROTECTED] [061201 19:46]:
Since you need I2C, you need to get parts of the south bridge
working.
Even though it's on the DIMM? Ugh. :(
It's the same as trying to see the SPD ROM, isnt it? That is connected
to the south bridge smbus. Not too wild though,..
Me too.
On Fri, Dec 01, 2006 at 08:10:45PM +0100, Stefan Reinauer wrote:
* Peter Stuge [EMAIL PROTECTED] [061201 19:46]:
Since you need I2C, you need to get parts of the south bridge
working.
Even though it's on the DIMM? Ugh. :(
It's the same as trying to see the SPD ROM, isnt it?
Right.
* Peter Stuge [EMAIL PROTECTED] [061201 20:24]:
That is connected to the south bridge smbus. Not too wild though,..
Ugh again. :( What a detour. The memory controller is in the CPU or
the northbridge, right?
Yeah. You need a little bit of everything to make it lit up.
--
coresystems GmbH
#57: libusb host program for PLX NET20DC debug device
+---
Reporter: stuge| Owner: somebody
Type: enhancement |Status: closed
Priority: major|
#57: libusb host program for PLX NET20DC debug device
+---
Reporter: stuge| Owner: somebody
Type: enhancement |Status: closed
Priority: major|
-Original Message-
From: Lu, Yinghai
To my understanding, you don't need to waiting for Eric's code.
You can use the cable on two systems without debug port support.
So just extend the program to make it can write the data too.
Greg,
Anyone is working on creating one usb_serial_driver
-Original Message-
From: Greg KH [mailto:[EMAIL PROTECTED]
I can do that in about 15 minutes if you give me the device ids for the
usb debug device that you wish to have.
Or you can also use the generic usb-serial driver today just fine with
no modification. Have you had a problem with
On Fri, Dec 01, 2006 at 11:19:16AM -0800, Greg KH wrote:
Well, earlyprintk will not work, as you need PCI up and running.
Not all of it though. LinuxBIOS will probably do just enough PCI
setup to talk to the EHCI controller and use the debug port _very_
soon after power on.
And I have some
Peter Stuge [EMAIL PROTECTED] writes:
On Fri, Dec 01, 2006 at 11:19:16AM -0800, Greg KH wrote:
Well, earlyprintk will not work, as you need PCI up and running.
Not all of it though. LinuxBIOS will probably do just enough PCI
setup to talk to the EHCI controller and use the debug port _very_
On Fri, Dec 01, 2006 at 02:15:24PM -0700, Eric W. Biederman wrote:
Right. For LinuxBIOS not a problem for earlyprintk in the kernel
somethings might need to be refactored. The challenge in the
kernel is we don't know at build to how to do a pci_read_config...
The other hard part early in
since the romcc builtin preprocessor silently eats lines of code,
can we just use the gcc preprocessor (cpp) before calling romcc as
a workaround?
That should work (if you get the -I directives, etc., right).
But use gcc -E instead of cpp...
Is there a reason romcc has its own preprocessor?
The place I order production boards from (local fab) do have 1.2mm
laminate but the minimum order they do is one full panel (about .5m2)
- that means a big bag of boards. :)
Real cheap-skates just demolish an existing (already broken) DIMM ;-)
If there's interest I'll be happy to make a DDR2
I am missing something here. If we have enough of PCI up to do
SPD-USB, I would bet that we have enough of it up to do USB debug? or
not?
Many systems don't require any PCI to access their I2C controllers.
LPC is going away on many boards, I understand. I think that we are
going into a
On 12/1/06, Segher Boessenkool [EMAIL PROTECTED] wrote:
I am missing something here. If we have enough of PCI up to do
SPD-USB, I would bet that we have enough of it up to do USB debug? or
not?
Many systems don't require any PCI to access their I2C controllers.
I have never used a PC that
The assumption was that not much needs to happen before the SPD I2C
bus is accessible by the CPU - is that valid?
Depends on the system. Intel tends to put the I2C controllers
on the south bridge, such a shame.
If not, what IS easily accessible besides the boot ROM?
In general? Nothing,
The assumption was that not much needs to happen before the SPD I2C
bus is accessible by the CPU - is that valid?
Since you need I2C, you need to get parts of the south bridge working.
So, its basically the same amount of work as with the USB debug port.
Most systems I work with have I2C
Since you need I2C, you need to get parts of the south bridge
working.
Even though it's on the DIMM? Ugh. :(
So, its basically the same amount of work as with the USB debug
port.
Yeah. Not much point to it then.
Well at least it's an I/O BAR instead of a memory BAR, quite a
bit easier to
Since you need I2C, you need to get parts of the south bridge
working.
Even though it's on the DIMM? Ugh. :(
It's the same as trying to see the SPD ROM, isnt it? That is connected
to the south bridge smbus. Not too wild though,..
No, it's on whatever I2C people put it on. Yes it's true
Many systems don't require any PCI to access their I2C controllers.
I have never used a PC that doesn't require it.
486-era PCs didn't, it has gone downhill since then...
We come from different worlds.
Yeah :-)
Segher
--
linuxbios mailing list
linuxbios@linuxbios.org
It seems to me the order of choices is something like this:
Best:
1. USB debug port. This is going to work well in the x86 world, as
even the embeddec boards tend to have USB. USB is replacing rs232 in
those worlds. Based on the boards we have used in last 7 years, on
x86, setting up the PCI
* Segher Boessenkool [EMAIL PROTECTED] [061201 23:38]:
No, it's on whatever I2C people put it on. Yes it's true
intel puts their I2C controllers on the south bridge, they
like making life hard. Not every hardware manufacturer is
that way :-)
all PC components manufacturers do. 99% of the
* Segher Boessenkool [EMAIL PROTECTED] [061201 23:36]:
See wiki page with list of EHCI chips that lack the debug port. On
the other hand maybe all boards using them will have a serial port?
Lots of boards don't have USB... Remember, the desktop market
is only a very small percentage of
* Segher Boessenkool [EMAIL PROTECTED] [061201 23:21]:
If not, what IS easily accessible besides the boot ROM?
In general? Nothing, not necessarily the boot ROM even!
Right. The machine might be booting out of the air.
Or have some overlay in the southbridge (our s-word today), like the
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, December 01, 2006 1:15 PM
Peter Stuge [EMAIL PROTECTED] writes:
On Fri, Dec 01, 2006 at 11:19:16AM -0800, Greg KH wrote:
Well, earlyprintk will not work, as you need PCI up and running.
Not all of it
Peter Stuge [EMAIL PROTECTED] writes:
On Fri, Dec 01, 2006 at 02:15:24PM -0700, Eric W. Biederman wrote:
Right. For LinuxBIOS not a problem for earlyprintk in the kernel
somethings might need to be refactored. The challenge in the
kernel is we don't know at build to how to do a
It seems to me the order of choices is something like this:
Best:
1. USB debug port. This is going to work well in the x86 world, as
even the embeddec boards tend to have USB. USB is replacing rs232 in
those worlds. Based on the boards we have used in last 7 years, on
x86, setting up the
On 11/30/06, Simon Labrecque [EMAIL PROTECTED] wrote:
The problem with the MSI K9N is that the Northbridge's passive cooler is
said to get very, VERY hot, which might be problematic in our application as
noise (and therefore airflow) needs to be minimized.
I haven't tested it personally
Thanks for the code.
In LinuxBIOS,
I put usbdevice_direct.c in lib/, and call it from usb2_init in
mcp55_usb2.c
Got
No device in debug port
Waiting for cable, hope to get that cable next Tuesday.
Will create usbdebug_direct_console.c in console/ for linuxbios_ram
code.
also
60 matches
Mail list logo
