On 15/09/14 23:17, Aaron Durbin wrote:
On Mon, Sep 15, 2014 at 5:13 PM, John Lewis jlewis@johnlewis.ie wrote:
On 15/09/14 23:10, Aaron Durbin wrote:
On Mon, Sep 15, 2014 at 5:00 PM, John Lewis jlewis@johnlewis.ie wrote:
On 15/09/14 22:50, Aaron Durbin wrote:
On Mon, Sep 15, 2014 at 4:29 PM, John Lewis jlewis@johnlewis.ie wrote:
On 15/09/14 22:03, Aaron Durbin wrote: > > > > On Mon, Sep 15, 2014 at 3:35 PM, John Lewis jlewis@johnlewis.ie > wrote: >> >> >> >> Hello, >> >> I've purchased the subject Chromebook with a view to getting some >> sort >> of >> custom ROM going for Baytrail based Chromebooks, and I have my first >> brick >> of the day. >> >> I'm using ChromeOS coreboot and the firmware-clapper-5218.B branch. >> As >> per >> the advice Aaron gave me regarding the ASUS C200 some time ago, I >> extracted >> the reference code binary and changed line 111 in >> src/arch/x86/Makefile.inc >> as follows: >> >> $(CBFSTOOL) $@.tmp add -f $(CONFIG_REFCODE_BLOB_FILE) -n >> $(CONFIG_CBFS_PREFIX)/refcode -t raw >> > > I think I might know. You are using upstream, right? This is my fault. > The rmodule format changed. We didn't bump the version, and dropped > the old code. Can you run readelf -e on that blob you extracted? I > think I allowed ELF packaging for that file. If that doesn't work > (hexdump -C) would be helpful. > No, I'm using ChromiumOS coreboot. With readelf -e I get:
readelf -e refcode.bin readelf: Error: Unable to read in 0x7115 bytes of section headers readelf: Error: Not an ELF file - it has the wrong magic bytes at the start
hexdump -C:
hexdump -C refcode.bin 00000000 01 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 |................| 00000010 00 00 00 00 ac 10 00 00 b8 4b 00 00 01 00 60 00 |.........K....`.| 00000020 00 a0 4b 00 00 00 00 00 00 00 7f 3f ec 22 15 71 |..K........?.".q|
snip
000010b0 ea 88 85 74 8b 20 1e db 6b 09 b3 c0 40 c3 eb ed |...t. ..k...@...| 000010c0 48 a8 8d c4 08 32 85 80 |H....2..| 000010c8
You may want to snip that. ;)
OK. A couple of things. Bear with me as I use this thread to think things through. This file is compressed. We extracted it, and added it back using 'raw'. That means cbfs_file->type != CBFS_TYPE_STAGE. So refcode loading would not work. Would it create a brick? I wouldn't think so, but I haven't tried.
Offhand, do you have the option rom? Do we see any life out of the display? I'm trying to think of ways to see how far we've gotten without serial console. Is MRC in the same place as the released firmware? Perhaps a cbfstool print might be instructive on your resulting image.
Yes, I extracted all the necessary files from the shellball ROM for Clapper. No, no life from the display (no backlight even).
coreboot.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 103424 config 0x429980 raw 4298 fallback/refcode 0x42aa80 raw 4296 (empty) 0x42bb80 null 17368 fallback/romstage 0x42ff80 stage 35171 fallback/coreboot_ram 0x438980 stage 71515 fallback/payload 0x44a140 payload 34866 img/Jeltka 0x4529c0 payload 2970296 (empty) 0x727cc0 null 492248 mrc.bin 0x79ffc0 (unknown) 70168 (empty) 0x7b1240 null 240984 spd.bin 0x7ebfc0 (unknown) 1536 (empty) 0x7ec600 null 79064
After bricking the device can you re-flash the spi part back to a released image?
I don't see why not, but it's getting late here and people are sleeping so I'll have to do that in the morning. If there's anything else quick I'll hang around this end for 10 or so minutes to answer.
Understood. The only thing I can think of trying really quickly is making the type of the file to be a stage instead of raw. You'll need to hexedit the rom to change the type.
-Aaron
Okay, fire away, I have it open and ready.
In your rom, find the "LARCHIVE" tombstone with the appropriate name afterwards ('fallback/refcode). It should be around offset 0x42aa80. For reference:
struct cbfs_file {
-------char magic[8]; -------uint32_t len; -------uint32_t type; -------uint32_t checksum; -------uint32_t offset;
} __attribute__((packed));
We want to change the type field. There should be a hex 0x50 associated with the fallback/refcode file. Change that number to be 0x10. Save and then cbfstool print should list the type as 'stage'.
Out of interest, the "Developer Information for Chrome OS Devices" page now lists a baseboard for each device - would it be worth compiling upstream rambi with EHCI debug if we get stuck with ChromiumOS coreboot?
Hello! (Speaking as an observer, currently.) It couldn't hurt.
And how difficult would it be to do that. ----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again."
On Mon, Sep 15, 2014 at 6:46 PM, John Lewis jlewis@johnlewis.ie wrote:
On 15/09/14 23:17, Aaron Durbin wrote:
On Mon, Sep 15, 2014 at 5:13 PM, John Lewis jlewis@johnlewis.ie wrote:
On 15/09/14 23:10, Aaron Durbin wrote:
On Mon, Sep 15, 2014 at 5:00 PM, John Lewis jlewis@johnlewis.ie wrote:
On 15/09/14 22:50, Aaron Durbin wrote:
On Mon, Sep 15, 2014 at 4:29 PM, John Lewis jlewis@johnlewis.ie wrote: > > > > On 15/09/14 22:03, Aaron Durbin wrote: >> >> >> >> >> On Mon, Sep 15, 2014 at 3:35 PM, John Lewis jlewis@johnlewis.ie >> wrote: >>> >>> >>> >>> >>> Hello, >>> >>> I've purchased the subject Chromebook with a view to getting some >>> sort >>> of >>> custom ROM going for Baytrail based Chromebooks, and I have my >>> first >>> brick >>> of the day. >>> >>> I'm using ChromeOS coreboot and the firmware-clapper-5218.B branch. >>> As >>> per >>> the advice Aaron gave me regarding the ASUS C200 some time ago, I >>> extracted >>> the reference code binary and changed line 111 in >>> src/arch/x86/Makefile.inc >>> as follows: >>> >>> $(CBFSTOOL) $@.tmp add -f $(CONFIG_REFCODE_BLOB_FILE) >>> -n >>> $(CONFIG_CBFS_PREFIX)/refcode -t raw >>> >> >> I think I might know. You are using upstream, right? This is my >> fault. >> The rmodule format changed. We didn't bump the version, and dropped >> the old code. Can you run readelf -e on that blob you extracted? I >> think I allowed ELF packaging for that file. If that doesn't work >> (hexdump -C) would be helpful. >> > No, I'm using ChromiumOS coreboot. With readelf -e I get: > > readelf -e refcode.bin > readelf: Error: Unable to read in 0x7115 bytes of section headers > readelf: Error: Not an ELF file - it has the wrong magic bytes at the > start > > hexdump -C: > > hexdump -C refcode.bin > 00000000 01 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 > |................| > 00000010 00 00 00 00 ac 10 00 00 b8 4b 00 00 01 00 60 00 > |.........K....`.| > 00000020 00 a0 4b 00 00 00 00 00 00 00 7f 3f ec 22 15 71 > |..K........?.".q|
snip
> 000010b0 ea 88 85 74 8b 20 1e db 6b 09 b3 c0 40 c3 eb ed |...t. > ..k...@...| > 000010c0 48 a8 8d c4 08 32 85 80 > |H....2..| > 000010c8 > > You may want to snip that. ;)
OK. A couple of things. Bear with me as I use this thread to think things through. This file is compressed. We extracted it, and added it back using 'raw'. That means cbfs_file->type != CBFS_TYPE_STAGE. So refcode loading would not work. Would it create a brick? I wouldn't think so, but I haven't tried.
Offhand, do you have the option rom? Do we see any life out of the display? I'm trying to think of ways to see how far we've gotten without serial console. Is MRC in the same place as the released firmware? Perhaps a cbfstool print might be instructive on your resulting image.
Yes, I extracted all the necessary files from the shellball ROM for Clapper. No, no life from the display (no backlight even).
coreboot.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 103424 config 0x429980 raw 4298 fallback/refcode 0x42aa80 raw 4296 (empty) 0x42bb80 null 17368 fallback/romstage 0x42ff80 stage 35171 fallback/coreboot_ram 0x438980 stage 71515 fallback/payload 0x44a140 payload 34866 img/Jeltka 0x4529c0 payload 2970296 (empty) 0x727cc0 null 492248 mrc.bin 0x79ffc0 (unknown) 70168 (empty) 0x7b1240 null 240984 spd.bin 0x7ebfc0 (unknown) 1536 (empty) 0x7ec600 null 79064
After bricking the device can you re-flash the spi part back to a released image?
I don't see why not, but it's getting late here and people are sleeping so I'll have to do that in the morning. If there's anything else quick I'll hang around this end for 10 or so minutes to answer.
Understood. The only thing I can think of trying really quickly is making the type of the file to be a stage instead of raw. You'll need to hexedit the rom to change the type.
-Aaron
Okay, fire away, I have it open and ready.
In your rom, find the "LARCHIVE" tombstone with the appropriate name afterwards ('fallback/refcode). It should be around offset 0x42aa80. For reference:
struct cbfs_file {
-------char magic[8]; -------uint32_t len; -------uint32_t type; -------uint32_t checksum; -------uint32_t offset;
} __attribute__((packed));
We want to change the type field. There should be a hex 0x50 associated with the fallback/refcode file. Change that number to be 0x10. Save and then cbfstool print should list the type as 'stage'.
Out of interest, the "Developer Information for Chrome OS Devices" page now lists a baseboard for each device - would it be worth compiling upstream rambi with EHCI debug if we get stuck with ChromiumOS coreboot?
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
On Mon, Sep 15, 2014 at 3:46 PM, John Lewis jlewis@johnlewis.ie wrote:
On 15/09/14 23:17, Aaron Durbin wrote:
On Mon, Sep 15, 2014 at 5:13 PM, John Lewis jlewis@johnlewis.ie wrote:
On 15/09/14 23:10, Aaron Durbin wrote:
On Mon, Sep 15, 2014 at 5:00 PM, John Lewis jlewis@johnlewis.ie wrote:
On 15/09/14 22:50, Aaron Durbin wrote:
On Mon, Sep 15, 2014 at 4:29 PM, John Lewis jlewis@johnlewis.ie wrote: > > > > On 15/09/14 22:03, Aaron Durbin wrote: >> >> >> >> >> On Mon, Sep 15, 2014 at 3:35 PM, John Lewis jlewis@johnlewis.ie >> wrote: >>> >>> >>> >>> >>> Hello, >>> >>> I've purchased the subject Chromebook with a view to getting some >>> sort >>> of >>> custom ROM going for Baytrail based Chromebooks, and I have my >>> first >>> brick >>> of the day. >>> >>> I'm using ChromeOS coreboot and the firmware-clapper-5218.B branch. >>> As >>> per >>> the advice Aaron gave me regarding the ASUS C200 some time ago, I >>> extracted >>> the reference code binary and changed line 111 in >>> src/arch/x86/Makefile.inc >>> as follows: >>> >>> $(CBFSTOOL) $@.tmp add -f $(CONFIG_REFCODE_BLOB_FILE) >>> -n >>> $(CONFIG_CBFS_PREFIX)/refcode -t raw >>> >> >> I think I might know. You are using upstream, right? This is my >> fault. >> The rmodule format changed. We didn't bump the version, and dropped >> the old code. Can you run readelf -e on that blob you extracted? I >> think I allowed ELF packaging for that file. If that doesn't work >> (hexdump -C) would be helpful. >> > No, I'm using ChromiumOS coreboot. With readelf -e I get: > > readelf -e refcode.bin > readelf: Error: Unable to read in 0x7115 bytes of section headers > readelf: Error: Not an ELF file - it has the wrong magic bytes at the > start > > hexdump -C: > > hexdump -C refcode.bin > 00000000 01 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 > |................| > 00000010 00 00 00 00 ac 10 00 00 b8 4b 00 00 01 00 60 00 > |.........K....`.| > 00000020 00 a0 4b 00 00 00 00 00 00 00 7f 3f ec 22 15 71 > |..K........?.".q|
snip
> 000010b0 ea 88 85 74 8b 20 1e db 6b 09 b3 c0 40 c3 eb ed |...t. > ..k...@...| > 000010c0 48 a8 8d c4 08 32 85 80 > |H....2..| > 000010c8 > > You may want to snip that. ;)
OK. A couple of things. Bear with me as I use this thread to think things through. This file is compressed. We extracted it, and added it back using 'raw'. That means cbfs_file->type != CBFS_TYPE_STAGE. So refcode loading would not work. Would it create a brick? I wouldn't think so, but I haven't tried.
Offhand, do you have the option rom? Do we see any life out of the display? I'm trying to think of ways to see how far we've gotten without serial console. Is MRC in the same place as the released firmware? Perhaps a cbfstool print might be instructive on your resulting image.
Yes, I extracted all the necessary files from the shellball ROM for Clapper. No, no life from the display (no backlight even).
coreboot.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 103424 config 0x429980 raw 4298 fallback/refcode 0x42aa80 raw 4296 (empty) 0x42bb80 null 17368 fallback/romstage 0x42ff80 stage 35171 fallback/coreboot_ram 0x438980 stage 71515 fallback/payload 0x44a140 payload 34866 img/Jeltka 0x4529c0 payload 2970296 (empty) 0x727cc0 null 492248 mrc.bin 0x79ffc0 (unknown) 70168 (empty) 0x7b1240 null 240984 spd.bin 0x7ebfc0 (unknown) 1536 (empty) 0x7ec600 null 79064
After bricking the device can you re-flash the spi part back to a released image?
I don't see why not, but it's getting late here and people are sleeping so I'll have to do that in the morning. If there's anything else quick I'll hang around this end for 10 or so minutes to answer.
Understood. The only thing I can think of trying really quickly is making the type of the file to be a stage instead of raw. You'll need to hexedit the rom to change the type.
-Aaron
Okay, fire away, I have it open and ready.
In your rom, find the "LARCHIVE" tombstone with the appropriate name afterwards ('fallback/refcode). It should be around offset 0x42aa80. For reference:
struct cbfs_file {
-------char magic[8]; -------uint32_t len; -------uint32_t type; -------uint32_t checksum; -------uint32_t offset;
} __attribute__((packed));
We want to change the type field. There should be a hex 0x50 associated with the fallback/refcode file. Change that number to be 0x10. Save and then cbfstool print should list the type as 'stage'.
Out of interest, the "Developer Information for Chrome OS Devices" page now lists a baseboard for each device - would it be worth compiling upstream rambi with EHCI debug if we get stuck with ChromiumOS coreboot?
I don't recall ever checking EHCI debug on rambi (and its derivatives). I have a bad feeling the port that would be used for debug isn't routed to one of the external ports. I can check the schematics tomorrow if someone reminds me. I only ever checked Falco back in the day.
-Aaron
-
Aaron Durbin -
Gregg Levine -
John Lewis