Am 06.05.2009 02:14, schrieb Kevin O'Connor:
What are your plans with lzma decoding? (Will the bootblock have an
lzma decoder for deploying coreboot_ram and will coreboot_ram have an
lzma decoder for the payload?)
Yes.
Tests with coreboot_ram showed that lzma compressing it gains more (vs.
nrv
Hi all,
I'm having problems with the flashrom on my system. I'm trying to read out
the rom content from my machine which is a hp machine with ich9 controller
and Amtel AT26DF321 flash chip. However, the reading only halfway through
and error occur. Anyone encountered this? Can provide some advice
Author: stuge
Date: 2009-05-06 15:38:55 +0200 (Wed, 06 May 2009)
New Revision: 465
Modified:
trunk/chipset_enable.c
Log:
Touch up some error messages in enable_flash_cs5536().
Signed-off-by: Peter Stuge
Acked-by: Peter Stuge
Modified: trunk/chipset_enable.c
Bertrand, thanks for your patch! It is obviously needed.
Carl-Daniel Hailfinger wrote:
> Although the fix seems trivial, it breaks the code a few lines
> down.
> Please fix. Thanks.
Carl-Daniel, this is a really silly argument. Stop wasting people's
lives with such trivial things, adress it if y
Author: stuge
Date: 2009-05-06 15:43:26 +0200 (Wed, 06 May 2009)
New Revision: 466
Modified:
trunk/chipset_enable.c
Log:
Cleanup redundant condition and clarify message a little.
Signed-off-by: Peter Stuge
Acked-by: Peter Stuge
Modified: trunk/chipset_enable.c
=
Author: hailfinger
Date: 2009-05-06 15:51:44 +0200 (Wed, 06 May 2009)
New Revision: 467
Modified:
trunk/chipset_enable.c
Log:
Revert r466 because it introduced a bug:
If unprotect succeeded, it will print "SB600 unprotect failed".
Signed-off-by: Carl-Daniel Hailfinger
Acked-by: Carl-Daniel Ha
Carl-Daniel Hailfinger wrote:
> Improve SST25 status register routines:
> - Using a 4-bit index into an array with 8 elements leads to
> out-of-bounds accesses. That bug was introduced by a self-acked patch
> from someone. Use proper bit masking to fix this.
I think it's pointless to write "it was
Author: hailfinger
Date: 2009-05-06 15:59:44 +0200 (Wed, 06 May 2009)
New Revision: 468
Modified:
trunk/spi.c
Log:
Improve SST25 status register routines:
- Using a 4-bit index into an array with 8 elements leads to
out-of-bounds accesses. Use proper bit masking to fix this.
- Factor out common
On 06.05.2009 15:52, Peter Stuge wrote:
> Carl-Daniel Hailfinger wrote:
>
>> Improve SST25 status register routines:
>> - Using a 4-bit index into an array with 8 elements leads to
>> out-of-bounds accesses. That bug was introduced by a self-acked patch
>> from someone. Use proper bit masking to
Just in case someone wants a more detailed explanation:
prot is read again after the first if (prot & 0x3) and may have changed,
so the second if (prot & 0x3) is not redundant.
Regards,
Carl-Daniel
On 06.05.2009 15:51, s...@coreboot.org wrote:
> Author: hailfinger
> Date: 2009-05-06 15:51:44 +020
Hi Guys
I was talking to Jason and we found we need to draw a bit better the
API and responsibilities between us. I figure out I`m going to support
hardware detection and initialization, and a framework to read and
write blocks from MSC devices.
Looking the current libpayload`s source code I foun
Carl-Daniel Hailfinger wrote:
> > I think it's pointless to write "it was introduced by self-ack" at
> > all if you do not also write who it was. Either go all the way and
> > actually blame someone because you think it's a big deal or don't
> > bother because it's just about _one bit_.
>
> It's o
s...@coreboot.org wrote:
> + if (prot & 0x3)
Yes of course! Silly me. Thanks for fixing!
> + printf("SB600 still %s%sprotected from %u to %u\n",
How about the wording though? Without -V, using "still" is not so
great. I realize the old prot value needs to be save
On 06.05.2009 16:36, Peter Stuge wrote:
> s...@coreboot.org wrote:
>
>> +if (prot & 0x3)
>>
>
> Yes of course! Silly me. Thanks for fixing!
>
No problem. To err is human.
>> +printf("SB600 still %s%sprotected from %u to %u\n",
>>
>
> How about the
Author: stuge
Date: 2009-05-06 17:05:39 +0200 (Wed, 06 May 2009)
New Revision: 469
Modified:
trunk/chipset_enable.c
Log:
Clarify error message in enable_flash_sb600() a little.
Signed-off-by: Peter Stuge
Acked-by: Peter Stuge
Modified: trunk/chipset_enable.c
===
Carl-Daniel Hailfinger wrote:
> printf("SB600 %s%sunprotect failed from %u to %u\n"
Let's try r469.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
Charles,
We have successfully tested both the 32-bit and 64-bit FlashROM utility on the
S5397 motherboard and found it 100% compatible. Can we have the S5397
motherboard added to the compatibility listings?
Thanks,
Joel Robertson
Tech Support Manager
Customer Service Manager
Vendor Relations
Stan Yong wrote:
> I'm having problems with the flashrom on my system. ...
> Can provide some advice on this?
I can only tell the reason. Your current BIOS prevents flashrom from
reading certain part of the flash chip. I don't know if there is any
way to bypass that setting.
If you are interested
Hi Joel,
jo...@tyan.com wrote:
> We have successfully tested both the 32-bit and 64-bit FlashROM
> utility on the S5397 motherboard and found it 100% compatible.
Great!
> Can we have the S5397 motherboard added to the compatibility
> listings?
The list which is included in the utility itself (
FENG Yu Ning wrote:
> Look at FREG2.
> Now look at FRAP.
Thanks a lot for those great explanations!
It might be nice to check this in the code as well.
//Peter
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
#131: New flashrom motherboard support
-+--
Reporter: anonymous | Owner: somebody
Type: enhancement| Status: new
Priority: trivial| Miles
on 06/05/2009 18:41 FENG Yu Ning said the following:
> Look at FREG2.
>> 0x5C: 0x023f000b (FREG2)
> The value 0x0(23f)0(00b) means, the area in the flash chip from
> 0x00(00b)000 to 0x00(23f)fff belongs to (F)lash (REG)ion (2), which
> stores data for the "Management Engine". That is, flashrom runs
I tried the latest svn version (6 May 09) of flashrom and unlike older
versions
didn't get a warning on my chipset. flashrom reads my chip successfully and
outputs a fine Phoenix bios. After writing a new image into the chip
I found that writer is not fully functional and reading the chip again
res
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hmm I checked the orig bios image for any special handling and there is none.
Even it seems that EC has its own flash somewhere else. (this is good)
Perhaps there are some locks in chip itself? Any expert here on that?
Can we read the status reg from
Author: hailfinger
Date: 2009-05-06 23:54:22 +0200 (Wed, 06 May 2009)
New Revision: 470
Modified:
trunk/flash.h
Log:
ASD chips may exist, but all available docs suggest they are just
rebranded Winbond chips with Winbond IDs.
The ASD vendor/chip IDs in flash.h are very likely just misinterpreted
#132: Add version number to flashrom output
-+--
Reporter: stuge | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone:
#132: Add version number to flashrom output
-+--
Reporter: stuge | Owner: hailfinger
Type: defect | Status: assigned
Priority: major | Milestone:
When flashrom JEDEC code sends the ID command to the chip, it expects to
see IDs in the default flash location. However, sometimes the chip does
not react to the ID command, either because it doesn't understand the
command or because the command never reached it.
One way to detect this is to compar
On 07.05.2009 00:16, Carl-Daniel Hailfinger wrote:
> When flashrom JEDEC code sends the ID command to the chip, it expects to
> see IDs in the default flash location. However, sometimes the chip does
> not react to the ID command, either because it doesn't understand the
> command or because the co
Author: uwe
Date: 2009-05-07 02:03:18 +0200 (Thu, 07 May 2009)
New Revision: 4255
Modified:
trunk/util/superiotool/smsc.c
Log:
Support for detecting the SMSC FDC37N869 (trivial).
No datasheet available, chip identified by probing and looking at the PCB.
Signed-off-by: Uwe Hermann
Acked-by: U
Author: uwe
Date: 2009-05-07 02:21:02 +0200 (Thu, 07 May 2009)
New Revision: 4256
Modified:
trunk/util/superiotool/smsc.c
Log:
Fix my last commit. I looked at the wrong dead laptop.
Signed-off-by: Uwe Hermann
Acked-by: Uwe Hermann
Modified: trunk/util/superiotool/smsc.c
==
#131: New flashrom motherboard support
-+--
Reporter: anonymous | Owner: somebody
Type: enhancement| Status: new
Priority: trivial| Miles
Andriy Gapon wrote:
> I wonder what the following means (on my machine):
> 0x54: 0x (FREG0)
All 0s value is confusing at the first sight. However, if you would
like to read the explanation once more and pay attention to the
detail, I believe you will get a different conclusion.
>> The va
#133: Create a typical failures FAQ
---+
Reporter: stuge| Owner: somebody
Type: enhancement | Status: new
Priority: major| Milest
#132: Add version number to flashrom output
-+--
Reporter: stuge | Owner: hailfinger
Type: defect | Status: assigned
Priority: major | Milestone:
Author: hailfinger
Date: 2009-05-07 02:59:53 +0200 (Thu, 07 May 2009)
New Revision: 471
Modified:
trunk/flashrom.c
Log:
Always print the flashrom version as first output line.
Suggested by Peter Stuge.
Signed-off-by: Carl-Daniel Hailfinger
Acked-by: Carl-Daniel Hailfinger
Modified: trunk/
#132: Add version number to flashrom output
-+--
Reporter: stuge | Owner: hailfinger
Type: defect|Status: closed
Priority: major | Milestone:
lspci -xxx output attached
On Thu, May 7, 2009 at 12:21 AM, Rudolf Marek wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hmm I checked the orig bios image for any special handling and there is
> none.
> Even it seems that EC has its own flash somewhere else. (this is good)
>
> Perha
Ali Nadalizadeh wrote:
> I'm also online on #coreboot as nadalizadeh
Some analysis after Ali worked with Carl-Daniel and me to debug this.
The chip needs a write enable command to set it's write enable latch
before each erase or write command.
flashrom sends this as a separate command, but for s
I have made an initial pass at porting the open source vgabios at:
http://www.nongnu.org/vgabios/
from bcc/as86 to gcc.
The new code can be found in the SeaBIOS git repository. To download
and build the code use:
git clone git://git.linuxtogo.org/home/kevin/seabios.git
cd seabios/
make out/vga
Author: linux_junkie
Date: 2009-05-07 07:47:05 +0200 (Thu, 07 May 2009)
New Revision: 4257
Modified:
trunk/coreboot-v2/src/mainboard/rca/rm4100/irq_tables.c
trunk/coreboot-v2/src/mainboard/thomson/ip1000/irq_tables.c
Log:
Trivial checksum fixup for irq tables on IP1000 and RM4100.
Signed-off
On Thu, 07 May 2009 02:01:18 -0400, Joseph Smith
wrote:
>
> This patch disables the AC97 modem via the ICH4 LPC disable function
> register early in the boot process. Leaving it enabled was causing
> resource
> allocation problems, making IO read/writes under 0x200 fail. As I found
> out
> by t
On Wed, 6 May 2009 23:53:24 -0400, Kevin O'Connor
wrote:
> I have made an initial pass at porting the open source vgabios at:
>
> http://www.nongnu.org/vgabios/
>
> from bcc/as86 to gcc.
>
> The new code can be found in the SeaBIOS git repository. To download
> and build the code use:
>
>
This patch disables the AC97 modem via the ICH4 LPC disable function
register early in the boot process. Leaving it enabled was causing resource
allocation problems, making IO read/writes under 0x200 fail. As I found out
by trail and error it has to be done right after the LAN Enable gpio pin is
d
This patch sets up PIRQs in mainboard Config.lb for IP1000 and RM4100
instead of using the ones in i82801xx_lpc.c
Signed-off-by: Joseph Smith
--
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.orgIndex: src/mainboard/thomson/ip1000/Config.lb
==
45 matches
Mail list logo
