Do you want to build Chrome from source to?
I have google doc that explains how building chromeos from source used to
work. Chromeos is quite a monster to build, and my google doc is out of
date (something changed), but it's possible to build a lot from source.
Just have a reasonably powerful CPU handy.
https://docs.google.com/document/d/1WQnfloMbcR798Lk-iYPbvZt-wplW83IYyCf7S...
One of the side goals of my u-root project is to create a root file system
that is small and simple and might replace chromeos someday. In u-root,
programs are dynamically compiled when you run them, so the root is mostly
source.
ron
On Fri, Feb 26, 2016 at 6:52 PM Gregg Levine <gregg.drwho8(a)gmail.com> wrote:
> Hello!
> Let us suppose I want to build from source ChromeOS. What is involved
> in doing that? And the reason some of you will ask, it concerns the
> previous discussion on building a ROM image for a particular Intel
> chipset.
>
> If possible I might be able to obtain a board that's reasonably close
> to that chipset.
> -----
> Gregg C Levine gregg.drwho8(a)gmail.com
> "This signature fought the Time Wars, time and again."
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
>
Hello!
Let us suppose I want to build from source ChromeOS. What is involved
in doing that? And the reason some of you will ask, it concerns the
previous discussion on building a ROM image for a particular Intel
chipset.
If possible I might be able to obtain a board that's reasonably close
to that chipset.
-----
Gregg C Levine gregg.drwho8(a)gmail.com
"This signature fought the Time Wars, time and again."
On 2/26/2016 5:48 PM, Julius Werner wrote:
>>>> 2) I've also seen mention of Servo, but I don't seen any such header on
>>>> my board. Looking at a photo of the Acer C720 here, it does look like
>>>> there's an oblong space with pads there, but that would be a hell of a
>>>> surface mounting job:
>>>> https://www.chromium.org/chromium-os/developer-information-for-chrome-os-...
> Yes, you'll likely not get very far without a serial console, and the
> only way to get that is with a soldering iron. The good news is that
> you shouldn't need the full Servo header... just the two AP UART lines
> is enough (should be pin 16 and 17). You can find the whole Servo
> pinout at https://www.chromium.org/chromium-os/servo/chromium_os_yoshi_flex.tar.gz
thanks to Stefan and Aaron I've got a servo en route and arriving
Monday, hopefully will have some time early next week to get it setup
and start playing with it.
I have a Baytrail Chromebox (ninja) and ran into the same issues, but
unlike swanky it has an intact debug port. I was supposed to get a
servo unit on loan from one of the google coreboot guys but lost track
with the holidays. I'll have to follow up on it as it's probably the
best bet for getting a full replacement firmware working on Baytrail
On 2/23/2016 5:31 PM, Marcos Scriven wrote:
> I've subsequently discovered that USB debugging requires EHCI, and
> sadly lspci yields no such debug capabilities. Presumably this means
> either I figure out what's wrong 'blind', or start soldering a servo port?
>
> On Tue, 23 Feb 2016 at 23:30, Marcos Scriven <marcos(a)scriven.org
> <mailto:marcos@scriven.org>> wrote:
>
>
> ---------- Forwarded message ---------
> From: Marcos Scriven <marcos(a)scriven.org <mailto:marcos@scriven.org>>
> Date: Tue, 23 Feb 2016 at 15:46
> Subject: Re: Issues building a ROM for Toshiba Chromebook 2 (aka
> Swanky)
> To: <coreboot(a)coreboot.org <mailto:coreboot@coreboot.org>>
>
>
> Sorry to follow up so soon - but just noticed an error in my post.
> I meant /*fallback/refcode */not /fallback/romstage, /which
> although still slightly different in size was at least built
> rather than extracted and re-inserted, and is at the same offset
> as the original.
>
> On Tue, Feb 23, 2016 at 3:41 PM, Marcos Scriven
> <marcos(a)scriven.org <mailto:marcos@scriven.org>> wrote:
>
> Hi all
>
> I've built a ROM for swanky which just results in a brick, and
> wondering if anyone else has had success with this (or any Bay
> Trail Chromebook), or could otherwise provide guidance please.
>
> I've been able to reprogram the ROM directly, and am working
> with a patched boot stub region for now. I'm happy to
> experiment with ROM builds that will brick the machine (though
> annoyingly on the Toshiba Chromebook 2 the Winbond chip is
> just a little too close to the shielding/heatsink, so I have
> to take that off too (sadpanda)).
>
> Some links for context:
>
> ROM build artifact:
> https://github.com/marcosscriven/chromebook-coreboot/releases/download/re...
>
> Config:
> https://github.com/marcosscriven/chromebook-coreboot/blob/release-1456238...
>
> Build script:
> https://github.com/marcosscriven/chromebook-coreboot/blob/release-1456238...
>
> Build log:
> https://travis-ci.org/marcosscriven/chromebook-coreboot/builds/111222889#...
>
>
> (NB The build log is for multiple boards, and includes other
> full and boot stub builds, so use the log link above to the
> line where the full swanky rom build starts.)
>
> Here's the layout for the custom build:
>
> /vagrant@vagrant-ubuntu-trusty-64:~$ cbfstool swanky.rom print
> //swanky.rom: 8192 kB, bootblocksize 1184, romsize
> 8388608, offset 0x700000
> //alignment: 64 bytes, architecture: x86
> //
> //Name Offset Type Size
> //cmos_layout.bin 0x700000 cmos_layout 1164
> //pci8086,0f31.rom 0x7004c0 optionrom 65536
> //cpu_microcode_blob.bin 0x710500 microcode
> 104448
> //config 0x729d80 raw 4555
> //fallback/refcode 0x72af80 stage 4171
> //etc/boot-menu-key 0x72c040 raw 1
> //etc/boot-menu-message 0x72c0c0 raw 27
> //(empty) 0x72c140 null 15896
> //fallback/romstage 0x72ff80 stage 35475
> //fallback/coreboot_ram 0x738a80 stage 74547
> //fallback/payload 0x74ae00 payload
> 103192
> //(empty) 0x764180 null 245272
> //mrc.bin 0x79ffc0 spd 70168
> //(empty) 0x7b1240 null 240984
> //spd.bin 0x7ebfc0 spd 1024
> //(empty) 0x7ec400 null 79576/
>
>
> And here's the layout for a backup made via SPI directly on
> the chip (Implied /0x700000 /offset):
>
> /vagrant@vagrant-ubuntu-trusty-64:~$ cbfstool
> swanky-by-spi.bin print -r BOOT_STUB/
> /Performing operation on 'BOOT_STUB' region.../
> /Name Offset Type Size/
> /cmos_layout.bin 0x0 cmos_layout 1164/
> /pci8086,0f31.rom 0x4c0 optionrom 65536/
> /cpu_microcode_blob.bin 0x10500 microcode
> 104448/
> /config 0x29d80 raw 5259/
> /fallback/vboot 0x2b240 stage 15518/
> /(empty) 0x2ef40 null 4120/
> /fallback/romstage 0x2ff80 stage 36458/
> /fallback/coreboot_ram 0x38e80 stage 82415/
> /fallback/refcode 0x4d0c0 stage 4296/
> /fallback/payload 0x4e1c0 payload 67396/
> /u-boot.dtb 0x5e940 mrc_cache 4842/
> /(empty) 0x5fc80 null 258840/
> /mrc.bin 0x9efc0 spd 70168/
> /(empty) 0xb0240 null 245080/
> /spd.bin 0xebfc0 spd 1024/
> /(empty) 0xec400 null 78360/
>
>
> The labels, offsets, types, and sizes of all the various blobs
> looks fine *except /fallback/romstage/**.* (vboot and u-boot
> are gone as I don't need verification, which worked fine for
> my wolf build.)
>
> I'm not sure why my build (from the same commit hash of
> Google's coreboot fork as in the config extracted from
> original rom) is placing that blob at a different offset? I
> can't see anything in the config that would affect that.
>
> The more troubling thing is my refcode is a little smaller!
> I've extracted it from the shellball with this method here:
> https://github.com/marcosscriven/chromebook-coreboot/blob/release-1456238...
>
> So far as I can tell /fallback/refcode /is a (U)EFI blob, the
> failure of which I'd imagine would result in not booting from
> disk, but not entirely sure it's the reason I seeing nothing
> at all.
>
> I guess the thing I'd find most helpful is guidance on *how to
> debug this* myself? Only two things I could find:
>
> 1) A mention of 'USB to USB' in a 2013 Coreboot
> presentation:
> https://docs.google.com/presentation/d/1eGPMu03vCxIO0a3oNX8Hmij_Qwwz6R6Vi...
>
> It's not entirely clear how this works - so far as I can
> tell it's essentially USB OTG, where the Chromebook USB
> port could act as a client. I don't see though how the CPU
> sets that up before the ROM code even runs, unless it's
> some microcode in the processor itself?
>
>
> 2) I've also seen mention of Servo, but I don't seen any
> such header on my board. Looking at a photo of the Acer
> C720 here, it does look like there's an oblong space with
> pads there, but that would be a hell of a surface mounting
> job:
> https://www.chromium.org/chromium-os/developer-information-for-chrome-os-...
>
>
> I hope I've provided sufficient background info, but if
> anyone's willing or able to help, I'd of course be happy to
> add more detail.
>
> Thanks
>
> Marcos
>
>
>
>
On 25-Feb-16 08:16, ron minnich wrote:
> We tried to do Doxygen starting in 2000, but the experiment never
> seemed to work out. I still like the idea. One result was that you could
> make documentation
> and get a manual for the board you were working on at the time. That
> actually did work for a few years but it all kind of decayed.
In fact you can run 'make doxygen' and it should work just fine. I had a
service running until around 2011 to rebuild doxygen documentation every
couple of builds, but it was slow enough and nobody seemed to be using
it, so that we stopped the regular updates once we switched to jenkins.
I guess we could turn them back on, but most comments in coreboot are
not doxygen style.
Stefan
>
> ron
>
> On Thu, Feb 25, 2016 at 12:11 AM daoud yessine
> <yessine.daoud.92(a)gmail.com <mailto:yessine.daoud.92@gmail.com>> wrote:
>
> Hi
>
> Can coreboot be explored using Doxygen ?
> Who tried it ?
>
> Thanks
> --
> coreboot mailing list: coreboot(a)coreboot.org
> <mailto:coreboot@coreboot.org>
> http://www.coreboot.org/mailman/listinfo/coreboot
>
>
>
We tried to do Doxygen starting in 2000, but the experiment never seemed to
work out. I still like the idea. One result was that you could
make documentation
and get a manual for the board you were working on at the time. That
actually did work for a few years but it all kind of decayed.
ron
On Thu, Feb 25, 2016 at 12:11 AM daoud yessine <yessine.daoud.92(a)gmail.com>
wrote:
> Hi
>
> Can coreboot be explored using Doxygen ?
> Who tried it ?
>
> Thanks
> --
> coreboot mailing list: coreboot(a)coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
Dear coreboot folks,
just a short thank you to Timothy Pearson from Raptor Engineering [1]
for implementing auxiliary channel PS/2 device presence detection in
coreboot [2] in commit 448e3863 (drivers/pc80: Add PS/2 mouse presence
detect).
As a result it was easy to adapt it for the Nuvoton NCT5572D used on
the ASRock E350M1 in commit bf725b48 (superio/nuvoton/nct5572d: Add
PS/2 presence detect) [3]. So now, PS/2 devices work with this board!
So for all those of you, suffering from similar problems on different
boards using Winbond or Nuvoton Super I/Os, please give it try to do
similar adaptations, and submit patches!
Thanks,
Paul
PS: With proprietary, closed firmware, this would not have been
possible over six years after a board was released. (Though to be fair,
normally such things work right away with the shipped vendor firmware
when you buy a board.)
[1] https://raptorengineeringinc.com/content/base/main.htm
[2] https://review.coreboot.org/13165
[3] https://review.coreboot.org/13618
I've subsequently discovered that USB debugging requires EHCI, and sadly
lspci yields no such debug capabilities. Presumably this means either I
figure out what's wrong 'blind', or start soldering a servo port?
On Tue, 23 Feb 2016 at 23:30, Marcos Scriven <marcos(a)scriven.org> wrote:
>
> ---------- Forwarded message ---------
> From: Marcos Scriven <marcos(a)scriven.org>
> Date: Tue, 23 Feb 2016 at 15:46
> Subject: Re: Issues building a ROM for Toshiba Chromebook 2 (aka Swanky)
> To: <coreboot(a)coreboot.org>
>
>
> Sorry to follow up so soon - but just noticed an error in my post. I meant
> *fallback/refcode *not *fallback/romstage, *which although still slightly
> different in size was at least built rather than extracted and re-inserted,
> and is at the same offset as the original.
>
> On Tue, Feb 23, 2016 at 3:41 PM, Marcos Scriven <marcos(a)scriven.org>
> wrote:
>
>> Hi all
>>
>> I've built a ROM for swanky which just results in a brick, and wondering
>> if anyone else has had success with this (or any Bay Trail Chromebook), or
>> could otherwise provide guidance please.
>>
>> I've been able to reprogram the ROM directly, and am working with a
>> patched boot stub region for now. I'm happy to experiment with ROM builds
>> that will brick the machine (though annoyingly on the Toshiba Chromebook 2
>> the Winbond chip is just a little too close to the shielding/heatsink, so I
>> have to take that off too (sadpanda)).
>>
>> Some links for context:
>>
>> ROM build artifact:
>> https://github.com/marcosscriven/chromebook-coreboot/releases/download/re...
>>
>> Config:
>> https://github.com/marcosscriven/chromebook-coreboot/blob/release-1456238...
>>
>> Build script:
>> https://github.com/marcosscriven/chromebook-coreboot/blob/release-1456238...
>>
>> Build log:
>> https://travis-ci.org/marcosscriven/chromebook-coreboot/builds/111222889#...
>>
>>
>> (NB The build log is for multiple boards, and includes other full and
>> boot stub builds, so use the log link above to the line where the full
>> swanky rom build starts.)
>>
>> Here's the layout for the custom build:
>>
>>
>> *vagrant@vagrant-ubuntu-trusty-64:~$ cbfstool swanky.rom print*
>> *swanky.rom: 8192 kB, bootblocksize 1184, romsize 8388608, offset
>> 0x700000*
>> *alignment: 64 bytes, architecture: x86*
>>
>> *Name Offset Type Size*
>> *cmos_layout.bin 0x700000 cmos_layout 1164*
>> *pci8086,0f31.rom 0x7004c0 optionrom 65536*
>> *cpu_microcode_blob.bin 0x710500 microcode 104448*
>> *config 0x729d80 raw 4555*
>> *fallback/refcode 0x72af80 stage 4171*
>> *etc/boot-menu-key 0x72c040 raw 1*
>> *etc/boot-menu-message 0x72c0c0 raw 27*
>> *(empty) 0x72c140 null 15896*
>> *fallback/romstage 0x72ff80 stage 35475*
>> *fallback/coreboot_ram 0x738a80 stage 74547*
>> *fallback/payload 0x74ae00 payload 103192*
>> *(empty) 0x764180 null 245272*
>> *mrc.bin 0x79ffc0 spd 70168*
>> *(empty) 0x7b1240 null 240984*
>> *spd.bin 0x7ebfc0 spd 1024**(empty)
>> 0x7ec400 null 79576*
>>
>>
>> And here's the layout for a backup made via SPI directly on the chip
>> (Implied *0x700000 *offset):
>>
>> *vagrant@vagrant-ubuntu-trusty-64:~$ cbfstool swanky-by-spi.bin print -r
>> BOOT_STUB*
>> *Performing operation on 'BOOT_STUB' region...*
>> *Name Offset Type Size*
>> *cmos_layout.bin 0x0 cmos_layout 1164*
>> *pci8086,0f31.rom 0x4c0 optionrom 65536*
>> *cpu_microcode_blob.bin 0x10500 microcode 104448*
>> *config 0x29d80 raw 5259*
>> *fallback/vboot 0x2b240 stage 15518*
>> *(empty) 0x2ef40 null 4120*
>> *fallback/romstage 0x2ff80 stage 36458*
>> *fallback/coreboot_ram 0x38e80 stage 82415*
>> *fallback/refcode 0x4d0c0 stage 4296*
>> *fallback/payload 0x4e1c0 payload 67396*
>> *u-boot.dtb 0x5e940 mrc_cache 4842*
>> *(empty) 0x5fc80 null 258840*
>> *mrc.bin 0x9efc0 spd 70168*
>> *(empty) 0xb0240 null 245080*
>> *spd.bin 0xebfc0 spd 1024*
>> *(empty) 0xec400 null 78360*
>>
>>
>> The labels, offsets, types, and sizes of all the various blobs looks fine
>> *except fallback/romstage**.* (vboot and u-boot are gone as I don't need
>> verification, which worked fine for my wolf build.)
>>
>> I'm not sure why my build (from the same commit hash of Google's coreboot
>> fork as in the config extracted from original rom) is placing that blob at
>> a different offset? I can't see anything in the config that would affect
>> that.
>>
>> The more troubling thing is my refcode is a little smaller! I've
>> extracted it from the shellball with this method here:
>> https://github.com/marcosscriven/chromebook-coreboot/blob/release-1456238...
>>
>> So far as I can tell *fallback/refcode *is a (U)EFI blob, the failure of
>> which I'd imagine would result in not booting from disk, but not entirely
>> sure it's the reason I seeing nothing at all.
>>
>> I guess the thing I'd find most helpful is guidance on *how to debug
>> this* myself? Only two things I could find:
>>
>> 1) A mention of 'USB to USB' in a 2013 Coreboot presentation:
>> https://docs.google.com/presentation/d/1eGPMu03vCxIO0a3oNX8Hmij_Qwwz6R6Vi...
>>
>> It's not entirely clear how this works - so far as I can tell it's
>> essentially USB OTG, where the Chromebook USB port could act as a client. I
>> don't see though how the CPU sets that up before the ROM code even runs,
>> unless it's some microcode in the processor itself?
>>
>>
>> 2) I've also seen mention of Servo, but I don't seen any such header on
>> my board. Looking at a photo of the Acer C720 here, it does look like
>> there's an oblong space with pads there, but that would be a hell of a
>> surface mounting job:
>> https://www.chromium.org/chromium-os/developer-information-for-chrome-os-...
>>
>>
>> I hope I've provided sufficient background info, but if anyone's willing
>> or able to help, I'd of course be happy to add more detail.
>>
>> Thanks
>>
>> Marcos
>>
>
>
Thanks M.Marcos
ᐧ
2016-02-23 16:55 GMT+01:00 Marcos Scriven <marcos(a)scriven.org>:
> Hi Daoud
>
> This might be a good start:
> https://docs.google.com/presentation/d/1eGPMu03vCxIO0a3oNX8Hmij_Qwwz6R6Vi...
>
> Marcos
>
> On Tue, Feb 23, 2016 at 1:17 PM, daoud yessine <yessine.daoud.92(a)gmail.com
> > wrote:
>
>> Hello
>>
>> I am searching a document describing the boot process of coreboot with
>> details ( modules , functions , ... )
>> who can help me ?
>>
>> thanks
>>
>> --
>> coreboot mailing list: coreboot(a)coreboot.org
>> http://www.coreboot.org/mailman/listinfo/coreboot
>>
>
>
