Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't install Fedora with Legacy RW #2

Closed
jeremy447 opened this issue Apr 28, 2016 · 17 comments
Closed

Can't install Fedora with Legacy RW #2

jeremy447 opened this issue Apr 28, 2016 · 17 comments

Comments

@jeremy447
Copy link

Hello Matt,

I can't install Fedora with Legacy RW on my Falco. The live USB boot to the bootloader, I select to start Fedora and one or two seconds later it reboots. There is an issue opened against Fedora but it's not really active and I don't know if it's a Fedora or firmware problem.

https://bugzilla.redhat.com/show_bug.cgi?id=1135793

Thanks !

@MrChromebox
Copy link
Owner

@Paviluf have you tried using the 'mem=1952M' parameter? There's a known issue with some versions of the syslinux bootloader and the stock ChromeOS firmware on Haswell (and Broadwell?) devices. Depending on how your boot media was created, sometimes writing the iso directly to USB (via dd or Win32DiskImager) can work around the issue. If you're not going to dual boot / run ChromeOS, then flashing the full firmware will also fix the issue.

@jeremy447
Copy link
Author

jeremy447 commented Apr 28, 2016

I already tried using the 'mem=1952M' parameter but that doesn't work. I wrote the ISO directly to USB with Gnome Disk but that doesn't work too. Do you know if it's something that can be fixed in Fedora or it's really a stock ChromeOS firmware bug ?

I know that flashing the full firmware fix the issue but I'm making some test because, if you remember, my Falco, with the full firmware, boot sometimes when I plug the power adapter. From what I found that should not happen :
https://productforums.google.com/forum/#!msg/chromebook-central/8zogoqEsMgM/cQ-QVk5pMc0J
https://groups.google.com/forum/#!topic/crouton-central/xo6IU4_d9iM
https://productforums.google.com/forum/#!topic/chromebook-central/Xp8OKGWnmHM;context-place=forum/chromebook-central

@MrChromebox
Copy link
Owner

I'm not sure whether it's a ChromeOS firmware bug or syslinux one, I just know the issue exists and the 'mem=' workaround. You might try writing the USB using Rufus if you have access to a Windows machine.

As for your power-on when plugging-in issue, that's likely an issue with the EC (embedded controller) firmware, and not something that can be worked around at the OS level.

@jeremy447
Copy link
Author

jeremy447 commented Apr 28, 2016

It seems that there is a fix in syslinux but it's not merged in Fedora 23 :
https://bugzilla.redhat.com/show_bug.cgi?id=1135793#c27
I just tried Fedora 24 alpha and it's the same. I don't know if it's merged in Fedora 24 alpha.

As for your power-on when plugging-in issue, that's likely an issue with the EC (embedded controller) firmware, and not something that can be worked around at the OS level.

That's what you said me but it's not 100% sure that an issue with the EC so I make tests, but not at the OS level, rather with the stock firmware (John Lewis Shellball) + Legacy RW (yours and John Lewis), full ROM (CoolStar and John Lewis), etc... ;)

By the way do you know how to update or at least check the version of the EC firmware ?

@MrChromebox
Copy link
Owner

well, one solution to the issue would be to update the bootloader on the USB install media to the latest testing build of syslinux (6.0.4) which includes the linked fix: https://www.kernel.org/pub/linux/utils/boot/syslinux/Testing/6.04/

Download, extract, and install (or update) to the (mounted) usb install media after writing via dd.

@MrChromebox
Copy link
Owner

@Paviluf FYI, I verified that updating syslinux to 6.0.4-pre1 fixes the issue. So download, extract, then:

syslinux-6.0.4-pre1/bios/linux --update /dev/sd[x]

where /dev/sd[x] is the device (not path - eg, /dev/sdb) and you should be good to go (assuming the usb install media is fat32 formatted)

@jeremy447
Copy link
Author

Great thank you very very much ! That's very nice. I will try to have syslinux updated or at least the patch integrated in Fedora 24.

@jeremy447
Copy link
Author

jeremy447 commented Apr 28, 2016

I don't want to abuse but I want to talk to you of 5 others things :D
Can I continue here or you prefer an other way ?

@jeremy447
Copy link
Author

jeremy447 commented Apr 28, 2016

This is what I want to talk about :

  1. How can I get a valid Falco Hardware ID because I lost mine and I didn't find a way to get it back :(
  2. There is a cursor jump bug with Libinput that I reported. If you have a Falco or know someone that does, it can help maybe.
  3. With the Coolstar and John Lewis full ROM, when I open lid when the Chromebook is completely off, the Chromebook not boot everytime whereas it does with default firmware + Legacy RW. So it seems to be a full ROM bug.
  4. I can confirm that the Chromebook don't boot when I plug the power adapter with default firmware + Legacy RW so it should be a full ROM bug (both Coolstar and John Lewis one). I just noticed that sometimes, with the default firmware, the Chromebook begin to start but stop and shutdown after 2s (before launching the OS). There is maybe some kind of fix or workaround in the default firmware that is not included in the full ROM ?
    I have found these 2 commits that seem related :
    https://review.coreboot.org/#/c/444 and https://review.coreboot.org/#/c/1323/
  5. When I saved VPD and GBB there was this error if I remember correctly. It don't seem to be a problem but I don't know if my VPD and GBB are valid because of that. I didn't know at the time but the error can be avoided with the "nopat" boot option.
Error accessing high tables, 0x100000 bytes at 0x7f77a000 /dev/mem mmap failed: Resource temporarily unavailable
Failed getting access to coreboot high tables.

I hope I don't ask too much. If I bother you just say me ;)

Last edit : 13h53 UTC

@MrChromebox
Copy link
Owner

for the hardware ID, you can use 'FALCO_C2A-T2Q-D4M' (and set it using the firmware utility script)

the libinput issue is likely an issue with the package itself or configuration, not a firmware issue. I'd check and see if GalliumOS has the issue, and if so, the devs there will likely be able to help

the GBB matters only for the hardware ID and GBB flags, both of which you can change easily. The VPD doesn't really matter for a device without ethernet. So I wouldn't worry about it.

coolstar is probably going to be more receptive to addressing the issue, so I'd ask him on reddit (/r/chultrabook) or IRC (#galliumOS)

@jeremy447
Copy link
Author

Thank you Matt for all these infos and for all the things you do and share :)

@jeremy447
Copy link
Author

jeremy447 commented Apr 29, 2016

the libinput issue is likely an issue with the package itself or configuration, not a firmware issue. I'd check and see if GalliumOS has the issue, and if so, the devs there will likely be able to help

Dudley Du, the author of the Kernel Cyapa driver basically says that my touchpad is broken... I don't think so. Peter Hutterer, the author of libinput, added a patch in libinput to discard these jumps ! I tried to contact Hugh from GalliumOS by email, I think he have a Falco, to try to confirm the bug and have a proper fix in the Kernel.

the GBB matters only for the hardware ID and GBB flags, both of which you can change easily. The VPD doesn't really matter for a device without ethernet. So I wouldn't worry about it.

Ok so GBB don't really need to be flashed if I understand correctly ? And if I still understand correctly the VPD is only used to get back the MAC address ?

coolstar is probably going to be more receptive to addressing the issue, so I'd ask him on reddit (/r/chultrabook) or IRC (#galliumOS)

I asked him on IRC but unfortunately he don't seem to be very receptive :( That's a big bug nevertheless with, I think, many people concerned. Do you think you can look at it ?

@jeremy447
Copy link
Author

Ok so GBB don't really need to be flashed if I understand correctly ? And if I still understand correctly the VPD is only used to get back the MAC address ?

Do you think you can look at these problems ?

  • Unwanted boot when plugged in
  • Open lid when the Chromebook is completely off, the Chromebook not boot everytime

If I bother you just say it ;)

@MrChromebox
Copy link
Owner

Do you think you can look at these problems ?

Unwanted boot when plugged in
Open lid when the Chromebook is completely off, the Chromebook not boot everytime

If I bother you just say it ;)

it's not an issue of being a bother, but my ability to diagnose/fix the issues. I don't produce any full firmware for Chromebooks (just boxes), so I'd need to clone coolstar's repo with his tweaks and start from there, but wouldn't have any way to test.

@jeremy447
Copy link
Author

Ok so GBB don't really need to be flashed if I understand correctly ? And if I still understand correctly the VPD is only used to get back the MAC address ?

Can you just say me if it's right ?

Maybe you can work with Coolstar ? John Lewis said me that he knew these problems for 2 years but he don't want to fix them.

@MrChromebox
Copy link
Owner

MrChromebox commented May 8, 2016

Can you just say me if it's right ?

Maybe you can work with Coolstar ? John Lewis said me that he knew these problems for 2 years but he don't want to fix them.

correct, you don't need to worry about backup up or flashing the GBB and VPD firmware regions.

Given that it's not an issue with the stock firmware, I'd suggest that you just use that instead, with JL's BOOT_STUB update. Like JL, debugging this sort of issue on hardware I don't have isn't something I'm interested in spending time on, esp when workaround are available

@jeremy447
Copy link
Author

It happen with JL's BOOT_STUB too :( Too bad that nobody is interested in fixing this.

Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants