coreboot November 2008

coreboot@coreboot.org

76 participants
490 discussions

SPIPGM source code
by RayeR 28 Nov '08

28 Nov '08

Hello, I was asked by Rudolf to give the source code of my DOS/WIN/LINUX universal SPI FlashROM programming utility. So here's it: http://www.volny.cz/rayer/programm/spipgm.c Feel free to integrate it into your flashrom utility (btw I would be interested in DOS/WIN32 port) Note: you will need to accomodate low-level function for I/O acces, this layer is NOT included. Under linux it should be enough to rise IOPL and then use inportb/ outportb (beware arguments order, I use DJGPP syntax). Sorry for the comments, my mind is randomly switching between cz/en :) RayeR

3 7

[PATCH] flashrom: Introduce SPI REMS probing function
by Carl-Daniel Hailfinger 28 Nov '08

28 Nov '08

Flashrom already has the following probe functions: - probe_spi_rdid with opcode 0x9f, usually 3 bytes ID - probe_spi_res with opcode 0xab, usually 1 byte ID We are missing the following probe function: - probe_spi_rems with opcode 0x90, usually 2 bytes ID RDID provides best specifity (manufacturer, device class and device) and RES is supported by quite a few old chips. However, RES only returns one byte and there are multiple flash chips with different sizes on the market and all of them have the same RES ID. REMS is from the same age as RES, but it provides a manufacturer and a device ID. It is therefore on par with the probing for parallel flash chips and specific enough. The order in which chips should be detected is as follows: 1. RDID 2. REMS 3. RES I have a few chip definitions in the queue where REMS is required. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-spi_rems/flash.h =================================================================== --- flashrom-spi_rems/flash.h (Revision 3774) +++ flashrom-spi_rems/flash.h (Arbeitskopie) @@ -449,6 +449,7 @@ /* spi.c */ int probe_spi_rdid(struct flashchip *flash); int probe_spi_rdid4(struct flashchip *flash); +int probe_spi_rems(struct flashchip *flash); int probe_spi_res(struct flashchip *flash); int spi_command(unsigned int writecnt, unsigned int readcnt, const unsigned char *writearr, unsigned char *readarr); Index: flashrom-spi_rems/spi.c =================================================================== --- flashrom-spi_rems/spi.c (Revision 3774) +++ flashrom-spi_rems/spi.c (Arbeitskopie) @@ -61,6 +61,16 @@ return 0; } +static int spi_rems(unsigned char *readarr) +{ + const unsigned char cmd[JEDEC_REMS_OUTSIZE] = { JEDEC_REMS, 0, 0, 0 }; + + if (spi_command(sizeof(cmd), JEDEC_REMS_INSIZE, cmd, readarr)) + return 1; + printf_debug("REMS returned %02x %02x.\n", readarr[0], readarr[1]); + return 0; +} + static int spi_res(unsigned char *readarr) { const unsigned char cmd[JEDEC_RES_OUTSIZE] = { JEDEC_RES, 0, 0, 0 }; @@ -155,6 +165,37 @@ return 0; } +int probe_spi_rems(struct flashchip *flash) +{ + unsigned char readarr[JEDEC_REMS_INSIZE]; + uint32_t manuf_id, model_id; + + if (spi_rems(readarr)) + return 0; + + manuf_id = readarr[0]; + model_id = readarr[1]; + + printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, manuf_id, + model_id); + + if (manuf_id == flash->manufacture_id && model_id == flash->model_id) { + /* Print the status register to tell the + * user about possible write protection. + */ + spi_prettyprint_status_register(flash); + + return 1; + } + + /* Test if this is a pure vendor match. */ + if (manuf_id == flash->manufacture_id && + GENERIC_DEVICE_ID == flash->model_id) + return 1; + + return 0; +} + int probe_spi_res(struct flashchip *flash) { unsigned char readarr[3]; Index: flashrom-spi_rems/spi.h =================================================================== --- flashrom-spi_rems/spi.h (Revision 3774) +++ flashrom-spi_rems/spi.h (Arbeitskopie) @@ -29,6 +29,11 @@ #define JEDEC_RDID_OUTSIZE 0x01 #define JEDEC_RDID_INSIZE 0x03 +/* Read Electronic Manufacturer Signature */ +#define JEDEC_REMS 0x90 +#define JEDEC_REMS_OUTSIZE 0x04 +#define JEDEC_REMS_INSIZE 0x02 + /* Read Electronic Signature */ #define JEDEC_RES 0xab #define JEDEC_RES_OUTSIZE 0x04 -- http://www.hailfinger.org/

2 2

r3775 - trunk/util/flashrom
by svn＠coreboot.org 28 Nov '08

28 Nov '08

Author: hailfinger Date: 2008-11-28 02:25:00 +0100 (Fri, 28 Nov 2008) New Revision: 3775 Modified: trunk/util/flashrom/flash.h trunk/util/flashrom/spi.c trunk/util/flashrom/spi.h Log: Flashrom already has the following probe functions: - probe_spi_rdid with opcode 0x9f, usually 3 bytes ID - probe_spi_res with opcode 0xab, usually 1 byte ID We are missing the following probe function: - probe_spi_rems with opcode 0x90, usually 2 bytes ID RDID provides best specifity (manufacturer, device class and device) and RES is supported by quite a few old chips. However, RES only returns one byte and there are multiple flash chips with different sizes on the market and all of them have the same RES ID. REMS is from the same age as RES, but it provides a manufacturer and a device ID. It is therefore on par with the probing for parallel flash chips and specific enough. The order in which chips should be detected is as follows: 1. RDID 2. REMS 3. RES Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: Peter Stuge <peter(a)stuge.se> Modified: trunk/util/flashrom/flash.h =================================================================== --- trunk/util/flashrom/flash.h 2008-11-27 22:48:48 UTC (rev 3774) +++ trunk/util/flashrom/flash.h 2008-11-28 01:25:00 UTC (rev 3775) @@ -449,6 +449,7 @@ /* spi.c */ int probe_spi_rdid(struct flashchip *flash); int probe_spi_rdid4(struct flashchip *flash); +int probe_spi_rems(struct flashchip *flash); int probe_spi_res(struct flashchip *flash); int spi_command(unsigned int writecnt, unsigned int readcnt, const unsigned char *writearr, unsigned char *readarr); Modified: trunk/util/flashrom/spi.c =================================================================== --- trunk/util/flashrom/spi.c 2008-11-27 22:48:48 UTC (rev 3774) +++ trunk/util/flashrom/spi.c 2008-11-28 01:25:00 UTC (rev 3775) @@ -61,6 +61,16 @@ return 0; } +static int spi_rems(unsigned char *readarr) +{ + const unsigned char cmd[JEDEC_REMS_OUTSIZE] = { JEDEC_REMS, 0, 0, 0 }; + + if (spi_command(sizeof(cmd), JEDEC_REMS_INSIZE, cmd, readarr)) + return 1; + printf_debug("REMS returned %02x %02x.\n", readarr[0], readarr[1]); + return 0; +} + static int spi_res(unsigned char *readarr) { const unsigned char cmd[JEDEC_RES_OUTSIZE] = { JEDEC_RES, 0, 0, 0 }; @@ -155,6 +165,37 @@ return 0; } +int probe_spi_rems(struct flashchip *flash) +{ + unsigned char readarr[JEDEC_REMS_INSIZE]; + uint32_t manuf_id, model_id; + + if (spi_rems(readarr)) + return 0; + + manuf_id = readarr[0]; + model_id = readarr[1]; + + printf_debug("%s: id1 0x%x, id2 0x%x\n", __FUNCTION__, manuf_id, + model_id); + + if (manuf_id == flash->manufacture_id && model_id == flash->model_id) { + /* Print the status register to tell the + * user about possible write protection. + */ + spi_prettyprint_status_register(flash); + + return 1; + } + + /* Test if this is a pure vendor match. */ + if (manuf_id == flash->manufacture_id && + GENERIC_DEVICE_ID == flash->model_id) + return 1; + + return 0; +} + int probe_spi_res(struct flashchip *flash) { unsigned char readarr[3]; Modified: trunk/util/flashrom/spi.h =================================================================== --- trunk/util/flashrom/spi.h 2008-11-27 22:48:48 UTC (rev 3774) +++ trunk/util/flashrom/spi.h 2008-11-28 01:25:00 UTC (rev 3775) @@ -29,6 +29,11 @@ #define JEDEC_RDID_OUTSIZE 0x01 #define JEDEC_RDID_INSIZE 0x03 +/* Read Electronic Manufacturer Signature */ +#define JEDEC_REMS 0x90 +#define JEDEC_REMS_OUTSIZE 0x04 +#define JEDEC_REMS_INSIZE 0x02 + /* Read Electronic Signature */ #define JEDEC_RES 0xab #define JEDEC_RES_OUTSIZE 0x04

1 0

YABEL: Yet another (legacy) BIOS Emulation Layer
by Pattrick Hueper 28 Nov '08

28 Nov '08

Hi, for the IBM SLOF OpenFirmware used in the YDL PowerStation, i developed a BIOS emulation Layer based on x86emu. It is successfully initialising several VGA cards in the PowerStation. Since the SLOF version for the PowerStation is released under a BSD license, i tried to integrate it into coreboot-v3 and succeeded today. It initializes the cirrus card of an unpatched qemu 0.9.1-5ubuntu3. (much slower than vm86 but i couldnt get it to initialize with the current x86emu) Using coreinfo as payload, i verified, that the console is working. I would like to know, wether you guys are interested in this code, i think it could basically be a replacement for the current x86emu code. Since x86emu is BSD licensed as well, i think integrating the biosemu code into coreboot should not be a problem? While working for IBM i also tried to initialize a UltraIDE card and almost got it to do some UDMA reads from a disk... and a ethernet card which started to execute the PXE stack. That code however is not released but based on the biosemu code. I am not sure where to go from here... i need to wait for the latest SLOF release to appear on the developerworks website http://www.ibm.com/developerworks/power/pa-slof/ which has some fixes. After that i could create a patch series or git repository for review?? Coming from a PPC background i thought about trying to get coreboot-v3 and the biosemu to run in qemu-ppc... Has anybody tried that before? Would trying this make sense at all? I dont currently have any hardware running coreboot, otherwise i could maybe try to recreate the code to get other PCI cards to initialize... Any thoughts? Cheers, Pattrick

6 11

r3774 build service
by coreboot information 28 Nov '08

28 Nov '08

Dear coreboot readers! This is the automated build check service of coreboot. The developer "hailfinger" checked in revision 3774 to the coreboot source repository and caused the following changes: Change Log: The existing check in probe_spi_res() was right for SPI controllers which support all commands, but may not exist. For controllers which support only a subset of commands, it will fail in unexpected ways. Even if a command is supported by the controller, it may be unavailable if the controller is locked down. The new logic checks if RDID could be issued and its return values made sense (not 0xff 0xff 0xff). In that case, RES probing is not performed. Otherwise, we try RES. There is one drawback: If RDID returned unexpected values, we don't issue a RES probe. However, in that case we should try to match RDID anyway. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: FENG yu ning <fengyuning1984(a)gmail.com> Build Log: Compilation of tyan:s2891 has been fixed If something broke during this checkin please be a pain in hailfinger's neck until the issue is fixed. If this issue is not fixed within 24h the revision should be backed out. Best regards, coreboot automatic build system

1 0

[PATCH] flashrom: Fix probe_spi_res failover
by Carl-Daniel Hailfinger 28 Nov '08

28 Nov '08

The existing check in probe_spi_res() was right for SPI controllers which support all commands, but may not exist. For controllers which support only a subset of commands, it will fail in unexpected ways. The new logic checks if RDID could be issued and its return values made sense. In that case, RES probing is not performed. Otherwise, we try RES. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Index: flashrom-spi_res_rdid_failover/spi.c =================================================================== --- flashrom-spi_res_rdid_failover/spi.c (revision 3773) +++ flashrom-spi_res_rdid_failover/spi.c (working copy) @@ -160,15 +160,13 @@ unsigned char readarr[3]; uint32_t model_id; - if (spi_rdid(readarr, 3)) - /* We couldn't issue RDID, it's pointless to try RES. */ + /* Check if RDID was successful and did not return 0xff 0xff 0xff. + * In that case, RES is pointless. + */ + if (!spi_rdid(readarr, 3) && ((readarr[0] != 0xff) || + (readarr[1] != 0xff) || (readarr[2] != 0xff))) return 0; - /* Check if RDID returns 0xff 0xff 0xff, then we use RES. */ - if ((readarr[0] != 0xff) || (readarr[1] != 0xff) || - (readarr[2] != 0xff)) - return 0; - if (spi_res(readarr)) return 0; -- http://www.hailfinger.org/

2 2

r3774 - trunk/util/flashrom
by svn＠coreboot.org 27 Nov '08

27 Nov '08

Author: hailfinger Date: 2008-11-27 23:48:48 +0100 (Thu, 27 Nov 2008) New Revision: 3774 Modified: trunk/util/flashrom/spi.c Log: The existing check in probe_spi_res() was right for SPI controllers which support all commands, but may not exist. For controllers which support only a subset of commands, it will fail in unexpected ways. Even if a command is supported by the controller, it may be unavailable if the controller is locked down. The new logic checks if RDID could be issued and its return values made sense (not 0xff 0xff 0xff). In that case, RES probing is not performed. Otherwise, we try RES. There is one drawback: If RDID returned unexpected values, we don't issue a RES probe. However, in that case we should try to match RDID anyway. Signed-off-by: Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006(a)gmx.net> Acked-by: FENG yu ning <fengyuning1984(a)gmail.com> Modified: trunk/util/flashrom/spi.c =================================================================== --- trunk/util/flashrom/spi.c 2008-11-27 00:47:07 UTC (rev 3773) +++ trunk/util/flashrom/spi.c 2008-11-27 22:48:48 UTC (rev 3774) @@ -160,15 +160,13 @@ unsigned char readarr[3]; uint32_t model_id; - if (spi_rdid(readarr, 3)) - /* We couldn't issue RDID, it's pointless to try RES. */ + /* Check if RDID was successful and did not return 0xff 0xff 0xff. + * In that case, RES is pointless. + */ + if (!spi_rdid(readarr, 3) && ((readarr[0] != 0xff) || + (readarr[1] != 0xff) || (readarr[2] != 0xff))) return 0; - /* Check if RDID returns 0xff 0xff 0xff, then we use RES. */ - if ((readarr[0] != 0xff) || (readarr[1] != 0xff) || - (readarr[2] != 0xff)) - return 0; - if (spi_res(readarr)) return 0;

1 0

CN700/C7 booting broken by most recent svn
by Corey Osgood 27 Nov '08

27 Nov '08

I've attached a patch (no major changes, mostly just debugging stuff) and boot log, this looks to me like something broken internally since the last time I was working on this. Anyone have any ideas? Thanks, Corey

3 3

Re: [coreboot] r3772 - trunk/coreboot-v2/targets/emulation/qemu-x86
by Carl-Daniel Hailfinger 27 Nov '08

27 Nov '08

On 26.11.2008 20:46, svn(a)coreboot.org wrote: > Author: ward > Date: 2008-11-26 20:46:27 +0100 (Wed, 26 Nov 2008) > New Revision: 3772 > > Modified: > trunk/coreboot-v2/targets/emulation/qemu-x86/Config.lb > Log: > > Increase the qemu rom size (non-LAB) to 512KB so that grub2 fits. > > This is a trivial patch. > IIRC older Qemu versions can't handle ROMs of that size. I could be wrong, though. > Signed-off-by: Ward Vandewege <ward(a)gnu.org> > Acked-by: Ward Vandewege <ward(a)gnu.org> > Regards, Carl-Daniel -- http://www.hailfinger.org/

3 3

Need a direction
by Timmothie (Timmo') Baker 27 Nov '08

27 Nov '08

Hi, Maybe I need some direction where to ask my question. Who am I ? ========== I'm Timmo' at (in-buiding stage) http://potchan.org. On my upcoming site I simplify a PuppyLinux fork named Muppy to a target of d' most lefthanded innocent users available. My three "technical demands" from a Potchan (=opener) user R: 1. Can you send an email on your own ? 2. Can you make a toast with a TOASTER without a technician's aid ? 3. Can you adjust 1st. BIOS boot to CD/DVD-ROM ? (-this 3rd. one is an OBSTICLE to many innocent ones). Me myself stand on a better place technically, but not too much better than this. Where I succeed simplification ? ================================ The main Potchan sits on an unzipped folder 2Gb+ you put on root HD ("c" or "d" don't matter). You can do it from your Windows/else session. Next, with one click user burns about 7M bootie files on CD. This is AFAIK my succeed without any help. Where do I FAIL simplification ? ================================ The CD doesn't "tell" PC where to boot itself. If BIOS is not configured as CD/DVD to B its 1st. boot - the user I want so much is about to freaks-out on me, or even worse: needs help from a buddy. This buddy can help but it also unsimplifies process. A buddy can also influence "my" innocent one not to go-on. So I lose my 'examplar' user before getting even my 1st. real one ... I'd like my 3rd. demand - a HUGE barrier to manyones - to be cancelled. So my question is : ==================== Can my bootCD/DVD tell PC to bypass whatever BIOS says and boot from CD/DVD ? (If you don't have a clue. Who does ?) -- Regards, Timmo' at http://potchan.org

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
49
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2008