From Fedora Project Wiki

 
(5 intermediate revisions by the same user not shown)
Line 3: Line 3:
I have mostly questions and only a few answers.
I have mostly questions and only a few answers.


Fedora 25 includes the dtb for this model: rk3288-veyron-speedy.dtb
* Fedora 25 includes the dtb for this model: rk3288-veyron-speedy.dtb
* As best I can tell from my research, the boot system on this chrome book is called "Depthcharge".
* Holding down the power button resets the chromebook after a boot attempt hangs.


If I wrap uImage or vmlinuz-4.. with
Apparently, it reads the kernel packed by vbutil_kernel --pack, verifies the signature, and transfers control to the kernel.  The bootloader doesn't seem to be used - it seems to be all zero on the factory boot partitions.  I don't know what the fedora kernel is missing - there is no output at all.


  vbutil_kernel --pack fedora.blob --keyblock fedora.keyblock --signprivate fedora.vbprivk \
Examining the ChromeOS kernel reveals a FIT image, so I created rk3288.its:
--version 4 --vmlinuz vmlinuz-4.8.6*  --config kcmdline --bootloader=dummy.boot --arch arm


then Booting in developer mode with Ctrl-U gets a blank screen and hangs - with just zero in part 1 and 2, it says it can't find a kernel. So the firmware is loading the image.
  /dts-v1/;
 
  / {
      description = "Fedora 25 kernel-4.8.6-300 for ASUS C201PA Chromebook";
      #address-cells = <1>;
      images {
          kernel@1{
              description = "vmlinuz-4.8.6";
              data = /incbin/("vmlinuz-4.8.6-300.fc25.armv7hl");
              type = "kernel_noload";
              arch = "arm";
              os = "linux";
              compression = "none";
              load = <0>;
              entry = <0>;
          };
          fdt@1{
              description = "rk3288-veyron-speedy";
              data = /incbin/("dtb-4.8.6-300.fc25.armv7hl/rk3288-veyron-speedy.dtb");
              type = "flat_dt";
              arch = "arm";
              compression = "none";
          };
      };
      configurations {
          default = "conf@1";
          conf@1{
              description = "rk3288-veyron-speedy (ASUS C201PA Chromebook)";
              kernel = "kernel@1";
              fdt = "fdt@1";
          };
      };
    };


How does initrd get loaded?  Doesn't uImage already incorporate the itb (compiled from its) and include all the platforms in the dtb-* directory?
and compiled (in the distro /boot directory) with:


Holding down the power button resets the chromebook after a boot attempt hangs.
  mkimage -vf rk3288.its rk3288.itb


I best I can tell from my research, the boot system on this chrome book is called "Depthcharge"Apparently, it reads the kernel packed by vbutil_kernel --pack, verifies the signature, and transfers control to the kernel.  The bootloader doesn't seem to be used - it seems to be all zero on the factory boot partitions.  I don't know what the fedora kernel is missing - there is no output at all.
I wrapped the FIT image with:
  vbutil_kernel --pack        fedora.blob \
                --keyblock    fedora.keyblock    \
                --signprivate fedora.vbprivk    \
                --config      kcmdline          \
                --vmlinuz    rk3288.itb        \
                --bootloader  dummy.boot        \
                --arch arm --version 1
 
Where dummy.boot is 4k of zeros to match google kernelThis is a similar size
to factory ChromeOS kernel imageNow to see if it gets any farther.  I still
don't see how initrd gets loaded.
 
So, I tried expanding the FIT image to include initrd:
 
  /dts-v1/;
 
  / {
      description = "Fedora 25 kernel-4.8.6-300 for ASUS C201PA Chromebook";
      #address-cells = <1>;
      images {
          kernel@1{
              description = "vmlinuz-4.8.6";
              data = /incbin/("vmlinuz-4.8.6-300.fc25.armv7hl");
              type = "kernel_noload";
              arch = "arm";
              os = "linux";
              compression = "none";
              load = <0>;
              entry = <0>;
          };
          ramdisk@1 {
              description = "recovery ramdisk";
              data = /incbin/("initramfs-4.8.6-300.fc25.armv7hl.img");
              type = "ramdisk";
              arch = "arm";
              os = "linux";
              compression = "gzip";
              load = <00000000>;
              entry = <00000000>;
              hash@1 {
              algo = "sha1";
              };
          };
          fdt@1{
              description = "rk3288-veyron-speedy";
              data = /incbin/("dtb-4.8.6-300.fc25.armv7hl/rk3288-veyron-speedy.dtb");
              type = "flat_dt";
              arch = "arm";
              compression = "none";
          };
      };
      configurations {
          default = "conf@1";
          conf@1{
              description = "rk3288-veyron-speedy (ASUS C201PA Chromebook)";
              kernel = "kernel@1";
              ramdisk = "ramdisk@1";
              fdt = "fdt@1";
          };
      };
    };
 
I also had to expand the boot partitions to hold the 48M image.  Still no joy.


== Wrapping uboot as "kernel" ==
== Wrapping uboot as "kernel" ==


This page mentions wrapping uboot as a kernel so that the chrome book will boot like a raspberry pi.  Where does one get uboot to wrap?
This page mentions wrapping uboot as a kernel so that the chrome book will boot like a raspberry pi.  Where does one get uboot to wrap?
== ASUS C201PA  Arm Chromebook debug console ==
The rockchip supports a debug console, and the Fedora kernel support the
[http://www.spinics.net/lists/arm-kernel/msg485122.html debug console] -
which would greatly help in seeing what is going wrong at boot.
The debug console is pinned out to one of the USB ports (or to the
micro-mmc slot for rk3128).  Either way requires a custom cable, and provides
3V serial TTL.  A 3V TTL serial to USB serial converter
[https://www.pi-supply.com/product/usb-ttl-serial-cable-debug-console-cable-raspberry-pi/ like this]
[https://www.amazon.com/JBtek-WINDOWS-Supported-Raspberry-Programming/dp/B00QT7LQ88/ or this] could be spliced to another sacrificial USB-A cable.

Latest revision as of 21:02, 15 March 2017

ASUS C201PA ARM Chromebook

I have mostly questions and only a few answers.

  • Fedora 25 includes the dtb for this model: rk3288-veyron-speedy.dtb
  • As best I can tell from my research, the boot system on this chrome book is called "Depthcharge".
  • Holding down the power button resets the chromebook after a boot attempt hangs.

Apparently, it reads the kernel packed by vbutil_kernel --pack, verifies the signature, and transfers control to the kernel. The bootloader doesn't seem to be used - it seems to be all zero on the factory boot partitions. I don't know what the fedora kernel is missing - there is no output at all.

Examining the ChromeOS kernel reveals a FIT image, so I created rk3288.its:

 /dts-v1/;
 
 / {
     description = "Fedora 25 kernel-4.8.6-300 for ASUS C201PA Chromebook";
     #address-cells = <1>;
     images {
         kernel@1{
             description = "vmlinuz-4.8.6";
             data = /incbin/("vmlinuz-4.8.6-300.fc25.armv7hl");
             type = "kernel_noload";
             arch = "arm";
             os = "linux";
             compression = "none";
             load = <0>;
             entry = <0>;
         };
         fdt@1{
             description = "rk3288-veyron-speedy";
             data = /incbin/("dtb-4.8.6-300.fc25.armv7hl/rk3288-veyron-speedy.dtb");
             type = "flat_dt";
             arch = "arm";
             compression = "none";
         };
     };
     configurations {
         default = "conf@1";
         conf@1{
             description = "rk3288-veyron-speedy (ASUS C201PA Chromebook)";
             kernel = "kernel@1";
             fdt = "fdt@1";
         };
     };
   };

and compiled (in the distro /boot directory) with:

 mkimage -vf rk3288.its rk3288.itb

I wrapped the FIT image with:

 vbutil_kernel --pack        fedora.blob \
               --keyblock    fedora.keyblock    \
               --signprivate fedora.vbprivk     \
               --config      kcmdline           \
               --vmlinuz     rk3288.itb         \
               --bootloader  dummy.boot         \
               --arch arm --version 1

Where dummy.boot is 4k of zeros to match google kernel. This is a similar size to factory ChromeOS kernel image. Now to see if it gets any farther. I still don't see how initrd gets loaded.

So, I tried expanding the FIT image to include initrd:

 /dts-v1/;
 / {
     description = "Fedora 25 kernel-4.8.6-300 for ASUS C201PA Chromebook";
     #address-cells = <1>;
     images {
         kernel@1{
             description = "vmlinuz-4.8.6";
             data = /incbin/("vmlinuz-4.8.6-300.fc25.armv7hl");
             type = "kernel_noload";
             arch = "arm";
             os = "linux";
             compression = "none";
             load = <0>;
             entry = <0>;
         };
         ramdisk@1 {
             description = "recovery ramdisk";
             data = /incbin/("initramfs-4.8.6-300.fc25.armv7hl.img");
             type = "ramdisk";
             arch = "arm";
             os = "linux";
             compression = "gzip";
             load = <00000000>;
             entry = <00000000>;
             hash@1 {
             algo = "sha1";
             };
         };
         fdt@1{
             description = "rk3288-veyron-speedy";
             data = /incbin/("dtb-4.8.6-300.fc25.armv7hl/rk3288-veyron-speedy.dtb");
             type = "flat_dt";
             arch = "arm";
             compression = "none";
         };
     };
     configurations {
         default = "conf@1";
         conf@1{
             description = "rk3288-veyron-speedy (ASUS C201PA Chromebook)";
             kernel = "kernel@1";
             ramdisk = "ramdisk@1";
             fdt = "fdt@1";
         };
     };
   };

I also had to expand the boot partitions to hold the 48M image. Still no joy.

Wrapping uboot as "kernel"

This page mentions wrapping uboot as a kernel so that the chrome book will boot like a raspberry pi. Where does one get uboot to wrap?

ASUS C201PA Arm Chromebook debug console

The rockchip supports a debug console, and the Fedora kernel support the debug console - which would greatly help in seeing what is going wrong at boot. The debug console is pinned out to one of the USB ports (or to the micro-mmc slot for rk3128). Either way requires a custom cable, and provides 3V serial TTL. A 3V TTL serial to USB serial converter like this or this could be spliced to another sacrificial USB-A cable.