Date   

Re: [PATCH 0/1] Enable to set RTC for beagleboard

Koen Kooi
 

Op 16 jun 2011, om 16:45 heeft Darren Hart het volgende geschreven:


On 06/15/2011 09:25 PM, Bruce Ashfield wrote:
On 11-06-15 10:23 PM, Lu Jingdong wrote:
On 06/16/2011 01:33 AM, Darren Hart wrote:

On 06/15/2011 09:52 AM, Bruce Ashfield wrote:
On 06/15/11 12:48, Darren Hart wrote:

On 06/15/2011 06:31 AM, Bruce Ashfield wrote:
On 06/15/11 09:25, Koen Kooi wrote:
Op 15 jun 2011, om 15:21 heeft Bruce Ashfield het volgende
geschreven:

On 06/15/11 06:41, Jingdong Lu wrote:
From: Jingdong Lu<jingdong.lu@...>

Ensure msecure is mux'd to be able to set the RTC for
beagleboard. Fixes bug [YOCTO #767]
Jingdong,

The fix looks reasonable to me, Darren has been refreshing the
beagleboard support as well, so I've cc'd him here to see if we
have this change present in the work in progress trees.
I do not have something similar queued.


What tests did you run to ensure that the RTC worked on the
beagleboard ? There was some debate around whether or not you
needed an add-on card to get this functionality available ?
The signal "msecure" on TPS65950 connects to "msecure" on OMAP3530 and
setting/writing RTC register is controlled by
OMAP3530 "msecure". So we should pull the "msecure" high on OMAP3530 so
that we can set/write RTC register on TPS65950.

We test RTC on beagleboard by adding this patch. RTC can be set a
correct date and
it works well when power on.
You need to remove some resistors and add a battery, or add an
expansionboard like the zippy or zippy2, which have a DS1307 RTC
with battery.
Because there is no backup battery on beagleboard C4, RTC can not be
saved when
power off. If we want to keep RTC without power, we should remove R66
and install
a battery on board.
Ack'd. For me, this is reasonable. Having a working RTC even
if it doesn't survive power cycle is worth having. In particular,
since the patch is simple.

Agreed.
FWIW, it survives warm resests.

regards,

Koen


Re: [PATCH 0/1] Enable to set RTC for beagleboard

Darren Hart <dvhart@...>
 

On 06/15/2011 09:25 PM, Bruce Ashfield wrote:
On 11-06-15 10:23 PM, Lu Jingdong wrote:
On 06/16/2011 01:33 AM, Darren Hart wrote:

On 06/15/2011 09:52 AM, Bruce Ashfield wrote:
On 06/15/11 12:48, Darren Hart wrote:

On 06/15/2011 06:31 AM, Bruce Ashfield wrote:
On 06/15/11 09:25, Koen Kooi wrote:
Op 15 jun 2011, om 15:21 heeft Bruce Ashfield het volgende
geschreven:

On 06/15/11 06:41, Jingdong Lu wrote:
From: Jingdong Lu<jingdong.lu@...>

Ensure msecure is mux'd to be able to set the RTC for
beagleboard. Fixes bug [YOCTO #767]
Jingdong,

The fix looks reasonable to me, Darren has been refreshing the
beagleboard support as well, so I've cc'd him here to see if we
have this change present in the work in progress trees.
I do not have something similar queued.


What tests did you run to ensure that the RTC worked on the
beagleboard ? There was some debate around whether or not you
needed an add-on card to get this functionality available ?
The signal "msecure" on TPS65950 connects to "msecure" on OMAP3530 and
setting/writing RTC register is controlled by
OMAP3530 "msecure". So we should pull the "msecure" high on OMAP3530 so
that we can set/write RTC register on TPS65950.

We test RTC on beagleboard by adding this patch. RTC can be set a
correct date and
it works well when power on.
You need to remove some resistors and add a battery, or add an
expansionboard like the zippy or zippy2, which have a DS1307 RTC
with battery.
Because there is no backup battery on beagleboard C4, RTC can not be
saved when
power off. If we want to keep RTC without power, we should remove R66
and install
a battery on board.
Ack'd. For me, this is reasonable. Having a working RTC even
if it doesn't survive power cycle is worth having. In particular,
since the patch is simple.

Agreed.



Thanks Koen,

This confirms what I thought (zippy*), so clearly this is either a
board with that setup, or runtime testing was .. unique. Either way,
more details and research is needed for this one.
I'll wait to hear upstream status on this. Given the requirements for
use, I wouldn't mind just closing 767 as will not fix as it can't work
with the beagleboard out of the box anyway.
I'm ok with that resolution .. for the bug. But if the patch
isn't already in another upstream tree, it's worth having
(if benign to the rest of the variants) and then we can get
it sent upstream from there.

I can change the bug's status if you like.
I want to hear back from Jingdong regarding this patch first. Is this
new code? If so, then yes, let's get it to mainline as Bruce suggested.
This patch can be found on linux-omap tree.
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=e2a346a2a054f702fd76f328ff747b9ad9264a4c
perfect.


arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC
Without msecure beeing high it isn't possible to set (or start)
the RTC.

Tested with a BeagleBoard C4.

Signed-off-by: Alexander Holler <holler@...>
Signed-off-by: Tony Lindgren <tony@...>

So maybe I should recommit it by adding some upstream status and author.
This is key. We must have this in our patch commits. I can provide
examples if you aren't familiar and Mark Hatle just sent out some oe-core
examples of the same thing.

In this case you'd put something like:

commit e2a346a2a054f7 from
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git

after the shortlog, and before the long log. Add your Integrated-by:
to the sign off section of the patch.

I will just pull the patch and add Jingdong as the Integrated-by.

--
Darren


Cheers,

Bruce



regards,

Jingdong
Cheers,

Bruce


--
Darren

Cheers,

Bruce

regards,

Koen
_______________________________________________ yocto mailing list
yocto@... https://lists.yoctoproject.org/listinfo/yocto
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Re: [PATCH 1/1] RTC: Ensure msecure is mux'd to be able to set RTC

Bruce Ashfield <bruce.ashfield@...>
 

On 06/16/11 03:27, Koen Kooi wrote:

Op 16 jun 2011, om 08:07 heeft Jingdong Lu het volgende geschreven:

From: Jingdong Lu<jingdong.lu@...>

commit e2a346a2a054f702fd76f328ff747b9ad9264a4c from git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
When I do 'git show e2a346a2a054f702fd76f328ff747b9ad9264a4' I get:

commit e2a346a2a054f702fd76f328ff747b9ad9264a4c
Author: Alexander Holler<holler@...>

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Date: Tue Apr 5 15:40:08 2011 +0200

arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC

Without msecure beeing high it isn't possible to set (or start)
the RTC.

Tested with a BeagleBoard C4.

Signed-off-by: Alexander Holler<holler@...>
Signed-off-by: Tony Lindgren<tony@...>

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index be71426..d64ed97 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -579,6 +579,9 @@ static void __init omap3_beagle_init(void)
omap_nand_flash_init(NAND_BUSWIDTH_16, omap3beagle_nand_partitions,
ARRAY_SIZE(omap3beagle_nand_partitions));

+ /* Ensure msecure is mux'd to be able to set the RTC. */
+ omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);


So if you're going to change the author, you'd also need to remove the SOBs.
It's likely just a glitch in patch generation.

Jindong: did you cherry-pick or git am this for the import
into your tree ? Or did you use another technique ?
If done properly, the author is always maintained in our
imported patches.

Cheers,

Bruce



arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC.
"Msecure" signal provides for protection of the RTC register in TPS65950 be
disabling that function via a control signal from the OMAP3530. So ensure
msecure is mux'd to be able to set the RTC.

Tested with a BeagleBoard C4.
Fixes bug [YOCTO #767]

Signed-off-by: Alexander Holler<holler@...>
Signed-off-by: Tony Lindgren<tony@...>
Integrated-by: Jingdong Lu<jingdong.lu@...>
---
arch/arm/mach-omap2/board-omap3beagle.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index af1166b..925c0b3 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -580,6 +580,9 @@ static void __init omap3_beagle_init(void)
usb_ehci_init(&ehci_pdata);
omap3beagle_flash_init();

+ /* Ensure msecure is mux'd to be able to set the RTC. */
+ omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
--
1.7.0.4

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: [PATCH 1/1] RTC: Ensure msecure is mux'd to be able to set RTC

Bruce Ashfield <bruce.ashfield@...>
 

On 06/16/11 02:13, Liming Wang wrote:
On 2011-6-16 14:07, Jingdong Lu wrote:
From: Jingdong Lu<jingdong.lu@...>

commit e2a346a2a054f702fd76f328ff747b9ad9264a4c from
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
It's fine if you break this line into two lines.
arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC.
"Msecure" signal provides for protection of the RTC register in
TPS65950 be
disabling that function via a control signal from the OMAP3530. So ensure
msecure is mux'd to be able to set the RTC.

Tested with a BeagleBoard C4.
Fixes bug [YOCTO #767]
I think it's best to put your comment in the top line.
And we don't want the bug tracking information directly
in the kernel commits, it just ends up cluttering things.

It's fine to include this in the 0/N email, but not in
the commit message itself.

Cheers,

Bruce


Liming Wang
Signed-off-by: Alexander Holler<holler@...>
Signed-off-by: Tony Lindgren<tony@...>
Integrated-by: Jingdong Lu<jingdong.lu@...>
---
arch/arm/mach-omap2/board-omap3beagle.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index af1166b..925c0b3 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -580,6 +580,9 @@ static void __init omap3_beagle_init(void)
usb_ehci_init(&ehci_pdata);
omap3beagle_flash_init();

+ /* Ensure msecure is mux'd to be able to set the RTC. */
+ omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: [PATCH 1/1] RTC: Ensure msecure is mux'd to be able to set RTC

Koen Kooi
 

Op 16 jun 2011, om 08:07 heeft Jingdong Lu het volgende geschreven:

From: Jingdong Lu <jingdong.lu@...>

commit e2a346a2a054f702fd76f328ff747b9ad9264a4c from git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
When I do 'git show e2a346a2a054f702fd76f328ff747b9ad9264a4' I get:

commit e2a346a2a054f702fd76f328ff747b9ad9264a4c
Author: Alexander Holler <holler@...>

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Date: Tue Apr 5 15:40:08 2011 +0200

arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC

Without msecure beeing high it isn't possible to set (or start)
the RTC.

Tested with a BeagleBoard C4.

Signed-off-by: Alexander Holler <holler@...>
Signed-off-by: Tony Lindgren <tony@...>

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index be71426..d64ed97 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -579,6 +579,9 @@ static void __init omap3_beagle_init(void)
omap_nand_flash_init(NAND_BUSWIDTH_16, omap3beagle_nand_partitions,
ARRAY_SIZE(omap3beagle_nand_partitions));

+ /* Ensure msecure is mux'd to be able to set the RTC. */
+ omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);


So if you're going to change the author, you'd also need to remove the SOBs.


arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC.
"Msecure" signal provides for protection of the RTC register in TPS65950 be
disabling that function via a control signal from the OMAP3530. So ensure
msecure is mux'd to be able to set the RTC.

Tested with a BeagleBoard C4.
Fixes bug [YOCTO #767]

Signed-off-by: Alexander Holler <holler@...>
Signed-off-by: Tony Lindgren <tony@...>
Integrated-by: Jingdong Lu <jingdong.lu@...>
---
arch/arm/mach-omap2/board-omap3beagle.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index af1166b..925c0b3 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -580,6 +580,9 @@ static void __init omap3_beagle_init(void)
usb_ehci_init(&ehci_pdata);
omap3beagle_flash_init();

+ /* Ensure msecure is mux'd to be able to set the RTC. */
+ omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
--
1.7.0.4

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: [PATCH 1/1] RTC: Ensure msecure is mux'd to be able to set RTC

Liming Wang <liming.wang@...>
 

On 2011-6-16 14:07, Jingdong Lu wrote:
From: Jingdong Lu<jingdong.lu@...>

commit e2a346a2a054f702fd76f328ff747b9ad9264a4c from git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git
It's fine if you break this line into two lines.
arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC.
"Msecure" signal provides for protection of the RTC register in TPS65950 be
disabling that function via a control signal from the OMAP3530. So ensure
msecure is mux'd to be able to set the RTC.

Tested with a BeagleBoard C4.
Fixes bug [YOCTO #767]
I think it's best to put your comment in the top line.

Liming Wang
Signed-off-by: Alexander Holler<holler@...>
Signed-off-by: Tony Lindgren<tony@...>
Integrated-by: Jingdong Lu<jingdong.lu@...>
---
arch/arm/mach-omap2/board-omap3beagle.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index af1166b..925c0b3 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -580,6 +580,9 @@ static void __init omap3_beagle_init(void)
usb_ehci_init(&ehci_pdata);
omap3beagle_flash_init();

+ /* Ensure msecure is mux'd to be able to set the RTC. */
+ omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);


[PATCH 1/1] RTC: Ensure msecure is mux'd to be able to set RTC

Jingdong Lu <jingdong.lu@...>
 

From: Jingdong Lu <jingdong.lu@...>

commit e2a346a2a054f702fd76f328ff747b9ad9264a4c from git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git

arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC.
"Msecure" signal provides for protection of the RTC register in TPS65950 be
disabling that function via a control signal from the OMAP3530. So ensure
msecure is mux'd to be able to set the RTC.

Tested with a BeagleBoard C4.
Fixes bug [YOCTO #767]

Signed-off-by: Alexander Holler <holler@...>
Signed-off-by: Tony Lindgren <tony@...>
Integrated-by: Jingdong Lu <jingdong.lu@...>
---
arch/arm/mach-omap2/board-omap3beagle.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index af1166b..925c0b3 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -580,6 +580,9 @@ static void __init omap3_beagle_init(void)
usb_ehci_init(&ehci_pdata);
omap3beagle_flash_init();

+ /* Ensure msecure is mux'd to be able to set the RTC. */
+ omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
--
1.7.0.4


[PATCH 0/1] RTC: Ensure msecure is mux'd to be able to set RTC for beagleboard

Jingdong Lu <jingdong.lu@...>
 

From: Jingdong Lu <jingdong.lu@...>

Ensure msecure is mux'd to be able to set the RTC for beagleboard.
Fixes bug [YOCTO #767]

Jingdong Lu (1):
RTC: Ensure msecure is mux'd to be able to set RTC

arch/arm/mach-omap2/board-omap3beagle.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)


Re: configure optimization feature update

Xu, Dongxiao <dongxiao.xu@...>
 

-----Original Message-----
From: Khem Raj [mailto:raj.khem@...]
Sent: Thursday, June 16, 2011 9:29 AM
To: Xu, Dongxiao
Cc: Richard Purdie (richard.purdie@...);
yocto@...
Subject: Re: [yocto] configure optimization feature update

On Wed, Jun 15, 2011 at 5:57 PM, Xu, Dongxiao <dongxiao.xu@...>
wrote:
Hi Richard,

Recently I was doing the "configure optimization" feature and collecting data
for it.

The main logic of this feature is straight forward:

1. Use the diff file as autoreconf cache. (I use command: "diff -ruN
SOURCE-ORIG SOURCE", here "SOURCE-ORIG" is the source directory before
running autoreconf, while "SOURCE" is the directory after running autoreconf).
2. Add SRC_URI checksum for all patches of the source code.
3. Tag each autoreconf cache file with ${PN} and the SRC_URI checksum of
source code and all patches.
4. If the currently SRC_URI checksum matches the cached checksum, then we
can patch the cache instead of running "autoreconf" stage.
The autoconf'ing is sort of arbitrary at the moment. Depending on what is
staged the results may vary. So some way of creating a cache is nice since it
can be used to verify if package rebuild happens with same configure variables
or not. Sometimes we have seen some packages are build differently first time
since many packages are not staged.


I did some testings for sato build, the result is not as good as we expected:

On a server build machine (Genuine Intel(R) CPU @ 2.40GHz, 2 sockets with 6
core each and hyperthreading, thus 24 logical CPUs in all, 66G memory):

w/o the optimization:
real    83m40.963s
user    496m58.550s
sys     329m1.590s

w/ the optimization:
real    79m1.062s
user    460m58.600s
sys     347m42.120s

It has about 5% performance gain.

I also tested the patch on a desktop core-i7 machine (Intel(R) Core(TM) i7
CPU 870 @ 2.93GHz, 4 core 8 logical CPU, 4G memory):

w/o the optimization:
real    105m25.436s
user    372m48.040s
sys     51m23.950s

w/ the optimization:
real    103m38.314s
user    332m35.770s
sys     49m4.520s

It only has about 2% performance gain.

The result is not encouraging.

There are also some other things we need to take into consideration for this
feature:

1. If add this feature, the first build time should be longer than current since it
needs to build the autoreconf cache.
2. Maintainers needs to maintain the SRC_URI checksums not only for source
code, but also all its patches. For some recipes, it has more than 20 patches,
which needs assignable maintenance effort.

Yeah thats definite pain.

3. How to distribute the caches will be a problem. The total size of such cache
is about 900M (before compression) and 200M (after compression). Since the
size is not small, distributing it with Poky source code doesn't make sense. On
another aspect, we can use something like "sstate". But since we already have
caches of sstate, I think it is not necessary for us to enable another similar
cache mechanism with little improvement.
hmm this is a real problem and probably the perf killer. I wonder why the sizes
are so big.
I diff the source files before and after autoreconf and using the generated patch as our autoreconf cache. For a certain source code, for example connman, such diff file will be as large as 3M, and for a sato build, we have about 300 recipes need autoreconf.

Thanks,
Dongxiao


Therefore my opinion is we may give up this feature. What's your comments
and suggestions?

Thanks,
Dongxiao

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Re: [PATCH 0/1] Enable to set RTC for beagleboard

Bruce Ashfield <bruce.ashfield@...>
 

On 11-06-15 10:23 PM, Lu Jingdong wrote:
On 06/16/2011 01:33 AM, Darren Hart wrote:

On 06/15/2011 09:52 AM, Bruce Ashfield wrote:
On 06/15/11 12:48, Darren Hart wrote:

On 06/15/2011 06:31 AM, Bruce Ashfield wrote:
On 06/15/11 09:25, Koen Kooi wrote:
Op 15 jun 2011, om 15:21 heeft Bruce Ashfield het volgende
geschreven:

On 06/15/11 06:41, Jingdong Lu wrote:
From: Jingdong Lu<jingdong.lu@...>

Ensure msecure is mux'd to be able to set the RTC for
beagleboard. Fixes bug [YOCTO #767]
Jingdong,

The fix looks reasonable to me, Darren has been refreshing the
beagleboard support as well, so I've cc'd him here to see if we
have this change present in the work in progress trees.
I do not have something similar queued.


What tests did you run to ensure that the RTC worked on the
beagleboard ? There was some debate around whether or not you
needed an add-on card to get this functionality available ?
The signal "msecure" on TPS65950 connects to "msecure" on OMAP3530 and
setting/writing RTC register is controlled by
OMAP3530 "msecure". So we should pull the "msecure" high on OMAP3530 so
that we can set/write RTC register on TPS65950.

We test RTC on beagleboard by adding this patch. RTC can be set a
correct date and
it works well when power on.
You need to remove some resistors and add a battery, or add an
expansionboard like the zippy or zippy2, which have a DS1307 RTC
with battery.
Because there is no backup battery on beagleboard C4, RTC can not be
saved when
power off. If we want to keep RTC without power, we should remove R66
and install
a battery on board.
Ack'd. For me, this is reasonable. Having a working RTC even
if it doesn't survive power cycle is worth having. In particular,
since the patch is simple.


Thanks Koen,

This confirms what I thought (zippy*), so clearly this is either a
board with that setup, or runtime testing was .. unique. Either way,
more details and research is needed for this one.
I'll wait to hear upstream status on this. Given the requirements for
use, I wouldn't mind just closing 767 as will not fix as it can't work
with the beagleboard out of the box anyway.
I'm ok with that resolution .. for the bug. But if the patch
isn't already in another upstream tree, it's worth having
(if benign to the rest of the variants) and then we can get
it sent upstream from there.

I can change the bug's status if you like.
I want to hear back from Jingdong regarding this patch first. Is this
new code? If so, then yes, let's get it to mainline as Bruce suggested.
This patch can be found on linux-omap tree.
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=e2a346a2a054f702fd76f328ff747b9ad9264a4c
perfect.


arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC
Without msecure beeing high it isn't possible to set (or start)
the RTC.

Tested with a BeagleBoard C4.

Signed-off-by: Alexander Holler <holler@...>
Signed-off-by: Tony Lindgren <tony@...>

So maybe I should recommit it by adding some upstream status and author.
This is key. We must have this in our patch commits. I can provide
examples if you aren't familiar and Mark Hatle just sent out some oe-core
examples of the same thing.

In this case you'd put something like:

commit e2a346a2a054f7 from git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git

after the shortlog, and before the long log. Add your Integrated-by:
to the sign off section of the patch.

Cheers,

Bruce



regards,

Jingdong
Cheers,

Bruce


--
Darren

Cheers,

Bruce

regards,

Koen
_______________________________________________ yocto mailing list
yocto@... https://lists.yoctoproject.org/listinfo/yocto


Re: [PATCH 0/1] Enable to set RTC for beagleboard

Lu Jingdong <jingdong.lu@...>
 

On 06/16/2011 01:33 AM, Darren Hart wrote:

On 06/15/2011 09:52 AM, Bruce Ashfield wrote:
On 06/15/11 12:48, Darren Hart wrote:

On 06/15/2011 06:31 AM, Bruce Ashfield wrote:
On 06/15/11 09:25, Koen Kooi wrote:
Op 15 jun 2011, om 15:21 heeft Bruce Ashfield het volgende
geschreven:

On 06/15/11 06:41, Jingdong Lu wrote:
From: Jingdong Lu<jingdong.lu@...>

Ensure msecure is mux'd to be able to set the RTC for
beagleboard. Fixes bug [YOCTO #767]
Jingdong,

The fix looks reasonable to me, Darren has been refreshing the
beagleboard support as well, so I've cc'd him here to see if we
have this change present in the work in progress trees.
I do not have something similar queued.


What tests did you run to ensure that the RTC worked on the
beagleboard ? There was some debate around whether or not you
needed an add-on card to get this functionality available ?
The signal "msecure" on TPS65950 connects to "msecure" on OMAP3530 and setting/writing RTC register is controlled by
OMAP3530 "msecure". So we should pull the "msecure" high on OMAP3530 so that we can set/write RTC register on TPS65950.

We test RTC on beagleboard by adding this patch. RTC can be set a correct date and
it works well when power on.
You need to remove some resistors and add a battery, or add an
expansionboard like the zippy or zippy2, which have a DS1307 RTC
with battery.
Because there is no backup battery on beagleboard C4, RTC can not be saved when
power off. If we want to keep RTC without power, we should remove R66 and install
a battery on board.

Thanks Koen,

This confirms what I thought (zippy*), so clearly this is either a
board with that setup, or runtime testing was .. unique. Either way,
more details and research is needed for this one.
I'll wait to hear upstream status on this. Given the requirements for
use, I wouldn't mind just closing 767 as will not fix as it can't work
with the beagleboard out of the box anyway.
I'm ok with that resolution .. for the bug. But if the patch
isn't already in another upstream tree, it's worth having
(if benign to the rest of the variants) and then we can get
it sent upstream from there.

I can change the bug's status if you like.
I want to hear back from Jingdong regarding this patch first. Is this
new code? If so, then yes, let's get it to mainline as Bruce suggested.
This patch can be found on linux-omap tree.
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=e2a346a2a054f702fd76f328ff747b9ad9264a4c

arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC
Without msecure beeing high it isn't possible to set (or start)
the RTC.

Tested with a BeagleBoard C4.

Signed-off-by: Alexander Holler <holler@...>
Signed-off-by: Tony Lindgren <tony@...>

So maybe I should recommit it by adding some upstream status and author.

regards,

Jingdong
Cheers,

Bruce


--
Darren

Cheers,

Bruce

regards,

Koen
_______________________________________________ yocto mailing list
yocto@... https://lists.yoctoproject.org/listinfo/yocto
--
Lu Jingdong
jingdong.lu@...
China, Wind River


Re: configure optimization feature update

Khem Raj
 

On Wed, Jun 15, 2011 at 5:57 PM, Xu, Dongxiao <dongxiao.xu@...> wrote:
Hi Richard,

Recently I was doing the "configure optimization" feature and collecting data for it.

The main logic of this feature is straight forward:

1. Use the diff file as autoreconf cache. (I use command: "diff -ruN SOURCE-ORIG SOURCE", here "SOURCE-ORIG" is the source directory before running autoreconf, while "SOURCE" is the directory after running autoreconf).
2. Add SRC_URI checksum for all patches of the source code.
3. Tag each autoreconf cache file with ${PN} and the SRC_URI checksum of source code and all patches.
4. If the currently SRC_URI checksum matches the cached checksum, then we can patch the cache instead of running "autoreconf" stage.
The autoconf'ing is sort of arbitrary at the moment. Depending on what
is staged the results may vary. So some way of creating a cache is
nice since it can be used to verify if package
rebuild happens with same configure variables or not. Sometimes we
have seen some packages are build differently first time since many
packages are not staged.


I did some testings for sato build, the result is not as good as we expected:

On a server build machine (Genuine Intel(R) CPU @ 2.40GHz, 2 sockets with 6 core each and hyperthreading, thus 24 logical CPUs in all, 66G memory):

w/o the optimization:
real    83m40.963s
user    496m58.550s
sys     329m1.590s

w/ the optimization:
real    79m1.062s
user    460m58.600s
sys     347m42.120s

It has about 5% performance gain.

I also tested the patch on a desktop core-i7 machine (Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz, 4 core 8 logical CPU, 4G memory):

w/o the optimization:
real    105m25.436s
user    372m48.040s
sys     51m23.950s

w/ the optimization:
real    103m38.314s
user    332m35.770s
sys     49m4.520s

It only has about 2% performance gain.

The result is not encouraging.

There are also some other things we need to take into consideration for this feature:

1. If add this feature, the first build time should be longer than current since it needs to build the autoreconf cache.
2. Maintainers needs to maintain the SRC_URI checksums not only for source code, but also all its patches. For some recipes, it has more than 20 patches, which needs assignable maintenance effort.
Yeah thats definite pain.

3. How to distribute the caches will be a problem. The total size of such cache is about 900M (before compression) and 200M (after compression). Since the size is not small, distributing it with Poky source code doesn't make sense. On another aspect, we can use something like "sstate". But since we already have caches of sstate, I think it is not necessary for us to enable another similar cache mechanism with little improvement.
hmm this is a real problem and probably the perf killer. I wonder why
the sizes are so big.

Therefore my opinion is we may give up this feature. What's your comments and suggestions?

Thanks,
Dongxiao

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


configure optimization feature update

Xu, Dongxiao <dongxiao.xu@...>
 

Hi Richard,

Recently I was doing the "configure optimization" feature and collecting data for it.

The main logic of this feature is straight forward:

1. Use the diff file as autoreconf cache. (I use command: "diff -ruN SOURCE-ORIG SOURCE", here "SOURCE-ORIG" is the source directory before running autoreconf, while "SOURCE" is the directory after running autoreconf).
2. Add SRC_URI checksum for all patches of the source code.
3. Tag each autoreconf cache file with ${PN} and the SRC_URI checksum of source code and all patches.
4. If the currently SRC_URI checksum matches the cached checksum, then we can patch the cache instead of running "autoreconf" stage.

I did some testings for sato build, the result is not as good as we expected:

On a server build machine (Genuine Intel(R) CPU @ 2.40GHz, 2 sockets with 6 core each and hyperthreading, thus 24 logical CPUs in all, 66G memory):

w/o the optimization:
real 83m40.963s
user 496m58.550s
sys 329m1.590s

w/ the optimization:
real 79m1.062s
user 460m58.600s
sys 347m42.120s

It has about 5% performance gain.

I also tested the patch on a desktop core-i7 machine (Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz, 4 core 8 logical CPU, 4G memory):

w/o the optimization:
real 105m25.436s
user 372m48.040s
sys 51m23.950s

w/ the optimization:
real 103m38.314s
user 332m35.770s
sys 49m4.520s

It only has about 2% performance gain.

The result is not encouraging.

There are also some other things we need to take into consideration for this feature:

1. If add this feature, the first build time should be longer than current since it needs to build the autoreconf cache.
2. Maintainers needs to maintain the SRC_URI checksums not only for source code, but also all its patches. For some recipes, it has more than 20 patches, which needs assignable maintenance effort.
3. How to distribute the caches will be a problem. The total size of such cache is about 900M (before compression) and 200M (after compression). Since the size is not small, distributing it with Poky source code doesn't make sense. On another aspect, we can use something like "sstate". But since we already have caches of sstate, I think it is not necessary for us to enable another similar cache mechanism with little improvement.

Therefore my opinion is we may give up this feature. What's your comments and suggestions?

Thanks,
Dongxiao


Re: [PATCH 0/1] Enable to set RTC for beagleboard

Darren Hart <dvhart@...>
 

On 06/15/2011 09:52 AM, Bruce Ashfield wrote:
On 06/15/11 12:48, Darren Hart wrote:


On 06/15/2011 06:31 AM, Bruce Ashfield wrote:
On 06/15/11 09:25, Koen Kooi wrote:

Op 15 jun 2011, om 15:21 heeft Bruce Ashfield het volgende
geschreven:

On 06/15/11 06:41, Jingdong Lu wrote:
From: Jingdong Lu<jingdong.lu@...>

Ensure msecure is mux'd to be able to set the RTC for
beagleboard. Fixes bug [YOCTO #767]
Jingdong,

The fix looks reasonable to me, Darren has been refreshing the
beagleboard support as well, so I've cc'd him here to see if we
have this change present in the work in progress trees.

I do not have something similar queued.


What tests did you run to ensure that the RTC worked on the
beagleboard ? There was some debate around whether or not you
needed an add-on card to get this functionality available ?
You need to remove some resistors and add a battery, or add an
expansionboard like the zippy or zippy2, which have a DS1307 RTC
with battery.
Thanks Koen,

This confirms what I thought (zippy*), so clearly this is either a
board with that setup, or runtime testing was .. unique. Either way,
more details and research is needed for this one.

I'll wait to hear upstream status on this. Given the requirements for
use, I wouldn't mind just closing 767 as will not fix as it can't work
with the beagleboard out of the box anyway.
I'm ok with that resolution .. for the bug. But if the patch
isn't already in another upstream tree, it's worth having
(if benign to the rest of the variants) and then we can get
it sent upstream from there.

I can change the bug's status if you like.

I want to hear back from Jingdong regarding this patch first. Is this
new code? If so, then yes, let's get it to mainline as Bruce suggested.



Cheers,

Bruce



--
Darren

Cheers,

Bruce


regards,

Koen
_______________________________________________ yocto mailing list
yocto@... https://lists.yoctoproject.org/listinfo/yocto
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Re: [PATCH 0/1] Enable to set RTC for beagleboard

Bruce Ashfield <bruce.ashfield@...>
 

On 06/15/11 12:48, Darren Hart wrote:


On 06/15/2011 06:31 AM, Bruce Ashfield wrote:
On 06/15/11 09:25, Koen Kooi wrote:

Op 15 jun 2011, om 15:21 heeft Bruce Ashfield het volgende
geschreven:

On 06/15/11 06:41, Jingdong Lu wrote:
From: Jingdong Lu<jingdong.lu@...>

Ensure msecure is mux'd to be able to set the RTC for
beagleboard. Fixes bug [YOCTO #767]
Jingdong,

The fix looks reasonable to me, Darren has been refreshing the
beagleboard support as well, so I've cc'd him here to see if we
have this change present in the work in progress trees.

I do not have something similar queued.


What tests did you run to ensure that the RTC worked on the
beagleboard ? There was some debate around whether or not you
needed an add-on card to get this functionality available ?
You need to remove some resistors and add a battery, or add an
expansionboard like the zippy or zippy2, which have a DS1307 RTC
with battery.
Thanks Koen,

This confirms what I thought (zippy*), so clearly this is either a
board with that setup, or runtime testing was .. unique. Either way,
more details and research is needed for this one.

I'll wait to hear upstream status on this. Given the requirements for
use, I wouldn't mind just closing 767 as will not fix as it can't work
with the beagleboard out of the box anyway.
I'm ok with that resolution .. for the bug. But if the patch
isn't already in another upstream tree, it's worth having
(if benign to the rest of the variants) and then we can get
it sent upstream from there.

I can change the bug's status if you like.

Cheers,

Bruce



--
Darren

Cheers,

Bruce


regards,

Koen
_______________________________________________ yocto mailing list
yocto@... https://lists.yoctoproject.org/listinfo/yocto


Re: [PATCH 0/1] Enable to set RTC for beagleboard

Darren Hart <dvhart@...>
 

On 06/15/2011 06:31 AM, Bruce Ashfield wrote:
On 06/15/11 09:25, Koen Kooi wrote:

Op 15 jun 2011, om 15:21 heeft Bruce Ashfield het volgende
geschreven:

On 06/15/11 06:41, Jingdong Lu wrote:
From: Jingdong Lu<jingdong.lu@...>

Ensure msecure is mux'd to be able to set the RTC for
beagleboard. Fixes bug [YOCTO #767]
Jingdong,

The fix looks reasonable to me, Darren has been refreshing the
beagleboard support as well, so I've cc'd him here to see if we
have this change present in the work in progress trees.

I do not have something similar queued.


What tests did you run to ensure that the RTC worked on the
beagleboard ? There was some debate around whether or not you
needed an add-on card to get this functionality available ?
You need to remove some resistors and add a battery, or add an
expansionboard like the zippy or zippy2, which have a DS1307 RTC
with battery.
Thanks Koen,

This confirms what I thought (zippy*), so clearly this is either a
board with that setup, or runtime testing was .. unique. Either way,
more details and research is needed for this one.

I'll wait to hear upstream status on this. Given the requirements for
use, I wouldn't mind just closing 767 as will not fix as it can't work
with the beagleboard out of the box anyway.


--
Darren

Cheers,

Bruce


regards,

Koen
_______________________________________________ yocto mailing list
yocto@... https://lists.yoctoproject.org/listinfo/yocto
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


Re: [PATCH 0/1] Enable to set RTC for beagleboard

Bruce Ashfield <bruce.ashfield@...>
 

On 06/15/11 09:25, Koen Kooi wrote:

Op 15 jun 2011, om 15:21 heeft Bruce Ashfield het volgende geschreven:

On 06/15/11 06:41, Jingdong Lu wrote:
From: Jingdong Lu<jingdong.lu@...>

Ensure msecure is mux'd to be able to set the RTC for beagleboard.
Fixes bug [YOCTO #767]
Jingdong,

The fix looks reasonable to me, Darren has been refreshing
the beagleboard support as well, so I've cc'd him here to
see if we have this change present in the work in progress
trees.

What tests did you run to ensure that the RTC worked on
the beagleboard ? There was some debate around whether or
not you needed an add-on card to get this functionality
available ?
You need to remove some resistors and add a battery, or add an expansionboard like the zippy or zippy2, which have a DS1307 RTC with battery.
Thanks Koen,

This confirms what I thought (zippy*), so clearly this is
either a board with that setup, or runtime testing was
.. unique. Either way, more details and research is
needed for this one.

Cheers,

Bruce


regards,

Koen


Re: [PATCH 0/1] Enable to set RTC for beagleboard

Koen Kooi
 

Op 15 jun 2011, om 15:21 heeft Bruce Ashfield het volgende geschreven:

On 06/15/11 06:41, Jingdong Lu wrote:
From: Jingdong Lu<jingdong.lu@...>

Ensure msecure is mux'd to be able to set the RTC for beagleboard.
Fixes bug [YOCTO #767]
Jingdong,

The fix looks reasonable to me, Darren has been refreshing
the beagleboard support as well, so I've cc'd him here to
see if we have this change present in the work in progress
trees.

What tests did you run to ensure that the RTC worked on
the beagleboard ? There was some debate around whether or
not you needed an add-on card to get this functionality
available ?
You need to remove some resistors and add a battery, or add an expansionboard like the zippy or zippy2, which have a DS1307 RTC with battery.

regards,

Koen


Re: [PATCH 0/1] Enable to set RTC for beagleboard

Bruce Ashfield <bruce.ashfield@...>
 

On 06/15/11 06:41, Jingdong Lu wrote:
From: Jingdong Lu<jingdong.lu@...>

Ensure msecure is mux'd to be able to set the RTC for beagleboard.
Fixes bug [YOCTO #767]
Jingdong,

The fix looks reasonable to me, Darren has been refreshing
the beagleboard support as well, so I've cc'd him here to
see if we have this change present in the work in progress
trees.

What tests did you run to ensure that the RTC worked on
the beagleboard ? There was some debate around whether or
not you needed an add-on card to get this functionality
available ?

Also for for any beagleboard changes, we should:

- check the various upstream trees and use their commits
if possible. Or if you've checked and couldn't find
anything. State that in the patch submission.

- reference the test platform details. Rev of the board,
the model, etc.

Thanks for the patch, we just need to do a bit more
checking on it before we can get it into the tree.

Cheers,

Bruce


Jingdong Lu (1):
RTC: Enable to set RTC

arch/arm/mach-omap2/board-omap3beagle.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


[PATCH 1/1] RTC: Enable to set RTC

Jingdong Lu <jingdong.lu@...>
 

From: Jingdong Lu <jingdong.lu@...>

"Msecure" signal provides for protection of the RTC register in TPS65950 be
disabling that function via a control signal from the OMAP3530. So ensure
msecure is mux'd to be able to set the RTC.
Fixes bug [YOCTO #767]

Signed-off-by: Jingdong Lu <jingdong.lu@...>
---
arch/arm/mach-omap2/board-omap3beagle.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index af1166b..925c0b3 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -580,6 +580,9 @@ static void __init omap3_beagle_init(void)
usb_ehci_init(&ehci_pdata);
omap3beagle_flash_init();

+ /* Ensure msecure is mux'd to be able to set the RTC. */
+ omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
/* Ensure SDRC pins are mux'd for self-refresh */
omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
--
1.7.0.4