qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v8 2/8] ARM: Samsung exynos4210-based boards emu


From: Evgeny Voevodin
Subject: Re: [Qemu-devel] [PATCH v8 2/8] ARM: Samsung exynos4210-based boards emulation
Date: Thu, 19 Jan 2012 17:15:14 +0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16

On 01/19/2012 04:19 PM, Peter Maydell wrote:
On 19 January 2012 08:31, Evgeny Voevodin<address@hidden>  wrote:

+    /*
+     * Secondary CPU startup code will be placed here.
+     */
+    memory_region_init_ram(&s->hack_mem, "exynos4210.hack", 0x1000);
+    memory_region_add_subregion(system_mem, EXYNOS4210_SMP_BOOT_ADDR,
+&s->hack_mem);
I've been thinking about this 'hack' memory region, because I figured
out that we didn't actually need it on vexpress (or realview, though
I haven't submitted a patch to fix that yet). Basically the idea is that
we need to put the secondary CPU startup code somewhere where Linux
won't trash it before the secondary cores get started properly. However
this requirement exists also for the real hardware. So the right thing
to do here is identify where the real hardware's boot ROM puts the
secondary CPU holding pen code, and use the same thing. (On vexpress
this is in an area of SDRAM). What does the Exynos4 hardware/bootrom do
here?

In our case it is not a hack. Secondary CPU boot loader resides in ROM memory.
And we have mapped a region in the ROM to place our boot-loader code there.
Here all is correct.
+    /*
+     * Hack: Map SECOND_CPU_BOOTREG, because it is in PMU USER5 register.
+     */
+    memory_region_init_ram(&s->bootreg_mem, "exynos4210.bootreg", 0x4);
+    memory_region_add_subregion(system_mem, EXYNOS4210_SECOND_CPU_BOOTREG,
+&s->bootreg_mem);
If this was modelled as an actual register in a device model with a reset
function we wouldn't have needed the code in arm_boot.c:do_cpu_reset()
that clears smp_bootreg_addr. I think that's an argument for implementing
this as an actual qdev device, however minimal (one that implements
exactly one register would do) rather than as a bit of RAM.

Boot reg could be in the RAM on other platforms and code which is monitoring this address
is awaiting a non-zero value here. If we would not clear this region, wrong
boot address for secondary CPU will be read. So, code to clear this region
should be at reset function anyway.
I think that it is a matter of current board how to manage boot address -
map a region or implement a device.

+static QEMUMachine nuri_machine = {
+        .name = "nuri",
+        .desc = "Samsung NURI board (Exynos4210)",
+        .init = nuri_init,
+        .max_cpus = EXYNOS4210_MAX_CPUS,
+};
+
+static QEMUMachine smdkc210_machine = {
+        .name = "smdkc210",
+        .desc = "Samsung SMDKC210 board (Exynos4210)",
+        .init = smdkc210_init,
+        .max_cpus = EXYNOS4210_MAX_CPUS,
+};
Indentation in these is still wrong.

Sorry, will fix.
-- PMM



--
Kind regards,
Evgeny Voevodin,
Leading Software Engineer,
ASWG, Moscow R&D center, Samsung Electronics
e-mail: address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]