Am 18.07.2013 19:15 schrieb Marc Jones:
> On Wed, Jul 17, 2013 at 7:21 PM, Stefan Tauner <
> stefan.tauner(a)student.tuwien.ac.at> wrote:
>
>> Our current development model with elaborate reviews has not been
>> working for a while now. Therefore, beginning with the release of
>> flashrom 0.9.7 our strategy on merging patches will change radically.
>>
>> The current rules regarding committing to subversion can be found here:
>> http://flashrom.org/Development_Guidelines#Committing
>> Essentially they prohibit merging non-trivial patches without explicit
>> consent from another community member and is not too specific on the
>> requirements for an ack.
>>
> Not to add undue overhead to the project, but why not go to git and gerrit?
> Automates a lot of this stuff and is already setup on coreboot.org.
<rant>
Because I think git sucks? I might be open for a switch to mercurial
because it has usable revision numbers and a user-friendly interface.
But git... without a command line and the right tree, I'll never know if
commit hash deadbeef is before or after badc0ffe. Besides that, I
managed to learn mercurial in a few hours and gave up on git after a few
days.
And gerrit needs known insecure OpenID for authentication. I'm not going
to get any OpenID capable account just to satisfy a defective login
mechanism. Apart from that, it seems gerrit pretty much killed all patch
discussion on the coreboot mailing list. It also was pretty much
unsuitable for offline use (no idea if that changed). While those
properties may work for coreboot development (with very infrequent
contributions/reviews by outsiders), I fear it will introduce an
additional barrier for flashrom.
</rant>
Regards,
Carl-Daniel
On Thu, 18 Jul 2013 11:31:12 +0200
san <san(a)plusnet.pl> wrote:
> Ok, i found my compiled version does not work. Will check this out later.
>
> Flashrom.log and other possibly useful informations can be found here
> http://e-san.info/Flashrom-P4/
I am quite sure that you will need a board enable that changes the
state of the WP and TBL pins. You can verify that by measuring the
voltage of said pins against ground.
You can read more about board enables here:
http://flashrom.org/Board_Enable
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Am 10.07.2013 21:17 schrieb Stefan Tauner:
> Detect and temporarily disable the IMC while accessing the flash.
> Disable writes on default, but allow the user to enforce it.
>
> Signed-off-by: Rudolf Marek <r.marek(a)assembler.cz>
> Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>
> ---
> imc.c | 171 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
I already mentioned the suboptimal file name and public function names
on IRC. You said:
"[...] best would be to name it amd_imc.c and name the one external
visible function amd_imc_shutdown [...]"
That change would be appreciated.
> diff --git a/chipset_enable.c b/chipset_enable.c
> index 3979347..c884c80 100644
> --- a/chipset_enable.c
> +++ b/chipset_enable.c
> @@ -922,6 +922,10 @@ static int enable_flash_sb600(struct pci_dev *dev, const char *name)
> uint8_t reg;
> int ret;
>
> + if (imc_shutdown(dev) != 0) {
Hm. Can we avoid calling this on SB600 (if SB600 doesn't support IMC at
all)?
> + return ERROR_FATAL;
> + }
> +
> /* Clear ROM protect 0-3. */
> for (reg = 0x50; reg < 0x60; reg += 4) {
> prot = pci_read_long(dev, reg);
> diff --git a/sb600spi.c b/sb600spi.c
> index a5c00d8..7043aec 100644
> --- a/sb600spi.c
> +++ b/sb600spi.c
> @@ -210,10 +211,26 @@ int sb600_probe_spi(struct pci_dev *dev)
> struct pci_dev *smbus_dev;
> uint32_t tmp;
> uint8_t reg;
> + bool amd_imc_force = false;
Ah yes, the joy of having a bool type in C99. It makes sense here.
>From a quick glance the code looks sane otherwise. I'll try to evaluate
it in light of the recent discussions about AMD IMC and associated problems.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Ok, i found my compiled version does not work. Will check this out later.
Flashrom.log and other possibly useful informations can be found here
http://e-san.info/Flashrom-P4/
Thanks for quick response.
> Unicorn wishes! ;)
Cherry lollipops!
2013/7/18 san <san(a)plusnet.pl>
> Ok, i found my compiled version does not work. Will check this out later.
>
> Flashrom.log and other possibly useful informations can be found here
> http://e-san.info/Flashrom-P4/
>
> Thanks for quick response.
>
> > Unicorn wishes! ;)
> Cherry lollipops!
>
>
> 2013/7/18 Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>
>
>> On Thu, 18 Jul 2013 02:14:22 +0200
>> san <san(a)plusnet.pl> wrote:
>>
>> > Hi!
>> >
>> > First of all, thank You for providing such a great software.
>> >
>> > I have problems with flashing bios on my no-name motherboard.
>> >
>> > It is propably Saphire or PCPartner (a bit different:
>> > http://www.compass.ua/products/view1.asp?code=28915 )
>> > But almost sure it is PP:
>> > http://support.pcpartner.com/products/old-intel/DM-262E.htm
>> >
>> > Flashrom does recognise chipset, flash chip and read rom but does not
>> write.
>> >
>> > I use TinyCore Linux LiveCD (http://distro.ibiblio.org/tinycorelinux/),
>> > Flashrom from ubuntu (binary) and current version (compiled).
>> >
>> > I hot swap chips but they are same model.
>> >
>> > Manual for motherboard found here:
>> > http://support.pcpartner.com/support/man/intel/p262.pdf (
>> > http://support.pcpartner.com/support/bios/i845.htm#845e => 845EAS4-262E
>> > [DDR]) doeas not provide any information about bios flash protection.
>> >
>> > Please help!
>>
>> Please provide flashrom's verbose output when it is trying to write.
>> With newer versions you can create a log file easily by using the -o
>> parameter. Without the detailed output we can only guess what happens.
>>
>> > Beast regards!
>>
>> Unicorn wishes! ;)
>>
>> --
>> Kind regards/Mit freundlichen Grüßen, Stefan Tauner
>>
>
>
>
> --
> [ e-San.info | San(a)plusnet.pl ]
>
--
[ e-San.info | San(a)plusnet.pl ]
On Thu, Jul 18, 2013 at 10:15 AM, Marc Jones <marcj303(a)gmail.com> wrote:
> On Wed, Jul 17, 2013 at 7:21 PM, Stefan Tauner <
> stefan.tauner(a)student.tuwien.ac.at> wrote:
>
>> Our current development model with elaborate reviews has not been
>> working for a while now. Therefore, beginning with the release of
>> flashrom 0.9.7 our strategy on merging patches will change radically.
>>
>> The current rules regarding committing to subversion can be found here:
>> http://flashrom.org/Development_Guidelines#Committing
>> Essentially they prohibit merging non-trivial patches without explicit
>> consent from another community member and is not too specific on the
>> requirements for an ack.
>>
>
> Not to add undue overhead to the project, but why not go to git and
> gerrit? Automates a lot of this stuff and is already setup on coreboot.org
> .
>
+1.
--
David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
On Thu, 18 Jul 2013 02:14:22 +0200
san <san(a)plusnet.pl> wrote:
> Hi!
>
> First of all, thank You for providing such a great software.
>
> I have problems with flashing bios on my no-name motherboard.
>
> It is propably Saphire or PCPartner (a bit different:
> http://www.compass.ua/products/view1.asp?code=28915 )
> But almost sure it is PP:
> http://support.pcpartner.com/products/old-intel/DM-262E.htm
>
> Flashrom does recognise chipset, flash chip and read rom but does not write.
>
> I use TinyCore Linux LiveCD (http://distro.ibiblio.org/tinycorelinux/),
> Flashrom from ubuntu (binary) and current version (compiled).
>
> I hot swap chips but they are same model.
>
> Manual for motherboard found here:
> http://support.pcpartner.com/support/man/intel/p262.pdf (
> http://support.pcpartner.com/support/bios/i845.htm#845e => 845EAS4-262E
> [DDR]) doeas not provide any information about bios flash protection.
>
> Please help!
Please provide flashrom's verbose output when it is trying to write.
With newer versions you can create a log file easily by using the -o
parameter. Without the detailed output we can only guess what happens.
> Beast regards!
Unicorn wishes! ;)
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
Am 17.07.2013 15:58 schrieb Stefan Tauner:
> unsigned long is not the right type for manipulating pointer values.
> Since C99 there are suitable unsigned and signed types available, namely
> uintptr_t and intptr_t respectively.
>
> Use them in functions assigned to programmers' map_flash_region fields and
> their callers where applicable.
>
> This patch also changes the display width of all associated address values in
> physmap.c to 16/8 hex characters depending on the actual size by
> introducing a macro PRIxPTR_WIDTH and exploiting printf's * field width
> specifier.
>
> Signed-off-by: Stefan Tauner <stefan.tauner(a)student.tuwien.ac.at>
> Acked-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net>
> ---
>
> Can you please verify that this is what you want?
Yes. Exactly.
> I put the _WIDTH macro in flash.h now for obvious reasons.
Thanks!
Regards,
Carl-Daniel
--
http://www.hailfinger.org/