headers
Carl-Daniel Hailfinger | 1 Mar 2008 01:13
Picon

Re: flashrom issues??

On 29.02.2008 20:21, Stefan Reinauer wrote:
> * Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net> [080229 20:13]:
>   
>>>>> Yes, it means the actual flash write mechanism is protected, though the
>>>>> ID command gets through. I had the same thing on another ICH4M board.
>>>>> Might be SMM protection, some GPIO or some other mapping/locking
>>>>> mechanism.

"Might be SMM...", so this is not certain.

>>>> Do you remember what you did to fix this on the ICH4-M?
>>>>     
>>>>         
>>> The issue remained unfixed, I used a Galep5 to burn the flash chips.
>>>   
>>>       
>> In theory, this should be debuggable with DOS ports of the ICH GPIO dumper 
>> and superiotool.
>>     
>
> SMM based bios lock down? How so? It does not seem to be a GPIO issue in
> case. 
>   

If the lockdown is indeed SMM based, we can find out with superiotool 
and the GPIO dumper (they will show no changes in GPIO configuration). 
Then again, if you can ID the chip, it means you can write to it and the 
only thing missing is setting the TBL# and WP# pins of the flash chip 
high. Both pins are probably connected to some GPIOs, so unless SMM 
protects access to the GPIO settings, flashing should be possible.
(Continue reading)

Permalink | Reply | 38 comments |
headers
Carl-Daniel Hailfinger | 1 Mar 2008 02:58
Picon

Re: patch: dbe62

On 29.02.2008 17:52, ron minnich wrote:
> On Fri, Feb 29, 2008 at 5:41 AM, Peter Stuge <peter <at> stuge.se> wrote:
>
>   
>>  > >  > +void mainboard_pre_payload(void)
>>  > >  > +{
>>  > >  > +     geode_pre_payload();
>>  > >  > +     banner(BIOS_DEBUG, "mainboard_pre_payload: done");
>>  > >  > +}
>>  > >
>>  > >  Why do we need this mainboard code when it is only calling a
>>  > >  function that can be determined using the dts?
>>  >
>>  > Show me how. I don't know.
>>
>>  arch/x86/stage1.c currently calls mainboard_pre_payload() - for
>>  Geode LX the call has nothing to do with the mainboard and
>>  everything to do with the north.
>>
>>  geode_pre_payload() is defined in geodelx/geodelxinit.c, so one easy
>>  way is to rename it to northbridge_amd_geodelx_pre_payload() and
>>  generate the call from data in the dts.
>>
>>  Another way would be to add it to struct device_operations. I like
>>  that better actually.
>>     
>
>
> Yep, but here you've hit a limitation in the design which we never
> thought of. Device stuff is in stage 2. But this mainboard_early stuff
(Continue reading)

Permalink | Reply | 13 comments |
headers
ron minnich | 1 Mar 2008 03:03
Picon

Re: patch: dbe62

On Fri, Feb 29, 2008 at 5:58 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 <at> gmx.net> wrote:

>  Peter's idea was probably to separate code from data and I think there
>  is some potential in that idea. write_pirq_routing_table() is identical
>  for alix1c and dbe62 and could in theory really live in the south
>  directory. AFAICS this wouldn't even require any changes in the function.

it's a great idea. I just don't yet know how to do it.

ron

--

-- 
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 10 comments |
headers
ron minnich | 1 Mar 2008 03:06
Picon

Re: patch: dbe62

On Fri, Feb 29, 2008 at 5:58 PM, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2006 <at> gmx.net> wrote:

>  5. Maybe the name of mainboard_pre_payload() is unfortunate and we
>  should have pre_payload() which calls cpu_pre_payload(),
>  chipset_pre_payload() and mainboard_pre_payload() in a row. That way, we
>  don't have to put any GeodeLX ROM cache disabling below mainboard() and
>  keep that stuff local to the southbridge code.
>

My concern here is we're going to walk our way back to the v1 style
functions that end up mostly empty (e.g. mainboard_pre_payload(){}) on
most targets. Mainboard_pre_payload is a hack but I have no good ideas
on workarounds. Let's think this out some more. We'll get it.

The chipsets are always changing our ideas on how to set up the software :-)

ron

--

-- 
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 1 comment |
headers
Carl-Daniel Hailfinger | 1 Mar 2008 03:33
Picon

Re: patch: dbe62

On 01.03.2008 03:06, ron minnich wrote:
> On Fri, Feb 29, 2008 at 5:58 PM, Carl-Daniel Hailfinger wrote:
>   
>>  5. Maybe the name of mainboard_pre_payload() is unfortunate and we
>>  should have pre_payload() which calls cpu_pre_payload(),
>>  chipset_pre_payload() and mainboard_pre_payload() in a row. That way, we
>>  don't have to put any GeodeLX ROM cache disabling below mainboard() and
>>  keep that stuff local to the southbridge code
>
> My concern here is we're going to walk our way back to the v1 style
> functions that end up mostly empty (e.g. mainboard_pre_payload(){}) on
> most targets. Mainboard_pre_payload is a hack but I have no good ideas
> on workarounds. Let's think this out some more. We'll get it.
>   

Actually, these empty functions should be zero cost in the binary with 
gcc, but they clutter the source code. Hmm. I'd like something like 
"overridable functions" similar to weak functions, but where gcc is able 
to strip out the call if no non-empty function exists.

> The chipsets are always changing our ideas on how to set up the software :-)
>   

Indeed.

Regards,
Carl-Daniel

--

-- 
http://www.hailfinger.org/
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Stuge | 1 Mar 2008 03:51
Picon

Re: Geode GX / CS5535 / PIC

On Fri, Feb 29, 2008 at 05:11:31PM +0100, Uwe Hermann wrote:
> > Here's the board itself:
> > http://www.nottoxic.com/wapcc/dectop/wiki/lib/exe/fetch.php?cache=cache&media=hardware:dectop:dectoplb.jpg
> 
> The BIOS chip is soldered.

It looks like J11 may also have the LPC bus signals. If the boot
flash selector ball is also on J11 you could use Artec's dongle or
just another LPC flash chip to work on coreboot rather than having to
desolder the existing chip.

//Peter

--

-- 
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 1 comment |
headers
Peter Stuge | 1 Mar 2008 03:54
Picon

Re: Fwd: Unable to power up db800 with coreboot

On Fri, Feb 29, 2008 at 09:47:16AM -0800, Phani Babu Giddi wrote:
> MENULST_FILE = "hda1:/grub/menu.lst"
> 
> AUTOBOOT_FILE = "hda1:/vmlinuz initrd hda1:/initrd root=/dev/hda3
>   vga=0x317 console=tty0 console=ttyS0,115200"

As far as I know these two are mutually exclusive. If using the grub
compatibility stuff in FILO then AUTOBOOT_FILE will never be used.

I don't like grub and thus always stick to only using AUTOBOOT_FILE.

In your case the line looks fine if the kernel is stored in
/boot/vmlinuz, if it's /vmlinuz then change to hda3 instead of hda1
in the first argument.

Oh, and make sure you build FILO with reiserfs support if the kernel
is on your root partition.

//Peter

--

-- 
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 1 comment |
headers
Phani Babu Giddi | 1 Mar 2008 04:04
Picon

Re: Fwd: Unable to power up db800 with coreboot

Hi Peter,
 
Yes I have turned on resierfs and ext2 too because /boot is and ext2 partition. From your description it looks like the AUTOBOOT options are good but not sure why it reports of Unsupported image format. Let me first get rid of GRUB. Do yout know if FILO works for all versions of GRUB boot loaders or there are some specific boot loaders that it supports.
 
Regards,
Phani

On Fri, Feb 29, 2008 at 6:54 PM, Peter Stuge <peter <at> stuge.se> wrote:
On Fri, Feb 29, 2008 at 09:47:16AM -0800, Phani Babu Giddi wrote:
> MENULST_FILE = "hda1:/grub/menu.lst"
>
> AUTOBOOT_FILE = "hda1:/vmlinuz initrd hda1:/initrd root=/dev/hda3
>   vga=0x317 console=tty0 console=ttyS0,115200"

As far as I know these two are mutually exclusive. If using the grub
compatibility stuff in FILO then AUTOBOOT_FILE will never be used.

I don't like grub and thus always stick to only using AUTOBOOT_FILE.

In your case the line looks fine if the kernel is stored in
/boot/vmlinuz, if it's /vmlinuz then change to hda3 instead of hda1
in the first argument.

Oh, and make sure you build FILO with reiserfs support if the kernel
is on your root partition.

--

-- 
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 0 comments |
headers
Corey Osgood | 1 Mar 2008 07:40
Picon

Re: GENFADT and GENDSDT

On Fri, Feb 29, 2008 at 2:15 PM, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 <at> gmx.net> wrote:

Please note that iasl can't perform any of the functions of
gendsdt

dumping the dsdt to a file, then iasl -d and iasl -tc will produce the same thing, but with some sort of optimizations. Disabling the optimizations, with -oa should produce exactly the same output as gendsdt, except for whitespace, the copyright header, and some dsdt header info (compiler, etc). You're entirely correct about genfadt vs iasl though, and now you've got me thinking that two utiliities is a better idea.

On Fri, Feb 29, 2008 at 2:56 PM, Uwe Hermann <uwe <at> hermann-uwe.de> wrote:
On Fri, Feb 29, 2008 at 08:15:24PM +0100, Carl-Daniel Hailfinger wrote:
> Can we at least agree on the name of the directory where the tool(s)
> should live? Should we call it gen_acpi or genacpi? I'd say you decide

genacpi sounds good.


Uwe.

Ack. Here's a sign-off to make it with:

Signed-off-by: Corey Osgood <corey.osgood <at> gmail.com>

-Corey
--

-- 
coreboot mailing list
coreboot <at> coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Permalink | Reply | 2 comments |
headers
Jun Ma | 1 Mar 2008 08:59
Picon

Probe missing on W49F002U

Hi, all.
 I downloaded flashrom from
http://www.openbios.org/viewvc/trunk/util/flashrom.tar.gz?view=tar,
also it was built correctly,  when I scp it to an SIS530/SIS5595 board
with debian-4.0r2, it just can't recognize my Winbond W49G002U EEPROM,
here comes the verbose log:

Sis530:~# ./flashrom -c W49F002U
Calibrating delay loop... OK.
No coreboot table found.
Found chipset "SIS5595", enabling flash write... OK.
No EEPROM/flash device found.
Sis530:~# ./flashrom -R
flashrom r
Sis530:~# ./flashrom --version
flashrom r
Sis530:~# ./flashrom -V -r
Calibrating delay loop... 59M loops per second. OK.
No coreboot table found.
Found chipset "SIS5595", enabling flash write... OK.
Probing for Am29F040B, 512 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for Am29LV040B, 512 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for Am29F016D, 2048 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for AE49F2008, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for At29C040A, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for At29C020, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for At49F002(N), 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for At49F002(N)T, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for EN29F002(A)(N)T, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for EN29F002(A)(N)B, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for MBM29F400TC, 512 KB
probe_m29f400bt: id1 0xff, id2 0xff
Probing for MX29F002, 256 KB
probe_29f002: id1 0xff, id2 0xff
Probing for MX25L4005, 512 KB
generic_spi_command called, but no SPI chipset detected
Probing for MX25L8005, 1024 KB
generic_spi_command called, but no SPI chipset detected
Probing for MX25L3205, 4096 KB
generic_spi_command called, but no SPI chipset detected
Probing for S25FL016A, 2048 KB
generic_spi_command called, but no SPI chipset detected
Probing for SST25VF040B, 512 KB
generic_spi_command called, but no SPI chipset detected
Probing for SST25VF016B, 2048 KB
generic_spi_command called, but no SPI chipset detected
Probing for SST29EE020A, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST28SF040A, 512 KB
probe_28sf040: id1 0xff, id2 0xff
Probing for SST39SF010A, 128 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST39SF020A, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST39SF040, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST39VF020, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF040B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF040, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF020A, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF080A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF002A/B, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF003A/B, 384 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF004A/B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF008A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for SST49LF004C, 512 KB
probe_49lfxxxc: id1 0xff, id2 0xff
Probing for SST49LF008C, 1024 KB
probe_49lfxxxc: id1 0xff, id2 0xff
Probing for SST49LF016C, 2048 KB
probe_49lfxxxc: id1 0xff, id2 0xff
Probing for SST49LF160C, 2048 KB
probe_49lfxxxc: id1 0xff, id2 0xff
Probing for Pm49FL002, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for Pm49FL004, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for Pm25LV512, 64 KB
generic_spi_command called, but no SPI chipset detected
Probing for Pm25LV010, 128 KB
generic_spi_command called, but no SPI chipset detected
Probing for Pm25LV020, 256 KB
generic_spi_command called, but no SPI chipset detected
Probing for Pm25LV040, 512 KB
generic_spi_command called, but no SPI chipset detected
Probing for Pm25LV080B, 1024 KB
generic_spi_command called, but no SPI chipset detected
Probing for Pm25LV016B, 2048 KB
generic_spi_command called, but no SPI chipset detected
Probing for W29C011, 128 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W29C040P, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W29C020C, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W29EE011, 128 KB
probe_w29ee011: id1 0xff, id2 0xff
Probing for W49F002U, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W49V002A, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W49V002FA, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W39V040FA, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W39V040A, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W39V040B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W39V080A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for W25x10, 128 KB
generic_spi_command called, but no SPI chipset detected
Probing for W25x20, 256 KB
generic_spi_command called, but no SPI chipset detected
Probing for W25x40, 512 KB
generic_spi_command called, but no SPI chipset detected
Probing for W25x80, 1024 KB
generic_spi_command called, but no SPI chipset detected
Probing for M29F002B, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FW040, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M29W040B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M29F002T/NT, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M29F400BT, 512 KB
probe_m29f400bt: id1 0xff, id2 0xff
Probing for M50FLW040A, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FLW040B, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FLW080A, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FLW080B, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FW080, 1024 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50FW016, 2048 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M50LPW116, 2048 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M29W010B, 128 KB
probe_jedec: id1 0xff, id2 0xff
Probing for M29F040B, 512 KB
probe_29f040b: id1 0xff, id2 0xff
Probing for M25P05-A, 64 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P10-A, 128 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P20, 256 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P40, 512 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P80, 1024 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P16, 2048 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P32, 4096 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P64, 8192 KB
generic_spi_command called, but no SPI chipset detected
Probing for M25P128, 16384 KB
generic_spi_command called, but no SPI chipset detected
Probing for 82802ab, 512 KB
probe_82802ab: id1 0xff, id2 0xff
Probing for 82802ac, 1024 KB
probe_82802ab: id1 0xff, id2 0xff
Probing for F49B002UA, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for LHF00L04, 1024 KB
probe_lhf00l04: id1 0xff, id2 0xff
Probing for S29C51001T, 128 KB
probe_jedec: id1 0xff, id2 0xff
Probing for S29C51002T, 256 KB
probe_jedec: id1 0xff, id2 0xff
Probing for S29C51004T, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for S29C31004T, 512 KB
probe_jedec: id1 0xff, id2 0xff
Probing for EON unknown SPI chip, 0 KB
WARNING: size: 0 -> 4096 (page size)
generic_spi_command called, but no SPI chipset detected
Probing for MX unknown SPI chip, 0 KB
WARNING: size: 0 -> 4096 (page size)
generic_spi_command called, but no SPI chipset detected
Probing for PMC unknown SPI chip, 0 KB
WARNING: size: 0 -> 4096 (page size)
generic_spi_command called, but no SPI chipset detected
Probing for SST unknown SPI chip, 0 KB
WARNING: size: 0 -> 4096 (page size)
generic_spi_command called, but no SPI chipset detected
Probing for ST unknown SPI chip, 0 KB
WARNING: size: 0 -> 4096 (page size)
generic_spi_command called, but no SPI chipset detected
No EEPROM/flash device found.
Sis530:~#

After quick reading of your source code, I saw this probing function:
int probe_jedec(struct flashchip *flash)
{
      volatile uint8_t *bios = flash->virtual_memory;
      uint8_t id1, id2;
      uint32_t largeid1, largeid2;

      /* Issue JEDEC Product ID Entry command */
      *(volatile uint8_t *)(bios + 0x5555) = 0xAA;
      myusec_delay(10);
      *(volatile uint8_t *)(bios + 0x2AAA) = 0x55;
      myusec_delay(10);
      *(volatile uint8_t *)(bios + 0x5555) = 0x90;
      /* Older chips may need up to 100 us to respond. The ATMEL 29C020
       * needs 10 ms according to the data sheet, but it has been tested
       * to work reliably with 20 us. Allow a factor of 2 safety margin.
       */
      myusec_delay(40);

      /* Read product ID */
      id1 = *(volatile uint8_t *)bios;
      id2 = *(volatile uint8_t *)(bios + 0x01);
      largeid1 = id1;
      largeid2 = id2;

      /* Check if it is a continuation ID, this should be a while loop. */
      if (id1 == 0x7F) {
              largeid1 <<= 8;
              id1 = *(volatile uint8_t *)(bios + 0x100);
              largeid1 |= id1;
      }
      if (id2 == 0x7F) {
              largeid2 <<= 8;
              id2 = *(volatile uint8_t *)(bios + 0x101);
              largeid2 |= id2;
      }

      /* Issue JEDEC Product ID Exit command */
      *(volatile uint8_t *)(bios + 0x5555) = 0xAA;
      myusec_delay(10);
      *(volatile uint8_t *)(bios + 0x2AAA) = 0x55;
      myusec_delay(10);
      *(volatile uint8_t *)(bios + 0x5555) = 0xF0;
      myusec_delay(40);

      printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__,
largeid1, largeid2);
      if (largeid1 == flash->manufacture_id && largeid2 == flash->model_id)
              return 1;

      return 0;
}

Seems flashrom routing got 0xff, 0xff on largeid1, largeid2.
Has anybody tested this routing on SIS530?
Thanks.

-- 
FIXME if it is wrong.

--

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

Gmane