You are not logged in.
sorry didn't mean to be a help vampire. I got the packages installed, rebooted and the touchpad still doesn't work. about to give up. It doesn't even show up under xinput -list
sudo grub-mkconfig - o /boot/grub/grub.cfg
Sun Netra T1 DC200 (x6 cluster) OpenBSD 5.4; Sun Ultra 5 OpenBSD 5.4; Futro S500 FreeBSD 10.0; Chromebook c720 ArchLinux; etc
Offline
@Latrina
Wow had no idea grub controlled devices! ran that and it worked perfectly!
Offline
@masmullin, do you have any plans to update your git repo (https://github.com/masmullin2000/arch-c720p) for compatibility with 3.15.7, or is there no need for you to maintain this now that you are on linux-next?
Offline
@masmullin, do you have any plans to update your git repo (https://github.com/masmullin2000/arch-c720p) for compatibility with 3.15.7, or is there no need for you to maintain this now that you are on linux-next?
Sorry, I've just had difficulties carving off some time. Repo is fixed.
Repo is updated to reflect that Scot's fixes have made it into 3.15.7 (thus, no need to download and apply the patch to the kernel).
3.15 and 3.16 will require patching for the touchpad/touchscreen (if you checkout the 3.16 of the arch-c720p you'll see that I've actually simply got a git-repo rather than patching), so I'll keep the github up to date as best I can.
linux-next requires no changes for the acer c720(p) (HURRAY!). So once Arch rolls around to using 3.17, the distro should run out of the box.
Offline
So i got my C720 last Friday, and for the past two days I've been working through the process of using the vboot utilities to directly boot arch instead of going through seabios. I think i'm close to having something working. For now though i present a vboot-utils PKGBUILD: http://msitton.com/arch/vboot-utils.tar.gz
Last edited by dfanz0r (2014-07-31 01:27:42)
Offline
Very nice! I remember reading that it's technically possible to do, while looking through the Chromium OS documentation, but figured it wasn't currently possible/worth I'm not aware of anyone having done it yet. Seeing as your have a PKGBUILD, this mean we would be able to do all of this from our current Arch installs, right?
Offline
Yeah at this point it should be possible to not be reliant on chrome os to much. So far my first attempt at doing things failed I wanted to try and use EFISTUB as the boot loader. However it seems you cant specify an initrd because it would need to be on the same partition as the kernel. Since chromebooks use this odd way of booting the kernel from a partition all on its own it cannot boot using an initrd.
Might try looking at other options, right now it would basically be limited to compile a kernel that doesn't boot with an initramfs, however i don't know how well this would play with arch. Another option could be booting into a kernel that would kexec the real kernel. I'll continue look for more information though.
Last edited by dfanz0r (2014-07-31 16:36:45)
Offline
[removed]
Last edited by Charlular (2023-10-24 13:51:47)
Offline
Has anyone tried to use coreboot with FILO, instead of depthcharge/verified boot?
Offline
I'm not sure if it's been posted already but some of you may be interested in these ROMs, they are basically custom builds of coreboot with an updated SeaBIOS, giving advantages such as reducing the boot time, removing the dev screen and enabling VMX, you can find more information here. I haven't tried it yet as I'm waiting until September so I can have a full refresh and install this custom ROM and then hopefully easily run Linux 3.16 with the drivers we need in the stable repos alongside Wayland and GNOME 3.14, should be pretty cool! I'll put some of this information in the wiki later.
I didn't know about those ROMs, but i just installed the newest ROM for C720/H14 (the are pretty much the same i guess) and it is working great. No white bootscreen, just straight seabios + grub. And the whole performance seems faster somehow Since tmp is removed, there is no need for the "tpm_tis.force=1 hack" anymore. Suspend works fine, at least when running it manually and waking it up afterwards. The only issue i have, is that it wont go to suspend anymore, when closing the lid. Any ideas about that?
EDIT: ok that was too easy; With the ROM you have to edit the /etc/systemd/logind.conf file and enable suspend with "HandleLidSwitch=suspend"
Last edited by tumas (2014-08-01 07:14:38)
Offline
[removed]
Last edited by Charlular (2023-10-24 13:51:51)
Offline
Nice one! Did you do this from inside Arch with the command
curl -k -L -O https://johnlewis.ie/getnflash_johnlewis_rom.sh; sudo bash getnflash_johnlewis_rom.sh
and if so did you need to specially compile any tools such as flashrom or was everything just fine from the official repositories?
Yes i did the flashing from inside my arch installation. I had to install one additional package (dmidecode i think) which is available from the official repositories. There was one error output which i can't remember exactly, but i did a quick google-search and obviously this error-message is perfectly normal and does not "brick" anything. Anything else just worked without to compile anything.
Offline
I'm not sure if it's been posted already but some of you may be interested in these ROMs, they are basically custom builds of coreboot with an updated SeaBIOS, giving advantages such as reducing the boot time, removing the dev screen and enabling VMX, you can find more information here. I haven't tried it yet as I'm waiting until September so I can have a full refresh and install this custom ROM and then hopefully easily run Linux 3.16 with the drivers we need in the stable repos alongside Wayland and GNOME 3.14, should be pretty cool! I'll put some of this information in the wiki later.
It would be great if someone could compile a custom c720 coreboot rom with ipxe enabled. Unfortunately I don't have access to a bus pirate yet, and therefore I don't feel like taking the risk of temp bricking my c720 due to a bad rom.
Also if the guy who built this custom rom could provide us with the config file, we could simply enable ipxe and rebuild a new rom and everything should be fine without risk of breaking it.
Sun Netra T1 DC200 (x6 cluster) OpenBSD 5.4; Sun Ultra 5 OpenBSD 5.4; Futro S500 FreeBSD 10.0; Chromebook c720 ArchLinux; etc
Offline
Alternatively, if you don't mind using a custom kernel, linux-chromebook provides patches for the touchpad, suspending, and some other fixes.
https://aur.archlinux.org/packages/linux-chromebook
Prebuilt 64-bit packages can be found here.
I downloaded https://aur.archlinux.org/packages/linux-chromebook, unpacked it with tar -xvf and ran makepkg -s in the generated directory 'linux-mainline-chromebook', which created, over 2.5 hours, the following files
linux-3.16-rc7.tar.xz
linux.install.pkg
linux-mainline-chromebook-3.16rc7-1-i686.pkg.tar.xz
linux-mainline-chromebook-docs-3.16rc7-1-i686.pkg.tar.xz
linux-mainline-chromebook-headers-3.16rc7-1-i686.pkg.tar.xz
I then did
pacman -U *.pkg.tar.xz
But evidently I have missed something as
~/linux-mainline-chromebook $ uname -a
Linux a 3.15.5-2-ARCH #1 SMP PREEMPT Fri Jul 11 07:55:51 CEST 2014 i686 GNU/Linux
still shows the original linux version after reboot.
I then tried
pacman -U linux-3.16-rc7.tar.xz
which was rejected and lastly I tried
chmod +x linux.install.pkg
./linux.install.pkg linux-3.16-rc7 linux-3.15-5.2
which raised no objections but produced no effect.
What exactly should I have done?
Offline
[removed]
Last edited by Charlular (2023-10-24 13:51:56)
Offline
I then tried
pacman -U linux-3.16-rc7.tar.xz
which was rejected and lastly I tried
chmod +x linux.install.pkg ./linux.install.pkg linux-3.16-rc7 linux-3.15-5.2
which raised no objections but produced no effect.
What exactly should I have done?
Well if you really only used those commands grub will not know about the new kernel version. You have to regenerate your grub.cfg by running "sudo grub-mkconfig -o /boot/grub/grub.cfg"
Offline
porphyry5,
linux-chromebook et al are custom kernels that don't replace the standard Arch kernel. Do as tumas suggested and make sure to selected it on the Grub screen instead of the standard kernel.
Last edited by SolarBoyMatt (2014-08-01 18:35:43)
Offline
It would be great if someone could compile a custom c720 coreboot rom with ipxe enabled. Unfortunately I don't have access to a bus pirate yet, and therefore I don't feel like taking the risk of temp bricking my c720 due to a bad rom.
Also if the guy who built this custom rom could provide us with the config file, we could simply enable ipxe and rebuild a new rom and everything should be fine without risk of breaking it.
It seems you're a bit ill-informed - there is no "option" as such to enable iPXE in coreboot/SeaBIOS. You simply compile iPXE giving it a ROM name corresponding to the id's of your network card (so that SeaBIOS can find it), and then use cbfstool (part of coreboot Git) to add the iPXE ROM you've just created, to the coreboot CBFS. It is, therefore, pretty risk free, once you're sure that the ROM your modifying won't brick in the first place. There is no need for you to compile your own ROM from scratch. Information on IPXE from coreboot/SeaBIOS is at http://www.coreboot.org/IPXE
I have since spent some time looking at this because I thought it would be really cool if we could use iPXE in Chromebook ROM's to connect to netboot.me and install any distro you like without people faffing with media. The good news is, it's easy to compile iPXE and get it into the existing ROM's. The bad news is there isn't enough room in 128k to enable WPA/WPA2, so you will have to disable security on your wifi router to do anything. The even worse news is that there's no iPXE driver for the AR9462 found in the HP Chromebook 14 (and presumably C720) so it's flat. Not. Going. To. Work.
Again, in the case of the coreboot config, it is already contained within the coreboot CBFS, so you can extract it at will using cbfstool, like so:
cbfstool coreboot-peppy-seabios-310714.rom extract -f coreboot-config -n config
Once you have your config, you will still need to extract the binaries from an existing ROM. Just be aware that if you try to read the ROM from an existing Chromebook, the ME binary will be garbage, and although that won't give you a brick, it will mean your Chromebook switches off after half an hour, if you try to build coreboot using it.
Last edited by jpl888 (2014-08-02 01:12:13)
Offline
Latrina wrote:It would be great if someone could compile a custom c720 coreboot rom with ipxe enabled. Unfortunately I don't have access to a bus pirate yet, and therefore I don't feel like taking the risk of temp bricking my c720 due to a bad rom.
Also if the guy who built this custom rom could provide us with the config file, we could simply enable ipxe and rebuild a new rom and everything should be fine without risk of breaking it.
It seems you're a bit ill-informed - there is no "option" as such to enable iPXE in coreboot/SeaBIOS. You simply compile iPXE giving it a ROM name corresponding to the id's of your network card (so that SeaBIOS can find it), and then use cbfstool (part of coreboot Git) to add the iPXE ROM you've just created, to the coreboot CBFS. It is, therefore, pretty risk free, once you're sure that the ROM your modifying won't brick in the first place. There is no need for you to compile your own ROM from scratch. Information on IPXE from coreboot/SeaBIOS is at http://www.coreboot.org/IPXE
I have since spent some time looking at this because I thought it would be really cool if we could use iPXE in Chromebook ROM's to connect to netboot.me and install any distro you like without people faffing with media. The good news is, it's easy to compile iPXE and get it into the existing ROM's. The bad news is there isn't enough room in 128k to enable WPA/WPA2, so you will have to disable security on your wifi router to do anything. The even worse news is that there's no iPXE driver for the AR9462 found in the HP Chromebook 14 (and presumably C720) so it's flat. Not. Going. To. Work.
Again, in the case of the coreboot config, it is already contained within the coreboot CBFS, so you can extract it at will using cbfstool, like so:
cbfstool coreboot-peppy-seabios-310714.rom extract -f coreboot-config -n config
Once you have your config, you will still need to extract the binaries from an existing ROM. Just be aware that if you try to read the ROM from an existing Chromebook, the ME binary will be garbage, and although that won't give you a brick, it will mean your Chromebook switches off after half an hour, if you try to build coreboot using it.
Thanks for making some great clarifications. Its quite sad to hear we cannot use WPA due to lack of space. However I do have few questions in regards to this.
Would it make any different if I would build ipxe on a usb key? Would I be able to use WPA / WEP in this case?
I do have a USB Alfa 500 rtl818, which by looking at the ipxe source code it seems to be supported under the rtl818x driver. Would I be able to use a usb wireless adapter with ipxe?
Last question, do I need a custom coreboot rom such as the one mentioned above or does it work with the stock one that comes with the chromebook itself?
Thanks.
Sun Netra T1 DC200 (x6 cluster) OpenBSD 5.4; Sun Ultra 5 OpenBSD 5.4; Futro S500 FreeBSD 10.0; Chromebook c720 ArchLinux; etc
Offline
Thanks for making some great clarifications. Its quite sad to hear we cannot use WPA due to lack of space. However I do have few questions in regards to this.
Would it make any different if I would build ipxe on a usb key? Would I be able to use WPA / WEP in this case?
I do have a USB Alfa 500 rtl818, which by looking at the ipxe source code it seems to be supported under the rtl818x driver. Would I be able to use a usb wireless adapter with ipxe?
Last question, do I need a custom coreboot rom such as the one mentioned above or does it work with the stock one that comes with the chromebook itself?
Thanks.
As I understand it, iPXE can only create a 128k ROM (that may be a restriction of the particular network card you're building for), but I encourage you to search around for yourself to confirm that further.
I don't think that iPXE supports USB network cards (at least looking at the info I managed to find the other night). However, a lot of that information was from a couple of years ago, therefore the situation may have changed.
Assuming there is a 128k space in the stock ROM CBFS, you can by all means put the iPXE option ROM in there.
You're welcome.
I'm looking at another way of achieving my goal at the moment, but I don't want to say too much until I (hopefully) have it working.
Offline
I opened an issue at freedesktop.org about the GPU related freezes I'm experiencing.
https://bugs.freedesktop.org/show_bug.cgi?id=82103
Edit: The issue marked as duplicated of https://bugs.freedesktop.org/show_bug.cgi?id=80229
Last edited by dhead (2014-08-04 08:46:36)
Offline
This patch might free us from the need to add either "tpm_tis.force=1" or "tpm_tis.interrupts=0" to the kernel command line in order to enable suspend/resume. Would anyone with any of the chromebooks / chromeboxes be willing to test it? Also, would anyone using TPM "for real" be willing to test it (either using a signed version of chromium or another laptop with TPM enabled)?
The general idea is that the Haswell-based Chromebooks' DSDT indicates that the tpm_tis module should use IRQ 6, but when the module tries to do so we see delays and freezes. So instead of taking the DSDT assertion as fact, we verify that such interrupts are being received, and ignore it if not. This has the same overall effect as setting tpm_tis.interrupts=0, which is enough to enable suspend/resume to work well.
Thanks for any help.
Edit: In order for the patch to work ehci_hcd and ehci_pci must be blacklisted.
diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
index a9ed227..923f9f0 100644
--- a/drivers/char/tpm/tpm_tis.c
+++ b/drivers/char/tpm/tpm_tis.c
@@ -602,12 +602,13 @@ static int tpm_tis_init(struct device *dev, resource_size_t start,
iowrite32(intmask,
chip->vendor.iobase +
TPM_INT_ENABLE(chip->vendor.locality));
- if (interrupts)
- chip->vendor.irq = irq;
- if (interrupts && !chip->vendor.irq) {
- irq_s =
- ioread8(chip->vendor.iobase +
- TPM_INT_VECTOR(chip->vendor.locality));
+ chip->vendor.irq = 0;
+ if (interrupts) {
+ irq_s = irq;
+ if (!irq_s)
+ irq_s =
+ ioread8(chip->vendor.iobase +
+ TPM_INT_VECTOR(chip->vendor.locality));
if (irq_s) {
irq_e = irq_s;
} else {
Last edited by scot14 (2014-08-06 13:34:55)
Offline
Great, thanks Scot. I'll give it a go and add it to linux-chromebook if it works.
EDIT: FWIW Scot, I have tried all of these patches from the last 4 months https://chromium.googlesource.com/chrom … s/char/tpm and they didn't make a difference. Should we use any of them for any other reason?
Last edited by parchedas (2014-08-05 05:01:32)
Offline
Thanks!
I don't think those patches would help anyone that's posted in this thread.
Offline
Charlular wrote:I'm not sure if it's been posted already but some of you may be interested in these ROMs, they are basically custom builds of coreboot with an updated SeaBIOS, giving advantages such as reducing the boot time, removing the dev screen and enabling VMX, you can find more information here. I haven't tried it yet as I'm waiting until September so I can have a full refresh and install this custom ROM and then hopefully easily run Linux 3.16 with the drivers we need in the stable repos alongside Wayland and GNOME 3.14, should be pretty cool! I'll put some of this information in the wiki later.
I didn't know about those ROMs, but i just installed the newest ROM for C720/H14 (the are pretty much the same i guess) and it is working great. No white bootscreen, just straight seabios + grub. And the whole performance seems faster somehow Since tmp is removed, there is no need for the "tpm_tis.force=1 hack" anymore. Suspend works fine, at least when running it manually and waking it up afterwards. The only issue i have, is that it wont go to suspend anymore, when closing the lid. Any ideas about that?
EDIT: ok that was too easy; With the ROM you have to edit the /etc/systemd/logind.conf file and enable suspend with "HandleLidSwitch=suspend"
I have flashed the latest custom coreboot rom for the peppy from the johnlewis.ie website and as you have mentioned I have enabled "HandleLidSwitch=suspend" in /etc/systemd/logind.conf , rebooted the c720 but resume doesn't work still. The system is literally frozen when resuming it from suspension.
This is what I have in /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet add_efi_memmap boot=local noresume noswap i915.modeset=1 nmi_watchdog=panic,lapic"
Have you done anything else to restore lid suspension/resume functionality ?
Thanks
Last edited by Latrina (2014-08-05 13:21:47)
Sun Netra T1 DC200 (x6 cluster) OpenBSD 5.4; Sun Ultra 5 OpenBSD 5.4; Futro S500 FreeBSD 10.0; Chromebook c720 ArchLinux; etc
Offline