Re: [coreboot] [RFH] Status of the Lenovo X201

On 02.05.2018 00:03, qtux wrote: > ... > ACPI Warning: SystemIO range 0x0480-0x04AF > conflicts with OpRegion 0x0480-0x04EB (\GPIO) > (20180105/utaddress-247) > ACPI: If an ACPI driver is available for this device, you should use it > instead of the

Re: [coreboot] [RFH] Status of the Lenovo X201

Thank you Kyösti, your patch solves all irq issues and USB is working again on my X201i. I opened a review for adding the X201i as an X201 variant: https://review.coreboot.org/#/c/coreboot/+/25971/ Apart from that I have the following ACPI conflict with PMIO and GPIO: ACPI: Battery Slot [BAT0]

Re: [coreboot] Why do we have FSP-S

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/01/2018 02:46 PM, Zoran Stojsavljevic wrote: >> Our recommendation for some time has been a mix -- arm64 client devices >> (laptops, tablets, etc.) and ppc64el servers. With those two, you can >> replace x86 entirely if you don't have

Re: [coreboot] Why do we have FSP-S

> Our recommendation for some time has been a mix -- arm64 client devices > (laptops, tablets, etc.) and ppc64el servers. With those two, you can > replace x86 entirely if you don't have proprietary software in your > environment. With all due respect, this is the discussion about Coreboot going

Re: [coreboot] Why do we have FSP-S

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/01/2018 01:30 PM, Julius Werner wrote: >> All the ARM64 boards I've seen that are desktop or higher class ship >> with AMI UEFI and AMI BMC. Plus they contain their own magic blobs, >> some akin to the ME. ARM64 is not a panacea either;

Re: [coreboot] Why do we have FSP-S

> All the ARM64 boards I've seen that are desktop or higher class ship > with AMI UEFI and AMI BMC. Plus they contain their own magic blobs, > some akin to the ME. ARM64 is not a panacea either; OpenPOWER's > actually shipping open POWER9 systems right now with source code. Why > not go down

Re: [coreboot] [RFH] Status of the Lenovo X201

Beware that patch is incomplete! Coreboot dies at src/southbridge/intel/common/acpi_pirq_gen.c line 97: if (!lpcb_path) die("ACPI_PIRQ_GEN: Missing LPCB ACPI path\n"); You have to add the lpc_acpi_name function to src/southbridge/intel/ibexpeak/lpc.c as in

Re: [coreboot] [RFH] Status of the Lenovo X201

On Mon, Apr 30, 2018 at 6:46 AM, qtux wrote: > I wrote a patch [0] for the finalize code issue. With that my X201i is > working fine on current master besides an regression introduced in commit > 7f5efd90e598320791200e03f761309ee04b58a3 [1]. With that regression USB and SD > card

Re: [coreboot] Thread derailment

We've had to remove people from the list before, and I suppose at some point it might have to happen again. Nobody likes this option. Sometimes there is no choice. I agree that on a technical discussion list there's no place for abusive language. We're all trying to do the best we can in a

[coreboot] Thread derailment

Hello all, Recently I've noticed an uptick in threads going off-topic. While some noise should be expected on an open source mailing list, I think it's become very counterproductive in many recent cases. A good example is the FSP-S thread going on where we see clear examples of people interjecting

Re: [coreboot] Why do we have FSP-S

On Mon, Apr 30, 2018 at 9:46 PM, taii...@gmx.com wrote: > Like I have said I believe the gradual encroachment of blobs and corporate > control will end up leaving coreboot dead in the water and eventually even Can you articulate what 'corporate control' is impacting coreboot?