Better support for Chromebooks
Chromebooks do have very limited hardware in terms of storage and RAM. But it is still the cheapest solution to a truly open source notebook, as it allows to replace its coreboot based bootloader with your own coreboot and payload (f.e. Tiano Core or Seabios).
By installing a standard proposal of Tumbleweed or Leap with btrfs you will be left with about 2-3 GB of free storage on a 16 GB eMMC storage for installing packages and saving files. In addition to that many features like hibernation, suspend and function buttons (TTY switching) don't work out of the box.
There is a special Ubuntu based distribution for Chromebooks available called "Gallium OS" (https://galliumos.org/). They do have a lot of patches and some neat configuration for XFCE4 to make it perfectly work on Chromebooks by still looking very nice and offering a lot of storage. But you know what it lacks? Correct, some Geeko love ;)
In this project following steps could be done to improve the openSUSE support on Chromebooks:
- port Chromebook specific patches of "Gallium OS" to Factory and upstream them if necessary/possible
- custom setup proposal for Chromebooks in Tumbleweed or a custom Image for Chromebooks
- including a modified XFCE configuration with openSUSE branding
- minimum selection of packages necessary for a proper desktop session (f.e. replace LibreOffice with smaller solutions)
- openSUSE Leap 15 Image for Chromebooks
- including a modified XFCE configuration with openSUSE branding
- minimum selection of packages necessary for a proper desktop session (f.e. replace LibreOffice with smaller solutions)
No Hackers yet
This project is part of:
Hack Week 17
Activity
Comments
-
about 7 years ago by suntorytimed | Reply
I can provide test hardware (Dell Chromebook 11 Education and Asus C200MA) with Coreboot and Tiano Core on it.
-
almost 7 years ago by suntorytimed | Reply
The more I think about it, the more I want to do this as a hacker myself. Too many project ideas but not enough time
Reply to mbrugger
You know that we have support for an arm based chromebook? https://en.opensuse.org/HCL:ARMChromebook ask @algraf for more info
# A First Level Header ## A Second Level Header Use one asterisk to *emphasize* Use two asterisks for **strong emphasis** - Use hyphens - for unordereed - lists This is an [link to example.com](http://example.com/) This is an image  This is a user link @hans This is a project link hw#some-cool-title
-
-
Reply to suntorytimed
The more I think about it, the more I want to do this as a hacker myself. Too many project ideas but not enough time
# A First Level Header ## A Second Level Header Use one asterisk to *emphasize* Use two asterisks for **strong emphasis** - Use hyphens - for unordereed - lists This is an [link to example.com](http://example.com/) This is an image  This is a user link @hans This is a project link hw#some-cool-title
Similar Projects
early stage kdump support by mbrugger
Project Description
When we experience a early boot crash, we are not able to analyze the kernel dump, as user-space wasn't able to load the crash system. The idea is to make the crash system compiled into the host kernel (think of initramfs) so that we can create a kernel dump really early in the boot process.
Goal for the Hackweeks
- Investigate if this is possible and the implications it would have (done in HW21)
- Hack up a PoC (done in HW22 and HW23)
- Prepare RFC series (giving it's only one week, we are entering wishful thinking territory here).
update HW23
- I was able to include the crash kernel into the kernel Image.
- I'll need to find a way to load that from
init/main.c:start_kernel()probably afterkcsan_init() - I workaround for a smoke test was to hack
kexec_file_load()systemcall which has two problems:- My initramfs in the porduction kernel does not have a new enough kexec version, that's not a blocker but where the week ended
- As the crash kernel is part of init.data it will be already stale once I can call
kexec_file_load()from user-space.
The solution is probably to rewrite the POC so that the invocation can be done from init.text (that's my theory) but I'm not sure if I can reuse the kexec infrastructure in the kernel from there, which I rely on heavily.
update HW24
- Day1
- rebased on v6.12 with no problems others then me breaking the config
- setting up a new compilation and qemu/virtme env
- getting desperate as nothing works that used to work
- Day 2
- getting to call the invocation of loading the early kernel from
__initafterkcsan_init()
- getting to call the invocation of loading the early kernel from
Day 3
- fix problem of memdup not being able to alloc so much memory... use 64K page sizes for now
- code refactoring
- I'm now able to load the crash kernel
- When using virtme I can boot into the crash kernel, also it doesn't boot completely (major milestone!), crash in
elfcorehdr_read_notes()
Day 4
- crash systems crashes (no pun intended) in
copy_old_mempage()link; will need to understand elfcorehdr... - call path
vmcore_init() -> parse_crash_elf_headers() -> elfcorehdr_read() -> read_from_oldmem() -> copy_oldmem_page() -> copy_to_iter()
- crash systems crashes (no pun intended) in
Day 5
- hacking
arch/arm64/kernel/crash_dump.c:copy_old_mempage()to see if crash system really starts. It does. - fun fact: retested with more reserved memory and with UEFI FW, host kernel crashes in init but directly starts the crash kernel, so it works (somehow) \o/
- hacking
TODOs
- fix elfcorehdr so that we actually can make use of all this...
- test where in the boot
__init()chain we can/should callkexec_early_dump()