On Wed, 2008-02-20 at 23:21 +0100, Ronald Hoogenboom wrote:
> On Tue, 2008-02-19 at 23:34 -0500, Ward Vandewege wrote:
<...>
> > > -default MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID=0x1022
> > > -default MAINBOARD_PCI_SUBSYSTEM_DEVICE_ID=0x2b80
> > > +default MAINBOARD_PCI_SUBSYSTEM_VENDOR_ID=0x1458
> > >
Hi Ward,
Thanks for reviewing my patch. I'm glad to hear that it got you a
booting mainboard too.
Most of the seemingly unrelated changes are a result of my quest to get
my nvidia VGA to work. Also I'm quite new submitting patches and I'm not
yet very familiar with what stuff is allowed to be in
Hi Ronald,
On Mon, Feb 18, 2008 at 10:45:23PM +0100, Ronald Hoogenboom wrote:
> Finally, now I know it's working (at least the part that I'm patching
> here...), here is the patch that uses PIO mode read from SPI rom with
> lzma decompression.
>
> This patch allows direct out-of-SPI-flash boot of
Finally, now I know it's working (at least the part that I'm patching
here...), here is the patch that uses PIO mode read from SPI rom with
lzma decompression.
This patch allows direct out-of-SPI-flash boot of a Linux kernel. It
circumvents the 512KB limitation in the IT8716f superio of memory
map
Carl-Daniel Hailfinger wrote:
>Harald: This patch should fix your problems writing to the chip. Use
>either "patch -l" or remove the // before
>//while (generic_spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
>
>Ronald: I need an ack to commit this.
>
>On 20.01.2008 11:59, Ronald Hoogenboom wrote
On 22.01.2008 03:53, ron minnich wrote:
> Just FYI, some luck writing this chip on the sis board ...
>
> The write had no errors. The -v failed. But on using the -r to read to
> a file, I find
> no differences between the file used for -w and the file used for -v!
>
Yes, very old lingering bug
On 22.01.2008 12:08, Harald Gutmann wrote:
> Am Dienstag, 22. Januar 2008 01:09:09 schrieben Sie:
>
>> Harald: This patch should fix your problems writing to the chip. Use
>> either "patch -l" or remove the // before
>> //while (generic_spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
>>
>
Am Dienstag, 22. Januar 2008 01:09:09 schrieben Sie:
> Harald: This patch should fix your problems writing to the chip. Use
> either "patch -l" or remove the // before
> //while (generic_spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
I've updated my flashrom tree to revision 3068 and commented th
Just FYI, some luck writing this chip on the sis board ...
The write had no errors. The -v failed. But on using the -r to read to
a file, I find
no differences between the file used for -w and the file used for -v!
Next is to try to actually put the vga bios onto the image and see if,
this time,
Harald: This patch should fix your problems writing to the chip. Use
either "patch -l" or remove the // before
//while (generic_spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
Ronald: I need an ack to commit this.
On 20.01.2008 11:59, Ronald Hoogenboom wrote:
> Carl-Daniel Hailfinger wrote:
>
>
On 21.01.2008 00:47, Ronald Hoogenboom wrote:
> On Mon, 2008-01-21 at 00:24 +0100, Ronald Hoogenboom wrote:
>
>> (LPC is the only datapath to the SB and CPU, so it has to!). We could
>> optimize by omitting the wait for SPI ready when there is no data to be
>> read, eg. readcnt==0. I'll have a l
On Mon, 2008-01-21 at 00:24 +0100, Ronald Hoogenboom wrote:
> (LPC is the only datapath to the SB and CPU, so it has to!). We could
> optimize by omitting the wait for SPI ready when there is no data to be
> read, eg. readcnt==0. I'll have a look at what can be gained by that.
>
Omitting it saves
On Sun, 2008-01-20 at 22:28 +0100, Carl-Daniel Hailfinger wrote:
> I think we can shorten the delay in the loop to about 5 us. However,
> even with 10 us delay we still can't explain the time needed to program
> the chip.
> In the case without status reading, we have exactly 5 bytes on the SPI
> b
On 20.01.2008 12:48, Ronald Hoogenboom wrote:
> On Sun, 2008-01-20 at 11:59 +0100, Ronald Hoogenboom wrote:
>
>> The read status register will take at least:
>> 16*(2/33) us = about 1 us (excluding the LPC latency, which is?), so
>> assuming that the first read status will show busy and the
On Sun, 2008-01-20 at 11:59 +0100, Ronald Hoogenboom wrote:
> The read status register will take at least:
> 16*(2/33) us = about 1 us (excluding the LPC latency, which is?), so
> assuming that the first read status will show busy and the second will
> show ready, it is only 2 us slower: ~20%
Carl-Daniel Hailfinger wrote:
>Did you have time to test with the while
>(generic_spi_read_status_register() & .._WIP) enabled? It would be more
>correct to have it enabled.
>
>
>
I had that in initially (that's why it was there, but commented out) but
all it got me was slower programming times
On 18.01.2008 23:10, Ward Vandewege wrote:
> On Wed, Jan 16, 2008 at 10:34:29PM -0500, Ward Vandewege wrote:
>
>>> Winbond W25X16VSSI
>>> Winbond W25X32VSSI
>>>
>>> Problem with Winbond is they really only want to sell large
>>> quantities. I haven't even gotten a quote and delivery time
>>> bac
On 19.01.2008 19:34, Ronald Hoogenboom wrote:
> Carl-Daniel Hailfinger wrote:
>
>> */
>> -//while (generic_spi_read_status_register() &
>> JEDEC_RDSR_BIT_WIP)
>> +while (generic_spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
>> myusec_delay(10);
>> -//if (i%1024==0
Carl-Daniel Hailfinger wrote:
> */
>- //while (generic_spi_read_status_register() &
>JEDEC_RDSR_BIT_WIP)
>+ while (generic_spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
> myusec_delay(10);
>- //if (i%1024==0) fputc('b',stderr);
>+
On 19.01.2008 01:23, Peter Stuge wrote:
> On Sat, Jan 19, 2008 at 01:18:11AM +0100, Carl-Daniel Hailfinger wrote:
>
>> +while (generic_spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
>> myusec_delay(10);
>>
>
> Indent this properly, please.
>
Will be done in th
On Sat, Jan 19, 2008 at 01:18:11AM +0100, Carl-Daniel Hailfinger wrote:
> + while (generic_spi_read_status_register() & JEDEC_RDSR_BIT_WIP)
> myusec_delay(10);
Indent this properly, please.
//Peter
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org
On 19.01.2008 01:08, Carl-Daniel Hailfinger wrote:
> On 19.01.2008 00:17, Ronald Hoogenboom wrote:
>
>> On Fri, 2008-01-18 at 23:31 +0100, Carl-Daniel Hailfinger wrote:
>>
>>
>>> Thanks for reworking the code! I have factored out some common status
>>> registers to duplicate less code an
On 19.01.2008 00:17, Ronald Hoogenboom wrote:
> On Fri, 2008-01-18 at 23:31 +0100, Carl-Daniel Hailfinger wrote:
>
>> Thanks for reworking the code! I have factored out some common status
>> registers to duplicate less code and hope the code still works. Could
>> you please review it and tell me
On Fri, 2008-01-18 at 23:31 +0100, Carl-Daniel Hailfinger wrote:
> Thanks for reworking the code! I have factored out some common status
> registers to duplicate less code and hope the code still works. Could
> you please review it and tell me what you think?
>
Fine by me, works like a charm, the
On 18.01.2008 21:48, Ronald Hoogenboom wrote:
> I think this is a matter of taste... But if the style is like this, I
> will comply. So I changed my patch again to do exactly the same, but
> with a few JEDEC_... defines.
>
>
> Signed-off-by: Ronald Hoogenboom <[EMAIL PROTECTED]>
>
Thanks for
On Wed, Jan 16, 2008 at 10:34:29PM -0500, Ward Vandewege wrote:
> > Winbond W25X16VSSI
> > Winbond W25X32VSSI
> >
> > Problem with Winbond is they really only want to sell large
> > quantities. I haven't even gotten a quote and delivery time
> > back from my sales rep on a request I made in Novemb
On 18.01.2008 21:09, Ronald Hoogenboom wrote:
> OK, I've checked it again and fixed a few things, see the read function
> and the erase also has the block protect disable, and it works again.
>
Thanks! It seems I was half asleep while coding the if (size > 512k) part.
> It takes just under a m
On Fri, 2008-01-18 at 09:39 -0800, ron minnich wrote:
> On Jan 18, 2008 6:49 AM, Carl-Daniel Hailfinger
> > should work as well and fit a little better into flashrom structure.
>
> The top 512 flash fine, the lower 1.5M did not flash, but did erase,
> maybe. hard to say if
> readback worked.
>
T
Thanks for the explanations, however vague ;-). I thought I was the only
one wandering in the dark..
On Thu, 2008-01-17 at 23:38 -0800, ron minnich wrote:
> other indexes, there is. Does this mean that the superio.c file fails
> to
> > configure this io port?
>
> yes, it means that the port is no
On Fri, 2008-01-18 at 03:13 +0100, Carl-Daniel Hailfinger wrote:
> I was unclear. I mean stuff like this:
>
> void spi_write_status_register(int status)
> {
> const unsigned char cmd[] = {0x01,(unsigned char)status};
> would probably be more readable if it looked like this:
>
> void spi
OK, I've checked it again and fixed a few things, see the read function
and the erase also has the block protect disable, and it works again.
It takes just under a minute to flash the whole chip, which is still
quite acceptable, I would say. It took WAY longer when the byte write
was timed by usle
On Fri, 2008-01-18 at 03:00 +0100, Carl-Daniel Hailfinger wrote:
> On 17.01.2008 22:25, Ronald Hoogenboom wrote:
...
> > the limited io transfer length options of the IT8716). It might be more
> > appropriate to have an 'over512k_page_write' for more speed with chips
> > that do support that. Also
On Jan 18, 2008 6:49 AM, Carl-Daniel Hailfinger
<[EMAIL PROTECTED]> wrote:
> I have a mad scheme which would work for v3 without downsides (except
> for the fact that the boot block and initram have to be in the upper 512
> kB, but that's the case anyway even without my scheme).
> Basically, we cr
On 18.01.2008 08:17, ron minnich wrote:
> OK, SiS sent me this nice board with some 2 MB flash parts and I have
> not gotten much past step 1, "Program the flash", as it is a 2 MB
> flash. I had no idea what a mess the superio/flash interface was going
> to be.
>
> So, Ronald, I am most interested
ron minnich wrote:
> On Jan 17, 2008 2:32 PM, Ronald Hoogenboom <[EMAIL PROTECTED]> wrote:
>
>> Now I'm looking at how to make the rom_stream read the flash chip like
>> in the over512k_read_chip.
>> But I'm a bit stuck on the overal mechanics of the initialization
>> process and how to get hold
On Jan 17, 2008 2:32 PM, Ronald Hoogenboom <[EMAIL PROTECTED]> wrote:
> Now I'm looking at how to make the rom_stream read the flash chip like
> in the over512k_read_chip.
> But I'm a bit stuck on the overal mechanics of the initialization
> process and how to get hold of the assigned io port for t
OK, SiS sent me this nice board with some 2 MB flash parts and I have
not gotten much past step 1, "Program the flash", as it is a 2 MB
flash. I had no idea what a mess the superio/flash interface was going
to be.
So, Ronald, I am most interested in your patch, hope it is ready soon!
And, well, s
On 18.01.2008 03:00, Carl-Daniel Hailfinger wrote:
> Nice. I have restructured your patch a bit, but I'd like to improve even
> further. Could you take a look at all those places where you added
> "const unsigned char cmd[] = XXX" and use #defines for commands like
> those at the top of spi.c? That
On 17.01.2008 22:25, Ronald Hoogenboom wrote:
> On Thu, 2008-01-17 at 00:56 +0100, Carl-Daniel Hailfinger wrote:
>
>
>> Please see
>> http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure for
>> details on patch submission. There are two things that block acceptance
>> of your patch:
Now I'm looking at how to make the rom_stream read the flash chip like
in the over512k_read_chip.
But I'm a bit stuck on the overal mechanics of the initialization
process and how to get hold of the assigned io port for the SPI serial
flash controller in the IT8716.
This is supposed to be configure
On Thu, 2008-01-17 at 00:56 +0100, Carl-Daniel Hailfinger wrote:
> Please see
> http://www.coreboot.org/Development_Guidelines#Sign-off_Procedure for
> details on patch submission. There are two things that block acceptance
> of your patch:
> - A "Signed-off-by:" line is missing. Please add one.
On Thu, 2008-01-17 at 01:24 +0100, Carl-Daniel Hailfinger wrote:
> On 17.01.2008 00:13, Ronald Hoogenboom wrote:
> > I mounted a SST25VF016B 2MByte flash chip on the second SPI bios
> ...
> > 33MHz) is negligible.
> >
>
> Please be aware that the M57SLI may read the reset vector and other
> rea
On Thu, Jan 17, 2008 at 03:00:35PM +0100, Peter Stuge wrote:
> I've found what seems to be a good 16Mbit candidate that is readily
> available to me at a fair price without(!) moq. :)
>
> Spansion S25FL016A0LMFI011
> http://www.spansion.com/products/S25FL016A.html
> http://www.spansion.com/datashe
On Thu, Jan 17, 2008 at 03:00:35PM +0100, Peter Stuge wrote:
> I've tried to get quotes also for 16 and 32Mbit Macronix but they
> weren't available last time I asked.
16Mbit is now, but 32 and 64 are still not in production, only
sampling.
//Peter
--
coreboot mailing list
coreboot@coreboot.or
On 17.01.2008 15:00, Peter Stuge wrote:
> I've found what seems to be a good 16Mbit candidate that is readily
> available to me at a fair price without(!) moq. :)
>
> Spansion S25FL016A0LMFI011
> http://www.spansion.com/products/S25FL016A.html
> http://www.spansion.com/datasheets/s25fl016a_00_c3.pd
On 17.01.2008 14:32, Harald Gutmann wrote:
> Do you think it would be possible to add write support for the MX25L8005 and
> the MX25L3205D to flashrom based on this patch?
>
Yes. The code is generic enough. But the order in which you write
sectors to the chip may differ between both flashing m
On Wed, Jan 16, 2008 at 10:34:29PM -0500, Ward Vandewege wrote:
> > > Any other suggestions for large SPI/SOIC-8 chips?
> >
> > Macronix MX25L8005M2C-15G
>
> Mouser/digikeys/jameco don't have this one.
I've tried to get quotes also for 16 and 32Mbit Macronix but they
weren't available last time
Do you think it would be possible to add write support for the MX25L8005 and
the MX25L3205D to flashrom based on this patch?
I'd be really glad to see write support for those chips.
regards,
Harald
--
coreboot mailing list
coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/corebo
Am Donnerstag, 17. Januar 2008 03:09:43 schrieb Ward Vandewege:
> On Thu, Jan 17, 2008 at 03:03:48AM +0100, Peter Stuge wrote:
> > On Wed, Jan 16, 2008 at 08:57:52PM -0500, Ward Vandewege wrote:
> > > > English translation:
> > > >
> > > > SST25VF016B is not really compatible with the IT8716F super
On Thu, Jan 17, 2008 at 03:24:23AM +0100, Peter Stuge wrote:
> On Wed, Jan 16, 2008 at 09:09:43PM -0500, Ward Vandewege wrote:
> > > > All right. So how about the Atmel AT45DB321D-SU
> > >
> > > Unfortunately it has a different pinout than the flash chips
> > > we've looked at so far.
> >
> > Oh,
On Wed, Jan 16, 2008 at 09:09:43PM -0500, Ward Vandewege wrote:
> > > All right. So how about the Atmel AT45DB321D-SU
> >
> > Unfortunately it has a different pinout than the flash chips
> > we've looked at so far.
>
> Oh, you're right, odd. It would work in a socket I guess, if that
> socket is
On 17.01.2008 02:48, Ward Vandewege wrote:
> Hi Ronald,
>
> On Thu, Jan 17, 2008 at 12:13:48AM +0100, Ronald Hoogenboom wrote:
>
>> Problem1 (for reading) is solved by NOT using the mmap method for
>> reading the flash contents, but using outb() for sending the flash read
>> commands (using a sp
On Thu, Jan 17, 2008 at 03:03:48AM +0100, Peter Stuge wrote:
> On Wed, Jan 16, 2008 at 08:57:52PM -0500, Ward Vandewege wrote:
> > > English translation:
> > >
> > > SST25VF016B is not really compatible with the IT8716F superio.
> >
> > All right. So how about the Atmel AT45DB321D-SU
>
> Unfortu
On Wed, Jan 16, 2008 at 08:57:52PM -0500, Ward Vandewege wrote:
> > English translation:
> >
> > SST25VF016B is not really compatible with the IT8716F superio.
>
> All right. So how about the Atmel AT45DB321D-SU
Unfortunately it has a different pinout than the flash chips we've
looked at so far.
On Thu, Jan 17, 2008 at 02:29:16AM +0100, Peter Stuge wrote:
> On Thu, Jan 17, 2008 at 01:24:38AM +0100, Carl-Daniel Hailfinger wrote:
> > Please be aware that the M57SLI may read the reset vector and other
> > really early stuff at 33 MHz, thereby causing read errors
> > (sometimes single bit shif
Hi Ronald,
On Thu, Jan 17, 2008 at 12:13:48AM +0100, Ronald Hoogenboom wrote:
> Problem1 (for reading) is solved by NOT using the mmap method for
> reading the flash contents, but using outb() for sending the flash read
> commands (using a specific 25vf016 read function). Also the normal read
> co
On 17.01.2008 02:29, Peter Stuge wrote:
> On Thu, Jan 17, 2008 at 01:24:38AM +0100, Carl-Daniel Hailfinger wrote:
>
>> Please be aware that the M57SLI may read the reset vector and other
>> really early stuff at 33 MHz, thereby causing read errors
>> (sometimes single bit shifts) which are reall
On Thu, Jan 17, 2008 at 01:24:38AM +0100, Carl-Daniel Hailfinger wrote:
> Please be aware that the M57SLI may read the reset vector and other
> really early stuff at 33 MHz, thereby causing read errors
> (sometimes single bit shifts) which are really hard to find.
English translation:
SST25VF016B
On 17.01.2008 00:13, Ronald Hoogenboom wrote:
> I mounted a SST25VF016B 2MByte flash chip on the second SPI bios
> landpattern on the m57sli mobo (as per the m57sli tutorial).
> There as some problems with that[...]
>
> Problem1 (for reading) is solved by NOT using the mmap method for
> reading the
On 17.01.2008 01:05, Ward Vandewege wrote:
> Hi Ronald and Carl-Daniel,
>
> Great work - I want to use larger SPI chips on this board myself.
>
> On Thu, Jan 17, 2008 at 12:56:08AM +0100, Carl-Daniel Hailfinger wrote:
>
>> I see you invested a lot of time to work around the deficiencies of the
>
Hi Ronald and Carl-Daniel,
Great work - I want to use larger SPI chips on this board myself.
On Thu, Jan 17, 2008 at 12:56:08AM +0100, Carl-Daniel Hailfinger wrote:
> I see you invested a lot of time to work around the deficiencies of the
> IT8716F SPI translation function. You even did it the wa
Hi Ronald,
first of all, welcome to coreboot.
I see you invested a lot of time to work around the deficiencies of the
IT8716F SPI translation function. You even did it the way I described
the process a few weeks ago (but I had no time to implement it).
Please see
http://www.coreboot.org/Developm
I mounted a SST25VF016B 2MByte flash chip on the second SPI bios
landpattern on the m57sli mobo (as per the m57sli tutorial).
There as some problems with that, on the one side from the point of the
LPC memory mapping options of the IT8716F (max. 512KB contiguous) and on
the other side with the prog
63 matches
Mail list logo
