[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b0933a59-239d-536f-4f63-a65e469f62a1@redhat.com>
Date: Tue, 17 May 2016 12:48:53 -0400
From: Jon Masters <jcm@...hat.com>
To: Mark Rutland <mark.rutland@....com>,
Aleksey Makarov <aleksey.makarov@...aro.org>
Cc: Russell King <linux@....linux.org.uk>,
"Rafael J . Wysocki" <rjw@...ysocki.net>,
Len Brown <lenb@...nel.org>, linux-acpi@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Graeme Gregory <graeme.gregory@...aro.org>,
"Zheng, Lv" <lv.zheng@...el.com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>
Subject: Re: [PATCH 3/3] ACPI: ARM64: support for ACPI_TABLE_UPGRADE
On 05/17/2016 12:44 PM, Jon Masters wrote:
> 1). During development of a platform, it is much easier to debug
> problems with tables if you can test replacement ones without having to
> respin the firmware. In the server world, you usually don't have the
> firmware source code, so to get it respun could be days-weeks even if
> you are working with the authors closely. We have practically used this
> feature on a number of platforms already and it will continue.
For example, on one platform we were unable to fully boot RHEL(SA) due
to a bug in one of the ACPI tables. But I was able to boot the system to
a ramdisk containing a uuencode library and then write out the content
of the tables over the serial port, then decompile/patch/recompile, and
override replacement tables on the system. Then we beat the vendor up
with the fixes and the official firmware was corrected.
--
Computer Architect | Sent from my Fedora powered laptop
Powered by blists - more mailing lists