headers
Corey Osgood | 1 Aug 07:59
Picon

Re: Is Asrock 775VM800 supported?

Christian Sturm wrote:
> Corey Osgood wrote:
>
>   
>> At this time, no. vt8237r is a work in progress, but afaik
>> noone's working on the p4m800.
>>     
>
> Thanks for the answer!
>
>   
>> Can you please send the output of lspci -n and lspci -xxx? 
>>     
>
> Of course.
>   

Thanks for the info, and sorry for the delayed reply. Looking at your
register dump, it seems that the two are very similar, but unfortunately
your board uses ddr memory, and everything I've done is geared towards
ddr2. Should have checked that out before I got all excited, I guess.

If you're interested in doing testing and have all the necessary
equipment (serial cable, spare flash chips, etc), I'll look into it
further when I'm done my current project (which should a couple more
weeks at the absolute most). Some C coding skills would also really help.

-Corey

--

--
(Continue reading)

Permalink | Reply | 501 comments |
headers
Augusto Pedroza | 1 Aug 13:00
Picon

LinuxBIOS Memory Error / Windows Vista

Hy guys,
  While trying to boot vista installation DVD using linuxBIOS/qemu I got the following:

LinuxBIOS-3.0.0 Mon Jul 30 20:36:58 BRT 2007 starting...
Choosing fallback boot.
LAR: Attempting to open 'fallback/initram'.
LAR: Start 0xfffc0000 len 0x40000
LAR: current filename is normal/initram
LAR: current filename is normal/option_table
LAR: current filename is normal/payload
LAR: current filename is normal/stage2
LAR: current filename is linuxbios.bootblock
LAR: copy_file: No such file 'fallback/initram'
LAR: Run file fallback/initram failed: No such file.
Failed RAM init code

Has anyone tried that? What modifications do you guys suggest?

Thanks,

--
Augusto Pedroza 

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 0 comments |
headers
Carl-Daniel Hailfinger | 1 Aug 13:45
Picon
Gravatar

Re: Use Linux MTD framework for SPI flash?

On 31.07.2007 23:44, Stefan Reinauer wrote:
> * Jordan Crouse <jordan.crouse <at> amd.com> [070731 23:33]:
>>> In this scenario, who loads the correct kernel module(s)? 
>> The user.  
>>
>>> Which southbridges does the MTD SPI code support? Last time I checked
>>> only some ARM embedded systems were possibly supported.
>> Sure - but what SPI southbridges does flashrom support? 
> 
> Exactly as many as mtd for x86 based systems: 0

I don't know how difficult it will be for the existing chipset support
drivers in the MTD framework to add SPI support, but maybe it is easier
than we think.
* Nvidia CK804
* AMD 76X
* Intel ICHx

> Are there any plans for mtd to do hardware detection like /dev/bios or
> flashrom do? 

MTD sort of has autodetection for SPI flash chips once the SPI
southbridge has a driver loaded.

BTW, that is something that bothers me about flashrom: You have to add
probing support for every single flash chip to the code even if a new
chip is detected by probe_jedec. Some generic JEDEC detection run for
different sizes followed by a lookup in a id table would be so much
nicer. In case flashing needs special code we still have to read the
data sheets now and this won't get worse in the future, but having a
message "Your flash chip was detected as unknown (id $ID) from
$MANUFACTURER, most probable size is $SIZE, please mail linuxbios@"
would surely help a lot for adoption of flashrom.

Regards,
Carl-Daniel

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 4 comments |
headers
Otávio Alcântara | 1 Aug 13:50
Picon

Re: PIRQ REF DES AMD LXUVCRDK


Hello to all,


Marc wrote:

>Looks like the RAMDISK is blowing up. Try without it. Try running a
>memory test. You can built memtest as a payload.

I've used memtest as a payload and the test was sucessfully. Any other idea for the RAMDISK blow up?

Bellow the log of the linuxbios + memtest try out. My board is similar to AMD RDK UVC.

Thanks,

Otávio Alcântara

LinuxBIOS-2.0.0.0Fallback Qua Jul 25 07:18:07 BRT 2007 starting...
_MSR GLCP_SYS_RSTPLL (4c000014) value is: 00000498:07de0020
Done cpuRegInit
SMBUS READ ERROR:03 device:a2
Ram1.00
Ram2.00
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
SMBUS READ ERROR:03 device:a2
Ram3
DRAM controller init done.
RAM DLL lock
Ram4
Copying LinuxBIOS to ram.
Jumping to LinuxBIOS.
LinuxBIOS-2.0.0.0Fallback Qua Jul 25 07:37:45 BRT 2007 booting...
clocks_per_usec: 432
Enumerating buses...
Enter northbridge_init_early
writeglmsr: MSR 0x10000020, val 0x20000000:0x000fff80
writeglmsr: MSR 0x10000021, val 0x20000000:0x080fffe0
writeglmsr: MSR 0x1000002c, val 0x20000000:0x00000003
sizeram: _MSR MC_CF07_DATA: 10077014:00004840
sizeram: sizem 0x200MB
SysmemInit: enable for 512MBytes
usable RAM: 536739839 bytes
SysmemInit: MSR 0x10000028, val 0x2000001f:0xfdf00100
sizeram: _MSR MC_CF07_DATA: 10077014:00004840
sizeram: sizem 0x200MB
SMMGL0Init: 536739840 bytes
SMMGL0Init: offset is 0x80400000
SMMGL0Init: MSR 0x10000026, val 0x29fbe080:0x400fffe0
writeglmsr: MSR 0x10000080, val 0x00000000:0x00000003
writeglmsr: MSR 0x40000020, val 0x20000000:0x000fff80
writeglmsr: MSR 0x40000021, val 0x20000000:0x080fffe0
writeglmsr: MSR 0x4000002e, val 0x20000000:0x00000003
sizeram: _MSR MC_CF07_DATA: 10077014:00004840
sizeram: sizem 0x200MB
SysmemInit: enable for 512MBytes
usable RAM: 536739839 bytes
SysmemInit: MSR 0x4000002a, val 0x2000001f:0xfdf00100
SMMGL1Init:
SMMGL1Init: MSR 0x40000023, val 0x20000080:0x400fffe0
writeglmsr: MSR 0x40000080, val 0x00000000:0x00000001
writeglmsr: MSR 0x400000e3, val 0x60000000:0x033000f0
CPU_RCONF_DEFAULT (1808): 0x25FFFC02:0x11FFDF00
CPU_RCONF_BYPASS (180A): 0x00000000 : 0x00000000
L2 cache enabled
Enabling cache
GLPCI R1: system msr.lo 0x00100130 msr.hi 0x1ffdf000
GLPCI R2: system msr.lo 0x80400120 msr.hi 0x8041f000
Exit northbridge_init_early
Done cpubug fixes
Not Doing ChipsetFlashSetup()
<<<WARNING>>> Graphics init...
 <<WARNING!!!>>> VRC_VG value: 0xffff
Before VSA:
do_vsmbios
buf ilen 35441 olen60466
buf 00060000 *buf 186 buf[256k] 255
buf[0x20] signature is b0:10:e6:80
Call real_mode_switch_call_vsm
biosint: INT# 0x15
biosint: eax 0xbea7 ebx 0x4e53 ecx 0x10000026 edx 0x10000028
biosint: ebp 0x17ed4 esp 0xff0 edi 0x8a71 esi 0x38
biosint:  ip 0x5b3   cs 0x6000  flags 0x46
biosint: gs 0x0 fs 0x0 ds 0x6000 es 0x0
handleint21, eax 0xbea7
biosint: INT# 0x15
biosint: eax 0xbea4 ebx 0x4e53 ecx 0x10000026 edx 0x10000028
biosint: ebp 0x17ed4 esp 0xfee edi 0x8a71 esi 0x38
biosint:  ip 0x5c1   cs 0x6000  flags 0x46
biosint: gs 0x0 fs 0x0 ds 0x6000 es 0x0
handleint21, eax 0xbea4
do_vsmbios: VSA2 VR signature verified
After VSA:
<<<WARNING>>> Graphics init...
 <<WARNING!!!>>> VRC_VG value: 0x2808
Finding PCI configuration type.
PCI: Using configuration type 1
PCI_DOMAIN: 0000 enabled
APIC_CLUSTER: 0 enabled
PCI: pci_scan_bus for bus 00
PCI: 00: 01.0 [1022/2080] enabled
PCI: 00:01.1 [1022/2081] enabled
PCI: 00:01.2 [1022/2082] enabled
cs5536: southbridge_enable: dev is 00010180
Disabling static device: PCI: 00:0b.0
cs5536: southbridge_enable: dev is 00010420
Disabling static device: PCI: 00:0c.0
cs5536: southbridge_enable: dev is 000106c0
PCI: 00:0d.0 [10ec/8139] enabled
cs5536: southbridge_enable: dev is 00010960
Disabling static device: PCI: 00:0e.0
cs5536: southbridge_enable: dev is 00010c00
PCI: 00:0f.0 [1022/2090] enabled
cs5536: southbridge_enable: dev is 00010ea0
PCI: 00:0f.2 [1022/209a] enabled
cs5536: southbridge_enable: dev is 00011140
PCI: 00:0f.3 [1022/2093] enabled
cs5536: southbridge_enable: dev is 000113e0
PCI: 00:0f.4 [1022/2094] enabled
cs5536: southbridge_enable: dev is 00011680
PCI: 00:0f.5 [1022/2095] enabled
PCI: 00:0f.6 [1022/2096] enabled
PCI: 00:0f.7 [1022/2097] enabled
PCI: pci_scan_bus returning with max=000
done
Allocating resources...
Reading resources...
Done reading resources.
Setting resources...
PCI: 00:01.1 10 <- [0x00fd000000 - 0x00fdffffff] mem
PCI: 00:01.1 14 <- [0x00fe000000 - 0x00fe003fff] mem
PCI: 00:01.1 18 <- [0x00fe004000 - 0x00fe007fff] mem
PCI: 00:01.1 1c <- [0x00fe008000 - 0x00fe00bfff] mem
PCI: 00:01.1 20 <- [0x00fe00c000 - 0x00fe00ffff] mem
PCI: 00:01.2 10 <- [0x00fe010000 - 0x00fe013fff] mem
PCI: 00:0d.0 10 <- [0x0000001000 - 0x00000010ff] io
PCI: 00:0d.0 14 <- [0x00fe019000 - 0x00fe0190ff] mem
PCI: 00:0f.0 10 <- [0x0000001cb0 - 0x0000001cb7] io
PCI: 00:0f.0 14 <- [0x0000001400 - 0x00000014ff] io
PCI: 00:0f.0 18 <- [0x0000001c00 - 0x0000001c3f] io
PCI: 00:0f.0 1c <- [0x0000001c80 - 0x0000001c9f] io
PCI: 00:0f.0 20 <- [0x0000001800 - 0x000000187f] io
PCI: 00:0f.0 24 <- [0x0000001c40 - 0x0000001c7f] io
PCI: 00:0f.2 20 <- [0x0000001ca0 - 0x0000001caf] io
PCI: 00:0f.3 10 <- [0x0000001880 - 0x00000018ff] io
PCI: 00:0f.4 10 <- [0x00fe016000 - 0x00fe016fff] mem
PCI: 00:0f.5 10 <- [0x00fe017000 - 0x00fe017fff] mem
PCI: 00:0f.6 10 <- [0x00fe014000 - 0x00fe015fff] mem
PCI: 00:0f.7 10 <- [0x00fe018000 - 0x00fe018fff] mem
Done setting resources.
Done allocating resources.
Enabling resources...
PCI: 00:01.0 cmd <- 145
PCI: 00:01.1 subsystem <- 00/00
PCI: 00:01.1 cmd <- 142
PCI: 00:01.2 cmd <- 142
PCI: 00:0d.0 subsystem <- 00/00
PCI: 00:0d.0 cmd <- 143
cs5536: cs5536_pci_dev_enable_resources()
PCI: 00: 0f.0 cmd <- 149
PCI: 00:0f.2 cmd <- 141
PCI: 00:0f.3 subsystem <- 00/00
PCI: 00:0f.3 cmd <- 141
PCI: 00:0f.4 subsystem <- 00/00
PCI: 00:0f.4 cmd <- 142
PCI: 00:0f.5 subsystem <- 00/00
PCI: 00:0f.5 cmd <- 142
PCI: 00:0f.6 cmd <- 142
PCI: 00:0f.7 cmd <- 142
done.
Initializing devices...
Root Device init
Norwich ENTER init
Norwich EXIT init
PCI: 00:01.0 init
PCI: 00: 01.1 init
PCI: 00:0d.0 init
PCI: 00:0f.0 init
cs5536: southbridge_init
RTC Init
rct_init finished
PCI: 00:0f.2 init
PCI: 00:0f.3 init
PCI: 00:0f.4 init
PCI: 00:0f.5 init
APIC_CLUSTER: 0 init
Initializing CPU #0
CPU: vendor AMD device 5a2
CPU: family 05, model 0a, stepping 02
model_lx_init
Enabling cache
A20 (0x92): 2
A20 (0x92): 2
CPU model_lx_init DONE
CPU #0 Initialized
PCI: 00:01.2 init
PCI: 00:0f.6 init
PCI: 00:0f.7 init
Devices initialized
Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...done
Checking IRQ routing table consistency...
check_pirq_routing_table() - irq_routing_table located at: 0x000f0000
/home/otavio/LinuxBIOSv2/src/arch/i386/boot/pirq_routing.c:    36:check_pirq_routing_table() - checksum is: 0x00 but should be: 0x96
done.
write_pirq_routing_table(8000785C, BAAB)
PIR Entry 0 Dev/Fn: 8 Slot: 0
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 0 PIRQ: 0
INT: C bitmap: 0 PIRQ: 0
INT: D bitmap: 0 PIRQ: 0
Assigning IRQ 11 to 0:1.1
  Readback = 11
Assigning IRQ 11 to 0:1.2
  Readback = 11
PIR Entry 1 Dev/Fn: 78 Slot: 0
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 400 PIRQ: 10
INT: C bitmap: 400 PIRQ: 10
INT: D bitmap: 800 PIRQ: 11
Assigning IRQ 10 to 0:f.3
  Readback = 10
Assigning IRQ 11 to 0:f.4
  Readback = 11
Assigning IRQ 11 to 0:f.5
  Readback = 11
PIR Entry 2 Dev/Fn: 68 Slot: 0
INT: A bitmap: 800 PIRQ: 11
INT: B bitmap: 0 PIRQ: 0
INT: C bitmap: 0 PIRQ: 0
INT: D bitmap: 0 PIRQ: 0
Assigning IRQ 11 to 0:d.0
  Readback = 11
PIR Entry 3 Dev/Fn: 0 Slot: 0
INT: A bitmap: 0 PIRQ: 0
INT: B bitmap: 0 PIRQ: 0
INT: C bitmap: 0 PIRQ: 0
INT: D bitmap: 0 PIRQ: 0
PIR Entry 4 Dev/Fn: 0 Slot: 0
INT: A bitmap: 0 PIRQ: 0
INT: B bitmap: 0 PIRQ: 0
INT: C bitmap: 0 PIRQ: 0
INT: D bitmap: 0 PIRQ: 0
PIR Entry 5 Dev/Fn: 0 Slot: 0
INT: A bitmap: 0 PIRQ: 0
INT: B bitmap: 0 PIRQ: 0
INT: C bitmap: 0 PIRQ: 0
INT: D bitmap: 0 PIRQ: 0
Moving GDT to 0x500...ok
Adjust low_table_end from 0x00000530 to 0x00001000
Adjust rom_table_end from 0x000f0400 to 0x00100000
Wrote linuxbios table at: 00000530 - 000006c4  checksum 379e

Welcome to elfboot, the open sourced starter.
January 2002, Eric Biederman.
Version 1.3

rom_stream: 0xfff89000 - 0xfffeffff
Found ELF candidate at offset 0
header_offset is 0
Try to load at offset 0x0
New segment addr 0x10000 size 0x17790 offset 0x1000 filesize 0x17790
(cleaned up) New segment addr 0x10000 size 0x17790 offset 0x1000 filesize 0x17790
Loading Segment: addr: 0x000000001f7bc000 memsz: 0x000000000000c000 filesz: 0x000000000000c000
Loading Segment: addr: 0x000000000001c000 memsz: 0x000000000000b790 filesz: 0x000000000000b790
Jumping to boot code at 0x10000
--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 2 comments |
headers
Stefan Reinauer | 1 Aug 14:28
Picon

Re: Use Linux MTD framework for SPI flash?

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net> [070801 13:45]:
> On 31.07.2007 23:44, Stefan Reinauer wrote:
> > * Jordan Crouse <jordan.crouse <at> amd.com> [070731 23:33]:
> >>> In this scenario, who loads the correct kernel module(s)? 
> >> The user.  
> >>
> >>> Which southbridges does the MTD SPI code support? Last time I checked
> >>> only some ARM embedded systems were possibly supported.
> >> Sure - but what SPI southbridges does flashrom support? 
> > 
> > Exactly as many as mtd for x86 based systems: 0
> 
> I don't know how difficult it will be for the existing chipset support
> drivers in the MTD framework to add SPI support, but maybe it is easier
> than we think.

Sure it is not difficult, it just has to be done by someone with
datasheets.

> * Nvidia CK804
> * AMD 76X
> * Intel ICHx

The code in mtd is completely useless. It just enables mapping the flash
to memory.
For SPI the actual flash logic (same as a flash chip driver for pre-spi
flash) goes into the southbridge code. Practically this means that
generic SPI support is completely useless unless you have your specific
southbridge supported.

> MTD sort of has autodetection for SPI flash chips once the SPI
> southbridge has a driver loaded.

With autodetection I was rather thinking about detection of the modules
to load.

Auto detection of SPI flash is a de facto nop, since all the logic is in
the southbridge driver, which you just loaded manually.

> BTW, that is something that bothers me about flashrom: You have to add
> probing support for every single flash chip to the code even if a new
> chip is detected by probe_jedec.

Why would you add probing support for chips if probe_jedec does the job
already?

The reason you have to have a function pointer for probing is that some
flash chips answer to the wrong probing commands with non-ID data. So
some few flash chips need their own probing function.

SPI will also get its own probing function probe_spi which calls into
the southbridge specific code to do the job.

> Some generic JEDEC detection run for
> different sizes followed by a lookup in a id table would be so much
> nicer. 

Why? Searching in positions where a chip can't possibly be anyways can
have pretty bad side effects. 

> In case flashing needs special code we still have to read the
> data sheets now and this won't get worse in the future, but having a
> message "Your flash chip was detected as unknown (id $ID) from
> $MANUFACTURER, most probable size is $SIZE, please mail linuxbios@"
> would surely help a lot for adoption of flashrom.

This can easily be done already by just adding a small snippet to probe_jedec.
just read the memory location before and after the ID command and test
if it changed.

-- 
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/

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 3 comments |
headers
Peter Stuge | 1 Aug 15:49
Picon

Re: PIRQ REF DES AMD LXUVCRDK

On Wed, Aug 01, 2007 at 08:50:30AM -0300, Otávio Alcântara wrote:
> I've used memtest as a payload and the test was sucessfully.

How long did you leave it running? 24 hours is good to make sure.

> Any other idea for the RAMDISK blow up?

It's usually because of bad RAM, unless there is a configuration
error in the initrd.

> Bellow the log of the linuxbios + memtest try out. My board is
> similar to AMD RDK UVC.

Sorry, the ANSI codes make the memtest output unlegible for me. :\

//Peter

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 1 comment |
headers
Carl-Daniel Hailfinger | 1 Aug 15:52
Picon
Gravatar

flashrom: mcp55 enable bit comment wrong?

Hi,

> static int enable_flash_mcp55(struct pci_dev *dev, char *name)
> {
>         unsigned char old, new, byte;
>         unsigned short word;
> 
>         /* Set the 4MB enable bit bit */
wrong comment, probably copy-pasted?

>         byte = pci_read_byte(dev, 0x88);
>         byte |= 0xff;           /* 256K */
>         pci_write_byte(dev, 0x88, byte);
>         byte = pci_read_byte(dev, 0x8c);
>         byte |= 0xff;           /* 1M */
>         pci_write_byte(dev, 0x8c, byte);
>         word = pci_read_word(dev, 0x90);
>         word |= 0x7fff;         /* 15M */
                                     ^^^
Shouldn't that be 16M?

>         pci_write_word(dev, 0x90, word);

Regards,
Carl-Daniel

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 501 comments |
headers
Carl-Daniel Hailfinger | 1 Aug 16:17
Picon
Gravatar

Re: Use Linux MTD framework for SPI flash?

On 01.08.2007 14:28, Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net> [070801 13:45]:
>> On 31.07.2007 23:44, Stefan Reinauer wrote:
>>> * Jordan Crouse <jordan.crouse <at> amd.com> [070731 23:33]:
>>>>> In this scenario, who loads the correct kernel module(s)? 
>>>> The user.  
>>>>
>>>>> Which southbridges does the MTD SPI code support? Last time I checked
>>>>> only some ARM embedded systems were possibly supported.
>>>> Sure - but what SPI southbridges does flashrom support? 
>>> Exactly as many as mtd for x86 based systems: 0
>> I don't know how difficult it will be for the existing chipset support
>> drivers in the MTD framework to add SPI support, but maybe it is easier
>> than we think.
> 
> Sure it is not difficult, it just has to be done by someone with
> datasheets.
> 
>> * Nvidia CK804
>> * AMD 76X
>> * Intel ICHx
> 
> The code in mtd is completely useless. It just enables mapping the flash
> to memory.

Not really. At least for ck804, it also enables flashing. Just look for
pci_read_config_byte in ck804xrom.c and notice the similarities with
chipset_enable.c from flashrom.

> For SPI the actual flash logic (same as a flash chip driver for pre-spi
> flash) goes into the southbridge code. Practically this means that
> generic SPI support is completely useless unless you have your specific
> southbridge supported.

I see.

>> MTD sort of has autodetection for SPI flash chips once the SPI
>> southbridge has a driver loaded.
>  
> With autodetection I was rather thinking about detection of the modules
> to load.
> 
> Auto detection of SPI flash is a de facto nop, since all the logic is in
> the southbridge driver, which you just loaded manually.

The pci device table ist there, so if somebody automatically loads all
pci drivers matching his hardware, he is covered.

>> BTW, that is something that bothers me about flashrom: You have to add
>> probing support for every single flash chip to the code even if a new
>> chip is detected by probe_jedec.
> 
> Why would you add probing support for chips if probe_jedec does the job
> already?

I don't want to do that.

> The reason you have to have a function pointer for probing is that some
> flash chips answer to the wrong probing commands with non-ID data. So
> some few flash chips need their own probing function.

Sure.

> SPI will also get its own probing function probe_spi which calls into
> the southbridge specific code to do the job.
> 
>> Some generic JEDEC detection run for
>> different sizes followed by a lookup in a id table would be so much
>> nicer. 
> 
> Why? Searching in positions where a chip can't possibly be anyways can
> have pretty bad side effects. 

probe_jedec is called for every supported chip in the list with
probe_jedec as probe function. Calling probe_jedec only once for every
possible/reasonable chip size would be a lot more efficient.

>> In case flashing needs special code we still have to read the
>> data sheets now and this won't get worse in the future, but having a
>> message "Your flash chip was detected as unknown (id $ID) from
>> $MANUFACTURER, most probable size is $SIZE, please mail linuxbios@"
>> would surely help a lot for adoption of flashrom.
> 
> This can easily be done already by just adding a small snippet to probe_jedec.
> just read the memory location before and after the ID command and test
> if it changed.

That would be nice.

Regards,
Carl-Daniel

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 2 comments |
headers
Ed Swierk | 1 Aug 16:19
Favicon

Re: flashrom: mcp55 enable bit comment wrong?

On 8/1/07, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net> wrote:
> Hi,
>
> > static int enable_flash_mcp55(struct pci_dev *dev, char *name)
> > {
> >         unsigned char old, new, byte;
> >         unsigned short word;
> >
> >         /* Set the 4MB enable bit bit */
> wrong comment, probably copy-pasted?
>
> >         byte = pci_read_byte(dev, 0x88);
> >         byte |= 0xff;           /* 256K */
> >         pci_write_byte(dev, 0x88, byte);
> >         byte = pci_read_byte(dev, 0x8c);
> >         byte |= 0xff;           /* 1M */
> >         pci_write_byte(dev, 0x8c, byte);
> >         word = pci_read_word(dev, 0x90);
> >         word |= 0x7fff;         /* 15M */
>                                      ^^^
> Shouldn't that be 16M?
>
> >         pci_write_word(dev, 0x90, word);

Yes and yes.

--Ed

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 501 comments |
headers
Peter Stuge | 1 Aug 16:49
Picon

Re: Use Linux MTD framework for SPI flash?

On Wed, Aug 01, 2007 at 04:17:20PM +0200, Carl-Daniel Hailfinger wrote:
> >> * Nvidia CK804
> >> * AMD 76X
> >> * Intel ICHx
> > 
> > The code in mtd is completely useless.
> 
> Not really.

Yes, really.

> At least for ck804, it also enables flashing. Just look for
> pci_read_config_byte in ck804xrom.c and notice the similarities
> with chipset_enable.c from flashrom.

..because they both only do parallel flash.

There's nothing in the MTD code that supports SPI flash on the above
hardware.

It's completely different from parallel flash.

//Peter

--

-- 
linuxbios mailing list
linuxbios <at> linuxbios.org
http://www.linuxbios.org/mailman/listinfo/linuxbios
Permalink | Reply | 0 comments |

Gmane