Re: [flashrom] Flashrom - DOS version report

[Carl-Daniel Hailfinger]

Hi,

[fullquote for [e-mail]]

On 23.03.2010 22:58, RayeR wrote:
> > That is very strange. Do you have a log?
> > SB600 should work fine. Maybe the SPI chip is not
> > attached to the SB600 but instead to the SuperI/O.
> > Can you try
> > flashrom -p it87spi
>
> Yes here's it:
>
> C:\F>flashrom.exe -p it87spi
> flashrom v0.9.1-r933
> Error: Programmer initialization failed.

OK, so it is not ITE IT87.
> C:\F>flashrom.exe -V -r
> flashrom v0.9.1-r933
> No coreboot table found.
> DMI string system-manufacturer: "Dell Inc.          "
> DMI string system-product-name: "OptiPlex 320              "
> DMI string system-version: "Not Specified"
> DMI string baseboard-manufacturer: "Dell Inc.           "
> DMI string baseboard-product-name: "0CU395"
> DMI string baseboard-version: "   "
> DMI string chassis-type: "Tower"
> Found chipset "AMD SB600", enabling flash write... SPI base address is
> at 0xd8000
> Error accessing SB600 SPI registers, 0x1000 bytes at 0x000d8000
> dpmi mmap failed: No such file or directory (ENOENT)

Ah yes. That's a limitation of the DOS port of flashrom.
Usually the SB600 SPI base address is near the top of the address space
(4 GB). On your board it is below 1 MB, and AFAIK Rudolf said that we
can't map any region below 1 MB as uncached due to CWSDPMI/DJGPP
limitations.

If anyone has an idea how to overcome these limitations, we can fix
flashrom for this special case.
> See PCI device listing attached.
> > The W25x40 supports multiple erase commands,
> > and your chipset does not allow flashrom to use
> > the spi_block_erase_20 command. Flashrom notices
> > that this command failed and tries another erase command which works.
>
> OK
> > Yes, strange. Maybe that happens as side effect from DJGPP compilation?
>
> I don't know...
> > It should try only 2 times. If it tries more often,
> > we have to check the code (bug?). I think Rudolf(?) said that there
> > are problems if we try to run a CWSDPMI app (dmidecode) from another
> > CWSDPMI app (flashrom).
> > Does it work if dmidecode.exe is in the PATH?
> > Hm. DMIDECODE.EXE is a name with 9+3 letters. That can't work on old
>
> DOS.
>
> Yes it works with dmidecode in path but nobody told me that I need it.
> On my home PC I already have dmidecode for DOS in my utilities
> directory. The file name is not problem because of DJGPP is smart
> and do some file name translation. If there's no LFN support it
> tries to look for "dmidecod.exe" and when run on LFN enabled OS
> it will use "dmidecode.exe". But it's different LFN truncating
> mode than windows use ("dmidec~1.exe"). I don't know why but e.g.
> DJGPP PKUNZIP tool use filename truncate this way without ~.
> But it would be better to check if both version of name exist and
> display non-confusing error message when nothing found.

Michael? Is there a good way to handle this?

Regards,
Carl-Daniel

Flashrom - DOS version report

[RayeR]

Carl-Daniel Hailfinger wrote:
> Ah yes. That's a limitation of the DOS port of flashrom.
> Usually the SB600 SPI base address is near the top of the address space
> (4 GB). On your board it is below 1 MB, and AFAIK Rudolf said that we
> can't map any region below 1 MB as uncached due to CWSDPMI/DJGPP
> limitations.

Acessing memory below 1MB is possible via dosmemput/dosmemget which use 
_dos_ds selector.
About caching - I think it's not a job for DPMI server to set cache 
mode. It's task for BIOS to configure
CPU MTRR. I know that is possible to change cache mode of A0000 window 
for VGA.
CPU has some number of MTRRs that can be set to specific base address, 
size and cache mode.
It's done via rdmsr/wrmsr instruction and it may be CPU vendor specific. 
I know only the intel way...

Martin

Flashrom - DOS version report

[Carl-Daniel Hailfinger]

On 24.03.2010 00:22, RayeR wrote:
> Carl-Daniel Hailfinger wrote:
> > Ah yes. That's a limitation of the DOS port of flashrom.
> > Usually the SB600 SPI base address is near the top of the address space
> > (4 GB). On your board it is below 1 MB, and AFAIK Rudolf said that we
> > can't map any region below 1 MB as uncached due to CWSDPMI/DJGPP
> > limitations.
>
> Acessing memory below 1MB is possible via dosmemput/dosmemget which
> use _dos_ds selector.

OK. Can you or Rudolf implement this?
The current code simply copies all memory from 0-1 MB to a high area for
easier access because we didn't know that some systems out there have
MMIO in that region. That copy is still OK for any cached readonly
accesses, but for uncached read/write accesses (MMIO) below 1 MB we need
dosmemget/dosmemput.
> About caching - I think it's not a job for DPMI server to set cache
> mode. It's task for BIOS to configure
> CPU MTRR. I know that is possible to change cache mode of A0000 window
> for VGA.
> CPU has some number of MTRRs that can be set to specific base address,
> size and cache mode.
> It's done via rdmsr/wrmsr instruction and it may be CPU vendor
> specific. I know only the intel way...

I have worked a lot with MTRRs and know them pretty well. If needed, I
can code up something that ensures correct cache mode, but for now we
can try to use what the BIOS gives us. If we're lucky, the BIOS performs
a correct MTRR setup and things will start working without having to
write special flashrom MTRR code.

Regards,
Carl-Daniel

Flashrom - DOS version report

[Rudolf Marek]

Carl-Daniel Hailfinger napsal(a):
> On 24.03.2010 00:22, RayeR wrote:
> > Carl-Daniel Hailfinger wrote:
> > > Ah yes. That's a limitation of the DOS port of flashrom.
> > > Usually the SB600 SPI base address is near the top of the address space
> > > (4 GB). On your board it is below 1 MB, and AFAIK Rudolf said that we
> > > can't map any region below 1 MB as uncached due to CWSDPMI/DJGPP
> > > limitations.
> >
> > Acessing memory below 1MB is possible via dosmemput/dosmemget which
> > use _dos_ds selector.
>
> OK. Can you or Rudolf implement this?

Well second possibility is to use another mapping function to map the 1MB using 
0508h as it was in NVCLOCK, I could not use that because I was running out of 
mem, because the function requires first to ALLOCATE the memory and then map 
OVER it the device mem. Maybe we can do following, we can use 0508 for the low 
mem acesses, and rest use the mapping as it is now.

Everyone is sure that the board really has so strange MMIO address? Maybe it is 
because of real mode accesses to SPI controller?

Rudolf

Flashrom - DOS version report

[Rudolf Marek]

Hi,

I put something together, not even compile tested but might work ;)

Rudolf

Flashrom - DOS version report

[Rudolf Marek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I just compiled the patch and resulting executable is on
http://assembler.cz/flashrom.exe

Please can someone try?

Thanks,

Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAku1B04ACgkQ3J9wPJqZRNXPXQCguInR1AK3mcEWF5F9+q53Dr76
1eQAoMbPAp1ATYxQOAdrYc2wdNZKUgMs
=d8fB
-----END PGP SIGNATURE-----

Flashrom - DOS version report

[RayeR]

Yes, unfortunatelly it crashed: http://rayer.ic.cz/350d/flashrom.avi
(at home on ICH7 it works still OK)

Rudolf Marek wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I just compiled the patch and resulting executable is on
> http://assembler.cz/flashrom.exe
>
> Please can someone try?
>
> Thanks,
>
> Rudolf
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAku1B04ACgkQ3J9wPJqZRNXPXQCguInR1AK3mcEWF5F9+q53Dr76
> 1eQAoMbPAp1ATYxQOAdrYc2wdNZKUgMs
> =d8fB
> -----END PGP SIGNATURE-----

Flashrom - DOS version report

[Rudolf Marek]

Hi all,

I think I fixed that. Now the DS selector limit is set to 4GB and all mmio 
accesses goes through DS, the 1:1 mapping is fixed so the _DS base is taken onto 
account. Plus is that the hwaccess.c needs no change and memcpy etc can be used 
on mmaped space.

Please test on both systems assembler.cz/flashrom.exe

Signed-off-by: Rudolf Marek

Thanks,
Rudolf

Flashrom - DOS version report

[Rudolf Marek]

Hi again,

I tested this on the real HW and it DOES work. Looking forward for the test on 
Rayers board too.

Rudolf

Flashrom - DOS version report

[RayeR]

Tomorrow ;)

Rudolf Marek wrote:
> Hi again,
>
> I tested this on the real HW and it DOES work. Looking forward for the 
> test on Rayers board too.
>
> Rudolf

Flashrom - DOS version report

[Carl-Daniel Hailfinger]

On 03.04.2010 20:57, Rudolf Marek wrote:
> Now the DS selector limit is set to 4GB and all mmio accesses goes
> through DS, the 1:1 mapping is fixed so the _DS base is taken onto
> account. Plus is that the hwaccess.c needs no change and memcpy etc
> can be used on mmaped space.
>
> Signed-off-by: Rudolf Marek

Looks good. One question, though:
If we execute any other binary from flashrom (e.g. dmidecode.exe) after
having mapped something, will this break? If that works, this is

Acked-by: Carl-Daniel Hailfinger

Regards,
Carl-Daniel

Flashrom - DOS version report

[Rudolf Marek]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> Looks good. One question, though:
> If we execute any other binary from flashrom (e.g. dmidecode.exe) after
> having mapped something, will this break? If that works, this is
>
> Acked-by: Carl-Daniel Hailfinger

Dunno, I think only Rayer tested that dmidecode.exe I think the mapping should
remain.

Rudolf
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvUmksACgkQ3J9wPJqZRNWo4wCeMrOxoeO8NAxH/WvyzkZ+uHdY
a0gAoLTGCAk2OBhrYBRvt9/MvNiX708+
=Xor8
-----END PGP SIGNATURE-----

Flashrom - DOS version report

[Joseph Smith]

Hello,
Does anyone has a pre-built exe I could try out?