From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [XEN/ARM PATCH v6 1/1] Add OdroidXU board (Exynos 5410) Date: Wed, 10 Sep 2014 18:03:17 -0700 Message-ID: <5410F4D5.9000503@linaro.org> References: <1409871443-15641-1-git-send-email-suriyan.r@gmail.com> <1410171636.10156.148.camel@kazak.uk.xensource.com> <5410CF05.9070403@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Suriyan Ramasami Cc: keir@xen.org, Ian Campbell , Tim Deegan , "xen-devel@lists.xen.org" , Jan Beulich , ian.jackson@citrix.com, Julien Grall List-Id: xen-devel@lists.xenproject.org Hi Suriyan, On 10/09/14 17:51, Suriyan Ramasami wrote: > On Wed, Sep 10, 2014 at 3:21 PM, Julien Grall wrote: >> On 08/09/14 10:26, Suriyan Ramasami wrote: >>> >>> As can be seen, the secondary CPUs check _hotplug_addr for a non zero >>> value on first being powered on, or after woken up from a wfe. This >>> _hotplug_addr happens to be at offset +0x1c from NS_RAM_BASE. >>> Linux mainline too has this hardcoded +0x1c. >> >> >> You half read the Linux code... This offset is only add when there is a >> secure firmware (detected by "samsung,secure-firmware" node in the device >> tree). >> >> On the Arndale the node doesn't exist. >> > Thanks for digging there Julien. Previously, I must have gone through > the linux code with only exynos5410 in mind. Nonetheless, looks like I > have left out the code which handles the arndale and possibly 5420 and > the 5800 (if they do not have "samsung,secure-firmware" defined). But > on the other hand, I do see arndale-octa has the "secure-firmware" > entry which is a 5420 (so does the 5800). This adds to the confusion. > This is from looking at the linux-3.16.y source. > > Nonetheless, I think to handle arndale for now, I should add the > "samsung,secure-firmware" logic in the code which will then use > sysram_base_addr instead without any offset. > > So, how do I go about this? Should I roll out another patch with these > cumulative changes and also add the BUG_ON change? I think you could avoid to check the "samsung,secure-firmware" logic by only replicate arch/arm/mach-exynos/platsmp.c to Xen. I suspect it will also work on the odroid-xu. Regards, -- Julien Grall