Question about mmc4 initialization on OMAP5432

2013-10-08 Thread Chen Baozi
Hi all,

I have got a problem when booting dom0 kernel for Xen on OMAP5432 uEVM.
With a recent patch, Xen hypervisor is avoid to map disabled device
memory for dom0. In omap5-uevm.dts, we have got the mmc4 node marked as
disabled. So the Xen won't populate 0x480d1000 0x400 memory region
to the dom0. If dom0 is trying to access any memory address in this
area, the hypervisor would be panic with a tranlation fault. However, it
turns out that even the mmc4 is disabled in omap5-uevm.dts, Linux kernel
is trying to access the 0x480d1010 when booting, which then leads a
hypervisor panic as mentioned.

The only point I know right now is that the 0x480d1010 is accessed by
the omap_hwmod_read(). However, what makes me confused is how the dom0
kernel called omap_hwmod_read() to access 0x480d1010 while the mmc4 is
disabled. I guess it might relate to hard coded omap_hwmod structure but
have no idea what happen exactly when dom0 access the address due to the
lack of calling stack information when booting Xen hypervisor.

Thanks a lot.

Chen Baozi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Question about SMP boot on OMAP5432

2013-08-09 Thread Chen Baozi
Hi all,

I'm reading OMAP5's smp boot codes and have got a question.

From my understanding, the omap4_omap_prepare_cpus() would set the startup 
address of secondary core, while omap4_boot_secondary() would set AuxCoreBoot0
to 0x20 which may make the omap5_secondary_startup() jump out of wait loop
to secondary_startup. 

And the comment in omap4_smp_prepare_cpus says:

Write the address of secondary startup routine into the
AuxCoreBoot1 where ROM code will jump and start executing
on secondary core once out of *WFE*

My question is: How will ROM code be out of WFE? Is it waked up by dsb_sev()
in omap4_boot_secondary()?

If so, how should I understand the comment in omap4_boot_secondary():

Update the AuxCoreBoot0 with boot state for secondary core.
omap4(5)_secondary_startup() routine will hold the secondary core till
the AuxCoreBoot1 register is update with cpu state.
 Since the entry to omap5_secondary_startup() is set up
 by AuxCoreBoot1, it seems a chicken and egg problem.
 And I didn't see any codes deal with AuxCoreBoot1 in
 either omap4_secondary_startup() or
 omap5_secondary_startup().

Thanks.

Chen Baozi


--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: fix wrong address when loading PRM_FRAC_INCREMENTOR_DENUMERATOR_RELOAD

2013-08-07 Thread Chen Baozi

On Aug 7, 2013, at 7:09 PM, Tony Lindgren t...@atomide.com wrote:

 * Chen Baozi baoz...@gmail.com [130805 08:33]:
 ping?
 
 On Aug 1, 2013, at 7:27 PM, Chen Baozi baoz...@gmail.com wrote:
 
 The denominator should be load from INCREMENTOR_DENUMERATOR_RELOAD_OFFSET
 rather than INCREMENTER_NUMERATOR_OFFSET.
 
 Maybe describe what exactly happens without this fix?

I think it is more likely a typo, since 
INCREMENTER_DENUMERATOR_RELOAD[23:17] is reserved. It seems
that it won't make much trouble without this fix because
the useful [11:0] bit is mask and set the right value later.

Cheers,

Baozi

 
 Also we should get few acks for this for the -rc series.
 
 Regards,
 
 Tony
 
 Signed-off-by: Chen Baozi baoz...@gmail.com
 ---
 arch/arm/mach-omap2/timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
 index b37e1fc..9265e03 100644
 --- a/arch/arm/mach-omap2/timer.c
 +++ b/arch/arm/mach-omap2/timer.c
 @@ -537,7 +537,7 @@ static void __init realtime_counter_init(void)
 reg |= num;
 __raw_writel(reg, base + INCREMENTER_NUMERATOR_OFFSET);
 
 -   reg = __raw_readl(base + INCREMENTER_NUMERATOR_OFFSET) 
 +   reg = __raw_readl(base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET) 
 NUMERATOR_DENUMERATOR_MASK;
 reg |= den;
 __raw_writel(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
 -- 
 1.8.1.4
 
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ARM: fix wrong address when loading PRM_FRAC_INCREMENTOR_DENUMERATOR_RELOAD

2013-08-07 Thread Chen Baozi
The denominator should be load from INCREMENTOR_DENUMERATOR_RELOAD_OFFSET
rather than INCREMENTER_NUMERATOR_OFFSET.

This is more likely a typo, since INCREMENTER_DENUMERATOR_RELOAD[23:17] is
reserved. It seems that it won't make much trouble without this fix, because
the useful [11:0] bits are mask and set the right value. Anyway, reading
from a right address is better choice.

Signed-off-by: Chen Baozi baoz...@gmail.com
---
 arch/arm/mach-omap2/timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 1e77f11..ccc5c72 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -537,7 +537,7 @@ static void __init realtime_counter_init(void)
reg |= num;
__raw_writel(reg, base + INCREMENTER_NUMERATOR_OFFSET);
 
-   reg = __raw_readl(base + INCREMENTER_NUMERATOR_OFFSET) 
+   reg = __raw_readl(base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET) 
NUMERATOR_DENUMERATOR_MASK;
reg |= den;
__raw_writel(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
-- 
1.8.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] ARM: fix wrong address when loading PRM_FRAC_INCREMENTOR_DENUMERATOR_RELOAD

2013-08-05 Thread Chen Baozi
ping?

On Aug 1, 2013, at 7:27 PM, Chen Baozi baoz...@gmail.com wrote:

 The denominator should be load from INCREMENTOR_DENUMERATOR_RELOAD_OFFSET
 rather than INCREMENTER_NUMERATOR_OFFSET.
 
 Signed-off-by: Chen Baozi baoz...@gmail.com
 ---
 arch/arm/mach-omap2/timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
 index b37e1fc..9265e03 100644
 --- a/arch/arm/mach-omap2/timer.c
 +++ b/arch/arm/mach-omap2/timer.c
 @@ -537,7 +537,7 @@ static void __init realtime_counter_init(void)
   reg |= num;
   __raw_writel(reg, base + INCREMENTER_NUMERATOR_OFFSET);
 
 - reg = __raw_readl(base + INCREMENTER_NUMERATOR_OFFSET) 
 + reg = __raw_readl(base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET) 
   NUMERATOR_DENUMERATOR_MASK;
   reg |= den;
   __raw_writel(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
 -- 
 1.8.1.4
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] ARM: fix wrong address when loading PRM_FRAC_INCREMENTOR_DENUMERATOR_RELOAD

2013-08-01 Thread Chen Baozi
The denominator should be load from INCREMENTOR_DENUMERATOR_RELOAD_OFFSET
rather than INCREMENTER_NUMERATOR_OFFSET.

Signed-off-by: Chen Baozi baoz...@gmail.com
---
 arch/arm/mach-omap2/timer.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b37e1fc..9265e03 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -537,7 +537,7 @@ static void __init realtime_counter_init(void)
reg |= num;
__raw_writel(reg, base + INCREMENTER_NUMERATOR_OFFSET);
 
-   reg = __raw_readl(base + INCREMENTER_NUMERATOR_OFFSET) 
+   reg = __raw_readl(base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET) 
NUMERATOR_DENUMERATOR_MASK;
reg |= den;
__raw_writel(reg, base + INCREMENTER_DENUMERATOR_RELOAD_OFFSET);
-- 
1.8.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Linux kernel for OMAP5432 uEVM

2013-07-31 Thread Chen Baozi

On Jul 30, 2013, at 11:52 AM, Lokesh Vutla lokeshvu...@ti.com wrote:

 You can also use Linus's kernel with the above clk data branch.( OMAP5 uEVM 
 boots)
 Please let me know if you need more info.

And the ethernet driver is not available by default?

Cheers,

Baozi--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Linux kernel for OMAP5432 uEVM

2013-07-31 Thread Chen Baozi
Hi Roger,
On Jul 31, 2013, at 8:16 PM, Roger Quadros rog...@ti.com wrote:

 Hi Chen,
 
 On 07/31/2013 02:31 PM, Roger Quadros wrote:
 On 07/31/2013 11:31 AM, Lokesh Vutla wrote:
 Hi Chen,
 
 On Wednesday 31 July 2013 01:19 PM, Chen Baozi wrote:
 
 On Jul 30, 2013, at 11:52 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 
 You can also use Linus's kernel with the above clk data branch.( OMAP5 
 uEVM boots)
 Please let me know if you need more info.
 
 And the ethernet driver is not available by default?
 You need the following patch series recently posted by Roger:
 http://www.mail-archive.com/linux-omap@vger.kernel.org/msg92694.html
 
 
 Those will work only if you proceed with Tero's clock data in DT approach.
 
 
 I've created a branch that contains all patches required to get ethernet 
 working on 
 uEVM on top of Tero's DT clocks. I took the leisure of picking the baseport 
 tree from
 Lokesh [1].
 
 You can get the necessary stuff from branch 
   usbhost-uevm-3.11-rc3
 in git tree 
   git://github.com/rogerq/linux.git

Thanks a lot. I'll have a try.

Baozi

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Linux kernel for OMAP5432 uEVM

2013-07-30 Thread Chen Baozi

On Jul 30, 2013, at 11:52 AM, Lokesh Vutla lokeshvu...@ti.com wrote:

 Hi Chen,
 On Tuesday 30 July 2013 09:08 AM, Chen Baozi wrote:
 Hi all,
 
 I'm trying to boot my OMAP5432 uEVM devboard with the lastest kernel of
 git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git.
 Which branch are you using ?

the master branch.

 However, after u-boot loading uImage  DTB, there is no output message any
 more, such as:
 Clk data might be missing here. Try merging the below branch and test it
 https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=for_3.11/out_of_tree/omap5_clk_data

Thanks, I'll have a try.

Baozi

 
 You can also use Linus's kernel with the above clk data branch.( OMAP5 uEVM 
 boots)
 Please let me know if you need more info.
 
 Thanks and regards,
 Lokesh
 
 
 ## Executing script at 8200
 reading omap5-evm-omap.dtb
 15280 bytes read in 6 ms (2.4 MiB/s)
 reading uImage-omap
 3996552 bytes read in 250 ms (15.2 MiB/s)
 ## Booting kernel from Legacy Image at 8030 ...
   Image Name:   Linux-3.10.0-rc6-12306-g0dbc346
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3996488 Bytes = 3.8 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
 ## Flattened Device Tree blob at 825f
   Booting using the fdt blob at 0x825f
   Loading Kernel Image ... OK
 OK
   reserving fdt memory region: addr=9d00 size=300
   Loading Device Tree to 83ff9000, end 83fffbaf ... OK
 
 Starting kernel ...
 
 Before trying this tree, I'm using the 3.8.4 kernel from TI. And it does
 support the board and can successfully boot.
 
 Anything that I may have missed when configuring the kernel? I use
 omap2plus_defconfig and add DEBUG_LL, DEBUG_OMAP2PLUS_UART,
 DEBUG_OMAP4UART3... 
 
 Cheers,
 
 Chen Baozi 
 --
 To unsubscribe from this list: send the line unsubscribe linux-omap in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Linux kernel for OMAP5432 uEVM

2013-07-30 Thread Chen Baozi
Hi Lokesh  list,

On Jul 30, 2013, at 11:52 AM, Lokesh Vutla lokeshvu...@ti.com wrote:

 Clk data might be missing here. Try merging the below branch and test it
 https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=for_3.11/out_of_tree/omap5_clk_data
 
 You can also use Linus's kernel with the above clk data branch.( OMAP5 uEVM 
 boots)
 Please let me know if you need more info.
 
 Thanks and regards,
 Lokesh

I've ported the two patches on the top of clk data branch to both of linux-omap 
tree and Linus's kernel. They all work now. Thanks a lot.

And a few more questions, ;-)

I read the timer initialization codes in kernel. It looks like the Linux kernel 
does not use the architected timer of Cortex-A15 MPCore. I tried to use 
arch_timer_get_cntfrq() to get its rate, but failed(returned frequency is 0). 
I'm wondering if it is because of lack of initialization or other issues.

Another question is about UART on OMAP5432. This is origin from my attempt to 
porting Xen to OMAP5432. Now Xen has already had a 8250 compatible driver. What 
I have done is to hook it with Xen's arm initialization codes (for example, 
hook it with device tree). Xen's original driver is rather simple compared to 
the Linux omap-serial.c. It enables receive and transmit interrupts in the end 
of initialization. Once the interrupt is enabled, it would generate nested 
interrupt of THRE and make the system dead loop in the interrupt handler. I 
have been digging this problem for nearly a month and haven't got a clue yet. I 
guess it might be caused by uninitialized architected timer, which then lead me 
to the previous question. Any idea?

Cheers,

Baozi--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Linux kernel for OMAP5432 uEVM

2013-07-30 Thread Chen Baozi

On Jul 30, 2013, at 8:24 PM, Nishanth Menon n...@ti.com wrote:

 On 07/30/2013 01:07 AM, Chen Baozi wrote:
 
 On Jul 30, 2013, at 11:52 AM, Lokesh Vutla lokeshvu...@ti.com wrote:
 
 Hi Chen,
 On Tuesday 30 July 2013 09:08 AM, Chen Baozi wrote:
 Hi all,
 
 I'm trying to boot my OMAP5432 uEVM devboard with the lastest kernel of
 git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git.
 Which branch are you using ?
 
 the master branch.
 
 However, after u-boot loading uImage  DTB, there is no output message any
 more, such as:
 Clk data might be missing here. Try merging the below branch and test it
 https://git.kernel.org/cgit/linux/kernel/git/ssantosh/linux.git/log/?h=for_3.11/out_of_tree/omap5_clk_data
 
 Thanks, I'll have a try.
 
 There is also clock data dts support now in Tero's series:
 http://marc.info/?l=linux-omapm=137456411706971w=2

Thanks, I'll have a look though Lokesh's suggestion has already booted my board.

Might be a stupid question. What's the different functionality between these 
two series of patch set? For it seems clk data patches have done the some of 
initialization that make the system boot.

Cheers,

Baozi--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Linux kernel for OMAP5432 uEVM

2013-07-29 Thread Chen Baozi
Hi all,

I'm trying to boot my OMAP5432 uEVM devboard with the lastest kernel of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git.
However, after u-boot loading uImage  DTB, there is no output message any
more, such as:

## Executing script at 8200
reading omap5-evm-omap.dtb
15280 bytes read in 6 ms (2.4 MiB/s)
reading uImage-omap
3996552 bytes read in 250 ms (15.2 MiB/s)
## Booting kernel from Legacy Image at 8030 ...
   Image Name:   Linux-3.10.0-rc6-12306-g0dbc346
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:3996488 Bytes = 3.8 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 825f
   Booting using the fdt blob at 0x825f
   Loading Kernel Image ... OK
OK
   reserving fdt memory region: addr=9d00 size=300
   Loading Device Tree to 83ff9000, end 83fffbaf ... OK

Starting kernel ...

Before trying this tree, I'm using the 3.8.4 kernel from TI. And it does
support the board and can successfully boot.

Anything that I may have missed when configuring the kernel? I use
omap2plus_defconfig and add DEBUG_LL, DEBUG_OMAP2PLUS_UART,
DEBUG_OMAP4UART3... 

Cheers,

Chen Baozi 
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html