ChromiumOS Build Process/Not getting anywhere

[Myke Predko]

Hey folks,

 

I'm trying to build the Chomium OS for some rather old Pentium M laptops and, once that is working, I want to add the Chrome OS Bluetooth extensions so that I can run my Jade Support Chrome App (https://chrome.google.com/webstore/detail/jade-support/gchcbahadlpkgkpenlkfgdgkdjedepod?hl=en) on the system (they have WinXP on them right now which is deadly slow).  

I'm following the instructions outlined in http://www.chromium.org/chromium-os/developer-guide  - I am able to get a USB Thumb Drive loaded with the image and it fails on the missing PAE flag (although the hardware is there) in the Pentium M.  

To start off, I want to ignore the PAE flag (since I know which systems I'll be running) but no joy on seeing the changes in the build.  I tried doing two builds, one with my changes and the other with a changed error message and in both cases, nothing comes up differently from the system boot from the original build.  

 

I modified:

cpu.c - with the different error message for "This kernel requires the following features"...

cpucheck.c - with the commented out error operation for PAE

 

in

chromiumos/src/third_party/kernel/v3.18/arch/x86/boot

 

 

Following the process (everything including chroot was set up so I thought I could just do the board setup, build and image the USB key):

 

Step 1: sudo rm -rf /build/x86-generic

Step 2; ./setup_board --board=${BOARD}

Step 3: ./set_shared_user_password.sh

Step 4: ./build_packages --board=${BOARD}

Step 5: ./build_image --board=${BOARD} --noenable-rootfs_verification dev

Step 6: cros flash usb:// ${BOARD}/latest

 

BOARD was set to x86-generic

 

So, am I modifying the correct sources?  If I am, why are my changes not being picked up in the build?  I can open the cpu.c and cpucheck.c files in KWrite before and after (I changed the write permissions before making the code updates) and can see the changes.  

 

What is the (re)build process that I should be using?  Can I reduce it to steps 4 to 6 or should it be steps 5 to 6?

 

Thanx and sorry for all the questions,

 

myke

[Gwendal Grignou]

Myke,

Looking at your sequence, you are missing the steps to tell
build_packages which package(s) contain changes.
See http://www.chromium.org/chromium-os/developer-guide#TOC-Create-a-branch-for-your-changes
and the following paragraphs before starting step 4.
Also, once you have a DUT running, you will not have to rebuild a USB
image every time.
You can install kernel directly with upgrade_kernel.sh:
https://www.chromium.org/chromium-os/how-tos-and-troubleshooting/kernel-faq#TOC-How-to-quickly-test-kernel-modifications-the-fast-way-

For other package, you will use cros deploy.
https://www.chromium.org/chromium-os/build/cros-deploy

Gwendal.

> --
> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>

[Myke Predko]

Hi Gwendal,

Thanx for the response.  

I was changing the source on my PC because I have the PAE issue (I want to bypass the check and go directly to the code that executes when "forcepae" is on the command line (see cpu.c and cpucheck.c noted below).  

So, in my cases where I require the changes to the code to boot, how would I go about that?  

Again thank you for the response, I really appreciate it.  

myke

[Myke Predko]

Hi Folks,

I got a suggestion from Ben Zhang regarding moving forwards (ie don't repeat the same operations) but create my own repository and things moved ahead but execution has stopped (as noted below).  

After checking the default build, I continued with the following steps:

1.  cros_workon --board=x86-generic start chromeos-kernel-3_18 (as suggested)

2.  repo sync (basically following the steps outlined in http://www.chromium.org/chromium-os/developer-guide)

3.  cros_workon info --board=x86-generic -all to get the directory names (which matched the ones in the document.

3.1.  I was expecting to see the 3.18 kernel files from src/third_party/kernel/v3.18 show up there but they didn't.

4.  repo start chromeOS-myke to make a branch

5.  I then made some changes to the message displayed by cpu.h in the original chromium/src/third_party/kernel/v3.18/arch/x86/boot folder noted below.  

6.  cros_workon_make --board=x86-generic chromeos-kernel-3_18 <= this took a surprisingly long period of time to run.  

7.  Not knowing what to do next, I decided to go back and build the USB image again: ./build_image --board=x87-generic --noenable_rootfs_verification dev and then started waiting (two hours now).  

This are stopped after doing the following.  

INFO    : Kernel partition image emitted: /mnt/host/source/src/build/images/x86-generic/R47-7472.0.2015_09_19_1354-a1/hd_vmlinuz.image

INFO    : Root filesystem hash emitted: /mnt/host/source/src/build/images/x86-generic/R47-7472.0.2015_09_19_1354-a1/rootfs.hash

INFO    : Kernel image A   size is 4772864 bytes.

INFO    : Kernel image B   size is 4772864 bytes.

INFO    : Kernel partition A size is 16777216 bytes.

INFO    : Kernel partition B size is 16777216 bytes.

INFO    : Appending rootfs.hash (10113024 bytes) to the root fs

INFO    : Extracting the kernel command line from /mnt/host/source/src/build/images/x86-generic/R47-7472.0.2015_09_19_1354-a1/vmlinuz.image

INFO    : Unmounting image from /mnt/host/source/src/build/images/x86-generic/R47-7472.0.2015_09_19_1354-a1/stateful_dir and /mnt/host/source/src/build/images/x86-generic/R47-7472.0.2015_09_19_1354-a1/rootfs_dir

When (and if) I get the prompt back up (the internet connection is good - I'm sending this from the build machine), I am planning on doing a cros flash usb:// ${BOARD}/latest to load a USB thumb drive with the (hopefully) updated image.

Now, somewhere along the way, I ended up with:

• EFI-SYSTEM
• STATE (2x instances)
• ROOT-A

Visible partitions on the build system's hard drive.  

So, overall:

1.  Am I on the right path?  Will my changes show up in the build?  

2.  What happened with the hard drive partitions that have just shown up?  Why are there there?

Thanx,

myke

[Gwendal Grignou]

On Sat, Sep 19, 2015 at 5:20 PM, Gwendal Grignou <gwe...@google.com> wrote:

> Yes. It should. We are using powerful machines for building. The
> minimum requirements are 8 core, 8GB of RAM, but the build will use
> whatever resources you have.

>> 2. What happened with the hard drive partitions that have just shown up?
>> Why are there there?

> Those are partition from files (loop mount) used to easily alter the
> images being built. They will be umounted once the build is complete.

[Myke Predko]

Hi Gwendal,

Thanx for the reply.  I'm using a 4 core AMD64 with 8GB of DDR.  

It's still going (roughly 8 hours later) - I guess I should keep waiting (and thinking about getting a more powerful machine).  Would an SSD help?

myke

[Myke Predko]

Still nothing - approximately 33 hours with nothing other than what's below.

Comments, suggestions?

Thanx,

myke


On Thursday, September 17, 2015 at 2:59:27 PM UTC-4, Myke Predko wrote:

[Gwendal Grignou]

On Sun, Sep 20, 2015 at 8:29 PM, Myke Predko <myke....@mimetics.ca> wrote:
> Still nothing - approximately 33 hours with nothing other than what's below.

It is stuck somewhere. It looks like the build tries to umount the
partitions. Be sure noone is using it: you may have a shell into one
of them still opened.

If not, try the build command again.

Gwendal.

[myke predko]

Hi Gwendal,

Oh crap. I wonder if clicking on the partitions that I was wondering about from the "Files" manager did this.

What's the best process for restarting the process? I've closed the open "Files" manager (where I was looking at the newly created partitions) but nothing has happened, for a half hour now.

Is it big red switch time on the PC (power cycle the PC) and delete the chromiumos folder or can I do something less drastic?

Thanx,

myke

[Bill Richardson]

You should be able to just kill it. Try ctrl-C first, then escalate. You can then run "mount" both inside and outside the chroot and see if anything's mounted that shouldn't be.

If you're in doubt as to where things ended up, you can try these steps. Stop after the first one that works.

• exit crosh, then re-enter
• politely reboot your workstation
• cros_sdk --replace

I've found that disabling automount makes life much easier. Google for the right commands for your desktop manager.

I regularly build chromium images on a Lenovo Thinkpad laptop. The first build takes an hour or so because it downloads binaries for pretty much any packages that I haven't run cros_workon start for, plus the cross-compilers, etc. After that, it's about 10-15 minutes. As others have mentioned, once you have an image built and installed on your chromebook, you can rebuild and replace individual packages without rebuilding the image.

Notes:

1. I've never tried to build the chromium browser. I understand that takes forever.

2. My laptop has an SSD. WIthout that, it could take 4X to 10X longer.

--

Art for Art's Sake

Engineering for Money

[Myke Predko]

Hi Bill,

Thanx for the pointers and reply.  

ctrl-C did not work, I'm not sure what you mean by "escalate".  The only thing I could do was to close the terminal.  

I do have automount disabled (as I could not get a good USB image with it in the default automount).  

I'm going through the process again will not be opening "Files" for any reason when the build is taking place.  

Question: Looking over the discussions, it notes that cros_sdk --bootstrap will build from "source".  Is this the source on my system and should I start with this for my experimentation with eliminating the PAE error and doing the force?

Thanx, more news as it happens,

myke

[Bill Richardson]

On Mon, Sep 21, 2015 at 11:02 AM, Myke Predko <myke....@mimetics.ca> wrote:

Hi Bill,

Thanx for the pointers and reply.  

ctrl-C did not work, I'm not sure what you mean by "escalate".  The only thing I could do was to close the terminal.

​I meant use "ps" to find what's stuck, and kill it, possibly with -9.

​

Question: Looking over the discussions, it notes that cros_sdk --bootstrap will build from "source".  Is this the source on my system and should I start with this for my experimentation with eliminating the PAE error and doing the force?

​No, that will recompile pretty much EVERYTHING. Don't do that! It'll take days.

I rarely work on the kernel, but this process is what I use to build a pristine, unmodified image in a brand new workspace:

Once:

repo init -u https://chromium.googlesource.com/chromiumos/manifest.git \

     --repo-url https://chromium.googlesource.com/external/repo.git

​repo sync

cros_sdk

​./setup_board --board $BOARD

​Repeatedly, as needed:​

./build_packages --board $BOARD

./build_image --board $BOARD test

​Generally, though you only build the packages and image once too. Put the newly-built image on a USB stick, boot it in your Chromebook in dev-mode, and install it (run chromeos-install). ​Then you can just tweak individual packages and put them on the Chromebook without reinstalling the whole image each time.

But to make changes to any package, you need to tell the build system to compile that package locally instead of just pulling down the binaries. For example:

cros_workon-$BOARD start vboot_reference

Then build just that package:

emerge-$BOARD vboot_reference

I don't work on the kernel regularly, and the specifics for picking the right version, changing the configuration, and installing it onto a live system tend to change more often than I need to do it. Gwendal is the kernel guy, if you have questions about the kernel specifically.

Good luck.

​Bill​

[myke predko]

Hi Bill,

 

Thanx for the follow up – I did kill the terminal process as you suggested (“-9”).  I wasn’t sure how to see where it was failing after doing that. 

 

The approach that you are listing matches the approach provided by the document, but I’m still wondering how I change the initial image to modify the cpu.c and cpucheck.c programs which check and flag the missing PAE. 

 

What I proposed (and where I got stuck on) was:

After checking the default build, I continued with the following steps:

1.  cros_workon --board=x86-generic start chromeos-kernel-3_18 (as suggested)
2.  repo sync (basically following the steps outlined in http://www.chromium.org/chromium-os/developer-guide

3.  cros_workon info --board=x86-generic -all to get the directory names (which matched the ones in the document).

3.1.  I was expecting to see the 3.18 kernel files from src/third_party/kernel/v3.18 show up there but they didn't.
4.  repo start chromeOS-myke to make a branch
5.  I then made some changes to the message displayed by cpu.h in the original chromium/src/third_party/kernel/v3.18/arch/x86/boot folder noted below.
6.  cros_workon_make --board=x86-generic chromeos-kernel-3_18

7.  Not knowing what to do next, I decided to go back and build the USB image again: ./build_image --board=x87-generic --noenable_rootfs_verification dev

8.  Go back and cros flash usb:// ${BOARD}/latest to make the USB image

 

Will this process give me a new image that I can modify the PAE testing so I can boot and then continue with my ultimate goal?  The ultimate goal is to add the ChromeOS Bluetooth Extension code so I can run Bluetooth Chrome Apps from Chromium (minus the BLE features which aren’t currently available in Bluez) – once I have the basic image working, I should be able to develop, test and debug the Bluetooth Extensions without any issues. 

 

Correct?

 

Thanx,

 

myke

 

 

From: wfri...@google.com [mailto:wfri...@google.com] On Behalf Of Bill Richardson
Sent: Monday, September 21, 2015 2:28 PM
To: Myke Predko <myke....@mimetics.ca>
Cc: Chromium OS dev <chromiu...@chromium.org>; Gwendal Grignou <gwe...@chromium.org>
Subject: Re: [cros-dev] Re: ChromiumOS Build Process/Not getting anywhere

 

On Mon, Sep 21, 2015 at 11:02 AM, Myke Predko <myke....@mimetics.ca> wrote:

[Bill Richardson]

That sounds right to me. I think it should work, but kernels are kind of special. I vaguely recall some special step or weirdness that was once required to pick a different kernel. For example, if the x86-generic image normally uses the 3.14 kernel, you may be able to build the 3.18 kernel, but it won't be used to create the disk/USB image without some extra something.

These instructions are what the magic incantation used to be, but I was just told that they're wrong. Gwendal should know the right way.

One other thing that I find helpful when booting images that I've built myself is this command:

rootdev -s 

This prints the disk partition that contains the running root (/) filesystem. ​As you know, Chromium OS images typically have two root partitions, /dev/sda3 and /dev/sda5 (or /dev/mmcblk0p3 and /dev/mmcblk0p5 for EMMC drives). If you've booted from USB, you'd expect to see /dev/sdb3. Sometimes I think I'm running from one image and instead I'm running from another.

[Myke Predko]

I'm very sure that the build is V3.18 - luckily, the PAE error message is only generated in v3.18.  I say "luckily" although I don't known if previous versions just skate right through without checking the PAE flag at all (not generating an error).  

Just going through the process again, updating the sequence because the previous step 3. 

1.  cros_workon --board=x86-generic start chromeos-kernel-3_18 (as suggested) 
2.  repo sync (basically following the steps outlined in http://www.chromium.org/chromium-os/developer-guide

3.  repo start chromeOS-myke to make a branch 
4.  Make some changes to the source. For the first build, I changed the message displayed by cpu.h in the original chromium/src/third_party/kernel/v3.18/arch/x86/boot folder noted below. 
5.  cros_workon_make --board=x86-generic chromeos-kernel-3_18 
6.  Not knowing what to do next, I decided to go back and build the USB image again: ./build_image --board=x87-generic --noenable_rootfs_verification dev

7.  Go back and cros flash usb:// ${BOARD}/latest to make the USB image

Let's see how it goes.  It's doing the cros_workon_make right now.  Hopefully it won't lock up again.  

More news as it happens.  

myke

[Myke Predko]

And...  

It didn't work.  My code wasn't picked up as part of the build.  

Anybody have any suggestions?  

I know there's an "87" in the instructions below and I changed that before executing the command.  

Thanx - suggestions and things I can try will be most welcome.

myke

On Thursday, September 17, 2015 at 2:59:27 PM UTC-4, Myke Predko wrote:

[Luigi Semenzato]

In your code fragments, sometime you write --board=x86-generic, other
times --board=${BOARD}. One would hope that somewhere you set
BOARD=x86-generic.

Also, after you build the image the first time (which you have), a
faster way of making sure the build is using your (modified) sources
is to introduce an error in a source file, and check that
emerge-x86-generic chromeos-kernel-3_18 fails. (It fails quickly.)

[Myke Predko]

Hi Luigi,

Great idea.  I put in an invalid line and it was picked up as an error.  

I took the line out and rebuilt the code (no errors this time), tried to create the new USB image and no luck.

The steps (after making the code change) I'm following are:

1.  cros_workon_make --board=x86-generic chromeos-kernel-3_18

2.  ./build_image --board=x86-generic --noenable_rootfs_verification dev

3.  cros flash usb:// x86-generic/latest

Anybody have an idea of what I'm missing/doing wrong here.  The build step seems to correct but I would guess the image build isn't correct/pulling the right information.  If I look in /build/x86-generic, I see:

ls /build/x86-generic

bin    debugd  home   mnt       postinst  run   sys-include  var

boot   dev     lib    opt       proc      sbin  tmp

build  etc     media  packages  root      sys   usr

but I don't see a "latest".  

Thoughts as to what's going wrong?

Thanx,

myke

[Luigi Semenzato]

The "latest" directory (actually symlink) containing the images is in
chromiumos/src/build, not chromiumos/build. The directories in
chromiumos/build contain the "sysroot", the directory tree that gets
packaged into the binary image.

Your steps seem correct. Next you need to make sure you're booting
from the right device. Try "uname -a" on the chromebook (or whatever)
after boot. The date in the output should match your compilation
date.

This information is all available in the build docs. Should this
thread dry up, I encourage you to keep reading them :)

[myke predko]

Hi Luigi,

Thanx for the comments.

The "/build" folder is in the folder system set up by cros_sdk.

Unfortunately, the issue is that I need to modify the initial image to boot on my target. The target system has a Pentium M which has the PAE flag disabled (but the hardware works correctly) and this is not handled correctly by the base kernel.

What I'm trying to do is produce a modified kernel that I can boot from on these systems.

So, how do I get the code that I've modified onto the USB key so I can boot chromiumOS successfully?

In the source code, it indicates that there is a command line which can force ignoring the missing processor PAE flag but I haven't discovered how to bring it up.

Thanx for any ideas,

myke

-----Original Message-----
From: seme...@google.com [mailto:seme...@google.com] On Behalf Of Luigi Semenzato
Sent: Monday, September 21, 2015 9:58 PM
To: Myke Predko <myke....@mimetics.ca>
Cc: Chromium OS dev <chromiu...@chromium.org>
Subject: Re: [cros-dev] Re: ChromiumOS Build Process/Not getting anywhere

[Yuly Novikov]

I think x86-generic uses kernel-3_14.

You should either be modifying kernel-3_14,

or remove kernel-3_14 from

USE="${USE} legacy_keyboard legacy_power_button kernel-3_14"

in overlays/overlay-x86-generic/make.conf

[Mike Frysinger]

correct, x86-generic currently uses 3.14.  once 3.18 stabilizes (maybe it already has?) we'll switch the generics to that.

-mike

[Myke Predko]

I've changed the line in make.conf to use 3_18 rather than 3_14.  

I've rerun the build command (cros_workon_make --board=x86-generic chromeos-kernel-3_18) with no difference between the two in terms of messages.  Should I have seen something?  

Now I'm building the USB image to be followed by burning the Thumb Drive.

I'll let you know how it goes.  

Should I be saving logs of the source build and image build?  

myke

[Luigi Semenzato]

The 3_18 vs. 3_14 issue was almost certainly your problem. There is
no safeguard against that.

[Myke Predko]

Nope.  That didn't change anything.  

I just tried a cros_workon info --board=x86-generic --all command (output attached) and didn't see anything of use although the line:

sys-kernel/chromeos-kernel-3_18 chromiumos/third_party/kernel src/third_party/kernel/v3.8

is suspicious.  the file with the dump information is attached.  

Just going through everything, I'm not saving to git but that shouldn't make a difference because I'm still trying to get a basic build going from my system.  

Any idea why the changes aren't getting picked up in the build?  

Thanx,

myke

[Yuly Novikov]

So, when you ran build_image, what kernel version did it use?

Look for something like sys-kernel/chromeos-kernel-3_18-9999::chromiumos in the output.

Perhaps you are missing "cros_workon-$BOARD start chromeos-kernel-3_18"?

BTW, for debugging it's more convenient to build a test image, like
./build_image --board=${BOARD} --noenable-rootfs_verification test

[Myke Predko]

Hi Yuly,

I'm using the build image command:

./build_image --board=x86-generic --noenable_rootfs_verification dev

Does the "dev" option at the end specify where things are coming from?  I will try the image build with "test" instead of "dev'.

I have done the 

cros_workon_make --board=x86-generic start chromeos-kernel-3_18

command and before the last build test I ran it again.  The instance above was copied from the terminal command log.  

The dump of the cros_workon and ./build commands is attached.  In it, I could not find the sys-kernel/chromeos-kernel-3_18-9999::chromiumos string anywhere in the dump.  

Where else should I be looking?

myke

On Thursday, September 17, 2015 at 2:59:27 PM UTC-4, Myke Predko wrote:

Hey folks,

 

I'm trying to build the Chomium OS for some rather old Pentium M laptops and, once that is working, I want to add the Chrome OS Bluetooth extensions so that I can run my Jade Support Chrome App (https://chrome.google.com/webstore/detail/jade-support/gchcbahadlpkgkpenlkfgdgkdjedepod?hl=en) on the system (they have WinXP on them right now which is deadly slow).  

[Chirantan Ekbote]

Looks like x86-generic is using chromeos-kernel-3_14.

[binary  N     ] sys-kernel/chromeos-kernel-3_14-3.14-r1252::chromiumos

which matches the USE flag in the make.conf for that board.

--

[Yuly Novikov]

On Tue, Sep 22, 2015 at 5:59 PM, Myke Predko <myke....@mimetics.ca> wrote:

Hi Yuly,

I'm using the build image command:

./build_image --board=x86-generic --noenable_rootfs_verification dev

Does the "dev" option at the end specify where things are coming from?  I will try the image build with "test" instead of "dev'.

No, it specifies the list of packages to build, so test will just install more useful for debugging packages on the device.

I have done the 

cros_workon_make --board=x86-generic start chromeos-kernel-3_18

command and before the last build test I ran it again.  The instance above was copied from the terminal command log.  

You are confusing cros_workon_make with cros_workon.

The former builds your sources.

The latter tells emerge/build_packages whether to build a specific stable version, or to build the current sources.

The dump of the cros_workon and ./build commands is attached.  In it, I could not find the sys-kernel/chromeos-kernel-3_18-9999::chromiumos string anywhere in the dump.  

Yes, because the line there is:

sys-kernel/chromeos-kernel-3_14-3.14-r1252

Which means you are building 3.14 stable kernel. And you need 3.18 cros_workon'ed kernel, which version would end with 9999.

I think for the changes in the overlay to apply, you need to run setup_board again (with --force). 

Where else should I be looking?

myke

On Thursday, September 17, 2015 at 2:59:27 PM UTC-4, Myke Predko wrote:

Hey folks,

 

I'm trying to build the Chomium OS for some rather old Pentium M laptops and, once that is working, I want to add the Chrome OS Bluetooth extensions so that I can run my Jade Support Chrome App (https://chrome.google.com/webstore/detail/jade-support/gchcbahadlpkgkpenlkfgdgkdjedepod?hl=en) on the system (they have WinXP on them right now which is deadly slow).  

I'm following the instructions outlined in http://www.chromium.org/chromium-os/developer-guide  - I am able to get a USB Thumb Drive loaded with the image and it fails on the missing PAE flag (although the hardware is there) in the Pentium M.  

To start off, I want to ignore the PAE flag (since I know which systems I'll be running) but no joy on seeing the changes in the build.  I tried doing two builds, one with my changes and the other with a changed error message and in both cases, nothing comes up differently from the system boot from the original build.  

 

I modified:

cpu.c - with the different error message for "This kernel requires the following features"...

cpucheck.c - with the commented out error operation for PAE

 

in

chromiumos/src/third_party/kernel/v3.18/arch/x86/boot

 

 

Following the process (everything including chroot was set up so I thought I could just do the board setup, build and image the USB key):

 

Step 1: sudo rm -rf /build/x86-generic

Step 2; ./setup_board --board=${BOARD}

Step 3: ./set_shared_user_password.sh

Step 4: ./build_packages --board=${BOARD}

Step 5: ./build_image --board=${BOARD} --noenable-rootfs_verification dev

Step 6: cros flash usb:// ${BOARD}/latest

 

BOARD was set to x86-generic

 

So, am I modifying the correct sources?  If I am, why are my changes not being picked up in the build?  I can open the cpu.c and cpucheck.c files in KWrite before and after (I changed the write permissions before making the code updates) and can see the changes.  

 

What is the (re)build process that I should be using?  Can I reduce it to steps 4 to 6 or should it be steps 5 to 6?

 

Thanx and sorry for all the questions,

 

myke

--

--
Chromium OS Developers mailing list: chromiu...@chromium.org

[Myke Predko]

Thanx Yuly and Chirantan,

Attached is the make.conf file I'm using with the build.  

Thanx for the explanation of "test" over "dev".  I will use "test" until I have the final project working.  

Should I go back through the process outlined in http://www.chromium.org/chromium-os/developer-guide starting at 

Initialize the build for a board with the command:

./setup_board --board=x86-generic --force  

and continue from there?

Thank you - this is feeling more promising,

myke

[Yuly Novikov]

On Tue, Sep 22, 2015 at 6:22 PM, Myke Predko <myke....@mimetics.ca> wrote:

Thanx Yuly and Chirantan,

Attached is the make.conf file I'm using with the build.  

Thanx for the explanation of "test" over "dev".  I will use "test" until I have the final project working.  

Should I go back through the process outlined in http://www.chromium.org/chromium-os/developer-guide starting at 

Initialize the build for a board with the command:

./setup_board --board=x86-generic --force  

and continue from there?

Yes.

To sum it up you should:

BOARD=x86-generic

./setup_board --board=${BOARD} --force

cros_workon-${BOARD} start chromeos-kernel-3_18

./build_packages --board=${BOARD}

./build_image --board=${BOARD} --noenable_rootfs_verification test

Afterwards you can make kernel changes with:

emerge-${BOARD} chromeos-kernel-3_18

./build_image --board=${BOARD} --noenable_rootfs_verification test

Once you've got a kernel that boots and has ethernet working, if you need additional changes you can:

emerge-${BOARD} chromeos-kernel-3_18

~/trunk/src/scripts/update_kernel.sh --remote <your Chromium laptop IP>

[myke predko]

Hi Yuly,

 

I appreciate the list but I have a couple of questions:

 

What does the “emerge” command do?

 

Also, as I’m cut and pasting commands from my list, I’m not worrying about the BOARD variable (just putting in “x86-generic”) – is this a problem?

 

Thanx,

 

myke

 

 

From: ynov...@google.com [mailto:ynov...@google.com] On Behalf Of Yuly Novikov
Sent: Tuesday, September 22, 2015 6:40 PM
To: Myke Predko <myke....@mimetics.ca>
Cc: Chromium OS dev <chromiu...@chromium.org>
Subject: Re: [cros-dev] Re: ChromiumOS Build Process/Not getting anywhere

 

On Tue, Sep 22, 2015 at 6:22 PM, Myke Predko <myke....@mimetics.ca> wrote:

 

[Yuly Novikov]

On Tue, Sep 22, 2015 at 6:46 PM, myke predko <myke....@mimetics.ca> wrote:

Hi Yuly,

 

I appreciate the list but I have a couple of questions:

 

What does the “emerge” command do?

If you really want to know, you should read about portage package management system. https://wiki.gentoo.org/wiki/Handbook:X86/Working/Portage

Or just "man emerge" in chroot.

Basically, it builds your sources, and puts the results in a place from which build_image can pick them up.

 

Also, as I’m cut and pasting commands from my list, I’m not worrying about the BOARD variable (just putting in “x86-generic”) – is this a problem?

No, setting the variable doesn't have any side effects, AFAIK. 

[Myke Predko]

Sorry, no luck.  I followed the process below but the same kernel executed (my message changes were not picked up).

Could you look at the emerge dump file (attached) and look at the following error:

[blocks B      ] sys-kernel/chromeos-kernel-3_18 ("sys-kernel/chromeos-kernel-3_18" is blocking virtual/linux-sources-1-r10)

 * Error: The above package list contains packages which cannot be

 * installed at the same time on the same system.

Could this be explaining why my code isn't being picked up?  Any other ideas?

Thanx,

myke

[Ausmus, James]

On Tue, Sep 22, 2015 at 8:57 PM, Myke Predko <myke....@mimetics.ca> wrote:

Sorry, no luck.  I followed the process below but the same kernel executed (my message changes were not picked up).

Could you look at the emerge dump file (attached) and look at the following error:

[blocks B      ] sys-kernel/chromeos-kernel-3_18 ("sys-kernel/chromeos-kernel-3_18" is blocking virtual/linux-sources-1-r10)

 * Error: The above package list contains packages which cannot be

 * installed at the same time on the same system.

Could this be explaining why my code isn't being picked up?  Any other ideas?

What is the output of the following two commands:

emerge-x86-generic -s chromeos-kernel

emerge-x86-generic -pv linux-sources

 

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

--

James Ausmus
ChromeOS Integration Architect
SSG-OTC ChromeOS Integration

[Myke Predko]

Hey James,

Thanx for the question - I'm just going through the process (http://www.chromium.org/chromium-os/developer-guide) again from the start (rm'ing the chromiumos folder and restarting the PC).  

I'm doing the "repo sync" right now.

Going through the process, it looks like I didn't execute "Making sudo a little more permissive" but I'm going through everything else.  

What are you looking for from the two commands?  

myke

[Yuly Novikov]

On Wed, Sep 23, 2015 at 11:58 AM, Myke Predko <myke....@mimetics.ca> wrote:

Hey James,

Thanx for the question - I'm just going through the process (http://www.chromium.org/chromium-os/developer-guide) again from the start (rm'ing the chromiumos folder and restarting the PC).  

That's an overkill. Wouldn't it be easier/faster to follow the suggestion in the error dump you've attached?

I.e.

For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked

Anyway, after you've "repo sync'ed", don't forget to make the change to  overlays/overlay-x86-generic/make.conf before you run setup_board.

And to cros_workon-$BOARD start chromeos-kernel-3_18 before you build_packages.

I'm doing the "repo sync" right now.

Going through the process, it looks like I didn't execute "Making sudo a little more permissive" but I'm going through everything else.  

What are you looking for from the two commands?  

myke

On Wednesday, September 23, 2015 at 11:25:54 AM UTC-4, James Ausmus wrote:

On Tue, Sep 22, 2015 at 8:57 PM, Myke Predko <myke....@mimetics.ca> wrote:

Sorry, no luck.  I followed the process below but the same kernel executed (my message changes were not picked up).

Could you look at the emerge dump file (attached) and look at the following error:

[blocks B      ] sys-kernel/chromeos-kernel-3_18 ("sys-kernel/chromeos-kernel-3_18" is blocking virtual/linux-sources-1-r10)

Great, you are getting real progress, it's now tries to build the right kernel! But now 3.18 kernel conflicts with other packages.

It would have been an easier path for you to try making your changes to 3.14 kernel.

I am not an expert on portage, so what I usually try in this case is "emerge-$BOARD -C linux-sources" to remove the conflicting package, and then try "emerge-$BOARD chromeos-kernel-3_18", hoping it will resolve the conflict on its own.

If you still get the same error, ask someone more proficient in portage, or just try working with 3.14 kernel.

[Myke Predko]

Thanx for the replies.  I decided to go back to the start because I have found in the past that when you are trying to figure out a build, it doesn't hurt to start from the beginning with everything documented.  

The good news is, it looks like the package build is finally going in the right direction, the bad news is the build is generating collisions.  

If you look at the attached files:

- 2015.09.23 - Build Process from (almost) Zero

   - This is the process that I have been following today

- 2015.09.23 - 17.27 - build_packages dump

   - This is the dump of the end of the ./build_packages command (where I stopped).  

How do I figure out where the collisions are happening and how do I deal with them?  

If I go to line 69 in the build_packages dump file, it seems that there are a number of radeon files which are in collision.  I've done some research, but I can't figure out what is the correct approach on this.

How do I deal with this issue?

Thanx,

myke

[Yuly Novikov]

On Wed, Sep 23, 2015 at 6:00 PM, Myke Predko <myke....@mimetics.ca> wrote:

Thanx for the replies.  I decided to go back to the start because I have found in the past that when you are trying to figure out a build, it doesn't hurt to start from the beginning with everything documented.  

The good news is, it looks like the package build is finally going in the right direction, the bad news is the build is generating collisions.  

If you look at the attached files:

- 2015.09.23 - Build Process from (almost) Zero

   - This is the process that I have been following today

- 2015.09.23 - 17.27 - build_packages dump

   - This is the dump of the end of the ./build_packages command (where I stopped).  

How do I figure out where the collisions are happening and how do I deal with them?  

If I go to line 69 in the build_packages dump file, it seems that there are a number of radeon files which are in collision.  I've done some research, but I can't figure out what is the correct approach on this.

How do I deal with this issue?

Your best approach would be not trying to upgrade the kernel in x86-generic overlay to 3.18, as this is too much effort.

It should be easier to backport the kernel changes you want to make into 3.14.

If you insist on going with 3.18, then you should try to figure out why both chromeos-kernel-3_18-9999 and linux-firmware-0.0.1-r74 are trying to install the same files, figure out which of them should be the one to install the files, and make the necessary changes to their builds.

One place to start looking is the ebuild files for these packages, which location you can find with "equery-${BOARD} w chromeos-kernel-3_18" and "equery-${BOARD} w linux-firmware".

[Ausmus, James]

On Wed, Sep 23, 2015 at 3:00 PM, Myke Predko <myke....@mimetics.ca> wrote:
>
> Thanx for the replies.  I decided to go back to the start because I have found in the past that when you are trying to figure out a build, it doesn't hurt to start from the beginning with everything documented.  
>
> The good news is, it looks like the package build is finally going in the right direction, the bad news is the build is generating collisions.  
>
> If you look at the attached files:
> - 2015.09.23 - Build Process from (almost) Zero
>    - This is the process that I have been following today
> - 2015.09.23 - 17.27 - build_packages dump
>    - This is the dump of the end of the ./build_packages command (where I stopped).  
>
> How do I figure out where the collisions are happening and how do I deal with them?  

The chromeos-kernel-3_18 kernel build is installing a number of Radeon firmware files that chromeos-kernel-3_14 does not - likely either a kernel config issue or an upstream kernel delta between 3.14 and 3.18

 
>
>
> If I go to line 69 in the build_packages dump file, it seems that there are a number of radeon files which are in collision.  I've done some research, but I can't figure out what is the correct approach on this.
>
> How do I deal with this issue?

Are you using a Radeon GPU? If not, you can stop the linux-firmware package from installing the radeon FW files - add the following line to overlays/x86-generic/make.conf:

VIDEO_CARDS=""

then do (in the SDK):

emerge-x86-generic linux-firmware chromeos-kernel-3_18

There are some other ways to work around it as well, but the above is probably the most straight-forward (assuming you're not using a Radeon)

HTH-

James

[Myke Predko]

Hi James,

Made the change (should be low risk as I'm working with WinXP laptops as my target).  

When I ran the emerge command, it started off with:

!!! CONFIG_PROTECT is empty for '/build/x86-generic/'

with the next line having a spinner but it seems to be starting to build now.

I'll let you know how it works.

[Myke Predko]

Sigh.  Well, it started well but ended up getting the radeon files conflict.  

I've attached the dump information.  

I tried the "portageq owners / RV730_me.bin" as suggested by the error message, but regardless of the permutations I used, I got the message with the command:

(cr) ((b772bc1...)) mimetics@mimetics-linux-01 ~/trunk/src/scripts $ portageq owners / RV730_me.bin

None of the installed packages claim these files:

RV730_me.bin

So, I'll try Yuly's suggestion to use the equery commands.  

On that note, I'm going with v3.18 because it recognizes and has code to deal with the missing "PAE" flag in the Pentium M processor in the target systems that I'm using.  When I look through the v3.14 and earlier code, it doesn't have the same code which means I would have to import it and probably end up at the same point I'm at here.

More in a bit.

myke

[Myke Predko]

The results of the equery (see attached) resulted in ebuilds in the /mnt folder - when I tried to look at them, there was nothing there that I could use.  

I then tried doing greps on the strings to see if I could find them in intersecting .ebuild files (see attached) but with no luck.  

When I ran the greps without the "--include=/*.ebuild" options, I got the same message:

Binary file chromiumos/src/third_party/chromiumos-overlay/.git/index matches

for both "chromeos-kernel-3_18" and "linux-firmware-0.0.1-r74".

Any ideas what I should be looking for and, when I find it, what are the changes I should make (to the .ebuild file)?

Thanx,

myke

[Myke Predko]

A summary of my latest analysis before I go to bed.  

If I look at the files which seem to be in collision, they are in the form of:

/build/x86-generic/lib/firmware/radeon/R%###_@@@.bin

Where "%" is an optional "V" or "S" character, "###" is a three digit number and "@@@" can be "me", "cp" or "pfp".  

They are found in the following folders:

./chromiumos/src/third_party/linux-firmware/radeon/

./chromiumos/chroot/build/x86-generic/lib/firmware/radeon/  <== This is where they're being listed in the error message

./chromiumos/chroot/build/x86-generic/var/cache/portage/sys-kernel/chromeos-kernel-3_18/firmware/radeon/

./chromiumos/chroot/build/x86-generic/tmp/portage/sys-kernel/chromeos-kernel-3_18-9999/image/lib/firmware/radeon/

and, what I presume is the source (adding the ".ihex" suffix to the file name) are found in:

./chromiumos/src/third_party/kernel/v3.8/firmware/radeon/

./chromiumos/src/third_party/kernel/v3.10/firmware/radeon/

./chromiumos/src/third_party/kernel/v3.14/firmware/radeon/

./chromiumos/src/third_party/kernel/v3.18/firmware/radeon/

Looking at the "modified" dates for the .bin files in the folders, I see:

./chromiumos/src/third_party/linux-firmware/radeon/  <== Wed, Sep 23 2015 15:07:12

./chromiumos/chroot/build/x86-generic/lib/firmware/radeon/  <== Thu, Sep 17 2015 22:36:00

./chromiumos/chroot/build/x86-generic/var/cache/portage/sys-kernel/chromeos-kernel-3_18/firmware/radeon/ <== Wed, Sep 23 2015 17:04:43

./chromiumos/chroot/build/x86-generic/tmp/portage/sys-kernel/chromeos-kernel-3_18-9999/image/lib/firmware/radeon/ <== Wed, Sep 23 2015 20:14:50

Notice that the .bin files in the folder which is identified as the repeat (./chromiumos/chroot/build/x86-generic/lib/firmware/radeon/) has a different "modified" date/time stamp?  

My first thought is that these files are an artefact in the repo process and were built with the repo package and passed along with it in error.  One way to test this theory is to yet again delete the chromiumos folder and go through the download and repo process again.  This, however is time consuming and shouldn't be necessary.  

Another would be to delete all instances of the radeon ".bin" files and see what happens when I run the emerge command again.  This is dangerous as I might end up removing files which are actually required (although I could keep a saved folder of them to copy them back into).  

Unfortunately, I can't identify the ebuild or other files which specify the conversion of the .hex to .bin files - which would be the best way to determine the error.  

Can anybody help me with suggestions?  I have been reading the Portage documentation and doing greps on the folders to try and find .ebuild files which specify the builds with no luck.  

Where else should I be looking or what else should I be doing?

Thanx,

myke

[Myke Predko]

Okay, I decided to move the conflicting radeon files into another folder that isn't accessed by the build and re-ran the emerge command.  

That seemed to fix one problem but I now have a new one; the 3.18 kernel doesn't seem to be built.  Here is the end of emerge dump:

>>> Installing (1 of 1) sys-kernel/chromeos-kernel-3_18-9999::chromiumos to /build/x86-generic/

 * Removing /usr/lib*/*.la

 * Removing /etc/init.d

 * Removing /etc/conf.d

 * Removing /etc/logrotate.d

 * Removing /etc/sandbox.d

 * Removing /usr/share/bash-completion

 * Removing /usr/share/man

 * Removing /usr/share/info

 * Removing /usr/share/doc

 * Running stacked hooks for pre_pkg_preinst

 *    wrap_old_config_scripts ...                                        [ ok ]

 * QA Notice: Symbolic link /lib/modules/3.18.0/source points to /mnt/host/source/src/third_party/kernel/v3.18 which does not exist.

 * QA Notice: Symbolic link /lib/modules/3.18.0/build points to /build/x86-generic/var/cache/portage/sys-kernel/chromeos-kernel-3_18 which does not exist.

 * QA Notice: Symbolic link /usr/src/linux points to /build/x86-generic/var/cache/portage/sys-kernel/chromeos-kernel-3_18 which does not exist.

 * Messages for package sys-kernel/chromeos-kernel-3_18-9999 merged to /build/x86-generic/:

 * Unable to find kernel sources at /build/x86-generic/usr/src/linux

 * Unable to calculate Linux Kernel version for build, attempting to use running version

 * Using kernel config: chromiumos-i386

 *    - enabling framebuffer console config

 *    - enabling CDC MBIM driver config

 *    - enabling 802.1Q VLAN config

 *    - enabling VT console config

>>> Auto-cleaning packages...

>>> Using system located in ROOT tree /build/x86-generic/

>>> No outdated packages were found on your system.

What now?  As I said before, I haven't had much luck finding/accessing the correct .ebuild make configuration files.  I'm guessing that the build is not going through with the v3.18 build.  

I did check the overlay make.conf file and it is referencing v3.18.  Where else should I be checking for it to be referenced? 

Thanx,

myke

[Yuly Novikov]

Do this:

1. Add "-video_cards_radeon" to USE flags in make.conf, i.e. it should look like this now:

USE="${USE} legacy_keyboard legacy_power_button kernel-3_18 -video_cards_radeon"

2. ./setup_board --board=x86-generic --force

3. emerge-x86-generic chromeos-kernel-3_18

--

[Myke Predko]

Did it and...

It got a lot further before it failed:

>>> Installing (24 of 24) sys-kernel/chromeos-kernel-3_18-3.18-r595::chromiumos to /build/x86-generic/

 * Removing /usr/lib*/*.la

 * Removing /etc/init.d

 * Removing /etc/conf.d

 * Removing /etc/logrotate.d

 * Removing /etc/sandbox.d

 * Removing /usr/share/bash-completion

 * Removing /usr/share/man

 * Removing /usr/share/info

 * Removing /usr/share/doc

 * Running stacked hooks for pre_pkg_preinst

 *    wrap_old_config_scripts ...                                         [ ok ]

 * QA Notice: Symbolic link /lib/modules/3.18.0-07500-gbece594/source points to /build/x86-generic/tmp/portage/sys-kernel/chromeos-kernel-3_18-3.18-r595/work/chromeos-kernel-3_18-3.18 which does not exist.

 * QA Notice: Symbolic link /lib/modules/3.18.0-07500-gbece594/build points to /build/x86-generic/var/cache/portage/sys-kernel/chromeos-kernel-3_18 which does not exist.

 * QA Notice: Symbolic link /usr/src/linux points to /build/x86-generic/var/cache/portage/sys-kernel/chromeos-kernel-3_18 which does not exist.

 * Messages for package dev-vcs/git-2.1.2 merged to /build/x86-generic/:

 * These additional scripts need some dependencies:

 *   git-quiltimport  : dev-util/quilt

 *   git-instaweb     : || ( www-servers/lighttpd www-servers/apache www-servers/nginx )

 * Messages for package sys-kernel/chromeos-kernel-3_18-3.18-r595 merged to /build/x86-generic/:

 * Unable to find kernel sources at /build/x86-generic/usr/src/linux

 * Unable to calculate Linux Kernel version for build, attempting to use running version

 * /mnt/host/source/src/third_party/kernel/v3.18 is not at rev bece5949d32ee6937f1f1439384e7983c903a180

 * Using kernel config: chromiumos-i386

 *    - enabling framebuffer console config

 *    - enabling CDC MBIM driver config

 *    - enabling 802.1Q VLAN config

 *    - enabling VT console config

>>> Auto-cleaning packages...

>>> Using system located in ROOT tree /build/x86-generic/

>>> No outdated packages were found on your system.

Note that it is still saying that the build can't find the kernel sources at /build/x86-generic/usr/src/linux

What should I try next?

Thanx for all the help/suggestions,

myke

[Yuly Novikov]

These look like warnings.

I think you are good, if you have /build/x86-generic/boot/vmlinuz.

Note that it built r595 version of kernel-3_18, if you need version 9999 with your kernel changes, you should "cros-workon-x86-generic start chromeos-kernel-3_18".

I wonder why that happened, as I recall that cros workon'ed packages were remembered even after setup_board --force. Did you start from scratch again?

So, after you've cros_workon'ed it again, try build_packages, etc.

[Myke Predko]

Hi Yuly,

I've changed the message in the cpu.c source file so I can see if the build happens.  I'm running the "emerg-x86-generic chromeos-kernel-3_18" command right now.  Afterwards, I'll do "./build_image --board=x86-generic --noenable_rootfs_verification test" followed by "cros flash usb:// x86-generic/latest".  

Should I have redone the "./setup_board --board=x86-gereric --force" before doing that?  This command was executed before when I was reloading everything.  

Attached is the process that I'm following with the setup - could you please confirm the process?  This is at the end with "Repeat from here:"

I'll let you know how things work as outlined above.  

Thanx,

myke

[Myke Predko]

As I do the setup_build, I got the message:

emerge: there are no ebuilds to satisfy "virtual/target-os" for /mnt/host/source/src/build/images/x86-generic/R47-7485.0.2015_09_24_1459-a1/rootfs/.

emerge: searching for similar names... nothing similar found.

INFO    : Unmounting image from /mnt/host/source/src/build/images/x86-generic/R47-7485.0.2015_09_24_1459-a1/stateful and /mnt/host/source/src/build/images/x86-generic/R47-7485.0.2015_09_24_1459-a1/rootfs

Cleaning up /usr/local symlinks for /mnt/host/source/src/build/images/x86-generic/R47-7485.0.2015_09_24_1459-a1/stateful/dev_image

An error occurred in your build so your latest output directory is invalid.

Would you like to delete the output directory (y/N)? 

I said yes...

And it looks like everything ends here.  

I'm going to retry with the process:

./setup_board --board=x86-generic --force

emerge-x86-generic chromeos-kernel-3_18

cros flash usb:// x86-generic/latest

Let's see what happens

myke

[Yuly Novikov]

On Thu, Sep 24, 2015 at 3:09 PM, Myke Predko <myke....@mimetics.ca> wrote:

As I do the setup_build, I got the message:

emerge: there are no ebuilds to satisfy "virtual/target-os" for /mnt/host/source/src/build/images/x86-generic/R47-7485.0.2015_09_24_1459-a1/rootfs/.

emerge: searching for similar names... nothing similar found.

INFO    : Unmounting image from /mnt/host/source/src/build/images/x86-generic/R47-7485.0.2015_09_24_1459-a1/stateful and /mnt/host/source/src/build/images/x86-generic/R47-7485.0.2015_09_24_1459-a1/rootfs

Cleaning up /usr/local symlinks for /mnt/host/source/src/build/images/x86-generic/R47-7485.0.2015_09_24_1459-a1/stateful/dev_image

An error occurred in your build so your latest output directory is invalid.

Would you like to delete the output directory (y/N)? 

I said yes...

And it looks like everything ends here.  

You've probably got this error because you didn't build_packages.

 

I'm going to retry with the process:

So add to this 

./setup_board --board=x86-generic --force

emerge-x86-generic chromeos-kernel-3_18

./build_packages --board=x86-generic

./build_image --board=x86-generic --noenable_rootfs_verification test

cros flash usb:// x86-generic/latest

To sum it up:

setup_board prepares the build environment

emerge builds individual package - you'd want to do this when you have 1 specific package that you want to modify

build_packaged runs emerge on all packages that setup_board configured

build_image creates an image from all the packages setup_board configured. It failed for you, because you only had the kernel built, as the rest of the packages were cleared by setup_board.

Let's see what happens

myke

On Thursday, September 24, 2015 at 2:54:36 PM UTC-4, Myke Predko wrote:

Hi Yuly,

I've changed the message in the cpu.c source file so I can see if the build happens.  I'm running the "emerg-x86-generic chromeos-kernel-3_18" command right now.  Afterwards, I'll do "./build_image --board=x86-generic --noenable_rootfs_verification test" followed by "cros flash usb:// x86-generic/latest".  

Should I have redone the "./setup_board --board=x86-gereric --force" before doing that?  This command was executed before when I was reloading everything.  

setup_board --force cleans everything that you've built, and sets up the build environment based on the overlay (make.conf).

So, you'd only want to do it only when you modify make.conf, or you've somehow ended up with bad build state - this is somewhat lightweight than deleting your chroot and sources and repo sync'ing again.

[Ausmus, James]

On Wed, Sep 23, 2015 at 5:45 PM, Myke Predko <myke....@mimetics.ca> wrote:

Sigh.  Well, it started well but ended up getting the radeon files conflict.  

Interesting - it worked for me - can you post the contents of your current overlay-x86-generic/make.conf file?

 

--

--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.

[Myke Predko]

Hey James,

my latest make.conf is attached.  

Just out of curiosity, what are the contents of your 

./chromiumos/chroot/build/x86-generic/lib/firmware/radeon 

folder?

Are there files like the R100_cp.bin which I had the conflict on and what are their "modified' dates?  

If you don't have them, could they have been copied in as we narrowed down to the current build approach?  

Thanx,

myke

[Ausmus, James]

On Thu, Sep 24, 2015 at 1:05 PM, Myke Predko <myke....@mimetics.ca> wrote:
>
> Hey James,
>
> my latest make.conf is attached.

That does look right

 >
> Just out of curiosity, what are the contents of your
> ./chromiumos/chroot/build/x86-generic/lib/firmware/radeon
> folder?

$ ls -al /build/x86-generic/lib/firmware/radeon/

total 268

drwxr-xr-x  2 root root  4096 Sep 24 13:57 .

drwxr-xr-x 36 root root  4096 Sep 24 13:57 ..

-rw-r--r--  1 root root  2048 Sep 24 13:57 R100_cp.bin

-rw-r--r--  1 root root  2048 Sep 24 13:57 R200_cp.bin

-rw-r--r--  1 root root  2048 Sep 24 13:57 R300_cp.bin

-rw-r--r--  1 root root  2048 Sep 24 13:57 R420_cp.bin

-rw-r--r--  1 root root  2048 Sep 24 13:57 R520_cp.bin

-rw-r--r--  1 root root 21504 Sep 24 13:57 R600_me.bin

-rw-r--r--  1 root root  2304 Sep 24 13:57 R600_pfp.bin

-rw-r--r--  1 root root  2048 Sep 24 13:57 RS600_cp.bin

-rw-r--r--  1 root root  2048 Sep 24 13:57 RS690_cp.bin

-rw-r--r--  1 root root 21504 Sep 24 13:57 RS780_me.bin

-rw-r--r--  1 root root  2304 Sep 24 13:57 RS780_pfp.bin

-rw-r--r--  1 root root 21504 Sep 24 13:57 RV610_me.bin

-rw-r--r--  1 root root  2304 Sep 24 13:57 RV610_pfp.bin

-rw-r--r--  1 root root 21504 Sep 24 13:57 RV620_me.bin

-rw-r--r--  1 root root  2304 Sep 24 13:57 RV620_pfp.bin

-rw-r--r--  1 root root 21504 Sep 24 13:57 RV630_me.bin

-rw-r--r--  1 root root  2304 Sep 24 13:57 RV630_pfp.bin

-rw-r--r--  1 root root 21504 Sep 24 13:57 RV635_me.bin

-rw-r--r--  1 root root  2304 Sep 24 13:57 RV635_pfp.bin

-rw-r--r--  1 root root 21504 Sep 24 13:57 RV670_me.bin

-rw-r--r--  1 root root  2304 Sep 24 13:57 RV670_pfp.bin

-rw-r--r--  1 root root  5440 Sep 24 13:57 RV710_me.bin

-rw-r--r--  1 root root  3392 Sep 24 13:57 RV710_pfp.bin

-rw-r--r--  1 root root  5440 Sep 24 13:57 RV730_me.bin

-rw-r--r--  1 root root  3392 Sep 24 13:57 RV730_pfp.bin

-rw-r--r--  1 root root  5440 Sep 24 13:57 RV770_me.bin

-rw-r--r--  1 root root  3392 Sep 24 13:57 RV770_pfp.bin

>
> Are there files like the R100_cp.bin which I had the conflict on and what are their "modified' dates?  
>
> If you don't have them, could they have been copied in as we narrowed down to the current build approach?  

Can you paste the output of the following two commands:

emerge-x86-generic -pv linux-sources chromeos-kernel-3_18 linux-firmware

equery-x86-generic f chromeos-kernel-3_18 | grep -i radeon

equery-x86-generic f linux-firmware | grep -i radeon

[Ausmus, James]

Ahem. Three commands... ;)

[Myke Predko]

Hi James,

Sorry for the long reply, I was waiting for the build_packages command to complete.  

The response for the three commands (which I trust will not affect the current build are:

for "emerge-x86-generic -pv linux-sources chromeos-kernel-3_18 linux-firmware":

(cr) ((b772bc1...)) mimetics@mimetics-linux-01 ~/trunk/src/scripts $ emerge-x86-generic -pv linux-sources chromeos-kernel-3_18 linux-firmware

!!! CONFIG_PROTECT is empty for '/build/x86-generic/'

These are the packages that would be merged, in order:

Calculating dependencies... done!

[ebuild   R    ] sys-kernel/linux-firmware-0.0.1-r74::chromiumos to /build/x86-generic/ USE="-cros_host -profiling" LINUX_FIRMWARE="iwlwifi-all -ath3k-all -ath3k-ar3011 -ath3k-ar3012 -ath9k_htc -bcm4354-bt -brcmfmac-all -brcmfmac4354-sdio -brcmfmac4356-pcie -cros-pd -fw_sst -fw_sst2 -i915_skl -ibt-hw -iwlwifi-100 -iwlwifi-1000 -iwlwifi-105 -iwlwifi-135 -iwlwifi-2000 -iwlwifi-2030 -iwlwifi-3160 -iwlwifi-3945 -iwlwifi-4965 -iwlwifi-5000 -iwlwifi-5150 -iwlwifi-6000 -iwlwifi-6005 -iwlwifi-6030 -iwlwifi-6050 -iwlwifi-7260 -iwlwifi-7265 -iwlwifi-7265D -marvell-pcie8897 -nvidia-xusb -rt2870" VIDEO_CARDS="-radeon" 0 KiB

[ebuild   R   *] sys-kernel/chromeos-kernel-3_18-9999::chromiumos to /build/x86-generic/ USE="fbconsole firmware_install mbim vlan vtconsole -acpi_ac_off -android_test -binder -blkdevram -boot_dts_device_tree -builtin_fw_t124_xusb -builtin_fw_t210_nouveau -builtin_fw_t210_xusb -ca0132 -cifs -cros_ec_mec -cros_host -debug -device_tree -dwc2_dual_role -dyndebug -factory_shim_ramfs -gdmwimax -gobi -highmem -i2cdev -kgdb -kvm -loader_kernel_ramfs -lxc -netboot_ramfs -nfc -nfs -nowerror -pcserial -ppp -profiling -qmi -realtekpstor -recovery_ramfs -samsung_serial -socketmon -systemtap -tpm -usb_gadget -usb_gadget_acm -usb_gadget_audio -usb_gadget_ncm -vfat -wifi_debug -wifi_testbed_ap -wireless316 -wireless318 -wireless34 -wireless38 -x32" BOARD_USE="x86-generic -acorn -amd64-corei7 -amd64-generic -amd64-generic_embedded -amd64-generic_freon -amd64-generic_mobbuild -amd64-host -aries -arkham -arm-generic -arm-generic_freon -arm64-generic -auron -auron_paine -auron_pearlvalley -auron_yuna -banjo -bayleybay -beaglebone -beaglebone_servo -beaglebone_vv1 -beltino -blackwall -bobcat -bolt -bruteus -buddy -butterfly -bwtm2 -bxt-rvp -candy -cardhu -celes -cid -clapper -cosmos -cranky -cyan -cyclone -daisy -daisy_embedded -daisy_skate -daisy_snow -daisy_spring -daisy_winter -dalmore -danger -danger_embedded -duck -enguarde -envoy-jerry -expresso -falco -falco_gles -falco_li -fb1 -foster -gandof -gizmo -glados -glimmer -gnawty -guado -guado_moblab -heli -hsb -ironhide -jecht -kayle -kip -klang -kunimitsu -lakitu -lakitu_mobbuild -lakitu_next -laser -leon -link -lulu -lumpy -mappy -mappy-envoy -mappy_flashstation -marble -mccloud -minnowboard -mipseb-n32-generic -mipseb-n64-generic -mipseb-o32-generic -mipsel-n32-generic -mipsel-n64-generic -mipsel-o32-generic -monroe -moose -ninja -nyan -nyan_big -nyan_blaze -nyan_freon -nyan_kitty -oak -optimus -orco -panda -panther -panther_embedded -panther_goofy -panther_moblab -parrot -parrot32 -parrot64 -parrot_ivb -peach -peach_kirby -peach_pi -peach_pit -peppy -ppcbe-32-generic -ppcbe-64-generic -ppcle-32-generic -ppcle-64-generic -puppy -purin -quawks -rambi -raspberrypi -reks -reptile -rikku -rizer -rotor -rush -rush_ryu -sama5d3 -samus -shogun -sklrvp -slippy -smaug -sonic -squawks -storm -storm_nand -stout -strago -stumpy -stumpy_moblab -stumpy_pico -sumo -swanky -tails -tegra3-generic -tidus -tricky -ultima -veyron -veyron_brain -veyron_caution -veyron_danger -veyron_gus -veyron_jaq -veyron_jerry -veyron_mickey -veyron_mighty -veyron_minnie -veyron_minnie-cheets -veyron_nicky -veyron_pinky -veyron_remy -veyron_rialto -veyron_romy -veyron_shark -veyron_speedy -veyron_thea -whirlwind -winky -wizpig -wolf -wsb -x32-generic -x86-agz -x86-alex -x86-alex32 -x86-alex32_he -x86-alex_he -x86-alex_hubble -x86-dogfood -x86-generic_embedded -x86-generic_freon -x86-mario -x86-mario64 -x86-zgb -x86-zgb32 -x86-zgb32_he -x86-zgb_he -zako" 0 KiB

[ebuild   R    ] virtual/linux-sources-1-r10::chromiumos to /build/x86-generic/ USE="kernel-3_18 -kernel-3_10 -kernel-3_14 -kernel-3_8 -kernel-upstream-mainline -kernel-upstream-next" 0 KiB

Total: 3 packages (3 reinstalls), Size of downloads: 0 KiB

for "equery-x86-generic f chromeos-kernel-3_18 | grep -i radeon":

(cr) ((b772bc1...)) mimetics@mimetics-linux-01 ~/trunk/src/scripts $ equery-x86-generic f chromeos-kernel-3_18 | grep -i radeon

/lib/firmware/radeon

/lib/firmware/radeon/R100_cp.bin

/lib/firmware/radeon/R200_cp.bin

/lib/firmware/radeon/R300_cp.bin

/lib/firmware/radeon/R420_cp.bin

/lib/firmware/radeon/R520_cp.bin

/lib/firmware/radeon/R600_me.bin

/lib/firmware/radeon/R600_pfp.bin

/lib/firmware/radeon/RS600_cp.bin

/lib/firmware/radeon/RS690_cp.bin

/lib/firmware/radeon/RS780_me.bin

/lib/firmware/radeon/RS780_pfp.bin

/lib/firmware/radeon/RV610_me.bin

/lib/firmware/radeon/RV610_pfp.bin

/lib/firmware/radeon/RV620_me.bin

/lib/firmware/radeon/RV620_pfp.bin

/lib/firmware/radeon/RV630_me.bin

/lib/firmware/radeon/RV630_pfp.bin

/lib/firmware/radeon/RV635_me.bin

/lib/firmware/radeon/RV635_pfp.bin

/lib/firmware/radeon/RV670_me.bin

/lib/firmware/radeon/RV670_pfp.bin

/lib/firmware/radeon/RV710_me.bin

/lib/firmware/radeon/RV710_pfp.bin

/lib/firmware/radeon/RV730_me.bin

/lib/firmware/radeon/RV730_pfp.bin

/lib/firmware/radeon/RV770_me.bin

/lib/firmware/radeon/RV770_pfp.bin

/lib/modules/3.18.0/kernel/drivers/gpu/drm/radeon

/lib/modules/3.18.0/kernel/drivers/gpu/drm/radeon/radeon.ko

/usr/lib/debug/lib/modules/3.18.0/kernel/drivers/gpu/drm/radeon

/usr/lib/debug/lib/modules/3.18.0/kernel/drivers/gpu/drm/radeon/radeon.ko.debug

for "equery-x86-generic f linux-firmware | grep -i radeon":

Nothing was returned

for:

mimetics@mimetics-linux-01:~/chromiumos/chroot/build/x86-generic/lib/firmware$ ls -al radeon/

total 268

drwxr-xr-x  2 root root  4096 Sep 24 16:58 .

drwxr-xr-x 38 root root  4096 Sep 24 17:22 ..

-rw-r--r--  1 root root  2048 Sep 24 16:55 R100_cp.bin

-rw-r--r--  1 root root  2048 Sep 24 16:55 R200_cp.bin

-rw-r--r--  1 root root  2048 Sep 24 16:55 R300_cp.bin

-rw-r--r--  1 root root  2048 Sep 24 16:55 R420_cp.bin

-rw-r--r--  1 root root  2048 Sep 24 16:55 R520_cp.bin

-rw-r--r--  1 root root 21504 Sep 24 16:55 R600_me.bin

-rw-r--r--  1 root root  2304 Sep 24 16:55 R600_pfp.bin

-rw-r--r--  1 root root  2048 Sep 24 16:55 RS600_cp.bin

-rw-r--r--  1 root root  2048 Sep 24 16:55 RS690_cp.bin

-rw-r--r--  1 root root 21504 Sep 24 16:55 RS780_me.bin

-rw-r--r--  1 root root  2304 Sep 24 16:55 RS780_pfp.bin

-rw-r--r--  1 root root 21504 Sep 24 16:55 RV610_me.bin

-rw-r--r--  1 root root  2304 Sep 24 16:55 RV610_pfp.bin

-rw-r--r--  1 root root 21504 Sep 24 16:55 RV620_me.bin

-rw-r--r--  1 root root  2304 Sep 24 16:55 RV620_pfp.bin

-rw-r--r--  1 root root 21504 Sep 24 16:55 RV630_me.bin

-rw-r--r--  1 root root  2304 Sep 24 16:55 RV630_pfp.bin

-rw-r--r--  1 root root 21504 Sep 24 16:55 RV635_me.bin

-rw-r--r--  1 root root  2304 Sep 24 16:55 RV635_pfp.bin

-rw-r--r--  1 root root 21504 Sep 24 16:55 RV670_me.bin

-rw-r--r--  1 root root  2304 Sep 24 16:55 RV670_pfp.bin

-rw-r--r--  1 root root  5440 Sep 24 16:55 RV710_me.bin

-rw-r--r--  1 root root  3392 Sep 24 16:55 RV710_pfp.bin

-rw-r--r--  1 root root  5440 Sep 24 16:55 RV730_me.bin

-rw-r--r--  1 root root  3392 Sep 24 16:55 RV730_pfp.bin

-rw-r--r--  1 root root  5440 Sep 24 16:55 RV770_me.bin

-rw-r--r--  1 root root  3392 Sep 24 16:55 RV770_pfp.bin

So, the radeon files were rebuilt during the past operations.  

I'm continuing with the build_image (which has changes to the PAE error messages) so we'll see how everything works out.  

More as it happens,

myke

[Ausmus, James]

It looks like you're past this particular trouble - you have both the linux-firmware and chromeos-kernel-3_18 packages installed without the radeon FW conflicts, so you should be good to go - for this at least... ;)

-James

[Myke Predko]

Woo hoo!

The message changes I put into the source showed up on the target machine from the USB thumb drive. 

Now, when I make changes at this level, do I have to go through the full process of:

Step 1: ./setup_board --board=x86-generic --force

Step 2: emerge-x86-generic chromeos-kernel-3_18

Step 3: ./build_packages --board=x86-generic

Step 4: ./build_image --board=x86-generic --noenable_rootfs_verification test

Step 5: cros flash usb:// x86-generic/latest

This will be until I resolve the PAE issue (which I'm addressing as soon as I finish this post) so hopefully it will just be for one more build cycle before I can load the Chromium OS image on to a target machine and start working at bringing in the Bluetooth extensions in via my local network.

Hopefully I'm not premature in thanking everybody in their help and I'm sure I'll have some questions when it comes to porting the Bluetooth extension code from Chrome to Chromium.

myke

[Luigi Semenzato]

A. You don't need step 3. Emerge the kernel (or any package), then
rebuild and flash the image.
B. If you already have a running ChromiumOs test image, you can use
src/scripts/update_kernel.sh after the emerge, without rebuilding the
image etc.

[Myke Predko]

Hi Luigi,

If I'm reading you right, I can eliminate Steps 3. & 4. by using "update_kernel.sh"?

myke

[Yuly Novikov]

On Thu, Sep 24, 2015 at 8:52 PM, Myke Predko <myke....@mimetics.ca> wrote:

Hi Luigi,

If I'm reading you right, I can eliminate Steps 3. & 4. by using "update_kernel.sh"?

myke

On Thursday, September 24, 2015 at 8:47:53 PM UTC-4, Luigi Semenzato wrote:

A. You don't need step 3.  Emerge the kernel (or any package), then
rebuild and flash the image.
B. If you already have a running ChromiumOs test image, you can use
src/scripts/update_kernel.sh after the emerge, without rebuilding the
image etc.

On Thu, Sep 24, 2015 at 5:42 PM, Myke Predko <myke....@mimetics.ca> wrote:
> Woo hoo!
>
> The message changes I put into the source showed up on the target machine
> from the USB thumb drive.

Congrats! 

>
> Now, when I make changes at this level, do I have to go through the full
> process of:
> Step 1: ./setup_board --board=x86-generic --force
> Step 2: emerge-x86-generic chromeos-kernel-3_18
> Step 3: ./build_packages --board=x86-generic
> Step 4: ./build_image --board=x86-generic --noenable_rootfs_verification
> test
> Step 5: cros flash usb:// x86-generic/latest

When you just want to modify kernel source files, you need just to (assuming you alredy did "cros_workon-x86-generic start chromeos-kernel-3_18" at some poing):

1. emerge-x86-generic chromeos-kernel-3_18

2.  ./build_image --board=x86-generic --noenable_rootfs_verification test

3. cros flash usb:// x86-generic/latest

If you already have ethernet working, this can be reduced to:

1. emerge-x86-generic chromeos-kernel-3_18
2. ~/trunk/src/scripts/update_kernel.sh --remote <IP of you chromiumbook>

[Yuly Novikov]

On Thu, Sep 24, 2015 at 8:54 PM, Yuly Novikov <ynov...@chromium.org> wrote:

On Thu, Sep 24, 2015 at 8:52 PM, Myke Predko <myke....@mimetics.ca> wrote:

Hi Luigi,

If I'm reading you right, I can eliminate Steps 3. & 4. by using "update_kernel.sh"?

myke

On Thursday, September 24, 2015 at 8:47:53 PM UTC-4, Luigi Semenzato wrote:

A. You don't need step 3.  Emerge the kernel (or any package), then
rebuild and flash the image.
B. If you already have a running ChromiumOs test image, you can use
src/scripts/update_kernel.sh after the emerge, without rebuilding the
image etc.

On Thu, Sep 24, 2015 at 5:42 PM, Myke Predko <myke....@mimetics.ca> wrote:
> Woo hoo!
>
> The message changes I put into the source showed up on the target machine
> from the USB thumb drive.

Congrats! 

>
> Now, when I make changes at this level, do I have to go through the full
> process of:
> Step 1: ./setup_board --board=x86-generic --force
> Step 2: emerge-x86-generic chromeos-kernel-3_18
> Step 3: ./build_packages --board=x86-generic
> Step 4: ./build_image --board=x86-generic --noenable_rootfs_verification
> test
> Step 5: cros flash usb:// x86-generic/latest

When you just want to modify kernel source files, you need just to (assuming you alredy did "cros_workon-x86-generic start chromeos-kernel-3_18" at some point):

(And did build the rest of the packages with ./build_packages --board=x86-generic already).

[Luigi Semenzato]

Thanks Yuly.

Myke: it may be worth taking another pass through the Developer Guide
at chromium.org.

[Myke Predko]

Final note on this thread.  

First off, I want to thank Yuly, Luigi, James, Chirantan, Bill, Gwendal and anybody I may have missed for their help.  

With your help, I was able to get my own kernel build together and what I thought was the fix for the PAE flag seemed to work first off.  

Of course, once I fixed the PAE problem, I ended up with a number of other ones which unfortunately varied from system to system.  For example, when I start a Lenovo system, the messages are:

WARNING: Forcing PAE in CPU Flags  <== This is my fix

early console in decompress_kernel

Decompressing Linux... Parsing ELF... Performing relocations... done.

Booting the kernel.

[    0.177550] error detecting cacheinfo..cpu0

[    0.214453] atkbd serio1: probe failed

[    6.703390] EXT4-fs (sdb3): couldn't mount as ext3 due to feature incompatibilities

[    8.134237] EXT4-fs (sdb1): VFS: Can't find ext4 filesystem

[    8.851463] lpw2200: lpw2200-bss.fw request_firmware failed: Reason -2

[    8.851537] lpw2200: Unable to load firmware: -2

Dells, Toshibas and Compaqs (I have a bit of a collection of WinXP systems that I want to use) all boot up differently and have different errors.  When I try a Windows 7 PC, it seems to boot up okay but it puts the ACPI (power) into a funny state and I have to pull the plug to restart.  

My plan is to:

a) Start researching the issues.   I may work through the Lenovo first and see where that gets me.  The error list is reasonably comprehensive and that should help me to move forwards to getting the boot working.  

b) Get a much faster build machine.  The one I am using here, a dual core AMD with DDR2 memory and a 5200 RPM disk drive really isn't adequate for doing timely builds.  It seems to work okay, but the 2+ hour build times will kill me.  

Thanx again and as I make progress, I'll let everybody know.

myke

[Bill Richardson]

​I'm impressed by your persistence.

If you'd summarize the process that eventually worked and/or detail the incomplete or misleading instructions on the public developer page, we'll try to update them so the next person doesn't have such an ordeal.

Thanks.

​

Art for Art's Sake

Engineering for Money

[Myke Predko]

Hey Bill,

Attached is the document I wrote out to do the build and load a USB thumb drive.  

Overall, the instructions are quite good.  The two areas I would consider lacking are:

1.  Setting the make.conf for version 3.18 (or, any version for that matter) build.  

2.  Explaining how and why "emerge" is used.  

Those are the areas that I would consider gave me (and the group at large) the most issues.  

Thanx again - I'll keep you updated on how I'm doing.

myke

...

[Alexander Potapenko]

Hi all,

I've also hit the problem with package collisions between kernel-3_18
and video_cards_radeon.
What's the proper place to document the workaround (adding
-video_cards_radeon to the USE flags)?

TIA,
Alex

Alexander Potapenko
Software Engineer

Google Germany GmbH
Dienerstraße 12
80331 München