flashrom November 2018

flashrom@flashrom.org

20 participants
22 discussions

[PATCH] Do not abuse cs_bit
by Vicente Bergas 22 Nov '18

22 Nov '18

"cs_bit[s]" variable stores the bit location for Chip Select, as implied by the name. A new variable "cfg" is added for static configuration bits, like Output Enables. If outputs are disabled during operation, then the result will depend on the target having proper pull-up resistors, which is not always guaranteed. Signed-off-by: Vicente Bergas <vicencb(a)gmail.com> --- ft2232_spi.c | 33 +++++++++++++++------------------ 1 file changed, 15 insertions(+), 18 deletions(-) diff --git a/ft2232_spi.c b/ft2232_spi.c index 95584aa..fe7fcf8 100644 --- a/ft2232_spi.c +++ b/ft2232_spi.c @@ -84,18 +84,19 @@ const struct dev_entry devs_ft2232spi[] = { #define BITMODE_BITBANG_NORMAL 1 #define BITMODE_BITBANG_SPI 2 -/* The variables cs_bits and pindir store the values for the "set data bits low byte" MPSSE command that +/* The variables cs_bit, cfg and pindir store the values for the "set data bits low byte" MPSSE command that * sets the initial state and the direction of the I/O pins. The pin offsets are as follows: * SCK is bit 0. * DO is bit 1. * DI is bit 2. - * CS is bit 3. + * CS is at cs_bit. Default is bit 3. * * The default values (set below) are used for most devices: * value: 0x08 CS=high, DI=low, DO=low, SK=low * dir: 0x0b CS=output, DI=input, DO=output, SK=output */ -static uint8_t cs_bits = 0x08; +static uint8_t cs_bit = 0x08; +static uint8_t cfg = 0x00; static uint8_t pindir = 0x0b; static struct ftdi_context ftdic_context; @@ -209,10 +210,9 @@ int ft2232_spi_init(void) ft2232_type = AMONTEC_JTAGKEY_PID; channel_count = 2; /* JTAGkey(2) needs to enable its output via Bit4 / GPIOL0 - * value: 0x18 OE=high, CS=high, DI=low, DO=low, SK=low - * dir: 0x1b OE=output, CS=output, DI=input, DO=output, SK=output */ - cs_bits = 0x18; - pindir = 0x1b; + * value: 0x08 #OE=low, CS=high, DI=low, DO=low, SK=low + * dir: 0x1b #OE=output, CS=output, DI=input, DO=output, SK=output */ + pindir |= 0x10; } else if (!strcasecmp(arg, "picotap")) { ft2232_vid = GOEPEL_VID; ft2232_type = GOEPEL_PICOTAP_PID; @@ -229,8 +229,7 @@ int ft2232_spi_init(void) /* In its default configuration it is a jtagkey clone */ ft2232_type = FTDI_FT2232H_PID; channel_count = 2; - cs_bits = 0x18; - pindir = 0x1b; + pindir |= 0x10; } else if (!strcasecmp(arg, "openmoko")) { ft2232_vid = FIC_VID; ft2232_type = OPENMOKO_DBGBOARD_PID; @@ -242,8 +241,7 @@ int ft2232_spi_init(void) /* arm-usb-ocd(-h) has an output buffer that needs to be enabled by pulling ADBUS4 low. * value: 0x08 #OE=low, CS=high, DI=low, DO=low, SK=low * dir: 0x1b #OE=output, CS=output, DI=input, DO=output, SK=output */ - cs_bits = 0x08; - pindir = 0x1b; + pindir |= 0x10; } else if (!strcasecmp(arg, "arm-usb-tiny")) { ft2232_vid = OLIMEX_VID; ft2232_type = OLIMEX_ARM_TINY_PID; @@ -253,8 +251,7 @@ int ft2232_spi_init(void) ft2232_type = OLIMEX_ARM_OCD_H_PID; channel_count = 2; /* See arm-usb-ocd */ - cs_bits = 0x08; - pindir = 0x1b; + pindir |= 0x10; } else if (!strcasecmp(arg, "arm-usb-tiny-h")) { ft2232_vid = OLIMEX_VID; ft2232_type = OLIMEX_ARM_TINY_H_PID; @@ -338,8 +335,8 @@ int ft2232_spi_init(void) return -2; } else { unsigned int pin = temp + 4; - cs_bits |= 1 << pin; - pindir |= 1 << pin; + cs_bit = 1 << pin; + pindir = (pindir & ~0x08) | cs_bit; } } free(arg); @@ -425,7 +422,7 @@ int ft2232_spi_init(void) msg_pdbg("Set data bits\n"); buf[0] = SET_BITS_LOW; - buf[1] = cs_bits; + buf[1] = cfg | cs_bit; buf[2] = pindir; if (send_buf(ftdic, buf, 3)) { ret = -8; @@ -480,7 +477,7 @@ static int ft2232_spi_send_command(struct flashctx *flash, */ msg_pspew("Assert CS#\n"); buf[i++] = SET_BITS_LOW; - buf[i++] = 0 & ~cs_bits; /* assertive */ + buf[i++] = cfg & ~cs_bit; buf[i++] = pindir; if (writecnt) { @@ -521,7 +518,7 @@ static int ft2232_spi_send_command(struct flashctx *flash, msg_pspew("De-assert CS#\n"); buf[i++] = SET_BITS_LOW; - buf[i++] = cs_bits; + buf[i++] = cfg | cs_bit; buf[i++] = pindir; ret = send_buf(ftdic, buf, i); failed |= ret; -- 2.19.1

1 0

Raspberry Pi spidev failure
by Sean Cross 22 Nov '18

22 Nov '18

Hi, I got this email from a mailing list somewhere. I'm experiencing an issue where I'm unable to flash using spidev on a Raspberry Pi. I'm running "4.14.79-1.rpi.fc27.armv7hl", which is based on Fedberry. I'm experiencing two issues: 1) I'm completely unable to access any SPI chips. This appears to be due to a bug in the kernel driver, which always yanks the CS line high despite the cs_change set to 0. A workaround I've come up with is to do everything as a single transaction, which seems to fix the problem on my device: diff --git a/linux_spi.c b/linux_spi.c index 3e60492..50f8220 100644 --- a/linux_spi.c +++ b/linux_spi.c @@ -183,14 +183,12 @@ static int linux_spi_send_command(struct flashctx *flash, unsigned int writecnt, unsigned char *rxbuf) { int iocontrol_code; + char tmp_buf[readcnt + writecnt]; struct spi_ioc_transfer msg[2] = { { .tx_buf = (uint64_t)(uintptr_t)txbuf, - .len = writecnt, - }, - { - .rx_buf = (uint64_t)(uintptr_t)rxbuf, - .len = readcnt, + .rx_buf = (uint64_t)(uintptr_t)tmp_buf, + .len = writecnt+readcnt, }, }; @@ -203,15 +201,14 @@ static int linux_spi_send_command(struct flashctx *flash, unsigned int writecnt, /* Just submit the first (write) request in case there is nothing to read. Otherwise submit both requests. */ - if (readcnt == 0) - iocontrol_code = SPI_IOC_MESSAGE(1); - else - iocontrol_code = SPI_IOC_MESSAGE(2); + iocontrol_code = SPI_IOC_MESSAGE(1); if (ioctl(fd, iocontrol_code, msg) == -1) { msg_cerr("%s: ioctl: %s\n", __func__, strerror(errno)); return -1; } + + memcpy(rxbuf, tmp_buf + writecnt, readcnt); return 0; } ------------------- 2) The other issue is that my device appears to want SPI_MODE_1. When I set SPI_MODE_1, it is able to detect and program the board, but fails to verify. The image that gets loaded still works, but I'm unsure of what's causing the issue. I can do some more debugging, but changing SPI_MODE_1 and applying the above-mentioned patch solves the issue for me. Sean

3 3

25FS406 and SST25WF040B have same ID's
by The_Raven Raven 15 Nov '18

15 Nov '18

Hi all Just for information: I have a chip with the label "25FS406" (i think it is a Sanyo "LE25FS406"). Flashrom detects the chip as "SST25WF040B". It seems that this chips have both the same ID's: id1 0x62 id2 0x1613 Chips are a little bit different in Voltage: LE25FS406: 1.65-2.10V SST25WF040B: 1.65-1.95V But i tested the LE25FS406 and it seems to work (read, erase and write with function 0) Greets

1 0

Intel Z97 chipset
by somebody 13 Nov '18

13 Nov '18

flashrom on Linux 4.18.18-041818-generic (x86_64) flashrom was built with libpci 3.5.2, GCC 7.3.0, little endian Command line (5 args): flashrom --programmer internal -V -o result.txt Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Initializing internal programmer /sys/class/mtd/mtd0 does not exist No coreboot table found. Using Internal DMI decoder. DMI string chassis-type: "Desktop" DMI string system-manufacturer: "Gigabyte Technology Co., Ltd." DMI string system-product-name: "Z97-HD3" DMI string system-version: "To be filled by O.E.M." DMI string baseboard-manufacturer: "Gigabyte Technology Co., Ltd." DMI string baseboard-product-name: "Z97-HD3" DMI string baseboard-version: "x.x" Found ITE Super I/O, ID 0x8620 on port 0x2e Found chipset "Intel Z97" with PCI ID 8086:8cc4. This chipset is marked as untested. If you are using an up-to-date version of flashrom *and* were (not) able to successfully update your firmware with it, then please email a report to flashrom(a)flashrom.org including a verbose (-V) log. Thank you! Enabling flash write... Root Complex Register Block address = 0xfed1c000 GCS = 0xc65: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI) Top Swap: not enabled 0xfff80000/0xffb80000 FWH IDSEL: 0x0 0xfff00000/0xffb00000 FWH IDSEL: 0x0 0xffe80000/0xffa80000 FWH IDSEL: 0x1 0xffe00000/0xffa00000 FWH IDSEL: 0x1 0xffd80000/0xff980000 FWH IDSEL: 0x2 0xffd00000/0xff900000 FWH IDSEL: 0x2 0xffc80000/0xff880000 FWH IDSEL: 0x3 0xffc00000/0xff800000 FWH IDSEL: 0x3 0xff700000/0xff300000 FWH IDSEL: 0x4 0xff600000/0xff200000 FWH IDSEL: 0x5 0xff500000/0xff100000 FWH IDSEL: 0x6 0xff400000/0xff000000 FWH IDSEL: 0x7 0xfff80000/0xffb80000 FWH decode enabled 0xfff00000/0xffb00000 FWH decode enabled 0xffe80000/0xffa80000 FWH decode enabled 0xffe00000/0xffa00000 FWH decode enabled 0xffd80000/0xff980000 FWH decode enabled 0xffd00000/0xff900000 FWH decode enabled 0xffc80000/0xff880000 FWH decode enabled 0xffc00000/0xff800000 FWH decode enabled 0xff700000/0xff300000 FWH decode enabled 0xff600000/0xff200000 FWH decode enabled 0xff500000/0xff100000 FWH decode enabled 0xff400000/0xff000000 FWH decode enabled Maximum FWH chip size: 0x100000 bytes SPI Read Configuration: prefetching enabled, caching enabled, BIOS_CNTL = 0x09: BIOS Lock Enable: disabled, BIOS Write Enable: enabled SPIBAR = 0x00007f3d65a61000 + 0x3800 0x04: 0xf008 (HSFS) HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1 SPI Configuration is locked down. Reading OPCODES... done OP Type Pre-OP op[0]: 0x02, write w/ addr, none op[1]: 0x3b, read w/ addr, none op[2]: 0x20, write w/ addr, none op[3]: 0x05, read w/o addr, none op[4]: 0x9f, read w/o addr, none op[5]: 0x01, write w/o addr, none op[6]: 0x00, read w/o addr, none op[7]: 0x00, read w/o addr, none Pre-OP 0: 0x06, Pre-OP 1: 0x00 0x06: 0x0000 (HSFC) HSFC: FGO=0, FCYCLE=0, FDBC=0, SME=0 0x08: 0x00000000 (FADDR) 0x50: 0x0000ffff (FRAP) BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff 0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write. 0x58: 0x07ff0000 FREG1: BIOS region (0x00000000-0x007fffff) is read-write. 0x5C: 0x01ff0001 FREG2: Management Engine region (0x00001000-0x001fffff) is read-write. 0x60: 0x00007fff FREG3: Gigabit Ethernet region is unused. 0x64: 0x00007fff FREG4: Platform Data region is unused. 0x74: 0x00000000 (PR0 is unused) 0x78: 0x00000000 (PR1 is unused) 0x7C: 0x00000000 (PR2 is unused) 0x80: 0x00000000 (PR3 is unused) 0x84: 0x00000000 (PR4 is unused) 0x90: 0xc0 (SSFS) SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0 0x91: 0xfc4010 (SSFC) SSFC: SCGO=0, ACS=0, SPOP=0, COP=1, DBC=0, SME=0, SCF=4 0x94: 0x0006 (PREOP) 0x96: 0x043b (OPTYPE) 0x98: 0x05203b02 (OPMENU) 0x9c: 0x0000019f (OPMENU+4) 0xA0: 0x00000000 (BBAR) 0xC4: 0x80802045 (LVSCC) LVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=1 0xC8: 0x00002045 (UVSCC) UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20 0xD0: 0x50444653 (FPB) Reading flash descriptors mapped by the chipset via FDOC/FDOD... done. === Content Section === FLVALSIG 0x0ff0a55a FLMAP0 0x02040003 FLMAP1 0x15100206 FLMAP2 0x26210120 --- Details --- NR (Number of Regions): 3 FRBA (Flash Region Base Address): 0x040 NC (Number of Components): 1 FCBA (Flash Component Base Address): 0x030 ISL (ICH/PCH Strap Length): 21 FISBA/FPSBA (Flash ICH/PCH Strap Base Address): 0x100 NM (Number of Masters): 3 FMBA (Flash Master Base Address): 0x060 MSL/PSL (MCH/PROC Strap Length): 1 FMSBA (Flash MCH/PROC Strap Base Address): 0x200 === Component Section === FLCOMP 0x64900044 FLILL 0xad604221 --- Details --- Component 1 density: 8 MB Component 2 is not used. Read Clock Frequency: 20 MHz Read ID and Status Clock Freq.: 50 MHz Write and Erase Clock Freq.: 50 MHz Fast Read is supported. Fast Read Clock Frequency: 50 MHz Dual Output Fast Read Support: disabled Invalid instruction 0: 0x21 Invalid instruction 1: 0x42 Invalid instruction 2: 0x60 Invalid instruction 3: 0xad === Region Section === FLREG0 0x00000000 FLREG1 0x07ff0000 FLREG2 0x01ff0001 --- Details --- Region 0 (Descr. ) 0x00000000 - 0x00000fff Region 1 (BIOS ) 0x00000000 - 0x007fffff Region 2 (ME ) 0x00001000 - 0x001fffff === Master Section === FLMSTR1 0xffff0000 FLMSTR2 0xffff0000 FLMSTR3 0xffff0118 --- Details --- Descr. BIOS ME GbE Platf. BIOS rw rw rw rw rw ME rw rw rw rw rw GbE rw rw rw rw rw Enabling hardware sequencing because some important opcode is locked. OK. Super I/O ID 0x8620 is not on the list of flash-capable controllers. The following protocols are supported: FWH, Programmer-specific. Probing for Programmer Opaque flash chip, 0 kB: Hardware sequencing reports 1 attached SPI flash chip with a density of 8192 kB. The flash address space (0x000000 - 0x7fffff) is divided at address 0x653000 in two partitions. The first partition ranges from 0x000000 to 0x652fff. In that range are 1619 erase blocks with 4096 B each. The second partition ranges from 0x653000 to 0x7fffff. In that range are 429 erase blocks with 4096 B each. Found Programmer flash chip "Opaque flash chip" (8192 kB, Programmer-specific) mapped at physical address 0x0000000000000000. Probing for Atmel AT49LH002, 256 kB: probe_82802ab: id1 0xc6, id2 0x33, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH00B4, 512 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Atmel AT49LH004, 512 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AB, 512 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Intel 82802AC, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL002, 256 kB: probe_jedec_common: id1 0xc6, id2 0x33, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for PMC Pm49FL004, 512 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Sharp LHF00L04, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF002A/B, 256 kB: probe_jedec_common: id1 0xc6, id2 0x33, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF003A/B, 384 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004A/B, 512 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF004C, 512 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008A, 1024 kB: probe_jedec_common: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF008C, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for SST SST49LF016C, 2048 kB: probe_82802ab: id1 0xe8, id2 0x94, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040A, 512 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW040B, 512 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080A, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for ST M50FLW080B, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW002, 256 kB: probe_82802ab: id1 0xc6, id2 0x33, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW016, 2048 kB: probe_82802ab: id1 0xe8, id2 0x94, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW040, 512 kB: probe_82802ab: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for ST M50FW080, 1024 kB: probe_82802ab: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FA, 512 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FB, 512 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V040FC, 512 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W49V002FA, 256 kB: probe_jedec_common: id1 0xc6, id2 0x33, id1 parity violation, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA, 1024 kB: probe_jedec_common: id1 0xea, id2 0xd0, id1 is normal flash content, id2 is normal flash content Probing for Winbond W39V080FA (dual mode), 512 kB: probe_jedec_common: id1 0x00, id2 0x00, id1 parity violation, id1 is normal flash content, id2 is normal flash content Found Programmer flash chip "Opaque flash chip" (8192 kB, Programmer-specific). No operations were specified. Restoring MMIO space at 0x7f3d65a648a0

2 1

Dediprog programmer
by Stanislas BERTRAND 12 Nov '18

12 Nov '18

Hi, I am using the dediprog programmer to handle SPI flash on the ESP32. I have issue erasing the flash with dediprog ( but works fine with FTDI 2232H ). I am however able to write/program the flash with the dediprog. I am using the SF600Plus. > flashrom -p dediprog -E flashrom v1.0 on Linux 4.15.0-38-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Found GigaDevice flash chip "GD25Q32(B)" (4096 kB, SPI) on dediprog. Erasing and writing flash chip... FAILED at 0x00002000! Expected=0xff, Found=0x00, failed byte count from 0x00002000-0x00002fff: 0x1000 ERASE FAILED! Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x00007fff: 0x5e68 ERASE FAILED! Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x0000ffff: 0x6a98 ERASE FAILED! Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x003fffff: 0x2d112 ERASE FAILED! Looking for another erase function. FAILED at 0x00000000! Expected=0xff, Found=0x00, failed byte count from 0x00000000-0x003fffff: 0x2d153 ERASE FAILED! Looking for another erase function. No usable erase functions left. FAILED! Your flash chip is in an unknown state. Please report this on IRC at chat.freenode.net (channel #flashrom) or mail flashrom(a)flashrom.org, thanks! > flashrom -p ft2232_spi:type=2232H,port=A -E flashrom v1.0 on Linux 4.15.0-38-generic (x86_64) flashrom is free software, get the source code at https://flashrom.org Using clock_gettime for delay loops (clk_id: 1, resolution: 1ns). Found GigaDevice flash chip "GD25Q32(B)" (4096 kB, SPI) on ft2232_spi. Erasing and writing flash chip... Erase/write done. Regards, Stan

1 0

verifying works, writing no device found
by M.Altschaeffel＠gmx.de 05 Nov '18

05 Nov '18

Hi, i have a problem with flashing a blank new bios chip. It´s a Macronix MXIC MX 25L3206E on a lenovo t430 mainboard. I successfully flashed the same mainboard with the orginal bios rom. Since i started using flashrom on a desolderd new chip the verifying process works 100 % at 20 try´s but the writing process failed because there is no EEPROM/flash device found. The /WP and /HOLD pin are high. For any help i would be thankful. Regards, Max

1 0

FOSDEM 2019 Hardware Enablement Devroom Call for Participation
by Paul Kocialkowski 03 Nov '18

03 Nov '18

Hi, The Hardware Enablement devroom is back for a second year at FOSDEM! It will take place on Sunday 3 February 2019. # Call for Participation We are opening the call for participation to our devroom, with the deadline for talk proposals set to Saturday 1 December 2018. # Devroom Scope This devroom covers topics related to hardware support and enablement with free software. It includes the following topics: * peripheral/controller firmwares * boot software * kernel drivers and hardware interfaces * hardware-related adaptation in operating systems * tools for firmware flashing * tools for low-level development Despite this large scope, the focus of the devroom is set on highlighting the technical aspects of the hardware and its enablement in free projects, rather than the specific applications and use cases that benefit from it. We also want to avoid purely commercial vague talks with marketing content, which leave little place to technical aspects. This year, we are looking to particularly highlighting free software outside of the operating system boundaries, especially with boot software as well as controller and peripheral firmwares. # Talk Format Since no Embedded devroom is taking place this year (and our devroom also covers embedded devices), we are expecting a significant number of submissions. In order to cover as much ground as we can, a new talk will be scheduled every half-hour, so accepted talks will follow this format: 20 minutes for the talk + 5 minutes for questions + 5 minutes for speaker setup We ask speakers to be present in the room before their talk so that speaker setup can go smoothly. # Submission Talks that fit in our devroom's scope can be submitted to the FOSDEM Pentabarf interface at https://penta.fosdem.org/submission/FOSDEM19 We encourage reusing accounts from previous years instead of creating new ones: * lost password: https://penta.fosdem.org/user/forgot_password * new Account: https://penta.fosdem.org/user/new_account/FOSDEM19 Here are a few guidelines when submitting a talk: * select the Hardware Enablement devroom as track * include an abstract for every submission and optionally a full description * make sure your contact details are up to date # Video Talks will be streamed live during the event and recorded. They will be available under a Creative Commons Attribution (BY) license later. # Contact For more information or questions about the devroom and this CFP, feel free to email hardware-devroom-manager at fosdem.org We're looking forward to lots of interesting proposals and hoping to see you all in Brussels at the event! Cheers, Paul for the Hardware Enablement devroom

1 0

Re: [flashrom] [coreboot] [LinuxBoot] FOSDEM 2019 deadline today
by Ron Minnich 02 Nov '18

02 Nov '18

ok it's in On Fri, Nov 2, 2018 at 3:54 PM Ron Minnich <rminnich(a)google.com> wrote: > > oh, wait, now the talk appears to be there and it lost all the links I > submitted. holy mackeral. > On Fri, Nov 2, 2018 at 3:53 PM Ron Minnich <rminnich(a)google.com> wrote: > > > > so, I just tried submitting an event to that @@@-for-brains fosdem > > pentabarf site. I can't tell what happened but it seems to have thrown > > all my work away. > > > > I can't believe they're still using penta but it used up my charitable > > instincts for the day, so no talk from me. > > > > ron > > On Fri, Nov 2, 2018 at 2:59 PM Carl-Daniel Hailfinger > > <c-d.hailfinger.devel.2006(a)gmx.net> wrote: > > > > > > In that case, I'd also like to point you to the deadline for submitting > > > main track talks which is tomorrow(!). > > > https://fosdem.org/2019/news/2018-08-10-call-for-participation/ > > > Having a coreboot/LinuxBoot talk there would be awesome. Ron/David, > > > could you submit something or do you have someone in mind who can do that? > > > > > > There's also lightning talks, deadline is a bit later. > > > > > > OK, I'm submitting a request for a stand. I need a backup contact for > > > the stand. Who is willing to do that? AFAICS we can still change the > > > backup contact later if life happens. > > > > > > Regards, > > > Carl-Daniel > > > > > > On 02.11.2018 20:48, David Hendricks wrote: > > > > > > > > > > > > On Fri, Nov 2, 2018 at 9:15 AM 'Ron Minnich' via linuxboot > > > > <linuxboot(a)googlegroups.com <mailto:linuxboot@googlegroups.com>> wrote: > > > > > > > > I"m leaning to yes, by which I mean if you do it, I'll show up. > > > > > > > > I can't believe I said that. > > > > On Fri, Nov 2, 2018 at 7:20 AM Carl-Daniel Hailfinger > > > > <c-d.hailfinger.devel.2006(a)gmx.net > > > > <mailto:c-d.hailfinger.devel.2006@gmx.net>> wrote: > > > > > > > > > > Hi! > > > > > > > > > > FOSDEM next year will be on 2 & 3 February 2019. > > > > > The deadline for applying for a stand is today. > > > > > Do we want a coreboot/flashrom/LinuxBoot stand/booth? > > > > > > > > > > > > Same as what Ron said. I think someone from FB can be there to talk > > > > about coreboot/LinuxBoot stuff and perhaps bring some hardware to demo. > > > > > > > > > > >

1 0

Re: [flashrom] [coreboot] [LinuxBoot] FOSDEM 2019 deadline today
by Ron Minnich 02 Nov '18

02 Nov '18

oh, wait, now the talk appears to be there and it lost all the links I submitted. holy mackeral. On Fri, Nov 2, 2018 at 3:53 PM Ron Minnich <rminnich(a)google.com> wrote: > > so, I just tried submitting an event to that @@@-for-brains fosdem > pentabarf site. I can't tell what happened but it seems to have thrown > all my work away. > > I can't believe they're still using penta but it used up my charitable > instincts for the day, so no talk from me. > > ron > On Fri, Nov 2, 2018 at 2:59 PM Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)gmx.net> wrote: > > > > In that case, I'd also like to point you to the deadline for submitting > > main track talks which is tomorrow(!). > > https://fosdem.org/2019/news/2018-08-10-call-for-participation/ > > Having a coreboot/LinuxBoot talk there would be awesome. Ron/David, > > could you submit something or do you have someone in mind who can do that? > > > > There's also lightning talks, deadline is a bit later. > > > > OK, I'm submitting a request for a stand. I need a backup contact for > > the stand. Who is willing to do that? AFAICS we can still change the > > backup contact later if life happens. > > > > Regards, > > Carl-Daniel > > > > On 02.11.2018 20:48, David Hendricks wrote: > > > > > > > > > On Fri, Nov 2, 2018 at 9:15 AM 'Ron Minnich' via linuxboot > > > <linuxboot(a)googlegroups.com <mailto:linuxboot@googlegroups.com>> wrote: > > > > > > I"m leaning to yes, by which I mean if you do it, I'll show up. > > > > > > I can't believe I said that. > > > On Fri, Nov 2, 2018 at 7:20 AM Carl-Daniel Hailfinger > > > <c-d.hailfinger.devel.2006(a)gmx.net > > > <mailto:c-d.hailfinger.devel.2006@gmx.net>> wrote: > > > > > > > > Hi! > > > > > > > > FOSDEM next year will be on 2 & 3 February 2019. > > > > The deadline for applying for a stand is today. > > > > Do we want a coreboot/flashrom/LinuxBoot stand/booth? > > > > > > > > > Same as what Ron said. I think someone from FB can be there to talk > > > about coreboot/LinuxBoot stuff and perhaps bring some hardware to demo. > > > > > > > >

1 0

Re: [flashrom] [LinuxBoot] FOSDEM 2019 deadline today
by David Hendricks 02 Nov '18

02 Nov '18

On Fri, Nov 2, 2018 at 9:15 AM 'Ron Minnich' via linuxboot < linuxboot(a)googlegroups.com> wrote: > I"m leaning to yes, by which I mean if you do it, I'll show up. > > I can't believe I said that. > On Fri, Nov 2, 2018 at 7:20 AM Carl-Daniel Hailfinger > <c-d.hailfinger.devel.2006(a)gmx.net> wrote: > > > > Hi! > > > > FOSDEM next year will be on 2 & 3 February 2019. > > The deadline for applying for a stand is today. > > Do we want a coreboot/flashrom/LinuxBoot stand/booth? > Same as what Ron said. I think someone from FB can be there to talk about coreboot/LinuxBoot stuff and perhaps bring some hardware to demo.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom November 2018