Message-ID: <CAD=FV=X17PeJ6JPE9Qyc1QT07AvA2PTE69Q87gz9a6MdUHgi4A@mail.gmail.com>
Date:	Mon, 9 Jun 2014 10:03:31 -0700
From:	Doug Anderson <dianders@...omium.org>
To:	Lorenzo Pieralisi <lorenzo.pieralisi@....com>
Cc:	Kukjin Kim <kgene.kim@...sung.com>,
	Nicolas Pitre <nicolas.pitre@...aro.org>,
	Abhilash Kesavan <a.kesavan@...sung.com>,
	Andrew Bresticker <abrestic@...omium.org>,
	Inderpal Singh <inderpal.s@...sung.com>,
	Thomas Abraham <thomas.ab@...sung.com>,
	"olof@...om.net" <olof@...om.net>,
	Tushar Behera <trblinux@...il.com>,
	Kevin Hilman <khilman@...aro.org>,
	Javier Martinez Canillas <javier.martinez@...labora.co.uk>,
	"linux-samsung-soc@...r.kernel.org" 
	<linux-samsung-soc@...r.kernel.org>,
	"linux@....linux.org.uk" <linux@....linux.org.uk>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ARM: EXYNOS: mcpm: Don't rely on firmware's secondary_cpu_start

Lorenzo,

On Sat, Jun 7, 2014 at 11:12 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@....com> wrote:
> On Fri, Jun 06, 2014 at 10:43:05PM +0100, Doug Anderson wrote:
>> On exynos mcpm systems the firmware is hardcoded to jump to an address
>> in SRAM (0x02073000) when secondary CPUs come up.  By default the
>> firmware puts a bunch of code at that location.  That code expects the
>> kernel to fill in a few slots with addresses that it uses to jump back
>> to the kernel's entry point for secondary CPUs.
>>
>> Originally (on prerelease hardware) this firmware code contained a
>> bunch of workarounds to deal with boot ROM bugs.  However on all
>> shipped hardware we simply use this code to redirect to a kernel
>> function for bringing up the CPUs.
>>
>> Let's stop relying on the code provided by the bootloader and just
>> plumb in our own (simple) code jump to the kernel.  This has the nice
>> benefit of fixing problems due to the fact that older bootloaders
>> (like the one shipped on the Samsung Chromebook 2) might have put
>> slightly different code into this location.
>>
>> Once suspend/resume is implemented for systems using exynos-mcpm we'll
>> need to make sure we reinstall our fixed up code after resume.  ...but
>> that's not anything new since IRAM (and thus the address of the
>> mcpm_entry_point) is lost across suspend/resume anyway.
>
> Can I ask you please what the firmware does for the boot (primary) cpu
> on cold-boot and warm-boot (resume from suspend) ?

On cold boot:

1. iROM loads BL1 from SPI flash
2. BL1 loads BL2 (SPL) from SPI flash
3. BL2 loads loads RO U-Boot from SPI flash
4. RO U-Boot (might) load RW U-Boot from SPI flash
5. U-Boot loads kernel from eMMC (or SD card or USB)
6. U-Boot boots kernel using bootm.


On resume from suspend:

1. iROM loads BL1 from SPI flash

2. BL1 loads BL2 (SPL) from SPI flash

3. BL2 does some basic init code (clocks, SDRAM out of self refresh,
...) and looks at some SoC registers that are preserved across
suspend/resume.  These registers contain flags indicating that this is
a resume from suspend and a pointer to the address in the kernel to
jump to at resume time.  The address of these registers and which bits
mean which flags is hardcoded and is part of the contract between the
bootloader and the kernel.

4. BL2 jumps to kernel.

---

I will note that BL1, BL2, and "RO U-Boot" are read only in production
systems.  Note that at resume time only Read-Only code is loaded from
persistent storage.  That means no extra verification is needed.  A
system exploit could survive suspend/resume but a reboot would clear
it and a reboot + suspend/resume wouldn't bring it back.


> Does it jump to a specific (hardcoded) location ?

I guess I could say it this way:

A) In resume from suspend, by agreement between the kernel and the
bootloader we'll jump to the address stored in 0x10040800 (INFORM0)

B) In bringing up a new CPU, by agreement between the kernel and the
bootloader we'll jump directly to 0x02073000 (and address in the SoC's
internal SRAM).


> Is the primary CPU (MPIDR) hardcoded in firmware so that on both
> cold and warm-boot firmware sees a specific MPIDR as "special" ?

Cold boot and resume from suspend are detected via various special
flags in various special locations.  Resume from suspend looks at
INFORM1 (0x10048004) for flags.  This register is 0 during a cold boot
and has special values set by the kernel at resume time.

It also looks as if some code looks at 0x10040900 (PMU_SPARE0) to help
tell initial cold boot and secondary CPU bringup.


> I am asking to check if on this platform CPUidle (where the notion of
> primary CPU disappears) has a chance to run properly.

I believe it should be possible, but we don't have CPUidle implemented
in our current system.  Abhilash may be able to comment more.


> Probably CPUidle won't attain idle states where IRAM content is lost, but I
> am still worried about the primary vs secondaries firmware boot behaviour.

I don't think iRAM can be turned off for CPUidle.


> What happens on reboot from suspend to RAM (or to put it differently,
> what does secure firmware do on reboot from suspend to RAM - in
> particular how is the "jump" address to bootloader/kernel set ?)

Should be described above now.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists