Re: Guix on the ASUS C201PA
> I have a few more changes to the veyron-specific config that were needed > for desktop use I've submitted the kernel, bootloader and example configuration patches as: https://issues.guix.info/issue/34978 live well, vagrant signature.asc Description: PGP signature
Re: Guix on the ASUS C201PA
On 2019-03-23, Ludovic Courtès wrote: > Vagrant Cascadian skribis: >> There's a FIXME for properly fetching the veyron kernel configuration, >> but otherwise it's looking almost like something worth formally >> submitting... ? > > It looks like it! Mark, could you comment on this patch, in particular > the ‘kernel-config-veyron’ bit (see below)? Danny is fine with it. :-) > > It’s great that you managed to simplify this. Then I guess we could add > the example and other useful bits that Timothy had. I feel like just getting a working kernel in guix will make it easier to work on the "bootloader" integration and such, since the kernel is a relatively large build, having to build that in a local branch only, rebase, etc. to keep current ... has it's cost. Although if you want to integrate the depthcharge/bootloader patches too, they do work, though there's no way I know of to implement system generation selection in a bootloader menu. Biggest reason I want to get u-boot working, but no progress on that. I have a few more changes to the veyron-specific config that were needed for desktop use (CONFIG_CGROUP_PERF + related), without which, enabling the desktop caused things like pam calls to fail... The desktop is unfortunately painfully slow. I might not get a chance to submit the updated patches for a few days yet... In theory and ideally, it should be possible to enable the right features in the "regular" linux-libre package, and document the extra modules needed in the initrd, but I have not yet managed to figure out a working combination there. Not sure if it would be better to just wait for that at this point. Now if it were just possible to build libreboot in guix... but since libreboot is essentially it's own system, it would most likely have to re-implement libreboot's build system in guix. live well, vagrant
Re: Guix on the ASUS C201PA
Ludovic Courtès writes: > Vagrant Cascadian skribis: > >> There's a FIXME for properly fetching the veyron kernel configuration, >> but otherwise it's looking almost like something worth formally >> submitting... ? > > It looks like it! Mark, could you comment on this patch, in particular > the 'kernel-config-veyron' bit (see below)? Danny is fine with it. :-) Clearly, our handling of kernel configurations and kernel variants should be redesigned, but this is fine for now. Thanks! Mark
Re: Guix on the ASUS C201PA
Hi Vagrant,
Vagrant Cascadian skribis:
> There's a FIXME for properly fetching the veyron kernel configuration,
> but otherwise it's looking almost like something worth formally
> submitting... ?
It looks like it! Mark, could you comment on this patch, in particular
the ‘kernel-config-veyron’ bit (see below)? Danny is fine with it. :-)
It’s great that you managed to simplify this. Then I guess we could add
the example and other useful bits that Timothy had.
Thank you,
Ludo’.
> From d521904a25ea6146a0641c0929cdb5ac5f486cc8 Mon Sep 17 00:00:00 2001
> From: Vagrant Cascadian
> Date: Mon, 18 Mar 2019 03:24:05 +
> Subject: [PATCH] gnu: Add linux-libre-arm-veyron.
>
> * gnu/packages/linux.scm (linux-libre-arm-veyron): New variable.
> FIXME: Merge with "kernel-config"...
> (kernel-config-veyron): Add function to find veyron kernel config.
> * gnu/packages/aux-files/linux-libre/5.0-arm-veyron.conf
> * Makefile.am (AUX_FILES): Adjust accordingly.
[...]
> --- a/gnu/packages/linux.scm
> +++ b/gnu/packages/linux.scm
> @@ -253,6 +253,15 @@ for ARCH and optionally VARIANT, or #f if there is no
> such configuration."
> (file (string-append "linux-libre/" name)))
> (search-auxiliary-file file)))
>
> +;; FIXME: Merge with "kernel-config"
> +(define* (kernel-config-veyron arch #:key variant)
> + "Return the absolute file name of the Linux-Libre build configuration file
> +for ARCH and optionally VARIANT, or #f if there is no such configuration."
> + (let* ((name (string-append (if variant (string-append variant "-") "")
> + (if (string=? "i386" arch) "i686" arch)
> "-veyron.conf"))
> + (file (string-append "linux-libre/" name)))
> +(search-auxiliary-file file)))
> +
> (define %default-extra-linux-options
>`(;; https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00039.html
> ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #t)
> @@ -471,6 +480,15 @@ It has been modified to remove all non-free binary
> blobs.")
> #:defconfig "multi_v7_defconfig"
> #:extra-version "arm-generic"))
>
> +(define-public linux-libre-arm-veyron
> + (make-linux-libre %linux-libre-version
> +%linux-libre-hash
> +'("armhf-linux")
> +#:patches %linux-libre-5.0-patches
> +;; #:configuration-file (search-auxiliary-file
> "/linux-libre/5.0-arm-veyron.conf")
> +#:configuration-file kernel-config-veyron
> +#:extra-version "arm-veyron"))
> +
> (define-public linux-libre-arm-generic-4.19
>(make-linux-libre %linux-libre-4.19-version
> %linux-libre-4.19-hash
Re: Guix on the ASUS C201PA
Hi, hmm, I'll let Mark comment on the possibility of merging the two configuration-file selectors--but the patch looks good to me regardless. pgprwBQnrXVcG.pgp Description: OpenPGP digital signature
Re: Guix on the ASUS C201PA
On 2019-03-17, Timothy Sample wrote: > Vagrant Cascadian writes: >> With libreboot re-installed, it's working for me as well! > > Hooray! > >> I haven't tried just applying the minimal patches and/or configuration >> on top of Guix's linux-libre, but that seems like a logical next step... > > One thing worth trying might be to turn off the patches in PrawnOS > kernel, to see if they make a difference for booting. I think it is > mostly the configuration that is making the difference. So, I threw away the patches and added a config only slightly updated from the prawnos config and it boots linux-libre 5.0! It's even proven stable enough to recompile the kernel on the c201 itself... Working for me: keyboard framebuffer console usb cpufreq battery status backlight There's a FIXME for properly fetching the veyron kernel configuration, but otherwise it's looking almost like something worth formally submitting... ? Even more ideal would be figuring out how to use the regular linux-libre package; it might be as simple as just documenting additional modules needed in the initramfs and enabling a few configuration options/modules in the kernel config. To properly make use of it also depends on the depthcharge "bootloader" patches, and the example asus-c201.cfg.tmpl. live well, vagrant From d521904a25ea6146a0641c0929cdb5ac5f486cc8 Mon Sep 17 00:00:00 2001 From: Vagrant Cascadian Date: Mon, 18 Mar 2019 03:24:05 + Subject: [PATCH] gnu: Add linux-libre-arm-veyron. * gnu/packages/linux.scm (linux-libre-arm-veyron): New variable. FIXME: Merge with "kernel-config"... (kernel-config-veyron): Add function to find veyron kernel config. * gnu/packages/aux-files/linux-libre/5.0-arm-veyron.conf * Makefile.am (AUX_FILES): Adjust accordingly. --- Makefile.am |1 + .../aux-files/linux-libre/5.0-arm-veyron.conf | 4351 + gnu/packages/linux.scm| 18 + 3 files changed, 4370 insertions(+) create mode 100644 gnu/packages/aux-files/linux-libre/5.0-arm-veyron.conf diff --git a/Makefile.am b/Makefile.am index e7109ec69c..49f92a5f7b 100644 --- a/Makefile.am +++ b/Makefile.am @@ -284,6 +284,7 @@ AUX_FILES = \ gnu/packages/aux-files/chromium/master-preferences.json \ gnu/packages/aux-files/emacs/guix-emacs.el \ gnu/packages/aux-files/linux-libre/5.0-arm.conf \ + gnu/packages/aux-files/linux-libre/5.0-arm-veyron.conf \ gnu/packages/aux-files/linux-libre/5.0-arm64.conf \ gnu/packages/aux-files/linux-libre/5.0-i686.conf \ gnu/packages/aux-files/linux-libre/5.0-x86_64.conf \ diff --git a/gnu/packages/aux-files/linux-libre/5.0-arm-veyron.conf b/gnu/packages/aux-files/linux-libre/5.0-arm-veyron.conf new file mode 100644 index 00..2852c4e9d8 --- /dev/null +++ b/gnu/packages/aux-files/linux-libre/5.0-arm-veyron.conf @@ -0,0 +1,4351 @@ +# +# Automatically generated file; DO NOT EDIT. +# Linux/arm 4.17.19-gnu Kernel Configuration +# +CONFIG_ARM=y +CONFIG_ARM_HAS_SG_CHAIN=y +CONFIG_NEED_SG_DMA_LENGTH=y +CONFIG_ARM_DMA_USE_IOMMU=y +CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8 +CONFIG_MIGHT_HAVE_PCI=y +CONFIG_SYS_SUPPORTS_APM_EMULATION=y +CONFIG_HAVE_PROC_CPU=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +CONFIG_RWSEM_XCHGADD_ALGORITHM=y +CONFIG_FIX_EARLYCON_MEM=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_ZONE_DMA=y +CONFIG_NEED_DMA_MAP_STATE=y +CONFIG_ARCH_SUPPORTS_UPROBES=y +CONFIG_ARM_PATCH_PHYS_VIRT=y +CONFIG_GENERIC_BUG=y +CONFIG_PGTABLE_LEVELS=3 +CONFIG_IRQ_WORK=y +CONFIG_BUILDTIME_EXTABLE_SORT=y + +# +# General setup +# +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_CROSS_COMPILE="" +# CONFIG_COMPILE_TEST is not set +CONFIG_LOCALVERSION="" +# CONFIG_LOCALVERSION_AUTO is not set +CONFIG_HAVE_KERNEL_GZIP=y +CONFIG_HAVE_KERNEL_LZMA=y +CONFIG_HAVE_KERNEL_XZ=y +CONFIG_HAVE_KERNEL_LZO=y +CONFIG_HAVE_KERNEL_LZ4=y +# CONFIG_KERNEL_GZIP is not set +# CONFIG_KERNEL_LZMA is not set +CONFIG_KERNEL_XZ=y +# CONFIG_KERNEL_LZO is not set +# CONFIG_KERNEL_LZ4 is not set +CONFIG_DEFAULT_HOSTNAME="debsus" +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +CONFIG_SYSVIPC_SYSCTL=y +CONFIG_POSIX_MQUEUE=y +CONFIG_POSIX_MQUEUE_SYSCTL=y +CONFIG_CROSS_MEMORY_ATTACH=y +# CONFIG_USELIB is not set +# CONFIG_AUDIT is not set +CONFIG_HAVE_ARCH_AUDITSYSCALL=y + +# +# IRQ subsystem +# +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_GENERIC_IRQ_SHOW=y +CONFIG_GENERIC_IRQ_SHOW_LEVEL=y +CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y +CONFIG_HARDIRQS_SW_RESEND=y +CONFIG_GENERIC_IRQ_CHIP=y +CONFIG_IRQ_DOMAIN=y +CONFIG_IRQ_DOMAIN_HIERARCHY=y +CONFIG_HANDLE_DOMAIN_IRQ=y +CONFIG_IRQ_FORCED_THREADING=y +CONFIG_SPARSE_IRQ=y +# CONFIG_GENERIC_IRQ_DEBUGFS is not set +CONFIG_ARCH_CLOCKSOURCE_DATA=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_ARCH_HAS_TICK_BROADCAST=y +CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y + +# +# Timers subsystem +# +CONFIG_TICK_ONESHOT=y +CONFIG_NO_HZ_COMMON=y +# CONFIG_HZ_PERIODIC
Re: Guix on the ASUS C201PA
Vagrant Cascadian writes:
> With libreboot re-installed, it's working for me as well!
Hooray!
> I haven't tried just applying the minimal patches and/or configuration
> on top of Guix's linux-libre, but that seems like a logical next step...
One thing worth trying might be to turn off the patches in PrawnOS
kernel, to see if they make a difference for booting. I think it is
mostly the configuration that is making the difference.
Also, I wrote a little script (see attached) that looks for semantic
differences in kernel configuration files. I’ll attach it in case you
could use it. My approach was to compare the PrawnOS and Arch Linux ARM
configurations against the Guix one, and find things that former two
have in common that Guix lacks. To this end, you can run
guile --no-auto-compile kconfig.scm guix.cfg prawnos.cfg alarm.cfg
and it should tell you all the things that both the working
configurations explicitly enable (either as “m” or “y”) that Guix does
not. (I found the output a little cleaner than using “diff”, “sort”,
and friends.)
(use-modules (ice-9 match)
(ice-9 rdelim))
(define (read-config path)
(call-with-input-file path
(lambda (port)
(let loop ((line (read-line port)) (acc '()))
(if (eof-object? line)
acc
(match (string-split line #\=)
((key-part value-part)
(let ((key (string->symbol key-part))
(value (match value-part
("y" #t)
("n" #f)
("m" 'm)
((? (lambda (x) (string-prefix? "0x" x)))
(string->number (substring value-part 2) 16))
(_ (call-with-input-string value-part read)
(loop (read-line port) (cons `(,key . ,value) acc
(_ (loop (read-line port) acc
(define (kequal? a b)
(or (equal? a b)
(and (memq a '(m #t))
(memq b '(m #t)
(match (program-arguments)
((_ p1 p2 p3)
(let ((c1 (read-config p1))
(c2 (read-config p2))
(c3 (read-config p3)))
(for-each (match-lambda
((k2 . v2)
(let ((v1 (match (assq k2 c1)
((_ . v1) v1)
(#f 'nil)))
(v3 (match (assq k2 c3)
((_ . v3) v3)
(#f 'nil
(unless (or (kequal? v1 v2)
(kequal? v1 v3))
(write `(,k2 ,v1 -> ,v2 / ,v3))
(newline)
c2
>> I did manage to get the rockchip.usb_uart with a hacked up USB cable to
>> produce a serial console for debugging and actually seeing the kernel
>> logs rather than them scrolling pass the screen only to give a kernel
>> panic.
>>
>> (kernel-arguments '("console=ttyS2,115200" "rockchip.usb_uart"))
>
> To be clear, this feature doesn't actually make a serial console over
> USB, it somehow "rewires" one of the USB ports to have a ground, rx and
> tx serial-ttl pinout. So you pretty much need a custom USB-A plug and
> solder/crimp the bare wires to a serial-ttl adapter. Slightly more
> details in Documentation/admin-guide/kernel-parameters.txt.
I made one of these cables, but wasn’t sure if it worked, and I didn’t
know what settings I needed in the kernel to make it work. Thanks for
figuring this out! I hope that it gives you a nicer way to debug the
kernel when it boots to a white screen.
Thanks for testing and working on this.
-- Tim
Re: Guix on the ASUS C201PA
On 2019-03-09, Vagrant Cascadian wrote:
> On 2019-03-06, Timothy Sample wrote:
>> Vagrant Cascadian writes:
>>> On 2019-03-06, Timothy Sample wrote:
I was able to get Guix to boot on an ASUS Chromebook C201PA.
>
> So, I've gotten the kernel to load, but the version of coreboot and/or
> depthcharge I have installed seems to ignore the presence of the initrd
> (which you had mentioned in your initial mail). I guess I should try
> libreboot again, maybe it fixed some other things too...
With libreboot re-installed, it's working for me as well!
I haven't tried just applying the minimal patches and/or configuration
on top of Guix's linux-libre, but that seems like a logical next step...
> I did manage to get the rockchip.usb_uart with a hacked up USB cable to
> produce a serial console for debugging and actually seeing the kernel
> logs rather than them scrolling pass the screen only to give a kernel
> panic.
>
> (kernel-arguments '("console=ttyS2,115200" "rockchip.usb_uart"))
To be clear, this feature doesn't actually make a serial console over
USB, it somehow "rewires" one of the USB ports to have a ground, rx and
tx serial-ttl pinout. So you pretty much need a custom USB-A plug and
solder/crimp the bare wires to a serial-ttl adapter. Slightly more
details in Documentation/admin-guide/kernel-parameters.txt.
live well,
vagrant
signature.asc
Description: PGP signature
Re: Guix on the ASUS C201PA
Hi, Ludovic Courtès writes: > Hello! > > Timothy Sample skribis: > >> I was able to get Guix to boot on an ASUS Chromebook C201PA. This model >> of computer is pretty neat. It’s an ARMv7 (32-bit) machine that can be >> run with entirely free software. There is even a free graphics driver >> in the works [1]. >> >> I’ve attached a (messy) patch that adds a (hacky) bootloader definition >> for Depthcharge and a Linux-Libre package that works on the machine >> (using an unsupported version of Linux-Libre). All those parenthetical >> comments are supposed to suggest that this work is not really finished. >> Now that the computer runs Guix, it should be straight-forward (if time >> consuming) to fix some of these problems and arrive at something nice. > > Impressive work! Thanks! > The patch is really not what I expected given the qualifiers you gave > above. :-) It could use more comments to explain what’s going on but > apart from that it looks rather clean to my eyes. > > What do you think would be the best course of action to integrate it? > Wait for Vagrant to test it and fix a couple of things? ;-) Or…? On the bootloader side, if you are okay with the way it works, then it is fine. I would just add some comments. Most importantly, I would want to write somewhere that it is okay for the bootloader installer to make use of the configuration file. Beyond that, there are some improvements that could be made, but they can come later. For instance, we could automatically roll-back one generation if booting fails. For the kernel, the patch currently uses an unsupported version of Linux-Libre, which is not great. I checked that we can switch to the 4.19 version developed by the PrawnOS project. However, they say that Wi-Fi is broken on that branch (I don’t have a dongle yet, so I don’t know). Parabola has a working 5.0 kernel, but I’ve found that their configuration is not as reliable as the PrawnOS one (it fails to boot sometimes). Ideally, we could figure out which configuration options and patches are necessary and just augment what we already do, rather than having a completely separate kernel package. I’ve tried getting there by trial and error, but that’s exhausting. I’m hoping Vagrant’s setup with the USB serial console will help, but I haven’t tried it yet. In short, I would rather not rely so closely on what PrawnOS is doing. It would be better to follow their approach loosely while using our own kernel versions and configurations. Does that make sense? -- Tim
Re: Guix on the ASUS C201PA
Hello! Timothy Sample skribis: > I was able to get Guix to boot on an ASUS Chromebook C201PA. This model > of computer is pretty neat. It’s an ARMv7 (32-bit) machine that can be > run with entirely free software. There is even a free graphics driver > in the works [1]. > > I’ve attached a (messy) patch that adds a (hacky) bootloader definition > for Depthcharge and a Linux-Libre package that works on the machine > (using an unsupported version of Linux-Libre). All those parenthetical > comments are supposed to suggest that this work is not really finished. > Now that the computer runs Guix, it should be straight-forward (if time > consuming) to fix some of these problems and arrive at something nice. Impressive work! The patch is really not what I expected given the qualifiers you gave above. :-) It could use more comments to explain what’s going on but apart from that it looks rather clean to my eyes. What do you think would be the best course of action to integrate it? Wait for Vagrant to test it and fix a couple of things? ;-) Or…? Thank you, Ludo’.
Re: Guix on the ASUS C201PA
On 2019-03-06, Timothy Sample wrote:
> Vagrant Cascadian writes:
>> On 2019-03-06, Timothy Sample wrote:
>>> I was able to get Guix to boot on an ASUS Chromebook C201PA.
So, I've gotten the kernel to load, but the version of coreboot and/or
depthcharge I have installed seems to ignore the presence of the initrd
(which you had mentioned in your initial mail). I guess I should try
libreboot again, maybe it fixed some other things too...
I did manage to get the rockchip.usb_uart with a hacked up USB cable to
produce a serial console for debugging and actually seeing the kernel
logs rather than them scrolling pass the screen only to give a kernel
panic.
(kernel-arguments '("console=ttyS2,115200" "rockchip.usb_uart"))
Anyone had any luck booting GuixSD without an initrd? I sort of thought
about dumping the initramfs to a partition and trying to work around it
that way...
I've also got patches to pull in u-boot 2019.04-rc3 with a
chromebook_speedy target for installing directly to flash, as well as
one to load from depthcharge. Unfortunately, I still get no
video. Someone's working on porting rockchip.usb_uart to u-boot to make
it easier to see what's going on. Mostly hoping to just get u-boot
support working and forget about depthcharge.
>> I have two big technical frustrations with Depthcharge:
>>
>> It's really hard to debug or select alternate kernels when boot is
>> failing.
>>
>> The kernel+initrd is limited to ~16MB. linux-libre on armhf is about
>> 5MB, and the initrd around 11MB... so it's running pretty close to that
>> limit (Debian initrd's are even larger these days). I even increased the
>> size of the partition to 32MB to see if it would work, but it refused to
>> boot from anything larger than 16MB.
>
> I didn’t know about the image size limit. Guix (with the very spartan
> PrawnOS kernel build) is only 14M, so I guess I was just lucky here.
This may have just been the older libreboot build I once had; I notice
that prawn-os and gentoo seem to work fine with 32MB/64MB kernel boot
partitions. Or maybe some other misunderstanding on my part about why
depthcharge refused to boot it... just now starting to grasp all those
"cgpt" partitioning flags.
live well,
vagrant
signature.asc
Description: PGP signature
Re: Guix on the ASUS C201PA
Parabola made an announcement in December last year: "Parabola officially supports librebooted Asus Chromebook C201". https://www.parabola.nu/news/parabola-officially-supports-librebooted-asus-chromebook-c201/ The announcement includes links which may be helpful.
Re: Guix on the ASUS C201PA
Hi Vagrant, Vagrant Cascadian writes: > On 2019-03-06, Timothy Sample wrote: >> I was able to get Guix to boot on an ASUS Chromebook C201PA. This model >> of computer is pretty neat. It’s an ARMv7 (32-bit) machine that can be >> run with entirely free software. There is even a free graphics driver >> in the works [1]. > > Very excited to try this! > > I've been working on getting Debian to work on it for years, and had it > working with linux 4.8.x... and then haven't gotten it working with any > kernel version since. I've very recently been trying to get Archlinux > and Parabola working on it, but haven't gotten very far yet... Arch Linux ARM worked well enough for me. It even boots from stock Google firmware. It was the system I used to build Guix. I assume that Parabola would be similar. >> For the bootloader, these machines use Depthcharge. Depthcharge boots a >> specially packaged and signed kernel image from a specially marked >> partition. This kernel image is written to the partition directly >> without a file system. > > I have two big technical frustrations with Depthcharge: > > It's really hard to debug or select alternate kernels when boot is > failing. > > The kernel+initrd is limited to ~16MB. linux-libre on armhf is about > 5MB, and the initrd around 11MB... so it's running pretty close to that > limit (Debian initrd's are even larger these days). I even increased the > size of the partition to 32MB to see if it would work, but it refused to > boot from anything larger than 16MB. I didn’t know about the image size limit. Guix (with the very spartan PrawnOS kernel build) is only 14M, so I guess I was just lucky here. It might be worth trying to better mimic what Google does with ChromeOS. That is, you could lay out the disk as follows. p1. kernel-a p2. initrd-a p3. kernel-b p4. initrd-b p5. root If you could get initrd to run correctly from a separate partition, then you could both make use of Depthcharge’s fall-back feature and avoid the size limitation. In Guix, we could toggle which kernel and initrd partition we write to and set the boot priorities appropriately. This would allow one to fearlessly run “guix system reconfigure”. > [...] > > Thanks for working on it, and I'll try it out and report back. Good luck! -- Tim
Re: Guix on the ASUS C201PA
Thanks a lot for sharing this -- Sent from my k-9 mail for Android.
Re: Guix on the ASUS C201PA
On 2019-03-06, Timothy Sample wrote: > I was able to get Guix to boot on an ASUS Chromebook C201PA. This model > of computer is pretty neat. It’s an ARMv7 (32-bit) machine that can be > run with entirely free software. There is even a free graphics driver > in the works [1]. Very excited to try this! I've been working on getting Debian to work on it for years, and had it working with linux 4.8.x... and then haven't gotten it working with any kernel version since. I've very recently been trying to get Archlinux and Parabola working on it, but haven't gotten very far yet... > For the bootloader, these machines use Depthcharge. Depthcharge boots a > specially packaged and signed kernel image from a specially marked > partition. This kernel image is written to the partition directly > without a file system. I have two big technical frustrations with Depthcharge: It's really hard to debug or select alternate kernels when boot is failing. The kernel+initrd is limited to ~16MB. linux-libre on armhf is about 5MB, and the initrd around 11MB... so it's running pretty close to that limit (Debian initrd's are even larger these days). I even increased the size of the partition to 32MB to see if it would work, but it refused to boot from anything larger than 16MB. > There may be a way to improve this by bringing U-Boot into the booting > process. The next version of U-Boot (to be released in April) will > support this machine directly. My recent renewed interest is actually to test the chromebook_speedy u-boot target included upstream... but the LCD doesn't work with my particular C201PA, and there's no simple to access serial console, so apparently not all variants are supported yet; am working with the person who added support to u-boot to get that fixed, though. > Alternatively, if using U-Boot directly causes problems, it’s possible > that Depthcharge could boot into U-Boot. That would be interesting to get working, though I'm not sure that's supported in the current chromebook_speedy target in u-boot. Would be easier to test (u-boot should fit in 16MB just fine for the forseeable future!). Thanks for working on it, and I'll try it out and report back. live well, vagrant signature.asc Description: PGP signature
