flashrom October 2016

flashrom@flashrom.org

17 participants
36 discussions

Start a nNew thread

Successful READ and WRITE, Asrock P4i65G
by R F 07 Oct '16

07 Oct '16

Using a legacy board as a flasher, flashrom nagged me to submit a report. Nice software, thanks.

1 0

Success flashrom on Wyse C10LE
by Romain MARIADASSOU - Service Informatique 06 Oct '16

06 Oct '16

Machine : Wyse C10LE Should work on Wyse C50LE Command line used : flashrom -w bios2012.img -V -p internal:laptop=this_is_not_a_laptop Log file attached -- Cordialement, CIAS à l'Ouest de Rennes *Romain MARIADASSOU* /Pôle Ressources/ - /Service Informatique/ CIAS à l'Ouest de Rennes Place Toulouse Lautrec - BP 31 - 35310 MORDELLES Tél : 02 23 41 28 00 - Fax : 02 23 41 28 09 Site : http://www.cias-ouest-rennes.fr Mail : informatique(a)cias-ouest-rennes.fr <mailto:informatique@cias-ouest-rennes.fr>

1 0

Jetway NF9G-QM77 test success
by Nick M 04 Oct '16

04 Oct '16

Greetings, Fortune was on my side when I extracted the same spi flash chip from my junk collection that this mini itx uses. A freshly downloaded bios image was flashed with external ft2232h to recycled flash and swapped with original chip. I followed the suggested methodology to test unknown hardware, output of hardware probing was piped to attached text files. Read, write, erase and probe work as intended. Diff returned no file differences and pc booted as expected using A07, A08 and backup binary images. Thanks, -- Nick

1 0

Re: [flashrom] [coreboot] Support for Gigabyte ga-ma78gm-us2h?
by Mike Banon 03 Oct '16

03 Oct '16

Get a hardware programmer for BIOS chips (e.g. cheap CH341A) together with SOIC8 test clip (if your type of BIOS chip is indeed SOIC8, I just looked at some photos of your board online...) and do In-System Programming with a flashrom. Thanks to a test clip you will not need to solder your board in order to flash a BIOS. Nothing can stop a hardware programmer ;) You could backup both of your current BIOSes and replace everything with coreboot to get rid of original BIOS warnings/checksums , and if you would like to restore the original BIOS back it will be really easy. Now, what could be tried if a current revision of coreboot does not work for you? 1) Check what is the date of last successful board status report. At your case, I see that nobody submitted a report for your board, so you probably need to choose this day as the day of support addition ( Aug 17 13:22:40 2010 ) and test if it worked at this time or maybe 1 month after this time (if a full support has been added gradually) 2) You divide the time between current date and "1)" date by 2 - to get a "test date" - then download a coreboot/seabios repositories at this "test date", build and test it. If it works --> you go forward in time, if it does not work --> you go back in time; again, dividing the remaining range by two. You have to go through a long history in your case, 2000 days, but if you are always dividing by two its less than 2048 = 2^11 so you could find the last day it worked in 11 tries 3) So you found the last day, and then the last commit when it worked. Now you see what commit broke a support for your board, and could either live with old coreboot stuff, or figure out what changes need to be made to newer coreboot - so that your board works, while not breaking a support for other boards (IMPORTANT) Best regards, Mike Banon > > Thanks a lot for the help, but now I don't even get to the black screen. > Whenever I flash coreboot and reboot the computer, after a few seconds of > black-screen the backup BIOS complains about a checksum fail from the main > bios chip and resets the contents to the original BIOS. I have a few ideas > to try tonight, so I'll try that. Hopefully I'll be able to achieve > something. > > Cheers, > Alberto > 2016-09-28 15:10 GMT-03:00 Zoran Stojsavljevic < zoran.stojsavljevic at gmail.com>: > *"Приветствую!* > *Если я правильно понял, то у меня была схожая проблема, когда я пытался > запустить coreboot на Asus m4a785-m. Я потратил 2 месяца на ее решение, а > решение оказалось простым.* > *Проблема в вызовах printk() до инициализации консоли. Видимо > переполняется кэш процессора."* > > Translation for the above is the following (maybe this also can help): > > Hello, > > If I correctly understand, I had very similar problem, when I > struggled/tried to bring up Coreboot on Asus m4a785-m. I lost two months > for solution finding, and solution appeared to be simplistic. > Problem is by calling printk() before console init. Apparently CPU cache > is overloading. > > (love Russian language, could not resist)! > > Zoran > > On Wed, Sep 28, 2016 at 5:54 PM, Alexey Borovikov via coreboot < > coreboot at coreboot.org> wrote: > >> Hi! >> May be the problems in call printk() before console_init(). Two way: >> 1. To comment printk in function which call before console_init. >> 2. Call console_init first in function cache_as_ram_main. >> May be this help. >> >> /* >> Приветствую! >> Если я правильно понял, то у меня была схожая проблема, когда я пытался >> запустить coreboot на Asus m4a785-m. Я потратил 2 месяца на ее решение, а >> решение оказалось простым. >> Проблема в вызовах printk() до инициализации консоли. Видимо >> переполняется кэш процессора. >> Для решения два пути: >> 1. Закомментировать все вызовы printk до вызова console_init >> 2. Попробовать вызвать console_init как можно раньше в функции >> cache_as_ram_main (файл romstage.c). >> Возможно это поможет. >> */ >> >> >> *From:* Alberto Simón Francés <alberto at simon.ph> >> *Sent:* Sunday, September 25, 2016 6:07 PM >> *To:* coreboot at coreboot.org >> *Subject:* [coreboot] Support for Gigabyte ga-ma78gm-us2h? >> >> >> Hello, >> >> I've been trying to make this board boot and I haven't had much success. >> Sometimes I've been able to get it to POST, but it's not something that >> happens consistently. Since I can't find much info other than it being >> listed, I'm asking here to see if by any chance there's something that I'm >> missing, because I feel like I'm just trying random things to see what >> sticks. >> >> Thankfully the board has dual bios, so it's easy to go back if I mess >> something up. Please, help. >> >> Best regards, >> Albert >> >> ------------------------------ >> -- >> coreboot mailing list: coreboot at coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> >> >> -- >> coreboot mailing list: coreboot at coreboot.org >> https://www.coreboot.org/mailman/listinfo/coreboot >> > >

1 0

Upgrade MS-7519 / MSI P45 NEO
by Jelle Martijn Kok 01 Oct '16

01 Oct '16

The bios of this board upgraded perfectly. 2 things to note: * I received several nasty "Trying to unmap a nonexisting mapping!" messages.("-c W25X80" prevented these) * I need to clear the BIOS setup using the jumper Enclosed is the log for the probe (with "-V") Jelle Martijn -- ------------------------------------------------------------------------ You/Com Audiocommunicatie BV Motorenweg 5k 2623CR Delft The Netherlands tel. : (+31)15 262 59 55 fax. : (+31)15 257 15 95 mail : jmkok(a)youcom.nl http : http://www.youcom.nl/ ------------------------------------------------------------------------

1 0

Re: [flashrom] ENE KB9012 patches: new test results
by Paul Kocialkowski 01 Oct '16

01 Oct '16

Hi, I got your emails just fine, I just didn't have time to sit down and write a proper reply but I'm very enthusiasic about working with you ! Cheers, Paul Kocialkowski Le vendredi 23 septembre 2016 à 03:16 +0300, mikeb mikeb a écrit : > Good day! I just tried reading from KB9012 and encountered exactly the same > problem as Joerg Albert has ( https://www.flashrom.org/pipermail/flashrom/2016 > -May/014653.html ) - chip is detected only every second time. This is not > caused by cabling. While it is recommended for SPI that the wires should be > shorter than 20cm, my wires are 11 cm: 8 cm of which is 12 strands high > quality copper and only 3 cm are ordinary aluminium inside the 30 pin 0.5mm > pitch keyboard-like connector This is interesting! I still haven't been able to reproduce the issue (but haven't tried so hard either). Could you indicate whether you are: * grounding pin 42 to go into test mode * powering the mainboard Thanks! > NOTE: it was much easier and safer to solder 1P wires to this connector rather > than to motherboard, and you could remove/insert it at any time - what a great > convenience! The only 1P wire I had to solder to motherboard is to > motherboard's ground, - to make it possible to unite three grounds > (motherboard s, KB9012 s and programmer s) - and that was really easy because > at least one of these orange circle grounds has a great distance between it > and motherboard's elements so it is difficult to screw up there :) Going to > share photos and write some manuals about connectivity, hopefully helpful to > the people like me who want to participate in Origami EC project - creation of > open source firmware for KB9012 which in case of success will be a HUGE step > towards Lenovo G505S liberation (AMD laptop with coreboot support) . > Discovered Paul's presentation talk by pure accident - > https://www.youtube.com/watch?v=B708jdCiW7o > > So I tried using two SPI programmers: 1) CH341A . 2) Bus Pirate v4 . The only > observed difference is a speed: for CH341A read takes 13-14 minutes, while for > BPv4 - despite the latest 7.0 firmware with level 3 optimizations ( http://dan > gerousprototypes.com/docs/Bus_Pirate#Download ) and SPI speed is 8 MHz - it > takes 40 minutes to read! Checksums of the files are the same and the files > have almost the same contains as KB9012 image for LA-A091P G505S that I found > online (same except the area 0x1d000 - 0x1e0f0, their image is filled with > 0xff there, mine has many 0x00 with a few 0xff and also data - probably > encoded serial number and similar stuff) , so I am pretty sure these > programmers both are reading without errors in my setup, just at the different > speeds for some weird reason > > Patches applied before testing: > 1) https://patchwork.coreboot.org/patch/4412/ > 2) https://patchwork.coreboot.org/patch/4413/ > 3) https://patchwork.coreboot.org/patch/4414/ > > This problem with 1/2 detection rate is not a blocker, more like a small > inconvenience, so I strongly believe that these patches should be merged as > soon as possible! Paul Kocialkowski has committed them almost a year ago, such > a major feature and still not merged?? > > Below you could see some -VVV detection logs. > > After reading this really inspiring article ( http://code.paulk.fr/article25/a > n-incentive-for-liberating-computers-my-own-use-case ) I guess that Paul's > motherboard is LA-A092P, very similar to LA-A091P but no extra GPU. Could that > be a reason he is not getting a detection problem? Just a wild guess... > > Yours sincerely, > Mikeb > > 1) Common part of "2) and "3)" - CH341A tries to detect: > sudo ./flashrom -p ch341a_spi -c "KB9012 (EDI)" -VVV > flashrom v0.9.9-r1954 on Linux 4.4.0-36-generic (x86_64) > flashrom is free software, get the source code at https://flashrom.org > flashrom was built with libpci 3.3.1, GCC 5.4.0 20160609, little endian > Command line (5 args): ./flashrom -p ch341a_spi -c KB9012 (EDI) -VVV > > 2) FAIL: > Calibrating delay loop... OS timer resolution is 1 usecs, 578M loops per > second, 10 myus = 11 us, 100 myus = 92 us, 1000 myus = 914 us, 10000 myus = > 9661 us, 4 myus = 5 us, OK. > Initializing ch341a_spi programmer, Device revision is 3.0.4 > Wrote 3 bytes: aa 61 00 > Wrote 4 bytes: ab b7 7f 20 > The following protocols are supported: SPI. > Probing for ENE KB9012 (EDI), 128 kB: programmer_map_flash_region: mapping > KB9012 (EDI) from 0x00000000fffe0000 to 0x0000000000000000 > Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 00 ff ff ff > Read 7 bytes: ff ff ff ff 00 00 00 > programmer_unmap_flash_region: unmapped 0x0000000000000000 > No EEPROM/flash device found. > Note: flashrom can never write if the flash chip isn't found automatically. > Wrote 4 bytes: ab b7 40 20 > > 3) SUCCESS: > Calibrating delay loop... OS timer resolution is 1 usecs, 629M loops per > second, 10 myus = 11 us, 100 myus = 100 us, 1000 myus = 994 us, 10000 myus = > 9974 us, 4 myus = 4 us, OK. > Initializing ch341a_spi programmer, Device revision is 3.0.4 > Wrote 3 bytes: aa 61 00 > Wrote 4 bytes: ab b7 7f 20 > The following protocols are supported: SPI. > Probing for ENE KB9012 (EDI), 128 kB: programmer_map_flash_region: mapping > KB9012 (EDI) from 0x00000000fffe0000 to 0x0000000000000000 > Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 00 ff ff ff > Read 7 bytes: 00 00 00 00 fa 0a c3 > Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 24 ff ff ff > Read 7 bytes: 00 00 00 00 fa 0a 20 > Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 28 ff ff ff > Read 7 bytes: 00 00 00 00 fa 0a 00 > Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 ff 28 80 > Read 5 bytes: 00 00 00 00 00 > Found ENE flash chip "KB9012 (EDI)" (128 kB, SPI) on ch341a_spi. > programmer_unmap_flash_region: unmapped 0x0000000000000000 > No operations were specified. > Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 ff 28 ff ff ff > Read 7 bytes: 00 00 00 00 fa 0a 80 > Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 ff 28 00 > Read 5 bytes: 00 00 00 00 00 > Wrote 34 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 a8 cf > Read 1 bytes: 00 > Wrote 4 bytes: ab b7 40 20 > > 4) Small part of Bus Pirate v4 reading log: > buspirate_sendrecv: write 9, read 4 Sending 0x04 0x00 0x04 0x00 0x03 0x30 0x00 > 0xfe 0xab, receiving 0x01 0x5f 0x50 0x90 > buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00 0x40 > 0x00 0xfe 0xa8 0xc6, receiving 0x01 > buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00 0x40 > 0x00 0xfe 0xac 0x03, receiving 0x01 > buspirate_sendrecv: write 9, read 4 Sending 0x04 0x00 0x04 0x00 0x03 0x30 0x00 > 0xfe 0xab, receiving 0x01 0x5f 0x50 0xec > buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00 0x40 > 0x00 0xfe 0xa8 0xc7, receiving 0x01 > buspirate_sendrecv: write 10, read 1 Sending 0x04 0x00 0x05 0x00 0x00 0x40 > 0x00 0xfe 0xac 0x03, receiving 0x01 > > 5) Small part of CH341A reading log: > Read 5 bytes: 00 00 00 00 00 > Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 7f d5 ff ff ff > Read 7 bytes: 00 00 00 00 fa 0a ff > Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 7f 15 fb > Read 5 bytes: 00 00 00 00 00 > Wrote 38 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 a8 02 00 7f 35 c0 > Read 5 bytes: 00 00 00 00 00 > Wrote 40 bytes: ab b7 b7 b7 b6 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 a8 0c 00 7f d5 ff ff ff > -- Paul Kocialkowski, developer of low-level free software for embedded devices Website: https://www.paulk.fr/ Coding blog: https://code.paulk.fr/ Git repositories: https://git.paulk.fr/ https://git.code.paulk.fr/ -- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

flashrom October 2016