Questions regarding building for 32-bit arm devices (specifically ASUS C100PA)
27 views
Skip to first unread message
Kapil Paranjape
Oct 14, 2020, 4:05:40 AM10/14/20
to Chromium OS Development
Some questions regarding building for devices like ASUS C100PA.
(This device is a 32-bit arm device which is AUE but many people like me have a working device which we want to keep working with!)
1. (prompted by an earlier thread) Is it likely that support for AUE devices will be dropped? If so, some suggestions on strategies to keep ChromiumOS going on these devices (basically security updates) for personal use would be appreciated.
2. Some hardware support needs files from `/lib/firmware` and `/opt/google/touch` which are on the device. Without going into the legal issues, is there a simple way to ensure that these are copied into the personal builds? (ACCEPT_LICENSE alone does not seem to do it.)
Some more ambitious questions!
3. Will it be possible to incorporate `sommelier` into the build? The "ebuild" seems to have a REQUIRED_USE of `kvm_guest` but should probably not depend on it since it should work without kvm support. Sommelier is useful for locally installed graphical programs.
4. Since this device now has a 4.14 kernel and can support kvm in the kernel, it seems possible that `kvm_guest` may also be possible! Is it feasible to try to build support for `crostini` or is that something that people have tried and failed?
Thanks for any helpful suggestions on where to look for answers.
Kapil.
--
Jack Rosenthal
Oct 14, 2020, 12:02:10 PM10/14/20
to Kapil Paranjape, Chromium OS Development
On Wed, Oct 14, 2020 at 2:05 AM Kapil Paranjape <kapil.p...@gmail.com> wrote:
Some questions regarding building for devices like ASUS C100PA.(This device is a 32-bit arm device which is AUE but many people like me have a working device which we want to keep working with!)1. (prompted by an earlier thread) Is it likely that support for AUE devices will be dropped? If so, some suggestions on strategies to keep ChromiumOS going on these devices (basically security updates) for personal use would be appreciated.
Google won't be doing any updates or testing of ChromiumOS on AUE devices. Breakages may be introduced, but we keep the overlays around on a "best effort" basis. We can accept patches on Gerrit if you have any fixes.
2. Some hardware support needs files from `/lib/firmware` and `/opt/google/touch` which are on the device. Without going into the legal issues, is there a simple way to ensure that these are copied into the personal builds? (ACCEPT_LICENSE alone does not seem to do it.)
Unfortunately, many of these files (or their sources) are in the private overlays due to licensing concerns. You can try copying them out of an official ChromeOS image.
Some more ambitious questions!3. Will it be possible to incorporate `sommelier` into the build? The "ebuild" seems to have a REQUIRED_USE of `kvm_guest` but should probably not depend on it since it should work without kvm support. Sommelier is useful for locally installed graphical programs.4. Since this device now has a 4.14 kernel and can support kvm in the kernel, it seems possible that `kvm_guest` may also be possible! Is it feasible to try to build support for `crostini` or is that something that people have tried and failed?
Why not try to compile with USE=kvm_guest?
Thanks for any helpful suggestions on where to look for answers.Kapil.--
--
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-dev
Brian Norris
Oct 14, 2020, 7:43:53 PM10/14/20
to Jack Rosenthal, Kapil Paranjape, Chromium OS Development
On Wed, Oct 14, 2020 at 9:02 AM Jack Rosenthal <jros...@chromium.org> wrote:
On Wed, Oct 14, 2020 at 2:05 AM Kapil Paranjape <kapil.p...@gmail.com> wrote:Some questions regarding building for devices like ASUS C100PA.(This device is a 32-bit arm device which is AUE but many people like me have a working device which we want to keep working with!)1. (prompted by an earlier thread) Is it likely that support for AUE devices will be dropped? If so, some suggestions on strategies to keep ChromiumOS going on these devices (basically security updates) for personal use would be appreciated.Google won't be doing any updates or testing of ChromiumOS on AUE devices. Breakages may be introduced, but we keep the overlays around on a "best effort" basis. We can accept patches on Gerrit if you have any fixes.2. Some hardware support needs files from `/lib/firmware` and `/opt/google/touch` which are on the device. Without going into the legal issues, is there a simple way to ensure that these are copied into the personal builds? (ACCEPT_LICENSE alone does not seem to do it.)Unfortunately, many of these files (or their sources) are in the private overlays due to licensing concerns. You can try copying them out of an official ChromeOS image.
For the particular /lib/firmware file in question on that earlier thread, I just moved it to the public overlay:
A similar file was already published for other variants long ago:
and it's "just" some text configuration data, so I don't see a problem there.
As Jack says though, we can't necessarily do that for all such files.
(By the way, the /opt/.../touch firmware files typically aren't necessary -- they're useful for upgrading a device with old touch firmware, but the firmware typically persists to the touch device, so you can get by without it just fine, if you ever ran an official Chrome OS build.)
Some more ambitious questions!3. Will it be possible to incorporate `sommelier` into the build? The "ebuild" seems to have a REQUIRED_USE of `kvm_guest` but should probably not depend on it since it should work without kvm support. Sommelier is useful for locally installed graphical programs.4. Since this device now has a 4.14 kernel and can support kvm in the kernel, it seems possible that `kvm_guest` may also be possible! Is it feasible to try to build support for `crostini` or is that something that people have tried and failed?
For the record, it's kernel 4.19, not 4.14. But I have a strong suspicion that the underlying CPU (Rockchip RK3288) doesn't actually support virtualization.
Brian
Sonny Rao
Oct 14, 2020, 8:43:35 PM10/14/20
to Brian Norris, Jack Rosenthal, Kapil Paranjape, Chromium OS Development
On Wed, Oct 14, 2020 at 4:43 PM Brian Norris <brian...@chromium.org> wrote:
On Wed, Oct 14, 2020 at 9:02 AM Jack Rosenthal <jros...@chromium.org> wrote:On Wed, Oct 14, 2020 at 2:05 AM Kapil Paranjape <kapil.p...@gmail.com> wrote:Some questions regarding building for devices like ASUS C100PA.(This device is a 32-bit arm device which is AUE but many people like me have a working device which we want to keep working with!)1. (prompted by an earlier thread) Is it likely that support for AUE devices will be dropped? If so, some suggestions on strategies to keep ChromiumOS going on these devices (basically security updates) for personal use would be appreciated.Google won't be doing any updates or testing of ChromiumOS on AUE devices. Breakages may be introduced, but we keep the overlays around on a "best effort" basis. We can accept patches on Gerrit if you have any fixes.2. Some hardware support needs files from `/lib/firmware` and `/opt/google/touch` which are on the device. Without going into the legal issues, is there a simple way to ensure that these are copied into the personal builds? (ACCEPT_LICENSE alone does not seem to do it.)Unfortunately, many of these files (or their sources) are in the private overlays due to licensing concerns. You can try copying them out of an official ChromeOS image.For the particular /lib/firmware file in question on that earlier thread, I just moved it to the public overlay:A similar file was already published for other variants long ago:and it's "just" some text configuration data, so I don't see a problem there.As Jack says though, we can't necessarily do that for all such files.(By the way, the /opt/.../touch firmware files typically aren't necessary -- they're useful for upgrading a device with old touch firmware, but the firmware typically persists to the touch device, so you can get by without it just fine, if you ever ran an official Chrome OS build.)Some more ambitious questions!3. Will it be possible to incorporate `sommelier` into the build? The "ebuild" seems to have a REQUIRED_USE of `kvm_guest` but should probably not depend on it since it should work without kvm support. Sommelier is useful for locally installed graphical programs.4. Since this device now has a 4.14 kernel and can support kvm in the kernel, it seems possible that `kvm_guest` may also be possible! Is it feasible to try to build support for `crostini` or is that something that people have tried and failed?For the record, it's kernel 4.19, not 4.14. But I have a strong suspicion that the underlying CPU (Rockchip RK3288) doesn't actually support virtualization.
Yeah there's an issue on RK3288 that could prevent virtualization from working properly out of the box -- it may be possible to fix it but probably not easy.
The issue was that the architectural virtual counters weren't initialized properly and had random values coming out of reset and our firmware doesn't try to initialize them.
I remember at the time (6 years ago) we decided we weren't going to use virtualization so we would just switch to using the "physical" version of the counters.
It looks like this is accounted for in upstream via the "arm,cpu-registers-not-fw-configured" property in the timer node in arch/arm/boot/dts/rk3288.dtsi.
--Brian--Why not try to compile with USE=kvm_guest?Thanks for any helpful suggestions on where to look for answers.Kapil.----
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-dev
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-dev
--
Chromium OS Developers mailing list: chromiu...@chromium.org
View archives, change email options, or unsubscribe:
https://groups.google.com/a/chromium.org/group/chromium-os-dev
---
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-os-d...@chromium.org.
Kapil Paranjape
Oct 15, 2020, 8:30:08 AM10/15/20
to Chromium OS Development, Chromium OS Development
Thanks for the help.
1. Adding 'kvm_guest' to the USE variable in overlay-variant-veyron-minnie/make.conf did not seem to do anything. There are probably other conflicts.
2. Since the `.txt` file has been added to the overlay, presumably it is not required to copy it over.
Right now after a fresh build, I am struggling with the fact that after boot, the device tries to start updating before doing anything else!
Regards,
Kapil.
--
Doug Anderson
Oct 22, 2020, 8:10:31 PM10/22/20
to Sonny Rao, Brian Norris, Jack Rosenthal, Kapil Paranjape, Chromium OS Development
Hi,
On Wed, Oct 14, 2020 at 5:43 PM Sonny Rao <sonn...@chromium.org> wrote:
>
>
> On Wed, Oct 14, 2020 at 4:43 PM Brian Norris <brian...@chromium.org> wrote:
>>
>> On Wed, Oct 14, 2020 at 9:02 AM Jack Rosenthal <jros...@chromium.org> wrote:
>>>
>>> On Wed, Oct 14, 2020 at 2:05 AM Kapil Paranjape <kapil.p...@gmail.com> wrote:
>>>>
>>>> Some questions regarding building for devices like ASUS C100PA.
>>>>
>>>> (This device is a 32-bit arm device which is AUE but many people like me have a working device which we want to keep working with!)
>>>>
>>>> 1. (prompted by an earlier thread) Is it likely that support for AUE devices will be dropped? If so, some suggestions on strategies to keep ChromiumOS going on these devices (basically security updates) for personal use would be appreciated.
>>>
>>>
>>> Google won't be doing any updates or testing of ChromiumOS on AUE devices. Breakages may be introduced, but we keep the overlays around on a "best effort" basis. We can accept patches on Gerrit if you have any fixes.
I'm wondering if we really will keep the overlays around in the case
of veyron. I'm not saying I'll be the one to delete them, but I could
sorta imagine that things with the old "variant" scheme that veyron
uses might break? I guess if it happens someone could try to convert
them over...
>>>> 2. Some hardware support needs files from `/lib/firmware` and `/opt/google/touch` which are on the device. Without going into the legal issues, is there a simple way to ensure that these are copied into the personal builds? (ACCEPT_LICENSE alone does not seem to do it.)
>>>
>>>
>>> Unfortunately, many of these files (or their sources) are in the private overlays due to licensing concerns. You can try copying them out of an official ChromeOS image.
>>
>>
>> For the particular /lib/firmware file in question on that earlier thread, I just moved it to the public overlay:
>> https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/2469298
>> A similar file was already published for other variants long ago:
>> https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/HEAD/overlay-veyron/chromeos-base/chromeos-bsp-veyron/files/firmware/brcmfmac4354-sdio.txt
>> and it's "just" some text configuration data, so I don't see a problem there.
>>
>> As Jack says though, we can't necessarily do that for all such files.
>>
>> (By the way, the /opt/.../touch firmware files typically aren't necessary -- they're useful for upgrading a device with old touch firmware, but the firmware typically persists to the touch device, so you can get by without it just fine, if you ever ran an official Chrome OS build.)
>>
>>>
>>>
>>>>
>>>>
>>>> Some more ambitious questions!
>>>>
>>>> 3. Will it be possible to incorporate `sommelier` into the build? The "ebuild" seems to have a REQUIRED_USE of `kvm_guest` but should probably not depend on it since it should work without kvm support. Sommelier is useful for locally installed graphical programs.
>>>>
>>>> 4. Since this device now has a 4.14 kernel and can support kvm in the kernel, it seems possible that `kvm_guest` may also be possible! Is it feasible to try to build support for `crostini` or is that something that people have tried and failed?
>>
>>
>> For the record, it's kernel 4.19, not 4.14. But I have a strong suspicion that the underlying CPU (Rockchip RK3288) doesn't actually support virtualization.
>
>
> Yeah there's an issue on RK3288 that could prevent virtualization from working properly out of the box -- it may be possible to fix it but probably not easy.
>
> The issue was that the architectural virtual counters weren't initialized properly and had random values coming out of reset and our firmware doesn't try to initialize them.
> I remember at the time (6 years ago) we decided we weren't going to use virtualization so we would just switch to using the "physical" version of the counters.
>
> It looks like this is accounted for in upstream via the "arm,cpu-registers-not-fw-configured" property in the timer node in arch/arm/boot/dts/rk3288.dtsi.
You should poke around on the #linux-rockchip IRC channel on freenode.
I think at one point in time Heiko (the upstream Rockchip maintainer)
managed to get virtualization working on Chromebooks by hacking
together the support that's in U-Boot. You might lose some of the
deeper suspend modes of rk3288 with that, but maybe it'd work?
-Doug
On Wed, Oct 14, 2020 at 5:43 PM Sonny Rao <sonn...@chromium.org> wrote:
>
>
> On Wed, Oct 14, 2020 at 4:43 PM Brian Norris <brian...@chromium.org> wrote:
>>
>> On Wed, Oct 14, 2020 at 9:02 AM Jack Rosenthal <jros...@chromium.org> wrote:
>>>
>>> On Wed, Oct 14, 2020 at 2:05 AM Kapil Paranjape <kapil.p...@gmail.com> wrote:
>>>>
>>>> Some questions regarding building for devices like ASUS C100PA.
>>>>
>>>> (This device is a 32-bit arm device which is AUE but many people like me have a working device which we want to keep working with!)
>>>>
>>>> 1. (prompted by an earlier thread) Is it likely that support for AUE devices will be dropped? If so, some suggestions on strategies to keep ChromiumOS going on these devices (basically security updates) for personal use would be appreciated.
>>>
>>>
>>> Google won't be doing any updates or testing of ChromiumOS on AUE devices. Breakages may be introduced, but we keep the overlays around on a "best effort" basis. We can accept patches on Gerrit if you have any fixes.
of veyron. I'm not saying I'll be the one to delete them, but I could
sorta imagine that things with the old "variant" scheme that veyron
uses might break? I guess if it happens someone could try to convert
them over...
>>>> 2. Some hardware support needs files from `/lib/firmware` and `/opt/google/touch` which are on the device. Without going into the legal issues, is there a simple way to ensure that these are copied into the personal builds? (ACCEPT_LICENSE alone does not seem to do it.)
>>>
>>>
>>> Unfortunately, many of these files (or their sources) are in the private overlays due to licensing concerns. You can try copying them out of an official ChromeOS image.
>>
>>
>> For the particular /lib/firmware file in question on that earlier thread, I just moved it to the public overlay:
>> https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/2469298
>> A similar file was already published for other variants long ago:
>> https://chromium.googlesource.com/chromiumos/overlays/board-overlays/+/HEAD/overlay-veyron/chromeos-base/chromeos-bsp-veyron/files/firmware/brcmfmac4354-sdio.txt
>> and it's "just" some text configuration data, so I don't see a problem there.
>>
>> As Jack says though, we can't necessarily do that for all such files.
>>
>> (By the way, the /opt/.../touch firmware files typically aren't necessary -- they're useful for upgrading a device with old touch firmware, but the firmware typically persists to the touch device, so you can get by without it just fine, if you ever ran an official Chrome OS build.)
>>
>>>
>>>
>>>>
>>>>
>>>> Some more ambitious questions!
>>>>
>>>> 3. Will it be possible to incorporate `sommelier` into the build? The "ebuild" seems to have a REQUIRED_USE of `kvm_guest` but should probably not depend on it since it should work without kvm support. Sommelier is useful for locally installed graphical programs.
>>>>
>>>> 4. Since this device now has a 4.14 kernel and can support kvm in the kernel, it seems possible that `kvm_guest` may also be possible! Is it feasible to try to build support for `crostini` or is that something that people have tried and failed?
>>
>>
>> For the record, it's kernel 4.19, not 4.14. But I have a strong suspicion that the underlying CPU (Rockchip RK3288) doesn't actually support virtualization.
>
>
> Yeah there's an issue on RK3288 that could prevent virtualization from working properly out of the box -- it may be possible to fix it but probably not easy.
>
> The issue was that the architectural virtual counters weren't initialized properly and had random values coming out of reset and our firmware doesn't try to initialize them.
> I remember at the time (6 years ago) we decided we weren't going to use virtualization so we would just switch to using the "physical" version of the counters.
>
> It looks like this is accounted for in upstream via the "arm,cpu-registers-not-fw-configured" property in the timer node in arch/arm/boot/dts/rk3288.dtsi.
I think at one point in time Heiko (the upstream Rockchip maintainer)
managed to get virtualization working on Chromebooks by hacking
together the support that's in U-Boot. You might lose some of the
deeper suspend modes of rk3288 with that, but maybe it'd work?
-Doug
Reply all
Reply to author
Forward
0 new messages