headers
ron minnich | 1 Oct 04:36
Picon

Re: successfully flashed Asus M2A-VM,

On 9/30/07, Rodney Crossman <rodc <at> ravenet.ca> wrote:

> WARNING: No chipset found. Flash detection will most likely fail.
> SST49LF080A found at physical address: 0xfff00000

It occurs to me that the 'will most likely fail' message is too
pessimistic. Anybody want to reword it :-)

I get that message all the time, followed by the 'OH! I found this flash part!"

Maybe even do this:

Note: flashrom has no support for this chipset.

Then set an internal variable indicating that there was no chipset support.

And then, if and only if no flash part is found, AND the chipset was
not supported:
Warning: no flash part identified, this *may* be due to the fact the
flashrom has no special code for this chipset.

thanks

ron

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
(Continue reading)

Permalink | Reply | 0 comments |
headers
Corey Osgood | 1 Oct 05:03
Picon

Re: EHCI stack to port to FILO?

Peter Stuge wrote:
> On Sun, Sep 30, 2007 at 04:08:56PM -0400, Corey Osgood wrote:
>   
>> I'm working from the 2.6 kernel driver at the moment,
>>     
>
> What about the early serial stuff? (Not debug port, but the other.)
>
> Maybe there's some EHCI stuff there?
>   

You mean in the kernel or LB?

>> And can anyone, perhaps with an EPIA or EPIA-M, confirm that UHCI
>> is working in FILO? I've tried disabling the EHCI device, but it
>> still fails on vt8237.
>>     
>
> All EHCI controllers also provide one UHCI or OHCI (I forget if
> there's a choice or if not, which it should be) per physical port in
> order to have backwards compatibility for 1.x-only devices.
>
> So you should find UHCI controller devices when EHCI is enabled. And
> if you disable EHCI, the UHCI/OHCI controllers should be disabled
> too.
>   

Hmm, vt8237r has a separate device for EHCI that can be disabled without
disabling the UHCI controllers. I'm assuming that this essentially makes
them act as regular UHCI controllers.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Stefan Reinauer | 1 Oct 08:59
Picon

Re: EHCI stack to port to FILO?

* Corey Osgood <corey.osgood <at> gmail.com> [071001 05:03]:
> > So you should find UHCI controller devices when EHCI is enabled. And
> > if you disable EHCI, the UHCI/OHCI controllers should be disabled
> > too.
> 
> Hmm, vt8237r has a separate device for EHCI that can be disabled without
> disabling the UHCI controllers. I'm assuming that this essentially makes
> them act as regular UHCI controllers.

You don't have to disable the EHCI controller device to use the other.
If you don't use the EHCI device, the USB communications will just be
1.1 instead of 2.0

> boot: uda1:/vmlinuz root=/dev/hda1 console=ttyS0,115200n8
> earlyprintk=ttyS0,115200n8 ro            
> LinuxLabs USB bootloader
> New USB device, setting address 2
> New USB device, setting address 2
> [...]
> New USB device, setting address 2
> There is a USB device, but it won't init! This is a bad thing.

I think the driver is broken and/or not well tested, unfortunately.

--

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
      Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info <at> coresystems.de  • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carl-Daniel Hailfinger | 1 Oct 12:28
Picon
Gravatar

Re: [PATCH] improved SPI flash support (restructured)

On 29.09.2007 15:59, Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net> [070929 04:08]:
>> +#define ITE_SUPERIO_PORT1	0x2e
>> +#define ITE_SUPERIO_PORT2	0x4e
> 
> This has nothing to do with the IDE. All PC SuperIOs are on 2e or 4e.
> 
>> +int probe_spi(struct flashchip *flash)
>> +{
>> +	unsigned char readarr[3];
> 
> This should be a struct imho
> 
> typedef struct spi_id {
>         unsigned char vendor_id;
>         unsigned short device_id;
> } spi_id_t;

Yes, but the underlying generic SPI function uses an array for commands
and results. Once I add write/erase support, it will become obvious why
I used unsigned char arrays.

> The driver does only probe so far, right?

Yes.

> what about the other SPI commands?

Will be implemented once this patch has been tested.
(Continue reading)

Permalink | Reply | 8 comments |
headers
Stefan Reinauer | 1 Oct 12:54
Picon

Re: [PATCH] improved SPI flash support (restructured)

Carl-Daniel Hailfinger wrote:
>>> +int probe_spi(struct flashchip *flash)
>>> +{
>>> +	unsigned char readarr[3];
>>>       
>> This should be a struct imho
>>
>> typedef struct spi_id {
>>         unsigned char vendor_id;
>>         unsigned short device_id;
>> } spi_id_t;
>>     
>
> Yes, but the underlying generic SPI function uses an array for commands
> and results. Once I add write/erase support, it will become obvious why
> I used unsigned char arrays.
>
>   
Ah, so maybe it should be a union?

>> what about the other SPI commands?
>>     
>
> Will be implemented once this patch has been tested.
>   

Cool. I'll wait.

--

-- 
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Carl-Daniel Hailfinger | 1 Oct 13:01
Picon
Gravatar

Re: [PATCH] improved SPI flash support (restructured)

On 01.10.2007 12:54, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>>>> +int probe_spi(struct flashchip *flash)
>>>> +{
>>>> +	unsigned char readarr[3];
>>>>       
>>> This should be a struct imho
>>>
>>> typedef struct spi_id {
>>>         unsigned char vendor_id;
>>>         unsigned short device_id;
>>> } spi_id_t;
>>>     
>> Yes, but the underlying generic SPI function uses an array for commands
>> and results. Once I add write/erase support, it will become obvious why
>> I used unsigned char arrays.
>>
>>   
> Ah, so maybe it should be a union?

That's an option. I'll consider this once I refine the code.

Carl-Daniel

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ward Vandewege | 1 Oct 14:25
Picon
Gravatar

Re: [PATCH] improved SPI flash support (restructured)

On Mon, Oct 01, 2007 at 12:28:46PM +0200, Carl-Daniel Hailfinger wrote:
> Will be implemented once this patch has been tested.

Ah, yes, sorry, here's the output:

# ./flashrom 
Calibrating delay loop... ok
No LinuxBIOS table found.
Found chipset "NVIDIA MCP55": Enabling flash write... OK.
No EEPROM/flash device found.

# ./flashrom -v
Calibrating delay loop... ok
No LinuxBIOS table found.
Found chipset "NVIDIA MCP55": Enabling flash write... OK.
No EEPROM/flash device found.

# ./flashrom -v -m gigabyte:m57sli
Calibrating delay loop... ok
No LinuxBIOS table found.
Found chipset "NVIDIA MCP55": Enabling flash write... OK.
Found board "GIGABYTE GA-M57SLI": Enabling flash write... Serial flash
segment 0xfffe0000-0xffffffff enabled
Serial flash segment 0x000e0000-0x000fffff enabled
Serial flash segment 0xffee0000-0xffefffff disabled
Serial flash segment 0xfff80000-0xfffeffff enabled
LPC write to serial flash enabled
serial flash pin 29
OK.
No EEPROM/flash device found.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Carl-Daniel Hailfinger | 1 Oct 14:53
Picon
Gravatar

Re: [PATCH] improved SPI flash support (restructured)

On 01.10.2007 14:25, Ward Vandewege wrote:
> On Mon, Oct 01, 2007 at 12:28:46PM +0200, Carl-Daniel Hailfinger wrote:
>> Will be implemented once this patch has been tested.
> 
> Ah, yes, sorry, here's the output:

Thanks!

> # ./flashrom 
> Calibrating delay loop... ok
> No LinuxBIOS table found.
> Found chipset "NVIDIA MCP55": Enabling flash write... OK.
> No EEPROM/flash device found.
> 
> # ./flashrom -v
> Calibrating delay loop... ok
> No LinuxBIOS table found.
> Found chipset "NVIDIA MCP55": Enabling flash write... OK.
> No EEPROM/flash device found.
> 
> # ./flashrom -v -m gigabyte:m57sli
> Calibrating delay loop... ok
> No LinuxBIOS table found.
> Found chipset "NVIDIA MCP55": Enabling flash write... OK.
> Found board "GIGABYTE GA-M57SLI": Enabling flash write... Serial flash
> segment 0xfffe0000-0xffffffff enabled
> Serial flash segment 0x000e0000-0x000fffff enabled
> Serial flash segment 0xffee0000-0xffefffff disabled
> Serial flash segment 0xfff80000-0xfffeffff enabled
> LPC write to serial flash enabled
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alan Carvalho de Assis | 1 Oct 14:52
Picon
Gravatar

Re: GA-M57SLI SPI support

2007/10/1, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net>:
>
> On 30.09.2007 22:03, Alan Carvalho de Assis wrote:
> > Hi Carl-Daniel,
> >
> > 2007/9/28, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net>:
> > sic
> >> Yes, looking for testers.
> >>
> >
> > Currently I'm off finishing my master degree thesis but I still
> > reading LB posts and I want to know if exist some memory size
> > limitation on LPC-to-SPI?
>
> Yes, but it depends on the translation chip. For the IT8176F, we get
> exactly 1152kBytes if we can trust the datasheet. I prefer not to trust
> it, but so far nodoby has done experiments.
>
So it needs more some experiments.

> > Today we are limited at 2MB BIOS LPC flash but SPI flash can have too
> > many mega bytes. Is possible to use bigger SPI flash using this
> > LPC-to-SPI convertion?
>
> Yes and no. You can still read chips up to 16MBytes by hand, but it is
> CPU-intensive. I might write a driver for that in the future, though.
> Please note that more than 16MBytes can't be addressed with the SPI
> flash protocol because of its limitation to 24bit addresses.
>
Sure. At SST web site the max. flash size I found is 4MBytes (32Mbits).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ward Vandewege | 1 Oct 15:00
Picon
Gravatar

Re: [PATCH] improved SPI flash support (restructured)

On Mon, Oct 01, 2007 at 02:53:35PM +0200, Carl-Daniel Hailfinger wrote:
> Unfortunately not. Hmm... you used -v (verify) instead of -V (verbose).

Woops - that's what happens when you try to do stuff before coffee.

> And my patch was incomplete.
> 
> Can you try "flashrom -V -m gigabyte:m57sli" with the attached patch
> (against current svn) and report back?

Yes, this looks a lot better:

# ./flashrom -V -m gigabyte:m57sli
Calibrating delay loop... 283M loops per second. ok
No LinuxBIOS table found.
Found chipset "NVIDIA MCP55": Enabling flash write... OK.
Found board "GIGABYTE GA-M57SLI": Enabling flash write... Serial flash
segment 0xfffe0000-0xffffffff enabled
Serial flash segment 0x000e0000-0x000fffff enabled
Serial flash segment 0xffee0000-0xffefffff disabled
Serial flash segment 0xfff80000-0xfffeffff enabled
LPC write to serial flash enabled
serial flash pin 29
OK.
Probing for Am29F040B, 512 KB
probe_29f040b: id1 0x49, id2 0x4d
Probing for Am29F016D, 2048 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for AE49F2008, 256 KB
probe_jedec: id1 0x83, id2 0x83
(Continue reading)

Permalink | Reply | 2 comments |

Gmane