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