Re: [U-Boot] [PATCH v2 3/7] ARM: add assembly routine to switch to non-secure state
Hi, Andre +.globl _nonsec_init +_nonsec_init: These two lines can be written: ENTRY(_nonsec_init) + mrc p15, 0, r0, c0, c0, 0 @ read MIDR + bfc r0, #20, #4 @ mask out variant + bfc r0, #0, #4 @ and revision Why do you hard code bit positions even though MIDR_PRIMARY_PART_MASK is available? + movwr1, #lo(MIDR_CORTEX_A7_R0P0 MIDR_PRIMARY_PART_MASK) + movtr1, #hi(MIDR_CORTEX_A7_R0P0 MIDR_PRIMARY_PART_MASK) Why don't you use ldr r*, =... statement here? + orr r1, #(MIDR_CORTEX_A15_R0P0 0xf0) This code relies on the value of MIDR_CORTEX_A15_R0P0. So, I think you can rewrite this part more simply as follows: mrc p15, 0, r0, c0, c0, 0 @ read MIDR ldr r1, =MIDR_PRIMARY_PART_MASK and r0, r0, r1 @ mask out variant and revision ldr r1, =MIDR_CORTEX_A7_R0P0 cmp r0, r1 @ check for Cortex-A7 ldr r1, =MIDR_CORTEX_A15_R0P0 cmpne r0, r1 @ check for Cortex-A15 + bx lr Add ENDPROC(_nonsec_init) when beginning with ENTRY(_nonsec_init). +/* defined in cpu/armv7/nonsec_virt.S */ +void _nonsec_init(void); I think this comment is not necessary and mantainancability is not excellent in case you renaming nonsec_virt.S. BTW, tag generation tool, GNU Global can help us for searching definition. If you begin routines in assembly with ENTRY(...), GNU Global picks up these symbols for tag jump. Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 4/7] ARM: switch to non-secure state during bootm execution
Hi Andre.
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -60,6 +60,8 @@ COBJS-y += reset.o
COBJS-y += cache.o
COBJS-y += cache-cp15.o
+COBJS-$(CONFIG_ARMV7_VIRT) += virt-v7.o
+
Judging from the file name virt-v7.c,
you are thinkig this file is specific to ARMv7, aren't you?
If so, why don't you move this file
to arch/arm/cpu/armv7/ ?
+static void set_generic_timer_frequency(void)
+{
+#ifdef CONFIG_SYS_CLK_FREQ
+ unsigned int reg;
+
+ reg = read_id_pfr1();
+ if ((reg CPUID_ARM_TIMER_MASK) == 1U CPUID_ARM_TIMER_SHIFT)
+ asm(mcr p15, 0, %0, c14, c0, 0\n
+ : : r(CONFIG_SYS_CLK_FREQ));
+#endif
CPUID_ARM_TIMER_MASK
CPUID_ARM_TIMER_SHIFT
I think these macro names are vague.
There are Generic Timer, Global Timer, Private Timer etc.
Unlike other parts, the care for Cortex-A9 is missing here.
To be more generic, I'd like to suggest to allow Non-secure access
to Global/Private timers before switching to non-secure state.
How about like this for armv7_switch_nonsec function?
/* check whether the CPU supports the security extensions */
reg = read_id_pfr1();
if ((reg 0xF0) == 0)
return HYP_ERR_NO_SEC_EXT;
if ((reg CPUID_ARM_TIMER_MASK) == 1U CPUID_ARM_TIMER_SHIFT)
set_generic_timer_frequency();
else
/* Allow Non-secure access to Global/Private timers */
writel(0xfff, periph_base + SCU_SNSAC);
For more info about SCU Non-secure Access Control (SNSAC) Register,
please refer Cortex A9 mpcore TRM. page 2-11
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0407g/DDI0407G_cortex_a9_mpcore_r3p0_trm.pdf
+ /* enable the GIC distributor */
+ writel(readl(gicdptr[GICD_CTLR]) | 0x03, gicdptr[GICD_CTLR]);
I am not sure this code is really necessary.
Because your are setting all available interrupts to Group1 just below,
I think we don't need to do this in secure state.
Best Regards
Masahiro Yamada
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] ARM: add SMP support for non-secure switch
Hi Andre, The actual CPU kick is done by sending an inter-processor interrupt via the GIC to all CPU interfaces except the requesting processor. The secondary cores will then setup their respective GIC CPU interface. This issue might have been raised already, I think how to kick secondary CPUs is board-specific. Other boards might use sev instruction for that purpose. +.globl _smp_pen +_smp_pen: ENTRY(_smp_pen) Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] p1020rdb-pd: platform support
From: Haijun.Zhang haijun.zh...@freescale.com
Add new board p1020RDB-PD. P1020RDB-PD board was update from P1020RDB.
DDR changed from DDR2 1G to DDR3 2G.
NAND: 128 MiB
Flash: 64 MiB
Also change P1020RDB to P1020RDB-PC to distinguish from P1020RDB board.
Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com
Signed-off-by: Haijun Zhang haijun.zh...@freescale.com
CC: Scott Wood scottw...@freescale.com
CC: Sun Yusong-R58495 york...@freescale.com
---
changes for V2:
- Add change log and update the config name for pc board
board/freescale/p1_p2_rdb_pc/README | 1 +
board/freescale/p1_p2_rdb_pc/ddr.c | 4 +--
board/freescale/p1_p2_rdb_pc/tlb.c | 2 +-
boards.cfg | 20 +--
include/configs/p1_p2_rdb_pc.h | 50 ++---
5 files changed, 63 insertions(+), 14 deletions(-)
diff --git a/board/freescale/p1_p2_rdb_pc/README
b/board/freescale/p1_p2_rdb_pc/README
index 4437731..f4cc43f 100644
--- a/board/freescale/p1_p2_rdb_pc/README
+++ b/board/freescale/p1_p2_rdb_pc/README
@@ -3,6 +3,7 @@ Overview
P1_P2_RDB_PC represents a set of boards including
P1020MSBG-PC
P1020RDB-PC
+P1020RDB-PD
P1020UTM-PC
P1021RDB-PC
P1024RDB
diff --git a/board/freescale/p1_p2_rdb_pc/ddr.c
b/board/freescale/p1_p2_rdb_pc/ddr.c
index 9355536..c8fde72 100644
--- a/board/freescale/p1_p2_rdb_pc/ddr.c
+++ b/board/freescale/p1_p2_rdb_pc/ddr.c
@@ -80,7 +80,7 @@ dimm_params_t ddr_raw_timing = {
.refresh_rate_ps = 780,
.tFAW_ps = 3,
};
-#elif defined(CONFIG_P1020MBG)
+#elif (defined(CONFIG_P1020MBG) || defined(CONFIG_P1020RDB_PD))
/* Micron MT41J512M8_187E */
dimm_params_t ddr_raw_timing = {
.n_ranks = 2,
@@ -111,7 +111,7 @@ dimm_params_t ddr_raw_timing = {
.refresh_rate_ps = 780,
.tFAW_ps = 37500,
};
-#elif defined(CONFIG_P1020RDB)
+#elif defined(CONFIG_P1020RDB_PC)
/*
* Samsung K4B2G0846C-HCF8
* The following timing are for downshift
diff --git a/board/freescale/p1_p2_rdb_pc/tlb.c
b/board/freescale/p1_p2_rdb_pc/tlb.c
index 3e4dffd..e19002f 100644
--- a/board/freescale/p1_p2_rdb_pc/tlb.c
+++ b/board/freescale/p1_p2_rdb_pc/tlb.c
@@ -110,7 +110,7 @@ struct fsl_e_tlb_entry tlb_table[] = {
MAS3_SX|MAS3_SW|MAS3_SR, 0,
0, 8, BOOKE_PAGESZ_1G, 1),
-#ifdef CONFIG_P1020MBG
+#if defined(CONFIG_P1020MBG) || defined(CONFIG_P1020RDB_PD)
/* 2G DDR on P1020MBG, map the second 1G */
SET_TLB_ENTRY(1, CONFIG_SYS_DDR_SDRAM_BASE + 0x4000,
CONFIG_SYS_DDR_SDRAM_BASE + 0x4000,
diff --git a/boards.cfg b/boards.cfg
index 35f38f3..8f50927 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -758,16 +758,20 @@ P1020RDB_36BIT powerpc mpc85xx
p1_p2_rdb freesca
P1020RDB_36BIT_SDCARDpowerpc mpc85xx p1_p2_rdb
freescale - P1_P2_RDB:P1020RDB,36BIT,SDCARD
P1020RDB_36BIT_SPIFLASH powerpc mpc85xx p1_p2_rdb
freescale - P1_P2_RDB:P1020RDB,36BIT,SPIFLASH
P1020RDB_NANDpowerpc mpc85xx p1_p2_rdb
freescale - P1_P2_RDB:P1020RDB,NAND
-P1020RDB-PC powerpc mpc85xx p1_p2_rdb_pc
freescale - p1_p2_rdb_pc:P1020RDB
-P1020RDB-PC_36BITpowerpc mpc85xx p1_p2_rdb_pc
freescale - p1_p2_rdb_pc:P1020RDB,36BIT
-P1020RDB-PC_36BIT_NAND powerpc mpc85xx p1_p2_rdb_pc
freescale - p1_p2_rdb_pc:P1020RDB,36BIT,NAND
-P1020RDB-PC_36BIT_SDCARD powerpc mpc85xx p1_p2_rdb_pc
freescale - p1_p2_rdb_pc:P1020RDB,36BIT,SDCARD
-P1020RDB-PC_36BIT_SPIFLASH powerpc mpc85xx p1_p2_rdb_pc
freescale - p1_p2_rdb_pc:P1020RDB,36BIT,SPIFLASH
-P1020RDB-PC_NAND powerpc mpc85xx p1_p2_rdb_pc
freescale - p1_p2_rdb_pc:P1020RDB,NAND
-P1020RDB-PC_SDCARD powerpc mpc85xx p1_p2_rdb_pc
freescale - p1_p2_rdb_pc:P1020RDB,SDCARD
-P1020RDB-PC_SPIFLASH powerpc mpc85xx p1_p2_rdb_pc
freescale - p1_p2_rdb_pc:P1020RDB,SPIFLASH
+P1020RDB-PC powerpc mpc85xx p1_p2_rdb_pc
freescale - p1_p2_rdb_pc:P1020RDB_PC
+P1020RDB-PC_36BITpowerpc mpc85xx p1_p2_rdb_pc
freescale - p1_p2_rdb_pc:P1020RDB_PC,36BIT
+P1020RDB-PC_36BIT_NAND powerpc mpc85xx p1_p2_rdb_pc
freescale - p1_p2_rdb_pc:P1020RDB_PC,36BIT,NAND
+P1020RDB-PC_36BIT_SDCARD powerpc mpc85xx p1_p2_rdb_pc
freescale - p1_p2_rdb_pc:P1020RDB_PC,36BIT,SDCARD
+P1020RDB-PC_36BIT_SPIFLASH powerpc mpc85xx p1_p2_rdb_pc
freescale - p1_p2_rdb_pc:P1020RDB_PC,36BIT,SPIFLASH
+P1020RDB-PC_NAND
Re: [U-Boot] [PATCH v2 6/7] ARM: extend non-secure switch to also go into HYP mode
Hi Andre [RFC] I'd like to suggest to separate HYP-switching code from Non-secure switching. And define different macros, for example: CONFIG_ARMV7_NONSECURE : switch to nonsecure CONFIG_ARMV7_VIRT : switch to hypervisor Of cource, CONFIG_ARMV7_NONSECURE must be defined when using CONFIG_ARMV7_VIRT. (If we introduced Kconfig to U-boot, we could handle nicely dependency between CONFIGs.) I know your incentive to switch to non-secure state is virtualization. But I think this separation would make this code useful for other boards and easy to understand. For example (this situtation might be specific to my board), non-secure switching is done for the reason to use a hardware debugger, because our debugger without security extension can work only in non-secure state. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] console: usbkbd: Improve TFTP booting performance
On Fri, 2013-06-28 at 02:20 +0800, Stephen Warren wrote: On 06/27/2013 03:45 AM, Jim Lin wrote: TFTP booting is observed a little bit slow, especially when a USB keyboard is installed. The fix is to move polling to every second if we sense that other task like TFTP boot is running. diff --git a/common/usb_kbd.c b/common/usb_kbd.c +#ifdef CONFIG_USBKB_TESTC_PERIOD + /* +* T is the time between two calls of usb_kbd_testc(). +* If CONFIG_USBKB_TESTC_PERIOD ms T 1000 ms, +* it implies other task like TFTP boot is running, +* then we reduce polling to every second +* to improve TFTP booting performance. +*/ + if ((get_timer(kbd_testc_tms) = + (CONFIG_USBKB_TESTC_PERIOD * CONFIG_SYS_HZ / 1000)) + (get_timer(kbd_testc_tms) CONFIG_SYS_HZ)) + return 0; + else + kbd_testc_tms = get_timer(0); +#endif I have a hard time understanding why the fact that some other task is running implies anything at all re: how often usb_kbd_testc() would be called. In my case it takes about 95 ms on Tegra20 and Tegra114 for usb_kbd_testc() to be called periodically. So I set CONFIG_USBKB_TESTC_PERIOD to 100. Like I said, if CONFIG_USBKB_TESTC_PERIOD ms T 1000 ms we reduce polling (send command to USB keyboard to check is there any key pressed) to every second. It's quite possible that some other task is extremely fine-grained, and calls usb_kbd_testc() every 0.1ms, and would be severely negatively affected by usb_kbd_testc() taking a long time to execute. Conversly, it's quite possible that some other task is quite granular, and calls usb_kbd_testc() a wide intervals, say every 200ms. So, I think this change keys of entirely the wrong thing. Shouldn't the TFTP process (or use of USB networking?) or other long-running tasks that do check for keyboard IO simply set some flag to indicate to usb_kbd_testc() that it should run at a reduced rate, or even just have those long-running processses call usb_kbd_testc() at a reduced rate themselves? To fix in usb_kbd_testc() is easier because this issue happens only when USB keyboard is installed and CONFIG_USB_KEYBOARD is defined. -- nvpublic ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/21] Refactor the bootm command to reduce code duplication
Hi Simon, On 06/28/2013 04:14 AM, Simon Glass wrote: I can create something with or without compression and I cannot see the failure. Tom is seeing it though. I will see if I can get another board to try. If you have any ideas please let me know. Sorry, but I don't have any ideas. I also checked the parameters of the gunzip call. And they were identical in the working (before this patch) and non-working version (with this patch). gunzip() just didn't return. One idea: It might have something to do with the interrupt disabling, as powerpc compresses to 0. And thats the location of the interrupt vectors (timer?). Just an idea. Do you remember shuffling the disable_interrupts() call around? I'll check myself in a few hours. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot2013:07-Recompile with -fPIC error for mips64 board
Hi Wolfgang, I am using xlp832 mips64 netlogic board.I referred these steps from u-boot README file. Configuration: TARGET archCPU BoardName brcm8xx mipsmips64 brcm8xx - - Options brcm8xx:SYS_BIG_ENDIAN Regards, Krishna On Thu, Jun 27, 2013 at 11:19 PM, Wolfgang Denk w...@denx.de wrote: Dear krishna dwivedi, In message CAKAK--mG07ZxHFzhw=qtVONpfrQS61Q=Ai_mYrLLYg+XmFj= d...@mail.gmail.com you wrote: --===1781805000== Content-Type: multipart/alternative; boundary=047d7bd6c6425eb96b04e02592ae --047d7bd6c6425eb96b04e02592ae Content-Type: text/plain; charset=ISO-8859-1 Hi All, I am cross-compiling u-boot2013-07 for mips64 board.These steps i have followed: 1)I have exported envionment variables CC,LD,AS,CCAS,AR and LD_LIBRARY_PATH. 2)export CROSS_COMPILE=mips64-unknown-elf- 3)make tools 4)make board_config 5)make all This is NOT the noral order of steps. There is no need to build tools manually, and in no way this should be done before the config target. I think I asked this before: which _exact_ machine configuration are you using, i. e. what is your board name? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The optimum committee has no members. - Norman Augustine ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 1/2] console: usbkbd: Improve TFTP booting performance
On 06/27/2013 09:59 PM, Jim Lin wrote: On Fri, 2013-06-28 at 02:20 +0800, Stephen Warren wrote: On 06/27/2013 03:45 AM, Jim Lin wrote: TFTP booting is observed a little bit slow, especially when a USB keyboard is installed. The fix is to move polling to every second if we sense that other task like TFTP boot is running. diff --git a/common/usb_kbd.c b/common/usb_kbd.c +#ifdef CONFIG_USBKB_TESTC_PERIOD + /* +* T is the time between two calls of usb_kbd_testc(). +* If CONFIG_USBKB_TESTC_PERIOD ms T 1000 ms, +* it implies other task like TFTP boot is running, +* then we reduce polling to every second +* to improve TFTP booting performance. +*/ + if ((get_timer(kbd_testc_tms) = + (CONFIG_USBKB_TESTC_PERIOD * CONFIG_SYS_HZ / 1000)) + (get_timer(kbd_testc_tms) CONFIG_SYS_HZ)) + return 0; + else + kbd_testc_tms = get_timer(0); +#endif I have a hard time understanding why the fact that some other task is running implies anything at all re: how often usb_kbd_testc() would be called. In my case it takes about 95 ms on Tegra20 and Tegra114 for usb_kbd_testc() to be called periodically. So I set CONFIG_USBKB_TESTC_PERIOD to 100. Like I said, if CONFIG_USBKB_TESTC_PERIOD ms T 1000 ms we reduce polling (send command to USB keyboard to check is there any key pressed) to every second. OK, so I think how this works is: If nothing is happening, then usb_kbd_testc() is repeatedly called back-to-back with no delay between. So, if the time between two calls to usb_kbd_testc() is much longer than the time it takes to execute it once, then something else is going on, and hence the code should skip some calls to usb_kbd_testc(). If that's how this works, then why require CONFIG_USBKBD_TESTC_PERIOD to be set? Why not simply measure the time between when usb_kbd_testc() returns, and when it is re-entered? If it's very short, nothing else is happening. If it's very long, something else is happening. That is a far more direct measurement, and is immune to e.g. CPU frequency differences in a way that a static value for CONFIG_USBKBD_TESTC_PERIOD is not. Also, any kind of time measurement doesn't solve the issue I mentioned re: how granular the other task is. Finally, if you're sitting at the command-prompt, is usb_kbd_testc() used at all? How does regular typing using a USB keyboard interact with this code; will typing react fast, but CTRL-C react slowly? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot compile error
+U-Boot Hi, Yes, it reqiures libssl-dev - please see this: http://patchwork.ozlabs.org/patch/255113/ Regards, Simon On Thu, Jun 27, 2013 at 8:48 PM, Liu Gang-B34182 b34...@freescale.comwrote: Hi, Simon Glass, ** ** The compiling of the lasted u-boot at master branch has the following error: ** ** u-boot-opensource/lib/rsa/rsa-sign.c:26:25: fatal error: openssl/rsa.h: No such file or directory ** ** Please have a look, thanks! ** ** *---* *Best Regards,* ** ** *Liu Gang* ** ** ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 15/21] Refactor the bootm command to reduce code duplication
Hi Stefan, On Thu, Jun 27, 2013 at 9:12 PM, Stefan Roese s...@denx.de wrote: Hi Simon, On 06/28/2013 04:14 AM, Simon Glass wrote: I can create something with or without compression and I cannot see the failure. Tom is seeing it though. I will see if I can get another board to try. If you have any ideas please let me know. Sorry, but I don't have any ideas. I also checked the parameters of the gunzip call. And they were identical in the working (before this patch) and non-working version (with this patch). gunzip() just didn't return. One idea: It might have something to do with the interrupt disabling, as powerpc compresses to 0. And thats the location of the interrupt vectors (timer?). Just an idea. Do you remember shuffling the disable_interrupts() call around? I'll check myself in a few hours. Thanks. Apparently it happens on an ARM board also. I am writing some more sandbox tests to increase the test coverage and hopefully spot something. Please let me know if you have any ideas on this. It seems like (at least in the ARM case) it must be returning BOOTM_ERR_OVERLAP from bootm_load_os(). In your case it may be dying before then by overwriting memory. So the addresses used in that function may be the key to it. However you say they are the same, so I am not sure. I am also doing a careful diff against the Chromium tree, which seems to work, to try to see if there is a difference somewhere. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
