coreboot October 2014

coreboot@coreboot.org

43 participants
111 discussions

Re: [coreboot] Suggested readings
by prasnik＠anche.no 07 Oct '14

07 Oct '14

> However, there's > nothing (that I know of) that encompasses the expanse that is > historical x86 systems. do you mean that no book (that you know) talks about x86 systems?

3 2

Re: [coreboot] Suggested readings
by David Hubbard 06 Oct '14

06 Oct '14

On Mon, Oct 6, 2014 at 8:28 AM, Aaron Durbin <adurbin(a)chromium.org> wrote: > On Mon, Oct 6, 2014 at 9:42 AM, <prasnik(a)anche.no> wrote: > > Dear cb folks, > > > > I ask you some advice on material that is worth reading in order to gain > > fundamental notions on computer architecture. > > > > Which book do you suggest to that purpose? > > > > These aren't specific to x86 or any particular architecture -- just > computer arch in general. I find them to helpful/interesting: > > > http://www.amazon.com/Inside-Machine-Introduction-Microprocessors-Architect… > > http://www.amazon.com/gp/product/0201633388/ref=wms_ohs_product?ie=UTF8&psc… > > There are more academic books, but I think the above provide an > interesting introduction. If you are looking for more practical books > about a particular architecture those exist as well. However, there's > nothing (that I know of) that encompasses the expanse that is > historical x86 systems. > > Aaron's suggestions are spot on. If you want exactly "computer architecture" then study those books. If you want to take a slightly off-track approach, study http://wiki.osdev.org/Main_Page with the idea of writing an Operating System from scratch. I realize you probably aren't going to write an Operating System, but that knowledge is critical to understanding what Coreboot is doing. Good luck! David

1 0

Suggested readings
by prasnik＠anche.no 06 Oct '14

06 Oct '14

Dear cb folks, I ask you some advice on material that is worth reading in order to gain fundamental notions on computer architecture. Which book do you suggest to that purpose? Thanks in advance

2 1

i945: AHCI timeout with Crucial m4 SSD 2.5 in SeaBIOS on cold boot
by Paul Menzel 04 Oct '14

04 Oct '14

Dear coreboot and SeaBIOS folks, testing the SSD Crucial m4 SSD 2.5 256 GB SATA 6 Gb/s on the Lenovo X60t, the payload SeaBIOS 1.7.5-40-g5109366 does not detect the drive. […] 32.705: |7f673000| WARNING - Timeout at ahci_port_setup:466! 32.705: |7f673000| AHCI/0: device not ready (tf 0x80) 33.205: |7f673000| WARNING - Timeout at ahci_port_reset:336! […] Hitting Ctrl + Alt + Delete, the drive is detected. It is also reproducible on the Lenovo T60 with coreboot from four years ago and SeaBIOS 1.7.0-91-g7a39e72. The drive is detected correctly on the ASRock E350M1 with coreboot and SeaBIOS 1.7.5. Please find the whole serial log from SeaBIOS below. Does that look like a coreboot or SeaBIOS problem? Thanks, Paul $ ./scripts/readserial.py /dev/ttyUSB0 115200 ======= Sun Sep 14 09:54:52 2014 (adjust=86.8us) 00.000: <00> 01.376: Changing serial settings was 0/0 now 3/0 01.376: SeaBIOS (version rel-1.7.5-40-g5109366-20140715_011246-my-lenovo-x60t) 01.376: Attempting to find coreboot table 01.376: Found coreboot table forwarder. 01.376: Now attempting to find coreboot memory map 01.376: SeaBIOS (version rel-1.7.5-40-g5109366-20140715_011246-my-lenovo-x60t) 01.376: Found coreboot cbmem console @ 7f7de000 01.376: Found mainboard Lenovo ThinkPad X60 / X60s 01.376: malloc preinit 01.376: Relocating init from 0x000e6c20 to 0x7f679220 (size 44320) 01.376: malloc init 01.376: Found CBFS header at 0xfffffa50 01.376: Add romfile: cmos_layout.bin (size=1828) 01.376: Add romfile: pci8086,27a2.rom (size=65536) 01.376: Add romfile: cmos.default (size=256) 01.376: Add romfile: cpu_microcode_blob.bin (size=94208) 01.377: Add romfile: etc/ps2-keyboard-spinup (size=8) 01.377: Add romfile: config (size=4221) 01.377: Add romfile: (size=29976) 01.377: Add romfile: fallback/romstage (size=50939) 01.377: Add romfile: fallback/ramstage (size=68308) 01.377: Add romfile: fallback/payload (size=55644) 01.377: Add romfile: (size=1723928) 01.377: init ivt 01.377: init bda 01.377: init bios32 01.377: init PMM 01.377: init PNPBIOS table 01.377: init keyboard 01.377: init mouse 01.377: init pic 01.377: math cp init 01.378: CPU Mhz=1663 01.379: init timer 01.379: PCI probe 01.379: PCI device 00:00.0 (vd=8086:27a0 c=0600) 01.379: PCI device 00:02.0 (vd=8086:27a2 c=0300) 01.379: PCI device 00:02.1 (vd=8086:27a6 c=0380) 01.379: PCI device 00:1b.0 (vd=8086:27d8 c=0403) 01.379: PCI device 00:1c.0 (vd=8086:27d0 c=0604) 01.379: PCI device 00:1c.1 (vd=8086:27d2 c=0604) 01.379: PCI device 00:1c.2 (vd=8086:27d4 c=0604) 01.379: PCI device 00:1c.3 (vd=8086:27d6 c=0604) 01.379: PCI device 00:1d.0 (vd=8086:27c8 c=0c03) 01.379: PCI device 00:1d.1 (vd=8086:27c9 c=0c03) 01.379: PCI device 00:1d.2 (vd=8086:27ca c=0c03) 01.379: PCI device 00:1d.3 (vd=8086:27cb c=0c03) 01.379: PCI device 00:1d.7 (vd=8086:27cc c=0c03) 01.379: PCI device 00:1e.0 (vd=8086:2448 c=0604) 01.379: PCI device 00:1f.0 (vd=8086:27b9 c=0601) 01.379: PCI device 00:1f.1 (vd=8086:27df c=0101) 01.379: PCI device 00:1f.2 (vd=8086:27c5 c=0106) 01.379: PCI device 00:1f.3 (vd=8086:27da c=0c05) 01.379: PCI device 01:00.0 (vd=8086:109a c=0200) 01.379: PCI device 02:00.0 (vd=8086:4227 c=0280) 01.380: PCI device 05:00.0 (vd=1180:0476 c=0607) 01.379: PCI device 05:00.1 (vd=1180:0552 c=0c00) 01.380: PCI device 05:00.2 (vd=1180:0822 c=0805) 01.380: Found 23 PCI devices (max PCI bus is 06) 01.380: Relocating coreboot bios tables 01.380: Copying SMBIOS entry point from 0x7f7cc000 to 0x000f1920 01.381: Copying ACPI RSDP from 0x7f7cd000 to 0x000f18f0 01.381: Copying MPTABLE from 0x7f7d9000/7f7d9010 to 0x000f1720 01.381: rsdp=0x000f18f0 01.381: rsdt=0x7f7cd030 01.381: fadt=0x7f7d0510 01.381: pm_tmr_blk=508 01.381: Using pmtimer, ioport 0x508 01.381: Scan for VGA option rom 01.381: Attempting to init PCI bdf 00:02.0 (vd 8086:27a2) 01.381: Copying data 65536@0xffe007b8 to 65536@0x000c0000 01.415: Running option rom at c000:0003 01.462: unimplemented handle_155fXX:26: 01.462: a=80005f34 b=0000078f c=00000002 d=00000002 ds=0000 es=c000 ss=e000 01.462: si=00000994 di=00000080 bp=50a06e0c sp=0000ffe8 cs=c000 ip=4a6e f=0046 01.509: Turning on vga text mode console 01.540: SeaBIOS (version rel-1.7.5-40-g5109366-20140715_011246-my-lenovo-x60t) 01.540: Machine UUID c09ecb7b-2a1f-dc11-b88a-942d40962902 01.540: /7f677000\ Start thread 01.541: |7f677000| init usb 01.541: |7f677000| EHCI init on dev 00:1d.7 (regs=0xe4444020) 01.541: /7f676000\ Start thread 01.541: init ps2port 01.541: /7f674000\ Start thread 01.542: |7f674000| Copying data 8@0xffe27978 to 8@0x7f674fc8 01.542: /7f673000\ Start thread 01.542: init lpt 01.542: Found 0 lpt ports 01.542: init serial 01.542: Found 1 serial ports 01.542: init hard drives 01.542: ATA controller 1 at 1f0/3f4/0 (irq 14 dev f9) 01.542: /7f672000\ Start thread 01.542: /7f671000\ Start thread 01.542: ATA controller 2 at 170/374/0 (irq 15 dev f9) 01.542: /7f670000\ Start thread 01.542: |7f670000| powerup IDE floating 01.542: |7f670000| powerup IDE floating 01.542: |7f670000| powerup IDE floating 01.542: |7f670000| powerup IDE floating 01.542: \7f670000/ End thread 01.543: /7f670000\ Start thread 01.543: \7f671000/ End thread 01.543: \7f673000/ End thread 01.543: init ahci 01.542: AHCI controller at 1f.2, iobase e4444400, irq 0 01.543: AHCI: cap 0xdf12ff03, ports_impl 0x1 01.543: /7f673000\ Start thread 01.543: |7f673000| AHCI/0: probing 01.543: /7f671000\ Start thread 01.543: |7f673000| AHCI/0: link up 01.543: |7f672000| DVD/CD [ata0-0: DVD/CDRW UJDA775 ATAPI-5 DVD/CD] 01.543: |7f672000| Searching bootorder for: /pci@i0cf8/*@1f,1/drive@0/disk@0 01.543: |7f672000| Registering bootable: DVD/CD [ata0-0: DVD/CDRW UJDA775 ATAPI-5 DVD/CD] (type:3 prio:102 data:f16b0) 01.543: \7f672000/ End thread 01.543: |7f674000| Got ps2 nak (status=51) 01.543: |7f674000| ps2 command 2ff failed (aux=0) 01.543: /7f672000\ Start thread 01.544: \7f671000/ End thread 01.544: \7f670000/ End thread 01.544: /7f671000\ Start thread 01.544: /7f670000\ Start thread 01.544: |7f674000| Got ps2 nak (status=51) 01.544: |7f674000| ps2 command 2ff failed (aux=0) 01.544: /7f66f000\ Start thread 01.546: \7f672000/ End thread 01.546: |7f674000| Got ps2 nak (status=51) 01.546: |7f674000| ps2 command 2ff failed (aux=0) 01.546: \7f670000/ End thread 01.549: |7f674000| Got ps2 nak (status=51) 01.549: |7f674000| ps2 command 2ff failed (aux=0) 01.549: \7f66f000/ End thread 01.551: |7f674000| Got ps2 nak (status=51) 01.551: |7f674000| ps2 command 2ff failed (aux=0) 01.553: |7f674000| Got ps2 nak (status=51) 01.553: |7f674000| ps2 command 2ff failed (aux=0) 01.555: |7f674000| Got ps2 nak (status=51) 01.555: |7f674000| ps2 command 2ff failed (aux=0) 01.557: |7f674000| Got ps2 nak (status=51) 01.557: |7f674000| ps2 command 2ff failed (aux=0) 01.559: |7f674000| Got ps2 nak (status=51) 01.559: |7f674000| ps2 command 2ff failed (aux=0) 01.561: |7f671000| set_address 0x7f678090 01.561: |7f674000| Got ps2 nak (status=51) 01.561: |7f674000| ps2 command 2ff failed (aux=0) 01.561: |7f677000| UHCI init on dev 00:1d.0 (io=5000) 01.561: /7f672000\ Start thread 01.561: /7f670000\ Start thread 01.561: \7f670000/ End thread 01.562: |7f671000| ehci_control 0x7f675450 (dir=0 cmd=8 data=0) 01.562: |7f677000| UHCI init on dev 00:1d.1 (io=5020) 01.562: /7f670000\ Start thread 01.562: /7f66f000\ Start thread 01.562: \7f66f000/ End thread 01.562: /7f66f000\ Start thread 01.562: \7f66f000/ End thread 01.562: |7f677000| UHCI init on dev 00:1d.2 (io=5040) 01.562: /7f66f000\ Start thread 01.562: /7f66e000\ Start thread 01.562: \7f66e000/ End thread 01.562: /7f66e000\ Start thread 01.562: \7f66e000/ End thread 01.562: |7f671000| config_usb: 0x7f675450 01.562: |7f671000| ehci_control 0x7f675450 (dir=128 cmd=8 data=8) 01.562: |7f674000| Got ps2 nak (status=51) 01.562: |7f674000| ps2 command 2ff failed (aux=0) 01.562: |7f677000| UHCI init on dev 00:1d.3 (io=5060) 01.562: /7f66e000\ Start thread 01.562: /7f66c000\ Start thread 01.563: \7f66c000/ End thread 01.562: /7f66c000\ Start thread 01.562: \7f66c000/ End thread 01.563: \7f672000/ End thread 01.563: |7f671000| device rev=0200 cls=09 sub=00 proto=02 size=64 01.563: |7f671000| ehci_control 0x7f675450 (dir=128 cmd=8 data=9) 01.563: \7f677000/ End thread 01.563: /7f672000\ Start thread 01.563: \7f672000/ End thread 01.563: \7f670000/ End thread 01.563: |7f671000| ehci_control 0x7f675450 (dir=128 cmd=8 data=41) 01.563: \7f66f000/ End thread 01.563: |7f671000| ehci_control 0x7f675450 (dir=0 cmd=8 data=0) 01.563: |7f674000| Got ps2 nak (status=51) 01.563: |7f674000| ps2 command 2ff failed (aux=0) 01.563: \7f66e000/ End thread 01.563: |7f671000| ehci_control 0x7f675450 (dir=128 cmd=8 data=7) 01.563: /7f672000\ Start thread 01.563: |7f672000| ehci_control 0x7f675450 (dir=0 cmd=8 data=0) 01.564: /7f670000\ Start thread 01.564: |7f674000| Got ps2 nak (status=51) 01.564: |7f674000| ps2 command 2ff failed (aux=0) 01.564: /7f66f000\ Start thread 01.564: |7f66f000| ehci_control 0x7f675450 (dir=0 cmd=8 data=0) 01.564: /7f66e000\ Start thread 01.564: |7f670000| ehci_control 0x7f675450 (dir=0 cmd=8 data=0) 01.565: |7f66e000| ehci_control 0x7f675450 (dir=0 cmd=8 data=0) 01.565: |7f674000| Got ps2 nak (status=51) 01.565: |7f674000| ps2 command 2ff failed (aux=0) 01.566: |7f674000| Got ps2 nak (status=51) 01.567: |7f674000| ps2 command 2ff failed (aux=0) 01.569: |7f674000| Got ps2 nak (status=51) 01.569: |7f674000| ps2 command 2ff failed (aux=0) 01.572: |7f674000| Got ps2 nak (status=51) 01.572: |7f674000| ps2 command 2ff failed (aux=0) 01.574: |7f674000| Got ps2 nak (status=51) 01.574: |7f674000| ps2 command 2ff failed (aux=0) 01.576: |7f674000| Got ps2 nak (status=51) 01.576: |7f674000| ps2 command 2ff failed (aux=0) 01.577: |7f674000| Got ps2 nak (status=51) 01.578: |7f674000| ps2 command 2ff failed (aux=0) 01.580: |7f674000| Got ps2 nak (status=51) 01.580: |7f674000| ps2 command 2ff failed (aux=0) 01.582: |7f674000| Got ps2 nak (status=51) 01.583: |7f674000| ps2 command 2ff failed (aux=0) 01.583: |7f672000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.584: |7f674000| Got ps2 nak (status=51) 01.585: |7f674000| ps2 command 2ff failed (aux=0) 01.585: |7f66f000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.586: |7f670000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.586: |7f672000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.586: |7f674000| Got ps2 nak (status=51) 01.586: |7f674000| ps2 command 2ff failed (aux=0) 01.586: |7f66e000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.587: |7f66f000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.587: |7f674000| Got ps2 nak (status=51) 01.587: |7f674000| ps2 command 2ff failed (aux=0) 01.587: |7f670000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.587: |7f672000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.588: |7f66e000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.588: |7f674000| Got ps2 nak (status=51) 01.588: |7f674000| ps2 command 2ff failed (aux=0) 01.588: |7f66f000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.588: |7f670000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.588: |7f672000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.588: |7f674000| Got ps2 nak (status=51) 01.589: |7f674000| ps2 command 2ff failed (aux=0) 01.589: \7f672000/ End thread 01.589: |7f66e000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.589: |7f66f000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.589: |7f674000| Got ps2 nak (status=51) 01.589: |7f674000| ps2 command 2ff failed (aux=0) 01.589: \7f66f000/ End thread 01.589: |7f670000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.589: \7f670000/ End thread 01.589: |7f66e000| ehci_control 0x7f675450 (dir=128 cmd=8 data=4) 01.590: |7f674000| Got ps2 nak (status=51) 01.590: |7f674000| ps2 command 2ff failed (aux=0) 01.590: \7f66e000/ End thread 01.590: |7f671000| Initialized USB HUB (0 ports used) 01.590: \7f671000/ End thread 01.590: |7f674000| Got ps2 nak (status=51) 01.591: |7f674000| ps2 command 2ff failed (aux=0) 01.591: \7f676000/ End thread 01.593: |7f674000| Got ps2 nak (status=51) 01.594: |7f674000| ps2 command 2ff failed (aux=0) 01.596: |7f674000| Got ps2 nak (status=51) 01.596: |7f674000| ps2 command 2ff failed (aux=0) 01.599: |7f674000| Got ps2 nak (status=51) 01.600: |7f674000| ps2 command 2ff failed (aux=0) 01.602: |7f674000| Got ps2 nak (status=51) 01.602: |7f674000| ps2 command 2ff failed (aux=0) 01.605: |7f674000| Got ps2 nak (status=51) 01.605: |7f674000| ps2 command 2ff failed (aux=0) 01.609: |7f674000| Got ps2 nak (status=51) 01.609: |7f674000| ps2 command 2ff failed (aux=0) 01.610: |7f674000| Got ps2 nak (status=51) 01.611: |7f674000| ps2 command 2ff failed (aux=0) 01.614: |7f674000| Got ps2 nak (status=51) 01.614: |7f674000| ps2 command 2ff failed (aux=0) 01.616: |7f674000| Got ps2 nak (status=51) 01.617: |7f674000| ps2 command 2ff failed (aux=0) 01.619: |7f674000| Got ps2 nak (status=51) 01.620: |7f674000| ps2 command 2ff failed (aux=0) 01.622: |7f674000| Got ps2 nak (status=51) 01.623: |7f674000| ps2 command 2ff failed (aux=0) 01.625: |7f674000| Got ps2 nak (status=51) 01.626: |7f674000| ps2 command 2ff failed (aux=0) 01.628: |7f674000| Got ps2 nak (status=51) 01.629: |7f674000| ps2 command 2ff failed (aux=0) 01.632: |7f674000| Got ps2 nak (status=51) 01.632: |7f674000| ps2 command 2ff failed (aux=0) 01.636: |7f674000| Got ps2 nak (status=51) 01.637: |7f674000| ps2 command 2ff failed (aux=0) 01.639: |7f674000| Got ps2 nak (status=51) 01.639: |7f674000| ps2 command 2ff failed (aux=0) 01.640: |7f674000| Got ps2 nak (status=51) 01.641: |7f674000| ps2 command 2ff failed (aux=0) 01.643: |7f674000| Got ps2 nak (status=51) 01.643: |7f674000| ps2 command 2ff failed (aux=0) 01.645: |7f674000| Got ps2 nak (status=51) 01.646: |7f674000| ps2 command 2ff failed (aux=0) 01.648: |7f674000| Got ps2 nak (status=51) 01.649: |7f674000| ps2 command 2ff failed (aux=0) 01.652: |7f674000| Got ps2 nak (status=51) 01.652: |7f674000| ps2 command 2ff failed (aux=0) 01.654: |7f674000| Got ps2 nak (status=51) 01.654: |7f674000| ps2 command 2ff failed (aux=0) 01.656: |7f674000| Got ps2 nak (status=51) 01.656: |7f674000| ps2 command 2ff failed (aux=0) 01.658: |7f674000| Got ps2 nak (status=51) 01.659: |7f674000| ps2 command 2ff failed (aux=0) 01.661: |7f674000| Got ps2 nak (status=51) 01.663: |7f674000| ps2 command 2ff failed (aux=0) 01.663: |7f674000| Got ps2 nak (status=51) 01.664: |7f674000| ps2 command 2ff failed (aux=0) 01.665: |7f674000| Got ps2 nak (status=51) 01.666: |7f674000| ps2 command 2ff failed (aux=0) 01.668: |7f674000| Got ps2 nak (status=51) 01.669: |7f674000| ps2 command 2ff failed (aux=0) 01.670: |7f674000| Got ps2 nak (status=51) 01.670: |7f674000| ps2 command 2ff failed (aux=0) 01.672: |7f674000| Got ps2 nak (status=51) 01.672: |7f674000| ps2 command 2ff failed (aux=0) 01.675: |7f674000| Got ps2 nak (status=51) 01.675: |7f674000| ps2 command 2ff failed (aux=0) 01.676: |7f674000| Got ps2 nak (status=51) 01.677: |7f674000| ps2 command 2ff failed (aux=0) 01.679: |7f674000| Got ps2 nak (status=51) 01.679: |7f674000| ps2 command 2ff failed (aux=0) 01.680: |7f674000| Got ps2 nak (status=51) 01.682: |7f674000| ps2 command 2ff failed (aux=0) 01.682: |7f674000| Got ps2 nak (status=51) 01.683: |7f674000| ps2 command 2ff failed (aux=0) 01.686: |7f674000| Got ps2 nak (status=51) 01.686: |7f674000| ps2 command 2ff failed (aux=0) 01.687: |7f674000| Got ps2 nak (status=51) 01.688: |7f674000| ps2 command 2ff failed (aux=0) 01.690: |7f674000| Got ps2 nak (status=51) 01.691: |7f674000| ps2 command 2ff failed (aux=0) 01.692: |7f674000| Got ps2 nak (status=51) 01.693: |7f674000| ps2 command 2ff failed (aux=0) 01.694: |7f674000| Got ps2 nak (status=51) 01.695: |7f674000| ps2 command 2ff failed (aux=0) 01.696: |7f674000| Got ps2 nak (status=51) 01.697: |7f674000| ps2 command 2ff failed (aux=0) 01.699: |7f674000| Got ps2 nak (status=51) 01.699: |7f674000| ps2 command 2ff failed (aux=0) 01.701: |7f674000| Got ps2 nak (status=51) 01.701: |7f674000| ps2 command 2ff failed (aux=0) 01.704: |7f674000| Got ps2 nak (status=51) 01.704: |7f674000| ps2 command 2ff failed (aux=0) 01.706: |7f674000| Got ps2 nak (status=51) 01.707: |7f674000| ps2 command 2ff failed (aux=0) 01.708: |7f674000| Got ps2 nak (status=51) 01.709: |7f674000| ps2 command 2ff failed (aux=0) 01.710: |7f674000| Got ps2 nak (status=51) 01.711: |7f674000| ps2 command 2ff failed (aux=0) 01.712: |7f674000| Got ps2 nak (status=51) 01.713: |7f674000| ps2 command 2ff failed (aux=0) 01.716: |7f674000| Got ps2 nak (status=51) 01.716: |7f674000| ps2 command 2ff failed (aux=0) 01.718: |7f674000| Got ps2 nak (status=51) 01.719: |7f674000| ps2 command 2ff failed (aux=0) 01.720: |7f674000| Got ps2 nak (status=51) 01.720: |7f674000| ps2 command 2ff failed (aux=0) 01.722: |7f674000| Discarding ps2 data aa (status=11) 02.335: |7f674000| PS2 keyboard initialized 02.335: \7f674000/ End thread 32.705: |7f673000| WARNING - Timeout at ahci_port_setup:466! 32.705: |7f673000| AHCI/0: device not ready (tf 0x80) 33.205: |7f673000| WARNING - Timeout at ahci_port_reset:336! 33.205: \7f673000/ End thread 33.206: All threads complete. 33.205: Scan for option roms 33.206: Attempting to init PCI bdf 00:00.0 (vd 8086:27a0) 33.206: Attempting to init PCI bdf 00:02.1 (vd 8086:27a6) 33.205: Attempting to init PCI bdf 00:1b.0 (vd 8086:27d8) 33.206: Attempting to init PCI bdf 00:1c.0 (vd 8086:27d0) 33.206: Attempting to init PCI bdf 00:1c.1 (vd 8086:27d2) 33.205: Attempting to init PCI bdf 00:1c.2 (vd 8086:27d4) 33.206: Attempting to init PCI bdf 00:1c.3 (vd 8086:27d6) 33.206: Attempting to init PCI bdf 00:1d.0 (vd 8086:27c8) 33.206: Attempting to init PCI bdf 00:1d.1 (vd 8086:27c9) 33.206: Attempting to init PCI bdf 00:1d.2 (vd 8086:27ca) 33.206: Attempting to init PCI bdf 00:1d.3 (vd 8086:27cb) 33.206: Attempting to init PCI bdf 00:1d.7 (vd 8086:27cc) 33.205: Attempting to init PCI bdf 00:1e.0 (vd 8086:2448) 33.205: Attempting to init PCI bdf 00:1f.0 (vd 8086:27b9) 33.206: Attempting to init PCI bdf 00:1f.2 (vd 8086:27c5) 33.206: Attempting to init PCI bdf 00:1f.3 (vd 8086:27da) 33.205: Attempting to init PCI bdf 01:00.0 (vd 8086:109a) 33.205: Attempting to init PCI bdf 02:00.0 (vd 8086:4227) 33.205: Attempting to init PCI bdf 05:00.0 (vd 1180:0476) 33.206: Attempting to init PCI bdf 05:00.1 (vd 1180:0552) 33.206: Attempting to init PCI bdf 05:00.2 (vd 1180:0822) 33.206: 33.206: Press F12 for boot menu. 33.206: 33.206: Checking for bootsplash 35.774: Searching bootorder for: HALT 35.774: Mapping cd drive 0x000f16b0 35.774: finalize PMM 35.774: malloc finalize 35.775: Space available for UMB: cf000-ee800, f0000-f1680 35.775: Returned 262144 bytes of ZoneHigh 35.775: e820 map has 6 items: 35.775: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 35.774: 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 35.774: 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 35.775: 3: 0000000000100000 - 000000007f6c4000 = 1 RAM 35.774: 4: 000000007f6c4000 - 0000000080000000 = 2 RESERVED 35.774: 5: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 35.775: Jump to int19 35.775: enter handle_19: 35.775: NULL 35.776: Booting from DVD/CD... 35.777: Device reports MEDIUM NOT PRESENT 35.777: scsi_is_ready returned -1 35.777: Boot failed: Could not read from CDROM (code 0003) 35.777: enter handle_18: 35.777: NULL 35.777: Booting from Floppy... 35.777: invalid handle_legacy_disk:696: 35.777: a=00000201 b=00000000 c=00000001 d=00000000 ds=0000 es=07c0 ss=e000 35.777: si=00000000 di=00000000 bp=00000000 sp=0000ffe8 cs=f000 ip=d066 f=0202 35.777: Boot failed: could not read the boot disk 35.777: 35.777: enter handle_18: 35.777: NULL 35.777: Booting from Hard Disk... 35.777: invalid handle_legacy_disk:696: 35.778: a=00000201 b=00000000 c=00000001 d=00000080 ds=0000 es=07c0 ss=e000 35.777: si=00000000 di=00000000 bp=00000000 sp=0000ffe8 cs=f000 ip=d066 f=0202 35.777: Boot failed: could not read the boot disk 35.777: 35.777: enter handle_18: 35.777: NULL 35.777: No bootable device. Retrying in 60 seconds. 41.647: In resume (status=0) 41.647: In 32bit resume 41.647: Attempting a hard reboot 41.873: <00> 42.313: <00> 43.046: Changing serial settings was 0/0 now 3/0 43.046: SeaBIOS (version rel-1.7.5-40-g5109366-20140715_011246-my-lenovo-x60t) 43.046: Attempting to find coreboot table 43.046: Found coreboot table forwarder. 43.046: Now attempting to find coreboot memory map 43.047: SeaBIOS (version rel-1.7.5-40-g5109366-20140715_011246-my-lenovo-x60t) 43.046: Found coreboot cbmem console @ 7f7de000 43.046: Found mainboard Lenovo ThinkPad X60 / X60s 43.047: malloc preinit 43.047: Relocating init from 0x000e6c20 to 0x7f679220 (size 44320) 43.046: malloc init 43.047: Found CBFS header at 0xfffffa50 43.046: Add romfile: cmos_layout.bin (size=1828) 43.047: Add romfile: pci8086,27a2.rom (size=65536) 43.046: Add romfile: cmos.default (size=256) 43.046: Add romfile: cpu_microcode_blob.bin (size=94208) 43.047: Add romfile: etc/ps2-keyboard-spinup (size=8) 43.047: Add romfile: config (size=4221) 43.047: Add romfile: (size=29976) 43.047: Add romfile: fallback/romstage (size=50939) 43.047: Add romfile: fallback/ramstage (size=68308) 43.047: Add romfile: fallback/payload (size=55644) 43.047: Add romfile: (size=1723928) 43.048: init ivt 43.048: init bda 43.047: init bios32 43.047: init PMM 43.047: init PNPBIOS table 43.047: init keyboard 43.047: init mouse 43.047: init pic 43.047: math cp init 43.048: CPU Mhz=1664 43.049: init timer 43.049: PCI probe 43.049: PCI device 00:00.0 (vd=8086:27a0 c=0600) 43.049: PCI device 00:02.0 (vd=8086:27a2 c=0300) 43.049: PCI device 00:02.1 (vd=8086:27a6 c=0380) 43.049: PCI device 00:1b.0 (vd=8086:27d8 c=0403) 43.049: PCI device 00:1c.0 (vd=8086:27d0 c=0604) 43.049: PCI device 00:1c.1 (vd=8086:27d2 c=0604) 43.049: PCI device 00:1c.2 (vd=8086:27d4 c=0604) 43.049: PCI device 00:1c.3 (vd=8086:27d6 c=0604) 43.049: PCI device 00:1d.0 (vd=8086:27c8 c=0c03) 43.049: PCI device 00:1d.1 (vd=8086:27c9 c=0c03) 43.049: PCI device 00:1d.2 (vd=8086:27ca c=0c03) 43.049: PCI device 00:1d.3 (vd=8086:27cb c=0c03) 43.049: PCI device 00:1d.7 (vd=8086:27cc c=0c03) 43.049: PCI device 00:1e.0 (vd=8086:2448 c=0604) 43.049: PCI device 00:1f.0 (vd=8086:27b9 c=0601) 43.049: PCI device 00:1f.1 (vd=8086:27df c=0101) 43.049: PCI device 00:1f.2 (vd=8086:27c5 c=0106) 43.049: PCI device 00:1f.3 (vd=8086:27da c=0c05) 43.049: PCI device 01:00.0 (vd=8086:109a c=0200) 43.049: PCI device 02:00.0 (vd=8086:4227 c=0280) 43.049: PCI device 05:00.0 (vd=1180:0476 c=0607) 43.050: PCI device 05:00.1 (vd=1180:0552 c=0c00) 43.049: PCI device 05:00.2 (vd=1180:0822 c=0805) 43.050: Found 23 PCI devices (max PCI bus is 06) 43.050: Relocating coreboot bios tables 43.051: Copying SMBIOS entry point from 0x7f7cc000 to 0x000f1920 43.051: Copying ACPI RSDP from 0x7f7cd000 to 0x000f18f0 43.051: Copying MPTABLE from 0x7f7d9000/7f7d9010 to 0x000f1720 43.051: rsdp=0x000f18f0 43.051: rsdt=0x7f7cd030 43.051: fadt=0x7f7d0510 43.051: pm_tmr_blk=508 43.051: Using pmtimer, ioport 0x508 43.051: Scan for VGA option rom 43.052: Attempting to init PCI bdf 00:02.0 (vd 8086:27a2) 43.051: Copying data 65536@0xffe007b8 to 65536@0x000c0000 43.084: Running option rom at c000:0003 43.132: unimplemented handle_155fXX:26: 43.132: a=80005f34 b=0000078f c=00000002 d=00000002 ds=0000 es=c000 ss=e000 43.132: si=00000994 di=00000080 bp=50a06e0c sp=0000ffe8 cs=c000 ip=4a6e f=0046 43.178: Turning on vga text mode console 43.210: SeaBIOS (version rel-1.7.5-40-g5109366-20140715_011246-my-lenovo-x60t) 43.211: Machine UUID c09ecb7b-2a1f-dc11-b88a-942d40962902 43.211: /7f677000\ Start thread 43.210: |7f677000| init usb 43.211: |7f677000| EHCI init on dev 00:1d.7 (regs=0xe4444020) 43.210: /7f676000\ Start thread 43.211: init ps2port 43.210: /7f674000\ Start thread 43.212: |7f674000| Copying data 8@0xffe27978 to 8@0x7f674fc8 43.211: /7f673000\ Start thread 43.212: init lpt 43.212: Found 0 lpt ports 43.212: init serial 43.212: Found 1 serial ports 43.212: init hard drives 43.212: ATA controller 1 at 1f0/3f4/0 (irq 14 dev f9) 43.212: /7f672000\ Start thread 43.212: /7f671000\ Start thread 43.212: ATA controller 2 at 170/374/0 (irq 15 dev f9) 43.213: /7f670000\ Start thread 43.213: |7f670000| powerup IDE floating 43.212: |7f670000| powerup IDE floating 43.212: |7f670000| powerup IDE floating 43.212: |7f670000| powerup IDE floating 43.212: \7f670000/ End thread 43.212: /7f670000\ Start thread 43.212: \7f671000/ End thread 43.212: \7f673000/ End thread 43.212: init ahci 43.212: AHCI controller at 1f.2, iobase e4444400, irq 0 43.212: AHCI: cap 0xdf12ff03, ports_impl 0x1 43.212: /7f673000\ Start thread 43.212: |7f673000| AHCI/0: probing 43.212: /7f671000\ Start thread 43.213: \7f670000/ End thread 43.213: |7f673000| AHCI/0: link up 43.213: |7f672000| DVD/CD [ata0-0: DVD/CDRW UJDA775 ATAPI-5 DVD/CD] 43.213: |7f672000| Searching bootorder for: /pci@i0cf8/*@1f,1/drive@0/disk@0 43.213: |7f672000| Registering bootable: DVD/CD [ata0-0: DVD/CDRW UJDA775 ATAPI-5 DVD/CD] (type:3 prio:102 data:f16b0) 43.213: \7f672000/ End thread 43.213: /7f672000\ Start thread 43.213: \7f671000/ End thread 43.213: |7f673000| AHCI/0: ... finished, status 0x51, ERROR 0x4 43.213: /7f671000\ Start thread 43.213: |7f673000| Searching bootorder for: /pci@i0cf8/*@1f,2/drive@0/disk@0 43.213: /7f670000\ Start thread 43.213: |7f673000| AHCI/0: registering: "AHCI/0: M4-CT256M4SSD2 ATA-9 Hard-Disk (238 GiBytes)" 43.213: |7f673000| Registering bootable: AHCI/0: M4-CT256M4SSD2 ATA-9 Hard-Disk (238 GiBytes) (type:2 prio:103 data:f1660) 43.213: \7f673000/ End thread 43.213: /7f673000\ Start thread 43.213: \7f670000/ End thread 43.213: \7f672000/ End thread 43.230: \7f673000/ End thread 43.261: |7f671000| set_address 0x7f678090 43.261: |7f677000| UHCI init on dev 00:1d.0 (io=5000) 43.261: /7f673000\ Start thread 43.261: /7f672000\ Start thread 43.262: \7f672000/ End thread 43.261: |7f671000| ehci_control 0x7f675bd0 (dir=0 cmd=8 data=0) 43.261: |7f677000| UHCI init on dev 00:1d.1 (io=5020) 43.262: /7f672000\ Start thread 43.261: /7f670000\ Start thread 43.261: \7f670000/ End thread 43.262: /7f670000\ Start thread 43.261: \7f670000/ End thread 43.261: |7f677000| UHCI init on dev 00:1d.2 (io=5040) 43.262: /7f670000\ Start thread 43.262: /7f66f000\ Start thread 43.262: \7f66f000/ End thread 43.262: /7f66f000\ Start thread 43.262: \7f66f000/ End thread 43.262: |7f671000| config_usb: 0x7f675bd0 43.262: |7f671000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=8) 43.262: |7f677000| UHCI init on dev 00:1d.3 (io=5060) 43.261: /7f66f000\ Start thread 43.262: /7f66e000\ Start thread 43.262: \7f66e000/ End thread 43.262: /7f66e000\ Start thread 43.262: \7f66e000/ End thread 43.262: \7f673000/ End thread 43.262: |7f671000| device rev=0200 cls=09 sub=00 proto=02 size=64 43.262: |7f671000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=9) 43.262: \7f677000/ End thread 43.262: /7f673000\ Start thread 43.262: \7f673000/ End thread 43.262: \7f672000/ End thread 43.262: |7f671000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=41) 43.262: \7f670000/ End thread 43.262: |7f671000| ehci_control 0x7f675bd0 (dir=0 cmd=8 data=0) 43.262: \7f66f000/ End thread 43.262: |7f671000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=7) 43.262: /7f673000\ Start thread 43.262: |7f673000| ehci_control 0x7f675bd0 (dir=0 cmd=8 data=0) 43.262: /7f672000\ Start thread 43.262: /7f670000\ Start thread 43.262: |7f670000| ehci_control 0x7f675bd0 (dir=0 cmd=8 data=0) 43.262: /7f66f000\ Start thread 43.262: |7f672000| ehci_control 0x7f675bd0 (dir=0 cmd=8 data=0) 43.262: |7f66f000| ehci_control 0x7f675bd0 (dir=0 cmd=8 data=0) 43.343: |7f673000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.347: |7f670000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: |7f672000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.347: |7f673000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.347: |7f66f000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.347: |7f670000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.347: |7f672000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.347: |7f673000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: |7f66f000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: |7f670000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: |7f672000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: |7f673000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: |7f66f000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: |7f670000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: |7f672000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: |7f673000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: |7f66f000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: |7f670000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: |7f672000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: |7f673000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: \7f673000/ End thread 43.348: |7f66f000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: |7f670000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.348: \7f670000/ End thread 43.348: |7f672000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.351: \7f672000/ End thread 43.349: |7f66f000| ehci_control 0x7f675bd0 (dir=128 cmd=8 data=4) 43.349: \7f66f000/ End thread 43.349: |7f671000| Initialized USB HUB (0 ports used) 43.348: \7f671000/ End thread 43.352: \7f676000/ End thread 43.501: |7f674000| PS2 keyboard initialized 43.501: \7f674000/ End thread 43.501: All threads complete. 43.501: Scan for option roms 43.501: Attempting to init PCI bdf 00:00.0 (vd 8086:27a0) 43.501: Attempting to init PCI bdf 00:02.1 (vd 8086:27a6) 43.501: Attempting to init PCI bdf 00:1b.0 (vd 8086:27d8) 43.501: Attempting to init PCI bdf 00:1c.0 (vd 8086:27d0) 43.501: Attempting to init PCI bdf 00:1c.1 (vd 8086:27d2) 43.501: Attempting to init PCI bdf 00:1c.2 (vd 8086:27d4) 43.502: Attempting to init PCI bdf 00:1c.3 (vd 8086:27d6) 43.501: Attempting to init PCI bdf 00:1d.0 (vd 8086:27c8) 43.501: Attempting to init PCI bdf 00:1d.1 (vd 8086:27c9) 43.501: Attempting to init PCI bdf 00:1d.2 (vd 8086:27ca) 43.501: Attempting to init PCI bdf 00:1d.3 (vd 8086:27cb) 43.501: Attempting to init PCI bdf 00:1d.7 (vd 8086:27cc) 43.501: Attempting to init PCI bdf 00:1e.0 (vd 8086:2448) 43.501: Attempting to init PCI bdf 00:1f.0 (vd 8086:27b9) 43.501: Attempting to init PCI bdf 00:1f.2 (vd 8086:27c5) 43.501: Attempting to init PCI bdf 00:1f.3 (vd 8086:27da) 43.501: Attempting to init PCI bdf 01:00.0 (vd 8086:109a) 43.501: Attempting to init PCI bdf 02:00.0 (vd 8086:4227) 43.501: Attempting to init PCI bdf 05:00.0 (vd 1180:0476) 43.501: Attempting to init PCI bdf 05:00.1 (vd 1180:0552) 43.502: Attempting to init PCI bdf 05:00.2 (vd 1180:0822) 43.501: 43.501: Press F12 for boot menu. 43.502: 43.502: Checking for bootsplash 46.035: Searching bootorder for: HALT 46.045: Mapping cd drive 0x000f16b0 46.045: Mapping hd drive 0x000f1660 to 0 46.045: drive 0x000f1660: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 s=500118192 46.045: finalize PMM 46.045: malloc finalize 46.045: Space available for UMB: cf000-ee800, f0000-f1630 46.045: Returned 253952 bytes of ZoneHigh 46.045: e820 map has 6 items: 46.045: 0: 0000000000000000 - 000000000009fc00 = 1 RAM 46.045: 1: 000000000009fc00 - 00000000000a0000 = 2 RESERVED 46.045: 2: 00000000000f0000 - 0000000000100000 = 2 RESERVED 46.045: 3: 0000000000100000 - 000000007f6c2000 = 1 RAM 46.045: 4: 000000007f6c2000 - 0000000080000000 = 2 RESERVED 46.045: 5: 00000000f0000000 - 00000000f4000000 = 2 RESERVED 46.045: Jump to int19 46.045: enter handle_19: 46.045: NULL 46.045: Booting from DVD/CD... 46.045: Device reports MEDIUM NOT PRESENT 46.045: scsi_is_ready returned -1 46.045: Boot failed: Could not read from CDROM (code 0003) 46.045: enter handle_18: 46.045: NULL 46.045: Booting from Hard Disk... 46.045: Booting from 0000:7c00

3 5

Re: [coreboot] Lenovo N20p Chromebook
by John Lewis 03 Oct '14

03 Oct '14

On 03/10/14 15:23, Aaron Durbin wrote: > On Thu, Oct 2, 2014 at 4:48 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >> >> >> On 02/10/14 22:25, Aaron Durbin wrote: >>> >>> On Thu, Oct 2, 2014 at 3:51 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >>>> >>>> On 02/10/14 19:31, Aaron Durbin wrote: >>>>> >>>>> >>>>> On Mon, Sep 22, 2014 at 3:21 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >>>>>> >>>>>> >>>>>> On 22/09/14 19:59, Aaron Durbin wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Sep 22, 2014 at 12:24 PM, John Lewis <jlewis(a)johnlewis.ie> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 22/09/14 17:39, Aaron Durbin wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sun, Sep 21, 2014 at 8:14 AM, John Lewis <jlewis(a)johnlewis.ie> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 21/09/14 14:06, Aaron Durbin wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Sun, Sep 21, 2014 at 7:44 AM, John Lewis <jlewis(a)johnlewis.ie> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> snip >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm trying to flash the ROM externally now, but it's telling >>>>>>>>>>>>>>>>> me >>>>>>>>>>>>>>>>> it >>>>>>>>>>>>>>>>> can't >>>>>>>>>>>>>>>>> disable block protection. It gets as far as trying to erase >>>>>>>>>>>>>>>>> 0x600000, >>>>>>>>>>>>>>>>> then >>>>>>>>>>>>>>>>> goes through all the erase functions, finally crapping out. >>>>>>>>>>>>>>>>> Do >>>>>>>>>>>>>>>>> you >>>>>>>>>>>>>>>>> know >>>>>>>>>>>>>>>>> how >>>>>>>>>>>>>>>>> I can work-around that? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The write protect screw is removed, right? After that the >>>>>>>>>>>>>>>> flash's >>>>>>>>>>>>>>>> write protect register needs to be updated. Do you know the >>>>>>>>>>>>>>>> status >>>>>>>>>>>>>>>> register values? Flashrom should be able to do that. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, it is definitely removed - I didn't put it back in after >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> initial >>>>>>>>>>>>>>> brick. It says the register value is 0x94 - I did also hook up >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> Bus >>>>>>>>>>>>>>> Pirate for use with statically linked ChromeOS Flashrom (as >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> particular >>>>>>>>>>>>>>> version I have doesn't have Dediprog support) - I had an idea >>>>>>>>>>>>>>> running >>>>>>>>>>>>>>> --wp-disable might help, but it didn't recognise the chip and >>>>>>>>>>>>>>> said >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> register was already 0x94 (paraphrasing). I am currently >>>>>>>>>>>>>>> compiling >>>>>>>>>>>>>>> a >>>>>>>>>>>>>>> newer >>>>>>>>>>>>>>> statically linked version of ChromeOS Flashrom using the SDK, >>>>>>>>>>>>>>> in >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> hope >>>>>>>>>>>>>>> that might be able to do the job. Am I barking up the wrong >>>>>>>>>>>>>>> tree >>>>>>>>>>>>>>> though, or >>>>>>>>>>>>>>> is there something else I could do? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> You are in the right spot. The fact that it failed at 6MiB is >>>>>>>>>>>>>> very >>>>>>>>>>>>>> indicative of the SPI part write protection. There are, >>>>>>>>>>>>>> however, >>>>>>>>>>>>>> more >>>>>>>>>>>>>> than one status register. There should be 3 of them: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Read Status Register-1 (05h), Status Register-2 (35h) & Status >>>>>>>>>>>>>> Register-3 (15h) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Btw, I'm referencing W25Q64FW datasheet. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Aaron >>>>>>>>>>>>>> >>>>>>>>>>>>> Yeah, using --wp-status with Clapper's Flashrom tells me that >>>>>>>>>>>>> the >>>>>>>>>>>>> write >>>>>>>>>>>>> protect *is* enabled, after all. But I can't see where, apart >>>>>>>>>>>>> from >>>>>>>>>>>>> the >>>>>>>>>>>>> screw I took out right next to the battery, the write-protect >>>>>>>>>>>>> screw >>>>>>>>>>>>> would be? And I'm confused as to why it let me write initially >>>>>>>>>>>>> if >>>>>>>>>>>>> the >>>>>>>>>>>>> write-protect wasn't enabled. >>>>>>>>>>>>> >>>>>>>>>>>>> This is the output I get trying to run --wp-disable: >>>>>>>>>>>>> >>>>>>>>>>>>> w25_set_srp0: old status: 0x94 >>>>>>>>>>>>> w25_set_srp0: new status: 0x94 >>>>>>>>>>>>> w25q_disable_writeprotect(): error=1. >>>>>>>>>>>>> No -i argument is specified, set ignore_fmap. >>>>>>>>>>>>> FAILED >>>>>>>>>>>>> Setting SPI voltage to 0.000 V >>>>>>>>>>>>> restore_power_management: Re-enabling power management. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I've sorted it out now - had to bridge pins 3,7 and 8 using a >>>>>>>>>>>> large >>>>>>>>>>>> paper-clip, as alluded to in the OSCON presentation, referenced >>>>>>>>>>>> by >>>>>>>>>>>> Barry >>>>>>>>>>>> Schultz. Never had to do that before, oddly. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Interesting. You had to hard pull WP# and HOLD#. I need to take a >>>>>>>>>>> look >>>>>>>>>>> at that circuit. I wouldn't have expected you to do that either. >>>>>>>>>>> >>>>>>>>>> I don't understand it obviously, but I thought the main point was >>>>>>>>>> to >>>>>>>>>> get >>>>>>>>>> voltage to the WP pin to disable the hard write-protect. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I looked at the schematics. There's a lot of complexity in that area >>>>>>>>> because of voltage differences. I'm not surprised you had to short >>>>>>>>> WP# >>>>>>>>> to SPI VCC to make it work. I'm guessing this is most likely >>>>>>>>> required >>>>>>>>> for all baytrail based ChromeOS devices. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Anyway, back to our original problem - the ROM with the refcode >>>>>>>>>> section >>>>>>>>>> changed from type 50 to type 10, still doesn't give us anything. As >>>>>>>>>> an >>>>>>>>>> experiment, I tried extracting one of my own kernel payloads, then >>>>>>>>>> adding >>>>>>>>>> it >>>>>>>>>> back in unchanged as a raw file, and changing the type to 50 on my >>>>>>>>>> Falco, >>>>>>>>>> and that doesn't work either. >>>>>>>>>> >>>>>>>>>> Could we try turning the extracted refcode binary back into an elf? >>>>>>>>>> How >>>>>>>>>> would I go about that? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I'm told firmware-clapper-5216.199.B is the correct firmware branch >>>>>>>>> to use. The other one is old and may not be working (this issue?). >>>>>>>>> >>>>>>>>> I'd be curious to see if you can get anything from your image. >>>>>>>>> http://www.chromium.org/chromium-os/servo has the servo pin >>>>>>>>> definitions for the cable. You could get uarts from EC and the >>>>>>>>> baytrail part. >>>>>>>>> >>>>>>>>> As for changing that thing back to ELF, it's definitely possible. >>>>>>>>> Can >>>>>>>>> we try using the proper branch first? If not, the refcode is an >>>>>>>>> rmodule so you'll just need to take the relocation information and >>>>>>>>> the >>>>>>>>> code to create a new ELF. We don't have a tool to do that right now, >>>>>>>>> but it wouldn't be too too hard. >>>>>>>>> >>>>>>>> >>>>>>>> I already switched to 5216.199.B today as that's the one the >>>>>>>> shellball >>>>>>>> is >>>>>>>> using. Unfortunately, it didn't make too much difference. >>>>>>>> >>>>>>>> That's a bit over my head - I am a complete dunce when it comes to >>>>>>>> electronics, can't even use a soldering iron. I don't know how to >>>>>>>> read >>>>>>>> schematics even. Unless you or someone else can illustrate further >>>>>>>> what >>>>>>>> would need to be done there, it's going to be a no go. I think Ron >>>>>>>> did >>>>>>>> semi-promise me a servo board near the start of the year though. ;) >>>>>>>> >>>>>>>> I also tried recreating the elf using the commands on the Hacking VMX >>>>>>>> page >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://www.chromium.org/chromium-os/developer-information-for-chrome-os-dev… >>>>>>>> but I'm fairly sure some of those values would be wrong. Happily >>>>>>>> though, >>>>>>>> the >>>>>>>> elf ended up exactly the right size once it was in the ROM (4296 >>>>>>>> bytes). >>>>>>>> Still didn't help though. >>>>>>>> >>>>>>>> Finally, I enabled the i915 driver in my Jeltka embedded Linux in the >>>>>>>> hope >>>>>>>> that there was just something wrong with SeaBIOS/video so it might >>>>>>>> get >>>>>>>> as >>>>>>>> far as the payload and give me a display regardless. But again, that >>>>>>>> didn't >>>>>>>> help. Tried with refcode done both ways. >>>>>>>> >>>>>>> >>>>>>> My concern is that we are focusing on this refcode thing, though >>>>>>> valid, but we're tripping over other issues. The only way I can see of >>>>>>> obtaining proof of life is to either get an LPC debug decoder (could >>>>>>> attach to TPM) or getting uarts from the EC and x86. The servo >>>>>>> connector has the EC and x86 uarts on it. We could tap into that. >>>>>>> >>>>>>> Could you load your SPI image to a place I could pull it down and >>>>>>> inspect it? I may be able to magically find some issue. But don't hold >>>>>>> your breath. :) >>>>>>> >>>>>> >>>>>> The only other thing that sticks out to me is vboot. Even though I have >>>>>> "# >>>>>> CONFIG_VBOOT_VERIFY_FIRMWARE is not set" in the config, the build still >>>>>> expects to find vboot_api.h from platform/vboot_reference. I've managed >>>>>> with >>>>>> some help to reasonably reliably get other models working using >>>>>> ChromeOS >>>>>> coreboot in the past, so I have to assume it's something new like this >>>>>> or >>>>>> refcode, causing the issue. It seems to me that a few problems are >>>>>> caused >>>>>> by >>>>>> code from one feature being tightly integrated with code from another, >>>>>> and >>>>>> when you don't want to use one of the features, things break. >>>>>> >>>>>> I've uploaded my last go to >>>>>> https://johnlewis.ie/coreboot-clapper-220914.rom >>>>> >>>>> >>>>> >>>>> I apologize for not getting back to this. It's been sitting in my >>>>> inbox, and I just realized last night that it's been over a week. The >>>>> mrc.bin is in the wrong part of the rom. It needs to be moved 1KiB >>>>> back. >>>>> >>>>> Current: >>>>> >>>>> $ cbfstool coreboot-clapper-220914.rom print >>>>> coreboot-clapper-220914.rom: 8192 kB, bootblocksize 1184, romsize >>>>> 8388608, offset 0x400000 >>>>> alignment: 64 bytes, architecture: x86 >>>>> >>>>> Name Offset Type Size >>>>> cmos_layout.bin 0x400000 cmos_layout 1164 >>>>> pci8086,0f31.rom 0x4004c0 optionrom 65536 >>>>> cpu_microcode_blob.bin 0x410500 microcode 104448 >>>>> config 0x429d80 raw 4852 >>>>> fallback/refcode 0x42b0c0 stage 4296 >>>>> (empty) 0x42c1c0 null 15768 >>>>> fallback/romstage 0x42ff80 stage 35539 >>>>> fallback/coreboot_ram 0x438ac0 stage 77305 >>>>> fallback/payload 0x44b900 payload 3263688 >>>>> (empty) 0x768600 null 227736 >>>>> mrc.bin 0x79ffc0 (unknown) 70168 >>>>> (empty) 0x7b1240 null 240984 >>>>> spd.bin 0x7ebfc0 (unknown) 2048 >>>>> (empty) 0x7ec800 null 78552 >>>>> >>>>> mrc.bin in this is actually an ELF file and there's 0x40 bytes of cbfs >>>>> metadata at 0x79ffc0. So ELF file lives at 0xfffa0000, but we want the >>>>> XIP code to live at that address. >>>>> >>>>> $ cbfstool coreboot-clapper-220914.rom extract -n mrc.bin -f mrc.elf >>>>> $ readelf -e mrc.elf >>>>> ELF Header: >>>>> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 >>>>> Class: ELF32 >>>>> Data: 2's complement, little endian >>>>> Version: 1 (current) >>>>> OS/ABI: UNIX - System V >>>>> ABI Version: 0 >>>>> Type: EXEC (Executable file) >>>>> Machine: Intel 80386 >>>>> Version: 0x1 >>>>> Entry point address: 0xfffa0000 >>>>> Start of program headers: 52 (bytes into file) >>>>> Start of section headers: 69848 (bytes into file) >>>>> Flags: 0x0 >>>>> Size of this header: 52 (bytes) >>>>> Size of program headers: 32 (bytes) >>>>> Number of program headers: 3 >>>>> Size of section headers: 40 (bytes) >>>>> Number of section headers: 8 >>>>> Section header string table index: 7 >>>>> >>>>> Section Headers: >>>>> [Nr] Name Type Addr Off Size ES Flg >>>>> Lk >>>>> Inf Al >>>>> [ 0] NULL 00000000 000000 000000 00 >>>>> 0 >>>>> 0 0 >>>>> [ 1] .MRC PROGBITS fffa0000 001000 00dadc 00 AX >>>>> 0 >>>>> 0 4 >>>>> [ 2] .GUID PROGBITS fffadadc 00eadc 000318 00 WA >>>>> 0 >>>>> 0 4 >>>>> [ 3] .VARS NOBITS fe008000 001000 002e08 00 WA >>>>> 0 >>>>> 0 4 >>>>> [ 4] .STACK NOBITS fe00ae08 001000 0051f8 00 WA >>>>> 0 >>>>> 0 1 >>>>> [ 5] .rel.MRC REL 00000000 00edf4 002110 08 >>>>> 0 >>>>> 1 1 >>>>> [ 6] .rel.GUID REL 00000000 010f04 0001a8 08 >>>>> 0 >>>>> 2 1 >>>>> [ 7] .shstrtab STRTAB 00000000 0110ac 00002b 00 >>>>> 0 >>>>> 0 1 >>>>> Key to Flags: >>>>> W (write), A (alloc), X (execute), M (merge), S (strings) >>>>> I (info), L (link order), G (group), T (TLS), E (exclude), x >>>>> (unknown) >>>>> O (extra OS processing required) o (OS specific), p (processor >>>>> specific) >>>>> >>>>> Program Headers: >>>>> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg >>>>> Align >>>>> LOAD 0x001000 0xfe008000 0xfe008000 0x00000 0x08000 RW >>>>> 0x1000 >>>>> LOAD 0x001000 0xfffa0000 0xfffa0000 0x0ddf4 0x0ddf4 RWE >>>>> 0x1000 >>>>> GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE >>>>> 0x4 >>>>> >>>>> Section to Segment mapping: >>>>> Segment Sections... >>>>> 00 .VARS .STACK >>>>> 01 .MRC .GUID >>>>> 02 >>>>> >>>>> The .MRC section is where the code lives (01 load segment). We want >>>>> that to live at 0xfffa0000 which is at offset 0x1000 into the elf >>>>> file. Therefore, we want this file to be added at 0xfffa0000 - 0x1000. >>>>> >>>>> You could manually move this or just 'cbfstool remove' then 'cbfstool >>>>> add' with the appropriate address. >>>>> >>>>> Hope that helps. >>>>> >>>> >>>> No worries at all. At least it's not had chance to gather too much dust >>>> upstairs. Don't you mean 4k back, as 0x1000 hex is 4096 bytes? >>> >>> >>> Yes. I thought that's what I said with '0xfffa0000 - 0x1000', but I >>> didn't mention that is where we want it in the end. >>> >>>> >>>> When I tried to add mrc.bin with a base address of 0x79efc0, it ended up >>>> at >>>> 0x79ef80. Using a base address of 0x79f000 got it in the right place, but >>>> there is still no output. >>> >>> >>> You need to account for the 0x40 bytes of cbfs metadata. 'cbfstool >>> print' shows offsets of files starting with their cbfs metadata -- not >>> the data they contain. It seems like you figured that out though. >>> >>>> >>>> Just to make sure I hadn't got the wrong end of the stick, I edited >>>> src/soc/intel/baytrail/Makefile.inc, changed mrc.bin-position to >>>> 0xfff9f000, >>>> and built again. The mrc.bin ended up at 0x79efc0, but again still no >>>> output. >>> >>> >>> That should be correct. >>> >>> (gdb) p/x -((8 << 20) - (0x79efc0 + 0x40)) >>> $14 = 0xfff9f000 >>> >>>> >>>> The only discernible difference is that the power button now switches off >>>> immediately, instead of requiring a long press. >>> >>> >>> Well that tells me we booted far enough to get SMIs flowing in that a >>> power button press does an immediate S5 transition. It seems like we >>> could be in the payload somewhere (that or around MP init). >>> >>> Do you know anyone who can solder? Tapping into the serial pins will >>> be really helpful. >>> >> >> My brother's great with a soldering iron, but he's over 300 miles away. >> >> I have a soldering iron, but I also have a psychological block about using >> it. I take it that the copper pads that are the "serial port" are what I >> will need to connect to? Do you think a bog standard soldering iron is small >> enough to manage it? > > I'm in the same boat as you. I'm capable of ripping pads off and > general destruction. That said, I think you could probably do it. You > really just need to attach a few wires. > > http://www.chromium.org/chromium-os/servo > > On that page is a link titled "schematic and layout for this cable". > In that tar.gz file is a schematic pdf. There is a header labeled "DUT > SIDE" that shows the pin out of the pads on your board. (DUT stands > for device under test). > > The pins you care about: > > GND - which can be picked up off of pin 1 or the other pins on there. > UART2_DUT_SERVO_TX - pin 17 > UART2_SERVO_DUT_TX - pin 16 > PPDUT_UART2_VREF - pin 18 > UART1_DUT_SERVO_TX - pin 33 > UART1_SERVO_DUT_TX - pin 32 > PPDUT_UART1_VREF - pin 34 > > Here's the decoder ring: > > UART2_DUT_SERVO_TX - x86 TX > UART2_SERVO_DUT_TX - x86 RX > > Both of those signals are 1.8V which you can pick up on > PPDUT_UART2_VREF if you need to. > > UART1_DUT_SERVO_TX - EC TX > UART1_SERVO_DUT_TX - EC RX > > Both of those signals are 3.3 which you can pick up on > PPDUT_UART1_VREF if you need to. > > Some example cables that should work (you can find the equivalent > across the internets). > http://www.ftdichip.com/Products/Cables/USBTTLSerial.htm > > TTL-232RG-VIP-WE - "Cable features voltage reference input for setting > UART signalling levels." > > That one you would need the VREF signals, but that cable should then > work for both x86 and EC side. Or you can go with a TTL serial cable > that has an internal regulator but then you need to match the > voltages. > > The EC will provide you the post codes sent by the x86 port80 on its > console. The x86 obviously will output all the coreboot messages. > > >> >> I could also do with pointing in the right direction on making the cable up >> - again, another thing I'm mostly unfamiliar with. > > Sorry for having to go down this path. It's the most immediate thing > to get information as I haven't had too much time to think about how > else to debug your setup as we're flying blind at the moment. > No problem at all, Aaron. I certainly feel a bit more confident now you've given me all that information. I'll get one of those cables ordered, probably the first one as it sounds easier than trying to regulate anything. ;) Thanks a mill, John.

1 0

Re: [coreboot] Lenovo N20p Chromebook
by John Lewis 03 Oct '14

03 Oct '14

On 02/10/14 22:25, Aaron Durbin wrote: > On Thu, Oct 2, 2014 at 3:51 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >> On 02/10/14 19:31, Aaron Durbin wrote: >>> >>> On Mon, Sep 22, 2014 at 3:21 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >>>> >>>> On 22/09/14 19:59, Aaron Durbin wrote: >>>>> >>>>> >>>>> On Mon, Sep 22, 2014 at 12:24 PM, John Lewis <jlewis(a)johnlewis.ie> >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 22/09/14 17:39, Aaron Durbin wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Sep 21, 2014 at 8:14 AM, John Lewis <jlewis(a)johnlewis.ie> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 21/09/14 14:06, Aaron Durbin wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sun, Sep 21, 2014 at 7:44 AM, John Lewis <jlewis(a)johnlewis.ie> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> snip >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm trying to flash the ROM externally now, but it's telling >>>>>>>>>>>>>>> me >>>>>>>>>>>>>>> it >>>>>>>>>>>>>>> can't >>>>>>>>>>>>>>> disable block protection. It gets as far as trying to erase >>>>>>>>>>>>>>> 0x600000, >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>> goes through all the erase functions, finally crapping out. Do >>>>>>>>>>>>>>> you >>>>>>>>>>>>>>> know >>>>>>>>>>>>>>> how >>>>>>>>>>>>>>> I can work-around that? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The write protect screw is removed, right? After that the >>>>>>>>>>>>>> flash's >>>>>>>>>>>>>> write protect register needs to be updated. Do you know the >>>>>>>>>>>>>> status >>>>>>>>>>>>>> register values? Flashrom should be able to do that. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, it is definitely removed - I didn't put it back in after >>>>>>>>>>>>> the >>>>>>>>>>>>> initial >>>>>>>>>>>>> brick. It says the register value is 0x94 - I did also hook up >>>>>>>>>>>>> the >>>>>>>>>>>>> Bus >>>>>>>>>>>>> Pirate for use with statically linked ChromeOS Flashrom (as the >>>>>>>>>>>>> particular >>>>>>>>>>>>> version I have doesn't have Dediprog support) - I had an idea >>>>>>>>>>>>> running >>>>>>>>>>>>> --wp-disable might help, but it didn't recognise the chip and >>>>>>>>>>>>> said >>>>>>>>>>>>> the >>>>>>>>>>>>> register was already 0x94 (paraphrasing). I am currently >>>>>>>>>>>>> compiling >>>>>>>>>>>>> a >>>>>>>>>>>>> newer >>>>>>>>>>>>> statically linked version of ChromeOS Flashrom using the SDK, in >>>>>>>>>>>>> the >>>>>>>>>>>>> hope >>>>>>>>>>>>> that might be able to do the job. Am I barking up the wrong tree >>>>>>>>>>>>> though, or >>>>>>>>>>>>> is there something else I could do? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> You are in the right spot. The fact that it failed at 6MiB is >>>>>>>>>>>> very >>>>>>>>>>>> indicative of the SPI part write protection. There are, however, >>>>>>>>>>>> more >>>>>>>>>>>> than one status register. There should be 3 of them: >>>>>>>>>>>> >>>>>>>>>>>> Read Status Register-1 (05h), Status Register-2 (35h) & Status >>>>>>>>>>>> Register-3 (15h) >>>>>>>>>>>> >>>>>>>>>>>> Btw, I'm referencing W25Q64FW datasheet. >>>>>>>>>>>> >>>>>>>>>>>> -Aaron >>>>>>>>>>>> >>>>>>>>>>> Yeah, using --wp-status with Clapper's Flashrom tells me that the >>>>>>>>>>> write >>>>>>>>>>> protect *is* enabled, after all. But I can't see where, apart from >>>>>>>>>>> the >>>>>>>>>>> screw I took out right next to the battery, the write-protect >>>>>>>>>>> screw >>>>>>>>>>> would be? And I'm confused as to why it let me write initially if >>>>>>>>>>> the >>>>>>>>>>> write-protect wasn't enabled. >>>>>>>>>>> >>>>>>>>>>> This is the output I get trying to run --wp-disable: >>>>>>>>>>> >>>>>>>>>>> w25_set_srp0: old status: 0x94 >>>>>>>>>>> w25_set_srp0: new status: 0x94 >>>>>>>>>>> w25q_disable_writeprotect(): error=1. >>>>>>>>>>> No -i argument is specified, set ignore_fmap. >>>>>>>>>>> FAILED >>>>>>>>>>> Setting SPI voltage to 0.000 V >>>>>>>>>>> restore_power_management: Re-enabling power management. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've sorted it out now - had to bridge pins 3,7 and 8 using a large >>>>>>>>>> paper-clip, as alluded to in the OSCON presentation, referenced by >>>>>>>>>> Barry >>>>>>>>>> Schultz. Never had to do that before, oddly. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Interesting. You had to hard pull WP# and HOLD#. I need to take a >>>>>>>>> look >>>>>>>>> at that circuit. I wouldn't have expected you to do that either. >>>>>>>>> >>>>>>>> I don't understand it obviously, but I thought the main point was to >>>>>>>> get >>>>>>>> voltage to the WP pin to disable the hard write-protect. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I looked at the schematics. There's a lot of complexity in that area >>>>>>> because of voltage differences. I'm not surprised you had to short WP# >>>>>>> to SPI VCC to make it work. I'm guessing this is most likely required >>>>>>> for all baytrail based ChromeOS devices. >>>>>>> >>>>>>>> >>>>>>>> Anyway, back to our original problem - the ROM with the refcode >>>>>>>> section >>>>>>>> changed from type 50 to type 10, still doesn't give us anything. As >>>>>>>> an >>>>>>>> experiment, I tried extracting one of my own kernel payloads, then >>>>>>>> adding >>>>>>>> it >>>>>>>> back in unchanged as a raw file, and changing the type to 50 on my >>>>>>>> Falco, >>>>>>>> and that doesn't work either. >>>>>>>> >>>>>>>> Could we try turning the extracted refcode binary back into an elf? >>>>>>>> How >>>>>>>> would I go about that? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I'm told firmware-clapper-5216.199.B is the correct firmware branch >>>>>>> to use. The other one is old and may not be working (this issue?). >>>>>>> >>>>>>> I'd be curious to see if you can get anything from your image. >>>>>>> http://www.chromium.org/chromium-os/servo has the servo pin >>>>>>> definitions for the cable. You could get uarts from EC and the >>>>>>> baytrail part. >>>>>>> >>>>>>> As for changing that thing back to ELF, it's definitely possible. Can >>>>>>> we try using the proper branch first? If not, the refcode is an >>>>>>> rmodule so you'll just need to take the relocation information and the >>>>>>> code to create a new ELF. We don't have a tool to do that right now, >>>>>>> but it wouldn't be too too hard. >>>>>>> >>>>>> >>>>>> I already switched to 5216.199.B today as that's the one the shellball >>>>>> is >>>>>> using. Unfortunately, it didn't make too much difference. >>>>>> >>>>>> That's a bit over my head - I am a complete dunce when it comes to >>>>>> electronics, can't even use a soldering iron. I don't know how to read >>>>>> schematics even. Unless you or someone else can illustrate further what >>>>>> would need to be done there, it's going to be a no go. I think Ron did >>>>>> semi-promise me a servo board near the start of the year though. ;) >>>>>> >>>>>> I also tried recreating the elf using the commands on the Hacking VMX >>>>>> page >>>>>> >>>>>> >>>>>> http://www.chromium.org/chromium-os/developer-information-for-chrome-os-dev… >>>>>> but I'm fairly sure some of those values would be wrong. Happily >>>>>> though, >>>>>> the >>>>>> elf ended up exactly the right size once it was in the ROM (4296 >>>>>> bytes). >>>>>> Still didn't help though. >>>>>> >>>>>> Finally, I enabled the i915 driver in my Jeltka embedded Linux in the >>>>>> hope >>>>>> that there was just something wrong with SeaBIOS/video so it might get >>>>>> as >>>>>> far as the payload and give me a display regardless. But again, that >>>>>> didn't >>>>>> help. Tried with refcode done both ways. >>>>>> >>>>> >>>>> My concern is that we are focusing on this refcode thing, though >>>>> valid, but we're tripping over other issues. The only way I can see of >>>>> obtaining proof of life is to either get an LPC debug decoder (could >>>>> attach to TPM) or getting uarts from the EC and x86. The servo >>>>> connector has the EC and x86 uarts on it. We could tap into that. >>>>> >>>>> Could you load your SPI image to a place I could pull it down and >>>>> inspect it? I may be able to magically find some issue. But don't hold >>>>> your breath. :) >>>>> >>>> >>>> The only other thing that sticks out to me is vboot. Even though I have >>>> "# >>>> CONFIG_VBOOT_VERIFY_FIRMWARE is not set" in the config, the build still >>>> expects to find vboot_api.h from platform/vboot_reference. I've managed >>>> with >>>> some help to reasonably reliably get other models working using ChromeOS >>>> coreboot in the past, so I have to assume it's something new like this or >>>> refcode, causing the issue. It seems to me that a few problems are caused >>>> by >>>> code from one feature being tightly integrated with code from another, >>>> and >>>> when you don't want to use one of the features, things break. >>>> >>>> I've uploaded my last go to >>>> https://johnlewis.ie/coreboot-clapper-220914.rom >>> >>> >>> I apologize for not getting back to this. It's been sitting in my >>> inbox, and I just realized last night that it's been over a week. The >>> mrc.bin is in the wrong part of the rom. It needs to be moved 1KiB >>> back. >>> >>> Current: >>> >>> $ cbfstool coreboot-clapper-220914.rom print >>> coreboot-clapper-220914.rom: 8192 kB, bootblocksize 1184, romsize >>> 8388608, offset 0x400000 >>> alignment: 64 bytes, architecture: x86 >>> >>> Name Offset Type Size >>> cmos_layout.bin 0x400000 cmos_layout 1164 >>> pci8086,0f31.rom 0x4004c0 optionrom 65536 >>> cpu_microcode_blob.bin 0x410500 microcode 104448 >>> config 0x429d80 raw 4852 >>> fallback/refcode 0x42b0c0 stage 4296 >>> (empty) 0x42c1c0 null 15768 >>> fallback/romstage 0x42ff80 stage 35539 >>> fallback/coreboot_ram 0x438ac0 stage 77305 >>> fallback/payload 0x44b900 payload 3263688 >>> (empty) 0x768600 null 227736 >>> mrc.bin 0x79ffc0 (unknown) 70168 >>> (empty) 0x7b1240 null 240984 >>> spd.bin 0x7ebfc0 (unknown) 2048 >>> (empty) 0x7ec800 null 78552 >>> >>> mrc.bin in this is actually an ELF file and there's 0x40 bytes of cbfs >>> metadata at 0x79ffc0. So ELF file lives at 0xfffa0000, but we want the >>> XIP code to live at that address. >>> >>> $ cbfstool coreboot-clapper-220914.rom extract -n mrc.bin -f mrc.elf >>> $ readelf -e mrc.elf >>> ELF Header: >>> Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 >>> Class: ELF32 >>> Data: 2's complement, little endian >>> Version: 1 (current) >>> OS/ABI: UNIX - System V >>> ABI Version: 0 >>> Type: EXEC (Executable file) >>> Machine: Intel 80386 >>> Version: 0x1 >>> Entry point address: 0xfffa0000 >>> Start of program headers: 52 (bytes into file) >>> Start of section headers: 69848 (bytes into file) >>> Flags: 0x0 >>> Size of this header: 52 (bytes) >>> Size of program headers: 32 (bytes) >>> Number of program headers: 3 >>> Size of section headers: 40 (bytes) >>> Number of section headers: 8 >>> Section header string table index: 7 >>> >>> Section Headers: >>> [Nr] Name Type Addr Off Size ES Flg Lk >>> Inf Al >>> [ 0] NULL 00000000 000000 000000 00 0 >>> 0 0 >>> [ 1] .MRC PROGBITS fffa0000 001000 00dadc 00 AX 0 >>> 0 4 >>> [ 2] .GUID PROGBITS fffadadc 00eadc 000318 00 WA 0 >>> 0 4 >>> [ 3] .VARS NOBITS fe008000 001000 002e08 00 WA 0 >>> 0 4 >>> [ 4] .STACK NOBITS fe00ae08 001000 0051f8 00 WA 0 >>> 0 1 >>> [ 5] .rel.MRC REL 00000000 00edf4 002110 08 0 >>> 1 1 >>> [ 6] .rel.GUID REL 00000000 010f04 0001a8 08 0 >>> 2 1 >>> [ 7] .shstrtab STRTAB 00000000 0110ac 00002b 00 0 >>> 0 1 >>> Key to Flags: >>> W (write), A (alloc), X (execute), M (merge), S (strings) >>> I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) >>> O (extra OS processing required) o (OS specific), p (processor >>> specific) >>> >>> Program Headers: >>> Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align >>> LOAD 0x001000 0xfe008000 0xfe008000 0x00000 0x08000 RW >>> 0x1000 >>> LOAD 0x001000 0xfffa0000 0xfffa0000 0x0ddf4 0x0ddf4 RWE >>> 0x1000 >>> GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 >>> >>> Section to Segment mapping: >>> Segment Sections... >>> 00 .VARS .STACK >>> 01 .MRC .GUID >>> 02 >>> >>> The .MRC section is where the code lives (01 load segment). We want >>> that to live at 0xfffa0000 which is at offset 0x1000 into the elf >>> file. Therefore, we want this file to be added at 0xfffa0000 - 0x1000. >>> >>> You could manually move this or just 'cbfstool remove' then 'cbfstool >>> add' with the appropriate address. >>> >>> Hope that helps. >>> >> >> No worries at all. At least it's not had chance to gather too much dust >> upstairs. Don't you mean 4k back, as 0x1000 hex is 4096 bytes? > > Yes. I thought that's what I said with '0xfffa0000 - 0x1000', but I > didn't mention that is where we want it in the end. > >> >> When I tried to add mrc.bin with a base address of 0x79efc0, it ended up at >> 0x79ef80. Using a base address of 0x79f000 got it in the right place, but >> there is still no output. > > You need to account for the 0x40 bytes of cbfs metadata. 'cbfstool > print' shows offsets of files starting with their cbfs metadata -- not > the data they contain. It seems like you figured that out though. > >> >> Just to make sure I hadn't got the wrong end of the stick, I edited >> src/soc/intel/baytrail/Makefile.inc, changed mrc.bin-position to 0xfff9f000, >> and built again. The mrc.bin ended up at 0x79efc0, but again still no >> output. > > That should be correct. > > (gdb) p/x -((8 << 20) - (0x79efc0 + 0x40)) > $14 = 0xfff9f000 > >> >> The only discernible difference is that the power button now switches off >> immediately, instead of requiring a long press. > > Well that tells me we booted far enough to get SMIs flowing in that a > power button press does an immediate S5 transition. It seems like we > could be in the payload somewhere (that or around MP init). > > Do you know anyone who can solder? Tapping into the serial pins will > be really helpful. > My brother's great with a soldering iron, but he's over 300 miles away. I have a soldering iron, but I also have a psychological block about using it. I take it that the copper pads that are the "serial port" are what I will need to connect to? Do you think a bog standard soldering iron is small enough to manage it? I could also do with pointing in the right direction on making the cable up - again, another thing I'm mostly unfamiliar with. John.

2 1

Re: [coreboot] Lenovo N20p Chromebook
by John Lewis 02 Oct '14

02 Oct '14

On 02/10/14 19:31, Aaron Durbin wrote: > On Mon, Sep 22, 2014 at 3:21 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >> On 22/09/14 19:59, Aaron Durbin wrote: >>> >>> On Mon, Sep 22, 2014 at 12:24 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >>>> >>>> >>>> >>>> On 22/09/14 17:39, Aaron Durbin wrote: >>>>> >>>>> >>>>> On Sun, Sep 21, 2014 at 8:14 AM, John Lewis <jlewis(a)johnlewis.ie> wrote: >>>>>> >>>>>> >>>>>> On 21/09/14 14:06, Aaron Durbin wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Sun, Sep 21, 2014 at 7:44 AM, John Lewis <jlewis(a)johnlewis.ie> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> snip >>>>>>>> >>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I'm trying to flash the ROM externally now, but it's telling me >>>>>>>>>>>>> it >>>>>>>>>>>>> can't >>>>>>>>>>>>> disable block protection. It gets as far as trying to erase >>>>>>>>>>>>> 0x600000, >>>>>>>>>>>>> then >>>>>>>>>>>>> goes through all the erase functions, finally crapping out. Do >>>>>>>>>>>>> you >>>>>>>>>>>>> know >>>>>>>>>>>>> how >>>>>>>>>>>>> I can work-around that? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The write protect screw is removed, right? After that the flash's >>>>>>>>>>>> write protect register needs to be updated. Do you know the >>>>>>>>>>>> status >>>>>>>>>>>> register values? Flashrom should be able to do that. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Yes, it is definitely removed - I didn't put it back in after the >>>>>>>>>>> initial >>>>>>>>>>> brick. It says the register value is 0x94 - I did also hook up the >>>>>>>>>>> Bus >>>>>>>>>>> Pirate for use with statically linked ChromeOS Flashrom (as the >>>>>>>>>>> particular >>>>>>>>>>> version I have doesn't have Dediprog support) - I had an idea >>>>>>>>>>> running >>>>>>>>>>> --wp-disable might help, but it didn't recognise the chip and said >>>>>>>>>>> the >>>>>>>>>>> register was already 0x94 (paraphrasing). I am currently compiling >>>>>>>>>>> a >>>>>>>>>>> newer >>>>>>>>>>> statically linked version of ChromeOS Flashrom using the SDK, in >>>>>>>>>>> the >>>>>>>>>>> hope >>>>>>>>>>> that might be able to do the job. Am I barking up the wrong tree >>>>>>>>>>> though, or >>>>>>>>>>> is there something else I could do? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You are in the right spot. The fact that it failed at 6MiB is very >>>>>>>>>> indicative of the SPI part write protection. There are, however, >>>>>>>>>> more >>>>>>>>>> than one status register. There should be 3 of them: >>>>>>>>>> >>>>>>>>>> Read Status Register-1 (05h), Status Register-2 (35h) & Status >>>>>>>>>> Register-3 (15h) >>>>>>>>>> >>>>>>>>>> Btw, I'm referencing W25Q64FW datasheet. >>>>>>>>>> >>>>>>>>>> -Aaron >>>>>>>>>> >>>>>>>>> Yeah, using --wp-status with Clapper's Flashrom tells me that the >>>>>>>>> write >>>>>>>>> protect *is* enabled, after all. But I can't see where, apart from >>>>>>>>> the >>>>>>>>> screw I took out right next to the battery, the write-protect screw >>>>>>>>> would be? And I'm confused as to why it let me write initially if >>>>>>>>> the >>>>>>>>> write-protect wasn't enabled. >>>>>>>>> >>>>>>>>> This is the output I get trying to run --wp-disable: >>>>>>>>> >>>>>>>>> w25_set_srp0: old status: 0x94 >>>>>>>>> w25_set_srp0: new status: 0x94 >>>>>>>>> w25q_disable_writeprotect(): error=1. >>>>>>>>> No -i argument is specified, set ignore_fmap. >>>>>>>>> FAILED >>>>>>>>> Setting SPI voltage to 0.000 V >>>>>>>>> restore_power_management: Re-enabling power management. >>>>>>>>> >>>>>>>> >>>>>>>> I've sorted it out now - had to bridge pins 3,7 and 8 using a large >>>>>>>> paper-clip, as alluded to in the OSCON presentation, referenced by >>>>>>>> Barry >>>>>>>> Schultz. Never had to do that before, oddly. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Interesting. You had to hard pull WP# and HOLD#. I need to take a look >>>>>>> at that circuit. I wouldn't have expected you to do that either. >>>>>>> >>>>>> I don't understand it obviously, but I thought the main point was to >>>>>> get >>>>>> voltage to the WP pin to disable the hard write-protect. >>>>> >>>>> >>>>> >>>>> I looked at the schematics. There's a lot of complexity in that area >>>>> because of voltage differences. I'm not surprised you had to short WP# >>>>> to SPI VCC to make it work. I'm guessing this is most likely required >>>>> for all baytrail based ChromeOS devices. >>>>> >>>>>> >>>>>> Anyway, back to our original problem - the ROM with the refcode section >>>>>> changed from type 50 to type 10, still doesn't give us anything. As an >>>>>> experiment, I tried extracting one of my own kernel payloads, then >>>>>> adding >>>>>> it >>>>>> back in unchanged as a raw file, and changing the type to 50 on my >>>>>> Falco, >>>>>> and that doesn't work either. >>>>>> >>>>>> Could we try turning the extracted refcode binary back into an elf? How >>>>>> would I go about that? >>>>> >>>>> >>>>> >>>>> I'm told firmware-clapper-5216.199.B is the correct firmware branch >>>>> to use. The other one is old and may not be working (this issue?). >>>>> >>>>> I'd be curious to see if you can get anything from your image. >>>>> http://www.chromium.org/chromium-os/servo has the servo pin >>>>> definitions for the cable. You could get uarts from EC and the >>>>> baytrail part. >>>>> >>>>> As for changing that thing back to ELF, it's definitely possible. Can >>>>> we try using the proper branch first? If not, the refcode is an >>>>> rmodule so you'll just need to take the relocation information and the >>>>> code to create a new ELF. We don't have a tool to do that right now, >>>>> but it wouldn't be too too hard. >>>>> >>>> >>>> I already switched to 5216.199.B today as that's the one the shellball is >>>> using. Unfortunately, it didn't make too much difference. >>>> >>>> That's a bit over my head - I am a complete dunce when it comes to >>>> electronics, can't even use a soldering iron. I don't know how to read >>>> schematics even. Unless you or someone else can illustrate further what >>>> would need to be done there, it's going to be a no go. I think Ron did >>>> semi-promise me a servo board near the start of the year though. ;) >>>> >>>> I also tried recreating the elf using the commands on the Hacking VMX >>>> page >>>> >>>> http://www.chromium.org/chromium-os/developer-information-for-chrome-os-dev… >>>> but I'm fairly sure some of those values would be wrong. Happily though, >>>> the >>>> elf ended up exactly the right size once it was in the ROM (4296 bytes). >>>> Still didn't help though. >>>> >>>> Finally, I enabled the i915 driver in my Jeltka embedded Linux in the >>>> hope >>>> that there was just something wrong with SeaBIOS/video so it might get as >>>> far as the payload and give me a display regardless. But again, that >>>> didn't >>>> help. Tried with refcode done both ways. >>>> >>> >>> My concern is that we are focusing on this refcode thing, though >>> valid, but we're tripping over other issues. The only way I can see of >>> obtaining proof of life is to either get an LPC debug decoder (could >>> attach to TPM) or getting uarts from the EC and x86. The servo >>> connector has the EC and x86 uarts on it. We could tap into that. >>> >>> Could you load your SPI image to a place I could pull it down and >>> inspect it? I may be able to magically find some issue. But don't hold >>> your breath. :) >>> >> >> The only other thing that sticks out to me is vboot. Even though I have "# >> CONFIG_VBOOT_VERIFY_FIRMWARE is not set" in the config, the build still >> expects to find vboot_api.h from platform/vboot_reference. I've managed with >> some help to reasonably reliably get other models working using ChromeOS >> coreboot in the past, so I have to assume it's something new like this or >> refcode, causing the issue. It seems to me that a few problems are caused by >> code from one feature being tightly integrated with code from another, and >> when you don't want to use one of the features, things break. >> >> I've uploaded my last go to https://johnlewis.ie/coreboot-clapper-220914.rom > > I apologize for not getting back to this. It's been sitting in my > inbox, and I just realized last night that it's been over a week. The > mrc.bin is in the wrong part of the rom. It needs to be moved 1KiB > back. > > Current: > > $ cbfstool coreboot-clapper-220914.rom print > coreboot-clapper-220914.rom: 8192 kB, bootblocksize 1184, romsize > 8388608, offset 0x400000 > alignment: 64 bytes, architecture: x86 > > Name Offset Type Size > cmos_layout.bin 0x400000 cmos_layout 1164 > pci8086,0f31.rom 0x4004c0 optionrom 65536 > cpu_microcode_blob.bin 0x410500 microcode 104448 > config 0x429d80 raw 4852 > fallback/refcode 0x42b0c0 stage 4296 > (empty) 0x42c1c0 null 15768 > fallback/romstage 0x42ff80 stage 35539 > fallback/coreboot_ram 0x438ac0 stage 77305 > fallback/payload 0x44b900 payload 3263688 > (empty) 0x768600 null 227736 > mrc.bin 0x79ffc0 (unknown) 70168 > (empty) 0x7b1240 null 240984 > spd.bin 0x7ebfc0 (unknown) 2048 > (empty) 0x7ec800 null 78552 > > mrc.bin in this is actually an ELF file and there's 0x40 bytes of cbfs > metadata at 0x79ffc0. So ELF file lives at 0xfffa0000, but we want the > XIP code to live at that address. > > $ cbfstool coreboot-clapper-220914.rom extract -n mrc.bin -f mrc.elf > $ readelf -e mrc.elf > ELF Header: > Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 > Class: ELF32 > Data: 2's complement, little endian > Version: 1 (current) > OS/ABI: UNIX - System V > ABI Version: 0 > Type: EXEC (Executable file) > Machine: Intel 80386 > Version: 0x1 > Entry point address: 0xfffa0000 > Start of program headers: 52 (bytes into file) > Start of section headers: 69848 (bytes into file) > Flags: 0x0 > Size of this header: 52 (bytes) > Size of program headers: 32 (bytes) > Number of program headers: 3 > Size of section headers: 40 (bytes) > Number of section headers: 8 > Section header string table index: 7 > > Section Headers: > [Nr] Name Type Addr Off Size ES Flg Lk Inf Al > [ 0] NULL 00000000 000000 000000 00 0 0 0 > [ 1] .MRC PROGBITS fffa0000 001000 00dadc 00 AX 0 0 4 > [ 2] .GUID PROGBITS fffadadc 00eadc 000318 00 WA 0 0 4 > [ 3] .VARS NOBITS fe008000 001000 002e08 00 WA 0 0 4 > [ 4] .STACK NOBITS fe00ae08 001000 0051f8 00 WA 0 0 1 > [ 5] .rel.MRC REL 00000000 00edf4 002110 08 0 1 1 > [ 6] .rel.GUID REL 00000000 010f04 0001a8 08 0 2 1 > [ 7] .shstrtab STRTAB 00000000 0110ac 00002b 00 0 0 1 > Key to Flags: > W (write), A (alloc), X (execute), M (merge), S (strings) > I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) > O (extra OS processing required) o (OS specific), p (processor specific) > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > LOAD 0x001000 0xfe008000 0xfe008000 0x00000 0x08000 RW 0x1000 > LOAD 0x001000 0xfffa0000 0xfffa0000 0x0ddf4 0x0ddf4 RWE 0x1000 > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 > > Section to Segment mapping: > Segment Sections... > 00 .VARS .STACK > 01 .MRC .GUID > 02 > > The .MRC section is where the code lives (01 load segment). We want > that to live at 0xfffa0000 which is at offset 0x1000 into the elf > file. Therefore, we want this file to be added at 0xfffa0000 - 0x1000. > > You could manually move this or just 'cbfstool remove' then 'cbfstool > add' with the appropriate address. > > Hope that helps. > No worries at all. At least it's not had chance to gather too much dust upstairs. Don't you mean 4k back, as 0x1000 hex is 4096 bytes? When I tried to add mrc.bin with a base address of 0x79efc0, it ended up at 0x79ef80. Using a base address of 0x79f000 got it in the right place, but there is still no output. Just to make sure I hadn't got the wrong end of the stick, I edited src/soc/intel/baytrail/Makefile.inc, changed mrc.bin-position to 0xfff9f000, and built again. The mrc.bin ended up at 0x79efc0, but again still no output. The only discernible difference is that the power button now switches off immediately, instead of requiring a long press. Thank you so much for all your help so far, and for coming back to this. John.

2 1

Re: [coreboot] Lenovo N20p Chromebook
by John Lewis 02 Oct '14

02 Oct '14

On 22/09/14 19:59, Aaron Durbin wrote: > On Mon, Sep 22, 2014 at 12:24 PM, John Lewis <jlewis(a)johnlewis.ie> wrote: >> >> >> On 22/09/14 17:39, Aaron Durbin wrote: >>> >>> On Sun, Sep 21, 2014 at 8:14 AM, John Lewis <jlewis(a)johnlewis.ie> wrote: >>>> >>>> On 21/09/14 14:06, Aaron Durbin wrote: >>>>> >>>>> >>>>> On Sun, Sep 21, 2014 at 7:44 AM, John Lewis <jlewis(a)johnlewis.ie> wrote: >>>>>> >>>>>> >>>>>> snip >>>>>> >>>>>> >>>>>>>>>>> >>>>>>>>>>> I'm trying to flash the ROM externally now, but it's telling me it >>>>>>>>>>> can't >>>>>>>>>>> disable block protection. It gets as far as trying to erase >>>>>>>>>>> 0x600000, >>>>>>>>>>> then >>>>>>>>>>> goes through all the erase functions, finally crapping out. Do you >>>>>>>>>>> know >>>>>>>>>>> how >>>>>>>>>>> I can work-around that? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The write protect screw is removed, right? After that the flash's >>>>>>>>>> write protect register needs to be updated. Do you know the status >>>>>>>>>> register values? Flashrom should be able to do that. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Yes, it is definitely removed - I didn't put it back in after the >>>>>>>>> initial >>>>>>>>> brick. It says the register value is 0x94 - I did also hook up the >>>>>>>>> Bus >>>>>>>>> Pirate for use with statically linked ChromeOS Flashrom (as the >>>>>>>>> particular >>>>>>>>> version I have doesn't have Dediprog support) - I had an idea >>>>>>>>> running >>>>>>>>> --wp-disable might help, but it didn't recognise the chip and said >>>>>>>>> the >>>>>>>>> register was already 0x94 (paraphrasing). I am currently compiling a >>>>>>>>> newer >>>>>>>>> statically linked version of ChromeOS Flashrom using the SDK, in the >>>>>>>>> hope >>>>>>>>> that might be able to do the job. Am I barking up the wrong tree >>>>>>>>> though, or >>>>>>>>> is there something else I could do? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> You are in the right spot. The fact that it failed at 6MiB is very >>>>>>>> indicative of the SPI part write protection. There are, however, more >>>>>>>> than one status register. There should be 3 of them: >>>>>>>> >>>>>>>> Read Status Register-1 (05h), Status Register-2 (35h) & Status >>>>>>>> Register-3 (15h) >>>>>>>> >>>>>>>> Btw, I'm referencing W25Q64FW datasheet. >>>>>>>> >>>>>>>> -Aaron >>>>>>>> >>>>>>> Yeah, using --wp-status with Clapper's Flashrom tells me that the >>>>>>> write >>>>>>> protect *is* enabled, after all. But I can't see where, apart from the >>>>>>> screw I took out right next to the battery, the write-protect screw >>>>>>> would be? And I'm confused as to why it let me write initially if the >>>>>>> write-protect wasn't enabled. >>>>>>> >>>>>>> This is the output I get trying to run --wp-disable: >>>>>>> >>>>>>> w25_set_srp0: old status: 0x94 >>>>>>> w25_set_srp0: new status: 0x94 >>>>>>> w25q_disable_writeprotect(): error=1. >>>>>>> No -i argument is specified, set ignore_fmap. >>>>>>> FAILED >>>>>>> Setting SPI voltage to 0.000 V >>>>>>> restore_power_management: Re-enabling power management. >>>>>>> >>>>>> >>>>>> I've sorted it out now - had to bridge pins 3,7 and 8 using a large >>>>>> paper-clip, as alluded to in the OSCON presentation, referenced by >>>>>> Barry >>>>>> Schultz. Never had to do that before, oddly. >>>>> >>>>> >>>>> >>>>> Interesting. You had to hard pull WP# and HOLD#. I need to take a look >>>>> at that circuit. I wouldn't have expected you to do that either. >>>>> >>>> I don't understand it obviously, but I thought the main point was to get >>>> voltage to the WP pin to disable the hard write-protect. >>> >>> >>> I looked at the schematics. There's a lot of complexity in that area >>> because of voltage differences. I'm not surprised you had to short WP# >>> to SPI VCC to make it work. I'm guessing this is most likely required >>> for all baytrail based ChromeOS devices. >>> >>>> >>>> Anyway, back to our original problem - the ROM with the refcode section >>>> changed from type 50 to type 10, still doesn't give us anything. As an >>>> experiment, I tried extracting one of my own kernel payloads, then adding >>>> it >>>> back in unchanged as a raw file, and changing the type to 50 on my Falco, >>>> and that doesn't work either. >>>> >>>> Could we try turning the extracted refcode binary back into an elf? How >>>> would I go about that? >>> >>> >>> I'm told firmware-clapper-5216.199.B is the correct firmware branch >>> to use. The other one is old and may not be working (this issue?). >>> >>> I'd be curious to see if you can get anything from your image. >>> http://www.chromium.org/chromium-os/servo has the servo pin >>> definitions for the cable. You could get uarts from EC and the >>> baytrail part. >>> >>> As for changing that thing back to ELF, it's definitely possible. Can >>> we try using the proper branch first? If not, the refcode is an >>> rmodule so you'll just need to take the relocation information and the >>> code to create a new ELF. We don't have a tool to do that right now, >>> but it wouldn't be too too hard. >>> >> >> I already switched to 5216.199.B today as that's the one the shellball is >> using. Unfortunately, it didn't make too much difference. >> >> That's a bit over my head - I am a complete dunce when it comes to >> electronics, can't even use a soldering iron. I don't know how to read >> schematics even. Unless you or someone else can illustrate further what >> would need to be done there, it's going to be a no go. I think Ron did >> semi-promise me a servo board near the start of the year though. ;) >> >> I also tried recreating the elf using the commands on the Hacking VMX page >> http://www.chromium.org/chromium-os/developer-information-for-chrome-os-dev… >> but I'm fairly sure some of those values would be wrong. Happily though, the >> elf ended up exactly the right size once it was in the ROM (4296 bytes). >> Still didn't help though. >> >> Finally, I enabled the i915 driver in my Jeltka embedded Linux in the hope >> that there was just something wrong with SeaBIOS/video so it might get as >> far as the payload and give me a display regardless. But again, that didn't >> help. Tried with refcode done both ways. >> > > My concern is that we are focusing on this refcode thing, though > valid, but we're tripping over other issues. The only way I can see of > obtaining proof of life is to either get an LPC debug decoder (could > attach to TPM) or getting uarts from the EC and x86. The servo > connector has the EC and x86 uarts on it. We could tap into that. > > Could you load your SPI image to a place I could pull it down and > inspect it? I may be able to magically find some issue. But don't hold > your breath. :) > The only other thing that sticks out to me is vboot. Even though I have "# CONFIG_VBOOT_VERIFY_FIRMWARE is not set" in the config, the build still expects to find vboot_api.h from platform/vboot_reference. I've managed with some help to reasonably reliably get other models working using ChromeOS coreboot in the past, so I have to assume it's something new like this or refcode, causing the issue. It seems to me that a few problems are caused by code from one feature being tightly integrated with code from another, and when you don't want to use one of the features, things break. I've uploaded my last go to https://johnlewis.ie/coreboot-clapper-220914.rom Thank you! John.

2 1

Re: [coreboot] X60: ethernet LED still on when machine is powered off or suspended
by Denis 'GNUtoo' Carikli 02 Oct '14

02 Oct '14

On Thu, 21 Aug 2014 15:41:02 -0700 ron minnich <rminnich(a)gmail.com> wrote: > On Thu, Aug 21, 2014 at 2:10 PM, The Gluglug <info(a)gluglug.org.uk> > wrote: [...] > > On 21/08/14 22:08, The Gluglug wrote: > >> A little quirk I noticed. If I put the machine in suspend while an > >> ethernet cable is plugged in to a switch (or if plugging it in > >> after suspending), the green light from the ethernet/eth0 is still > >> active. > >> > >> Any ideas? > >> > > > > The same thing also happens while the machine is powered off, if I > > leave the AC adapter/charger connected. > > > and only on coreboot? > > I can't recall but I did have laptops that would light the LED even > when off, I always assumed it was the ME The only thing that is supposed to be on is the EC. The Ethernet NIC isn't supposed to have a firmware, right? Else it would have a flash chip connected to it, right? It still has a very small eeprom for its configuration bits, and I think some bits are documented in some intel datasheets. I hope that: * The computer is properly powered off when on battery, and that the NIC and its led are also off during suspend to ram. * There is no firmware or such that I missed, because I guess that this NIC can do DMA. Denis.

1 0

Secure boot(against evil-maids) on Lenovo i945 laptops.
by Denis 'GNUtoo' Carikli 02 Oct '14

02 Oct '14

Hi, Use case: --------- Usually when people do full disk encryption, it's not really full disk, instead they still have a /boot in clear. So an evil maid attack can still be done, in two passes: 1) Clone the hdd, Infect the initramfs or the kernel. 2) Wait for the user to enter its password, recover the password, luksOpen the hdd image. I wanted a real full-disk encryption so I've put grub in flash and I have the following: The HDD has a LUKS rootfs(containing /boot) on an lvm partition, so no partition is in clear. So when the computer boots it executes coreboot, then grub as a payload. Grub then opens the LUKS partition and loads the kernel and initramfs from there. To prevent hardware level tempering(like reflashing), I used nail polish with a lot of gilder, that acts like a seal. Then a high resolution picture of it is taken, to be able to tell the difference. The problem: ------------ But then comes the docking port issue: Some LPC pins are exported there, such as the CLKRUN and LDRQ#. LDRQ# is "Encoded DMA/Bus Master Request": "Only needed by peripherals that need DMA or bus mastering. Requires an individual signal per peripheral. Peripherals may not share an LDRQ# signal." So now DMA access is possible trough the dock connector. So I want to be able to turn that off. If I got it right, the X60 has 2 superio, one is in the dock, and the other one is in the laptop, so we have: ________________ _________________ | | | | | Dock connector:| |Dock: NSC pc87982|<--LPC--->D_LPC_DREQ0 | |_________________| |_______^________| | | | | ___________________|____ | v | | SuperIO: DLDRQ# | | NSC pc87382 LDRQ# | |___________________^____| | | | | ___________________|___ | v | | Southbridge: LDRQ0 | | ICH7 | |_______________________| The code: --------- Now if I look at the existing code, there is some superio drivers, like pc87382 in src/superio/nsc, the code is very small. The only interesting part is the pnp_info pnp_dev_info struct. Now if I look inside src/mainboard/lenovo/x60 there is some more complete dock driver: Inside dock.c I see some dock_connect and dock_disconnect functions. Such functions are called during the initialisation (romstage.c) and from the x60's SMI handler (smihandler.c). Questions: ---------- 1) Would the following be sufficent to prevent DMA access from the outside: > int dock_connect(void) > { > int timeout = 1000; > + int val; > + > + if (get_option(&val, "dock") != CB_SUCCESS) > + val = 1; > + if (val == 0) > + return 0; > [...] > } > > void dock_disconnect(void) { > + if (dock_present()) > + return; > [...] > } 2) Would an nvram option be ok for that? Should a Kconfig option be added too? > config DOCK_AUTODETECT > bool "Autodetect" > help > The dock is autodetected. If unsure select this option. > > config DOCK_DISABLED > bool "Disabled" > help > The dock is always disabled. > > config DOCK_NVRAM_ENABLE > bool "Nvram" > help > The dock autodetection is tried only if it is also enabled > trough nvram. Denis.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2014