Hello Mark,
1. You can skip this step in your instructions. Instead, when running
make menuconfig, look in Chipset / ChromeOS and select "Build for
ChromeOS". This should cause Depthcharge to appear as a payload option.
You can find the reason for this is in depthcharge/Kconfig.name. The
"depends on" statement keeps it from being visible until the CHROMEOS
condition is met.
2. I would probably keep this step, although I don't know
veyron/speedy. You'll see one of the options under Depthcharge, "Use
default libpayload config". That may move the build along, but I doubt it
has the options you'll need as it works for x86.
Thanks,
Marshall
On Wed, Feb 28, 2018 at 3:39 PM, Mark Wylde <me(a)markwylde.co.uk> wrote:
> Hello
>
> I'm trying to put together a step by step guide of building and flashing
> coreboot to a Chromebook C201.
>
> If you look at the bugfixes part of my guide here (
> https://gist.github.com/markwylde/4061eab71fa1ec7a27c40a87499924c4#bugfixs),
> you'll see I've added two problems I had with the master branch of coreboot:
>
> 1. Depthcharge is not a payload. The `payloads/Kconfig` file doesn't have
> an option for Depthcharge. However if you add it and run menuconfig,
> selecting the new payload, everything works great (well apart from issues 2)
>
> 2. Coreboot/Depthcharge can't find a config file for veyron_speedy because
> `payloads/libpayload/configs/config.veyron_speedy` is not present. If I
> clone `payloads/libpayload/configs/config.veyron` then it works perfectly.
>
> When you run make you are going to get an error message, something like
> below:
>
> I'm almost certain my "fixes" aren't actually fixes, and I'm just doing
> something wrong, if you could correct me I'd be so grateful.
>
> Otherwise, if this is correct I'd be more than happy to try and workout
> submitting a pull request.
>
> Thanks a lot
>
> Mark
>
>
>
>
> --
> coreboot mailing list: coreboot(a)coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
Mark Wylde wrote:
> 1. Depthcharge is not a payload. The `payloads/Kconfig` file
> doesn't have an option for Depthcharge. However if you add it and
> run menuconfig, selecting the new payload, everything works great
> (well apart from issues 2)
coreboot very much intentionally does not limit what can be used as
payload. Any bare metal program can be used as payload.
Thus, Depthcharge indeed *is* a possible payload, it is just not
mentioned in Kconfig.
It was maybe a mistake to offer this automation near the choice of payload,
creating an impression that a few payloads are somehow better than others.
> 2. Coreboot/Depthcharge can't find a config file for veyron_speedy
> because `payloads/libpayload/configs/config.veyron_speedy` is not
> present. If I clone `payloads/libpayload/configs/config.veyron`
> then it works perfectly.
It would be good to know why this happens. Is config.veyron used
elsewhere? Is there both a veyron and a veyron_speedy board? Was the
board renamed in coreboot but this file (in libpayload) overlooked?
> I'm almost certain my "fixes" aren't actually fixes, and I'm just
> doing something wrong, if you could correct me I'd be so grateful.
The second part with the board name looks like a bug, but I don't
know what the appropriate fix is. That requires studying coreboot and
libpayload repos a bit before creating a patch.
If you want, you can of course also push a patch to Gerrit to add
Depthcharge to the list of payloads.
//Peter
Hi all,
Later I noticed that it is reported from #coreboot that linux needs
"acpi=noirq" to boot properly
在 2018年03月01日 18:08, Persmule 写道:
>
> Hi Heymans,
>
> Today I performed a test on my x230, which shows that commit
> d2d2aef6a3222af909183fb96dc7bc908fac3cd4 (
> https://review.coreboot.org/23287 ) renders keyboard unable to operate
> under Heads, too. The regression seems not only affect hp 810g1.
>
> The tests below are performed on my 810g1, for its spi flash is easy
> to access:
>
> 1. Grub payload: complete stalls after the menu gets shown on the screen.
> 2. SeaBIOS: Keyboard can be used to operate SeaBIOS and grub-pc, but
> linux kernel booted from it behaves ill: a log "rtc_cmos: hctosys:
> unable to read the hardware clock." is printed, and rootfs on hdd
> cannot be mounted.
>
> The coreboot config used to build the ill image from HEAD revision
> with grub payload is attached, within which some hints might be found.
>
