On 03/10/14 15:23, Aaron Durbin wrote:
On Thu, Oct 2, 2014 at 4:48 PM, John Lewis <[email protected]> wrote:
On 02/10/14 22:25, Aaron Durbin wrote:
On Thu, Oct 2, 2014 at 3:51 PM, John Lewis <[email protected]> wrote:
On 02/10/14 19:31, Aaron Durbin wrote:
On Mon, Sep 22, 2014 at 3:21 PM, John Lewis <[email protected]> wrote:
On 22/09/14 19:59, Aaron Durbin wrote:
On Mon, Sep 22, 2014 at 12:24 PM, John Lewis <[email protected]>
wrote:
On 22/09/14 17:39, Aaron Durbin wrote:
On Sun, Sep 21, 2014 at 8:14 AM, John Lewis <[email protected]>
wrote:
On 21/09/14 14:06, Aaron Durbin wrote:
On Sun, Sep 21, 2014 at 7:44 AM, John Lewis <[email protected]>
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-devices/samsung-sandy-bridge/coreboot-vmx-hack
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.
--
coreboot mailing list: [email protected]
http://www.coreboot.org/mailman/listinfo/coreboot
