On 12/15/2015 11:28 AM, G Gregory wrote:
On 15 December 2015 at 16:13, G Gregory graeme.gregory@linaro.org wrote:
On 15 December 2015 at 15:36, Jon Masters jcm@redhat.com wrote:
On 12/15/2015 06:19 AM, G Gregory wrote:
<below refers to the GRUB-based approach not the initrd override>
Tried it, results were not great :-(
set root='hd0,gpt2' insmod acpi acpi /DSDT.aml linux /Image-leg earlycon=pl011,0xe1010000 console=ttyAMA0 acpi=force root =/dev/sda2
<snip>
[ 0.000000] PC is at setup_arch+0xfc/0x564 [ 0.000000] LR is at setup_arch+0xf8/0x564
<snip>
So we unmask SError in setup_arch, which happens now later enough that it'll come out of the UART where you can see it. However there are still occasions on some of these early platforms where an unhandled SError can exist as GRUB exits. I have seen that a number of times on Seattle if there's a pending error from one of the IO IP blocks on the SoC You might need a firmware update, but can you also confirm that this happened reproducibly?
It is Seattle RevB I am using and it is repeatable. I have pre-release firmware on there!
Repeatable on ROD0084E as well.
I'll try it on a couple of other platforms later this week. I've pondered before whether GRUB should unmask SError and report this prior to entering the kernel, because today Linux always gets the blame ;)
Jon.