Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
On a Samsung ARM Chromebook, could nv-uboot easily boot to stock linux kernels, by way of ARM-GRUB?
149 views
Skip to first unread message
Subharo Bhikkhu
Jan 1, 2014, 9:50:02 AM1/1/14
to
Hello,
Firstly, huge props to the Debian ARM gods who have done so much wonderful work so far, especially Marcin Juszkiewicz, Olof Johansson, Andrew Wafaa, and Jay Lee.
http://ubuntuforums.org/showthread.php?t=2181898
I'm not excited to freshly install Chrubuntu 13.10 either, as the security updates will run out too quickly as well. I want something that will last at least a couple of years!
https://wiki.debian.org/InstallingDebianOn/Samsung/ARMChromebook
The Debian folks are currently stuck on how to boot a stock linux kernel from nv-u-boot:
"Three partitions are created on the disk. In time, the intention is that these be used for:
- a copy of nv-uboot that is chainloaded by the standard firmware,
- a /boot filesystem containing the standard (non-ChromeOS) kernel, read by nv-uboot,
- the root filesystem.
Currently nv-uboot is *not* used, and so the arrangement is:
- a copy of the ChromeOS kernel that is loaded by the standard firmware,
- a /boot filesystem that is used only to contain the ChromeOS kernel (which is not used during booting, just during the preparation of the previous partition),
- the root filesystem."
Also helpful: "Appendix A: Using nv-U-Boot on the Samsung ARM Chromebook":
http://www.chromium.org/chromium-os/u-boot-porting-guide/using-nv-u-boot-on-the-samsung-arm-chromebook
...but nv-U-Boot has several disadvantages listed there (as compared to, say, the much more mature and familiar GRUB).
There is a version of GRUB for ARM: http://sourceforge.net/projects/arm-grub/
Can anybody comment on the feasibility of the following idea?
What if nv-u-boot was used simply to boot to ARM-GRUB, and then GRUB in turn was used to boot from a "normal-looking" selection of stock linux kernels (along with rescue modes, etc.)? For example, GRUB stage 1 (and/or stage 1.5) could be installed to a small GPT partition (instead of the MBR, as is done on pre-UEFI PC's). Then GRUB stage 1 (or 1.5) could in turn boot from a GRUB stage 2, located in a small dedicated /boot ext2 partition (stored along with stock linux kernels, in the way that is familiar to us on PC's). Or maybe GRUB stage 1 (or 1.5) could boot directly to stock linux kernels on an ext4 root partition (with no dedicated /boot partition).
It might sound cumbersome to effectively have 2 boot-loaders, but it might make this whole situation much simpler, as there's *a lot* more GRUB expertise out there (than there is around nv-u-boot). I'm thinking about potentially saving lots of time and manpower, and not caring about squandering a few tens of MB and an unused GPT partition in my internal 16GB eMMC.
What if nv-u-boot was used simply to boot to ARM-GRUB, and then GRUB in turn was used to boot from a "normal-looking" selection of stock linux kernels (along with rescue modes, etc.)? For example, GRUB stage 1 (and/or stage 1.5) could be installed to a small GPT partition (instead of the MBR, as is done on pre-UEFI PC's). Then GRUB stage 1 (or 1.5) could in turn boot from a GRUB stage 2, located in a small dedicated /boot ext2 partition (stored along with stock linux kernels, in the way that is familiar to us on PC's). Or maybe GRUB stage 1 (or 1.5) could boot directly to stock linux kernels on an ext4 root partition (with no dedicated /boot partition).
It might sound cumbersome to effectively have 2 boot-loaders, but it might make this whole situation much simpler, as there's *a lot* more GRUB expertise out there (than there is around nv-u-boot). I'm thinking about potentially saving lots of time and manpower, and not caring about squandering a few tens of MB and an unused GPT partition in my internal 16GB eMMC.
Remember the joke "Internet Explorer is a good Web Browser, for installing a better Web Browser"? Well, perhaps a corollary joke might become "nv-uboot is a good boot-loader, for booting to a better bootloader". ;)
Note: I'm aware of the this tutorial, to install Debian Jesse:
"Replacing Chrome OS with Debian Jessie on the Samsung Series 3 Chromebook":
http://www.neowin.net/forum/topic/1173005-replacing-chrome-os-with-debian-jessie-on-the-samsung-series-3-chromebook/
"Replacing Chrome OS with Debian Jessie on the Samsung Series 3 Chromebook":
http://www.neowin.net/forum/topic/1173005-replacing-chrome-os-with-debian-jessie-on-the-samsung-series-3-chromebook/
...however there are a lot of custom-compiled packages packaged by the author ("Karl L.") that one would need to place a great deal of trust on (both now, and in the future, especially considering the ongoing need for timely security updates). I'd like to rely on something much more "official"-looking (as posted on https://wiki.debian.org/InstallingDebianOn/Samsung/ARMChromebook), whereby all ongoing security updates would ideally "just work" like any regular Debian install.
Any constructive feedback would be most appreciated (especially comments on the maturity of ARM-GRUB, or any "magical" GRUB options and configurations that might help on the Samsung ARM Chromebook).
Cheers,
Subharo
Luke Kenneth Casson Leighton
Jan 1, 2014, 12:10:02 PM1/1/14
to
subharo, hi,
basically you've been caught out by the use of treacherous computing,
and have purchased a product that you cannot and will not ever own.
the samsung processors have bootloader-signing actually built-in to
the ROM: once the e-fuses are fired and the private key installed in
EEPROM there is no way to gain control of the machine short of paying
someone tens of thousands of dollars to have the top taken off the
processor in a class 1 cleanroom and to use lasers to dig around, hunt
for and re-build the e-fuse. and then put the plastic back.
actually, there *might* be a cheaper way: obtain a replacement
processor, pay for the treacherous one to be removed and have the
"stock" one soldered in its place (and then blow the e-fuse which
permanently disables treacherous computing). as this would involve
heating up the board to around 200C and these SoCs have a hell of a
lot of pins it is not without risk.
but, without going down that insane route, you are along the right
kind of lines with loading a 2nd bootloader - one that can then load
an unsigned kernel.
there is potentially a simpler option: you might wish to look at the
kexec option. this would allow you to continue to use the *existing*
kernel - unmodified - purely as a bootloader. there is a userspace
program kicking around which allows selection of kernels (heck, you
could even try using grub in userspace). modify /sbin/init (or other
method) to run that userspace "kernel-selector", then that userspace
kernel-selector-program will kexec the *actual* kernel that you
require, which can, of course, be anything you want.
regarding the custom-compiled packages: yep... tough. that's how
things are in the ARM world. i won't say "get used to it"... instead
i'll say "please *consider* getting used to it" :) there is no BIOS:
*every* kernel is custom-compiled and hard-coded to match the
hardware... which, because there is no BIOS, and all the CPUs are
different *and* all the hardware is different.... you see how that
quickly becomes a complete nightmare?
so.... yeah, if someone's already done custom-compiled packages then
you are very, very lucky.
l.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAPweEDyyfQRgredyzcaVWO8bRqENFq+2=Hnryua9c...@mail.gmail.com
basically you've been caught out by the use of treacherous computing,
and have purchased a product that you cannot and will not ever own.
the samsung processors have bootloader-signing actually built-in to
the ROM: once the e-fuses are fired and the private key installed in
EEPROM there is no way to gain control of the machine short of paying
someone tens of thousands of dollars to have the top taken off the
processor in a class 1 cleanroom and to use lasers to dig around, hunt
for and re-build the e-fuse. and then put the plastic back.
actually, there *might* be a cheaper way: obtain a replacement
processor, pay for the treacherous one to be removed and have the
"stock" one soldered in its place (and then blow the e-fuse which
permanently disables treacherous computing). as this would involve
heating up the board to around 200C and these SoCs have a hell of a
lot of pins it is not without risk.
but, without going down that insane route, you are along the right
kind of lines with loading a 2nd bootloader - one that can then load
an unsigned kernel.
there is potentially a simpler option: you might wish to look at the
kexec option. this would allow you to continue to use the *existing*
kernel - unmodified - purely as a bootloader. there is a userspace
program kicking around which allows selection of kernels (heck, you
could even try using grub in userspace). modify /sbin/init (or other
method) to run that userspace "kernel-selector", then that userspace
kernel-selector-program will kexec the *actual* kernel that you
require, which can, of course, be anything you want.
regarding the custom-compiled packages: yep... tough. that's how
things are in the ARM world. i won't say "get used to it"... instead
i'll say "please *consider* getting used to it" :) there is no BIOS:
*every* kernel is custom-compiled and hard-coded to match the
hardware... which, because there is no BIOS, and all the CPUs are
different *and* all the hardware is different.... you see how that
quickly becomes a complete nightmare?
so.... yeah, if someone's already done custom-compiled packages then
you are very, very lucky.
l.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/CAPweEDyyfQRgredyzcaVWO8bRqENFq+2=Hnryua9c...@mail.gmail.com
David Hicks
Jan 2, 2014, 9:30:01 AM1/2/14
to
Sorry to butt in, but this seems a little strong to me -
"basically you've been caught out by the use of treacherous computing,
and have purchased a product that you cannot and will not ever own.
the samsung processors have bootloader-signing actually built-in to
the ROM: once the e-fuses are fired and the private key installed in
EEPROM there is no way to gain control of the machine short of paying
someone tens of thousands of dollars to have the top taken off the
processor in a class 1 cleanroom and to use lasers to dig around, hunt
for and re-build the e-fuse. and then put the plastic back."
Because you can turn off the checking and boot up pretty much
anything, and if you can boot up a second stage bootloader that's not
signed then the world is your oyster.
I'd agree these devices could be more open, but they aren't locked
down like a console or anything.
Archive: http://lists.debian.org/CAHY+LM71X0q4OvOvV2Z0JynM...@mail.gmail.com
"basically you've been caught out by the use of treacherous computing,
and have purchased a product that you cannot and will not ever own.
the samsung processors have bootloader-signing actually built-in to
the ROM: once the e-fuses are fired and the private key installed in
EEPROM there is no way to gain control of the machine short of paying
someone tens of thousands of dollars to have the top taken off the
processor in a class 1 cleanroom and to use lasers to dig around, hunt
for and re-build the e-fuse. and then put the plastic back."
anything, and if you can boot up a second stage bootloader that's not
signed then the world is your oyster.
I'd agree these devices could be more open, but they aren't locked
down like a console or anything.
Subharo Bhikkhu
Jan 2, 2014, 10:00:01 AM1/2/14
to
Hello Luke,
On Wed, Jan 1, 2014 at 12:09 PM, Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:
subharo, hi,
basically you've been caught out by the use of treacherous computing,
and have purchased a product that you cannot and will not ever own.
the samsung processors have bootloader-signing actually built-in to
the ROM:
I agree with David Hicks. I think Googl (or Samsung) is slightly less evil than you're portraying them, since at least Google supplies the alternate nv-uboot bootloader whatsoever. The "nv" here stands for "non-verified", meaning Google is providing a way to bypass the bootloader signing. They didn't need to do that. I think that linux geeks would probably prefer (instead of nv-uboot) that the alternate "non-verified" bootloader would be GRUB, which is far more feature-rich, and well known than nv-uboot.
Google, are you listening? My 2 cents: Please use GRUB in the future for your bootloader, by default, if you're too cheap to include a Debian-friendly BIOS in your hardware. GRUB is trying to support EFI (at least on AMD64, at present), and there are efforts to bring GRUB into the ARM world. You're reputation for "not being evil" is long gone, IMHO, but perhaps here's a way to try to earn it back.
Google, are you listening? My 2 cents: Please use GRUB in the future for your bootloader, by default, if you're too cheap to include a Debian-friendly BIOS in your hardware. GRUB is trying to support EFI (at least on AMD64, at present), and there are efforts to bring GRUB into the ARM world. You're reputation for "not being evil" is long gone, IMHO, but perhaps here's a way to try to earn it back.
once the e-fuses are fired and the private key installed in
EEPROM there is no way to gain control of the machine short of paying
someone tens of thousands of dollars to have the top taken off the
processor in a class 1 cleanroom and to use lasers to dig around, hunt
for and re-build the e-fuse. and then put the plastic back.
actually, there *might* be a cheaper way: obtain a replacement
processor, pay for the treacherous one to be removed and have the
"stock" one soldered in its place (and then blow the e-fuse which
permanently disables treacherous computing). as this would involve
heating up the board to around 200C and these SoCs have a hell of a
lot of pins it is not without risk.
Your point is taken that "owning" hardware like this (by applying some reasonable, reproducible method) is very, very difficult, and is pretty much only for elite linux geeks to attempt. Scripts like Chrubuntu may help the newbie user get off the ground with a few mere hours of tinkering, but then they'll run into a brick wall later, once it's time to re-install the OS (or they try a dist-upgrade, when virtually nobody has ever QA'ed that that will work well, as is the case for my potential Chrubuntu 13.04 -> Chrubuntu 13.10 upgrade, which I know better than to attempt).
but, without going down that insane route, you are along the right
kind of lines with loading a 2nd bootloader - one that can then load
an unsigned kernel.
there is potentially a simpler option: you might wish to look at the
kexec option. this would allow you to continue to use the *existing*
kernel - unmodified - purely as a bootloader. there is a userspace
program kicking around which allows selection of kernels (heck, you
could even try using grub in userspace). modify /sbin/init (or other
method) to run that userspace "kernel-selector", then that userspace
kernel-selector-program will kexec the *actual* kernel that you
require, which can, of course, be anything you want.
To me, GRUB seems a cleaner approach. It gives the valuable option of booting kernels in recovery modes, which is something that might not be available using your approach. Your approach needs a working kernel, before you can boot other kernels. But what if you have booting problems with that first kernel somehow? Your approach seems vulnerable to a chicken-and-egg problem, should that first kernel somehow not boot. GRUB has lots of available tricks for getting out of those tight jams. Having said that, I'm not feeling up to actually trying to cleanly (and reproducibly) shoehorn GRUB in there. Sorry everyone, for just being "all talk and no action" on this one. I'm feeling too old and battle-scarred for that now.
Before you flame me, at least I did discover something new and useful to contribute, and it's this. If you went the way I did (installing Chrubuntu 13.04 to the internal 16GB eMMC), and you instead want to move to Karl L's *much* cleaner and correct Debian Jesse install, you can at least boot back to ChromeOS first (which is needed *before* following Karl L.'s procedure), by adjusting the GPT partition priorities as follows.
Do this from a terminal, within Chrubuntu:
Do this from a terminal, within Chrubuntu:
sudo cgpt add -i 2 -P 13 -S 1 /dev/mmcblk0
sudo cgpt add -i 4 -P 14 -S 1 /dev/mmcblk0
sudo reboot
sudo reboot
This effectively took me back to ChromeOS.
regarding the custom-compiled packages: yep... tough. that's how
things are in the ARM world. i won't say "get used to it"... instead
i'll say "please *consider* getting used to it" :) there is no BIOS:
*every* kernel is custom-compiled and hard-coded to match the
hardware... which, because there is no BIOS, and all the CPUs are
different *and* all the hardware is different.... you see how that
quickly becomes a complete nightmare?
Indeed. It seems that the Utopian technological future that I was hoping for, where solid state hardware would last *even longer* than non-solid state hardware, has been replaced with a distopian present, where the solid state hardware lasts *even less long* than the non-solid state hardware that came before it, and this planned obsolescence was very intentionally engineered (as you explained with the e-fuses, "verified" bootloader, etc.).
so.... yeah, if someone's already done custom-compiled packages then
you are very, very lucky.
Thanks for helping me to appreciate Karl L.'s work. I'm now on my way to following Karl L's procedure to install Debian Jesse. So this story has a somewhat happy ending.
Cheers,
Subharo Bhikkhu
Luke Kenneth Casson Leighton
Jan 2, 2014, 1:10:04 PM1/2/14
to
On Thu, Jan 2, 2014 at 2:57 PM, Subharo Bhikkhu
<sub...@forestsangha.net> wrote:
> Indeed. It seems that the Utopian technological future that I was hoping for, where solid state hardware would last *even longer* than non-solid state hardware, has been replaced with a distopian present, where the solid state hardware lasts *even less long* than the non-solid state hardware that came before it,
ah if you are referring to NAND flash, that's nothing to do with ARM
<sub...@forestsangha.net> wrote:
> Indeed. It seems that the Utopian technological future that I was hoping for, where solid state hardware would last *even longer* than non-solid state hardware, has been replaced with a distopian present, where the solid state hardware lasts *even less long* than the non-solid state hardware that came before it,
processors and more to do with cost (no moving parts, smaller
devices). the issue with NAND is that the smaller the geometries
become (25nm, 22nm etc.) the less reliable the storage and the more we
end up relying on software and ECC. so it's not *planned*
obsolescence! it's down to the physics :)
but, that _really_ has nothing to do with what type of processor is
in the device.
l.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marcin Juszkiewicz
Jan 2, 2014, 4:40:01 PM1/2/14
to
W dniu 01.01.2014 15:48, Subharo Bhikkhu pisze:
> I have a Samsung ARM Cromebook. I'm running Chrubuntu 13.04 in the
> internal 16GB eMMC.
of booting. If you want to have working easy way then go with nv-uboot way:
- Chromebook boots
- starts U-Boot from write protected SPI flash
- U-Boot displays white screen with info about developer mode
- U-Boot loads "nv" U-Boot from kernel partition
- "nv" U-Boot loads normal unsigned Linux kernel
Other way involves voiding warranty and flashing U-Boot into SPI flash
so steps 3/4 disappear.
If you want to boot into GRUB then you "only" need proper "nv" U-Boot.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/52C5DA9C...@juszkiewicz.com.pl
> I have a Samsung ARM Cromebook. I'm running Chrubuntu 13.04 in the
> internal 16GB eMMC.
> ...but the current problem is that one cannot boot from a stock
> linux kernel. One currently must "borrow" the ChromeOS kernel, and
> "sign" it. I would prefer to have no ongoing dependency on ChromeOS
> if I can help it, and have a Chromebook completely free of ChromeOS
> altogether.
> The Debian folks are currently stuck on how to boot a stock linux
> kernel from nv-u-boot:
So far Chromebook is not supported by Debian so there is no official way
> linux kernel. One currently must "borrow" the ChromeOS kernel, and
> "sign" it. I would prefer to have no ongoing dependency on ChromeOS
> if I can help it, and have a Chromebook completely free of ChromeOS
> altogether.
> The Debian folks are currently stuck on how to boot a stock linux
> kernel from nv-u-boot:
of booting. If you want to have working easy way then go with nv-uboot way:
- Chromebook boots
- starts U-Boot from write protected SPI flash
- U-Boot displays white screen with info about developer mode
- U-Boot loads "nv" U-Boot from kernel partition
- "nv" U-Boot loads normal unsigned Linux kernel
Other way involves voiding warranty and flashing U-Boot into SPI flash
so steps 3/4 disappear.
If you want to boot into GRUB then you "only" need proper "nv" U-Boot.
--
To UNSUBSCRIBE, email to debian-ar...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Subharo Bhikkhu
Jan 4, 2014, 10:00:02 AM1/4/14
to
Hello Luke,
On Thu, Jan 2, 2014 at 1:03 PM, Luke Kenneth Casson Leighton <lk...@lkcl.net> wrote:
On Thu, Jan 2, 2014 at 2:57 PM, Subharo Bhikkhuah if you are referring to NAND flash, that's nothing to do with ARM
<sub...@forestsangha.net> wrote:
> Indeed. It seems that the Utopian technological future that I was hoping for, where solid state hardware would last *even longer* than non-solid state hardware, has been replaced with a distopian present, where the solid state hardware lasts *even less long* than the non-solid state hardware that came before it,
processors and more to do with cost (no moving parts, smaller
devices). the issue with NAND is that the smaller the geometries
become (25nm, 22nm etc.) the less reliable the storage and the more we
end up relying on software and ECC. so it's not *planned*
obsolescence! it's down to the physics :)
I was referring to today's ARM-based smartphones (like iPhones, Android phones) and MP3 players (like iPod touch, and iPads), which *are* solid state, where most of which are difficult or impossible to switch the OS (because they're so heavily locked down, intentionally). I've observed that for many of these, OS updates stop being available within a few years, from the corporations that made them. Furthermore, when the non-user-replaceable rechargeable battery won't hold a charge, most people will just opt for buying a new device (for say, $200-$300), rather than getting the battery factory-replaced (for say, $80, which I observed an iPod Touch battery replacement recently was for an acquaintance of mine, and it only had 60% the capacity of the original battery). It's just about impossible to find an MP3 player or smartphone these days where you can replace the battery yourself. For example, I had a rare Sandisk Sansa e280 MP3 player, and a replacement battery was only $13, and I could easily replace it myself with a small Philips screwdriver.
With PC's (which are almost always *not* all solid state), by contrast, you can keep changing the OS to an increasingly lightweight linux distro/Desktop environment over the years, so it's not hard for an average linux geek to get 7 years or more use out of them.
So non-solid-state stuff ironically seems to generally be the better technology, in the sense of durability over time. The consumer-grade solid-state stuff seems to have an expected lifespan of only 2-3 years.
I'm heartened by developments like the BeagleBone Black, and Raspberry Pi, where it's dead easy to install a different linux OS (like Debian/Raspbian, respectively), but those are just development boards, which are a far cry from resembling a sleek-looking smartphone or a MP3 player.
Cheers,
Subharo
0 new messages