Hello! (Speaking as an observer, currently.) It couldn't hurt. And how difficult would it be to do that. ----- Gregg C Levine [email protected] "This signature fought the Time Wars, time and again."
On Mon, Sep 15, 2014 at 6:46 PM, John Lewis <[email protected]> wrote: > On 15/09/14 23:17, Aaron Durbin wrote: >> >> On Mon, Sep 15, 2014 at 5:13 PM, John Lewis <[email protected]> wrote: >>> >>> On 15/09/14 23:10, Aaron Durbin wrote: >>>> >>>> >>>> On Mon, Sep 15, 2014 at 5:00 PM, John Lewis <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On 15/09/14 22:50, Aaron Durbin wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Sep 15, 2014 at 4:29 PM, John Lewis <[email protected]> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 15/09/14 22:03, Aaron Durbin wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Mon, Sep 15, 2014 at 3:35 PM, John Lewis <[email protected]> >>>>>>>> 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) [email protected] 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: [email protected] > http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
