[PATCH 0/5] Misc updates for EZX bits in OE

[PATCH 0/5] Misc updates for EZX bits in OE

[Antonio Ospite]

Hi,

here are some updates for EZX bits in OE.

With these changes we have a working image to experiment with ts27010mux
driver and ezxd, no fso support yet. Tested on Motorola A780.

Note that although ezx-gen-blob builds fine now, it seems to have issues with
GCC 4.4: the binary size is about 300KiB instead of the expected 64KiB, if
anyone has a clue please let me know.

Thanks,
   Antonio

Antonio Ospite (5):
  ezx: update openezx-kernel version
  ezx: update ezx-boot-usb-native version
  ezx: update ezxd version and ezxd.init script
  ezx: update ezx-gen-blob version
  ezx: update device_table-ezx.txt

 conf/distro/include/sane-srcrevs.inc   |    8 ++++----
 files/device_table-ezx.txt             |    6 +++---
 recipes/ezx/ezx-boot-usb-native_svn.bb |    2 +-
 recipes/ezx/ezxd/ezxd.init             |    5 +++++
 recipes/ezx/ezxd_svn.bb                |    4 +++-
 recipes/linux/openezx-kernel_git.bb    |    4 ++--
 6 files changed, 18 insertions(+), 11 deletions(-)


-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[PATCH 1/5] ezx: update openezx-kernel version

[Antonio Ospite]

This version uses an adapted ts27010mux driver from Motorola Milestone.

Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
---
 conf/distro/include/sane-srcrevs.inc |    2 +-
 recipes/linux/openezx-kernel_git.bb  |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/conf/distro/include/sane-srcrevs.inc b/conf/distro/include/sane-srcrevs.inc
index da44903..7e08ca0 100644
--- a/conf/distro/include/sane-srcrevs.inc
+++ b/conf/distro/include/sane-srcrevs.inc
@@ -138,7 +138,7 @@ SRCREV_pn-ologicd ?= "4a32af91a9479ebd4d1d39057354ac9904d74cbb"
 SRCREV_pn-om-locations ?= "942e88a1b689ffe3f11a2d982cce389cc965b2ec"
 SRCREV_pn-openbsc ?= "5e68183a201ab92f29cd2467df5209f7b351a66d"
 SRCREV_pn-openbsc-onwaves ?= "0d9ed87d5c7d5b6e21dc3bbb282e215068742566"
-SRCREV_pn-openezx-kernel ?= "43b844d1d38f0343272d3f0f844f80666186c526"
+SRCREV_pn-openezx-kernel ?= "b390bb1ee708277297fdfd38e26d955b17d81c2e"
 SRCREV_pn-openmoko-footer ?= "2354"
 SRCREV_pn-openmoko-terminal2 ?= "4782"
 SRCREV_pn-openmoocow ?= "39648419825cddfea1cb1321e552a12b71fede14"
diff --git a/recipes/linux/openezx-kernel_git.bb b/recipes/linux/openezx-kernel_git.bb
index 64fac44..a986b4a 100644
--- a/recipes/linux/openezx-kernel_git.bb
+++ b/recipes/linux/openezx-kernel_git.bb
@@ -1,9 +1,9 @@
 DESCRIPTION = "OpenEZX 2.6 Linux Development Kernel for the Motorola EZX GSM phones"
 AUTHOR = "The OpenEZX Team <openezx-devel@lists.openezx.org>"
 HOMEPAGE = "http://www.openezx.org"
-KV = "2.6.29+2.6.30rc2"
+KV = "2.6.33"
 PV = "${KV}+gitr${SRCREV}"
-PR = "r3"
+PR = "r4"
 
 require linux.inc
 
-- 
1.7.0.3

Re: [PATCH 1/5] ezx: update openezx-kernel version

[Stefan Schmidt]

Hello.

On Thu, 2010-03-25 at 18:19, Antonio Ospite wrote:
> This version uses an adapted ts27010mux driver from Motorola Milestone.
> 
> Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>

Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>

regards
Stefan Schmidt

[PATCH 2/5] ezx: update ezx-boot-usb-native version

[Antonio Ospite]

Fix also ezx-boot-usb-native_svn.bb as the code now resides in a 'src'
subdirectory.

Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
---
 conf/distro/include/sane-srcrevs.inc   |    2 +-
 recipes/ezx/ezx-boot-usb-native_svn.bb |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/conf/distro/include/sane-srcrevs.inc b/conf/distro/include/sane-srcrevs.inc
index 7e08ca0..2248e78 100644
--- a/conf/distro/include/sane-srcrevs.inc
+++ b/conf/distro/include/sane-srcrevs.inc
@@ -55,7 +55,7 @@ SRCREV_pn-elf2flt ?= "1786"
 SRCREV_pn-epdfview ?= "346"
 SRCREV_pn-epiphany ?= "7837"
 SRCREV_pn-essential-dialer ?= "194"
-SRCREV_pn-ezx-boot-usb-native ?= "2371"
+SRCREV_pn-ezx-boot-usb-native ?= "2512"
 SRCREV_pn-ezx-gen-blob ?= "2426"
 SRCREV_pn-ezxd ?= "2074"
 SRCREV_pn-fbgrab-viewer-native ?= "1943"
diff --git a/recipes/ezx/ezx-boot-usb-native_svn.bb b/recipes/ezx/ezx-boot-usb-native_svn.bb
index 1298cac..237d06b 100644
--- a/recipes/ezx/ezx-boot-usb-native_svn.bb
+++ b/recipes/ezx/ezx-boot-usb-native_svn.bb
@@ -14,7 +14,7 @@ inherit autotools native
 
 do_deploy() {
         install -d ${DEPLOY_DIR_TOOLS}
-        install -m 0755 boot_usb ${DEPLOY_DIR_TOOLS}/ezx-boot-usb-${PV}
+        install -m 0755 src/boot_usb ${DEPLOY_DIR_TOOLS}/ezx-boot-usb-${PV}
 }
 
 do_stage() {
-- 
1.7.0.3

Re: [PATCH 2/5] ezx: update ezx-boot-usb-native version

[Stefan Schmidt]

Hello.

On Thu, 2010-03-25 at 18:19, Antonio Ospite wrote:
> Fix also ezx-boot-usb-native_svn.bb as the code now resides in a 'src'
> subdirectory.
> 
> Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>

Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>

regards
Stefan Schmidt

[PATCH 3/5] ezx: update ezxd version and ezxd.init script

[Antonio Ospite]

Newer kernels have drivers for BP interaction built as modules, add the
loading sequence in ezxd.init.

Fix also the recipe so that the CC and CROSS variables do not interfere
with the crosscompiler from OE.

Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
---
 conf/distro/include/sane-srcrevs.inc |    2 +-
 recipes/ezx/ezxd/ezxd.init           |    5 +++++
 recipes/ezx/ezxd_svn.bb              |    4 +++-
 3 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/conf/distro/include/sane-srcrevs.inc b/conf/distro/include/sane-srcrevs.inc
index 2248e78..1b4972a 100644
--- a/conf/distro/include/sane-srcrevs.inc
+++ b/conf/distro/include/sane-srcrevs.inc
@@ -57,7 +57,7 @@ SRCREV_pn-epiphany ?= "7837"
 SRCREV_pn-essential-dialer ?= "194"
 SRCREV_pn-ezx-boot-usb-native ?= "2512"
 SRCREV_pn-ezx-gen-blob ?= "2426"
-SRCREV_pn-ezxd ?= "2074"
+SRCREV_pn-ezxd ?= "2513"
 SRCREV_pn-fbgrab-viewer-native ?= "1943"
 SRCREV_pn-flashrom ?= "3682"
 SRCREV_pn-frameworkd-config-shr ?= "cdf5b5f3d8f37d6d91e1eb8d9cf07d034291df87"
diff --git a/recipes/ezx/ezxd/ezxd.init b/recipes/ezx/ezxd/ezxd.init
index a345952..ba44942 100644
--- a/recipes/ezx/ezxd/ezxd.init
+++ b/recipes/ezx/ezxd/ezxd.init
@@ -37,6 +37,11 @@ start_it_up()
   fi
 
   echo -n "Starting $DESC: "
+  modprobe ohci-hcd
+  sleep 2
+  modprobe moto-usb-ipc
+  modprobe ts27010mux
+
   start-stop-daemon --start --background --quiet --pidfile $PIDFILE \
     --exec $DAEMON -- --system $PARAMS
   # We need to sleep here because opening the mux devices takes some time
diff --git a/recipes/ezx/ezxd_svn.bb b/recipes/ezx/ezxd_svn.bb
index 134980f..19bbd93 100644
--- a/recipes/ezx/ezxd_svn.bb
+++ b/recipes/ezx/ezxd_svn.bb
@@ -22,7 +22,9 @@ CFLAGS_append = " -DDEBUG "
 TARGET_CC_ARCH += "${LDFLAGS}"
 
 do_configure() {
-        sed -i -e s:CROSS:CC:g Makefile
+        # Comment out both CC and CROSS definitions
+        sed -i -e 's:^CC.*$:#\0:g' Makefile
+        sed -i -e 's:^CROSS.*$:#\0:g' Makefile
 }
 
 fakeroot do_install() {
-- 
1.7.0.3

Re: [PATCH 3/5] ezx: update ezxd version and ezxd.init script

[Stefan Schmidt]

Hello.

On Thu, 2010-03-25 at 18:19, Antonio Ospite wrote:
> Newer kernels have drivers for BP interaction built as modules, add the
> loading sequence in ezxd.init.
> 
> Fix also the recipe so that the CC and CROSS variables do not interfere
> with the crosscompiler from OE.

Hmm, we should really think about moving it from the handwritten makefile to
autotools. On the other hand it was never designed to stay ... as so much other
code. :)

Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>

regards
Stefan Schmidt

[PATCH 4/5] ezx: update ezx-gen-blob version

[Antonio Ospite]

NOTE: this version builds fine but the resulting binaries do not seem to
be correct, their size is about 300KiB instead of the expected 64KiB.

Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
---
 conf/distro/include/sane-srcrevs.inc |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/conf/distro/include/sane-srcrevs.inc b/conf/distro/include/sane-srcrevs.inc
index 1b4972a..8451e3d 100644
--- a/conf/distro/include/sane-srcrevs.inc
+++ b/conf/distro/include/sane-srcrevs.inc
@@ -56,7 +56,7 @@ SRCREV_pn-epdfview ?= "346"
 SRCREV_pn-epiphany ?= "7837"
 SRCREV_pn-essential-dialer ?= "194"
 SRCREV_pn-ezx-boot-usb-native ?= "2512"
-SRCREV_pn-ezx-gen-blob ?= "2426"
+SRCREV_pn-ezx-gen-blob ?= "2517"
 SRCREV_pn-ezxd ?= "2513"
 SRCREV_pn-fbgrab-viewer-native ?= "1943"
 SRCREV_pn-flashrom ?= "3682"
-- 
1.7.0.3

Re: [PATCH 4/5] ezx: update ezx-gen-blob version

[Stefan Schmidt]

Hello.

On Thu, 2010-03-25 at 18:19, Antonio Ospite wrote:
> NOTE: this version builds fine but the resulting binaries do not seem to
> be correct, their size is about 300KiB instead of the expected 64KiB.
> 
> Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>

I would need some more information before acking this one. Does the old rev
still build with the gcc in OE?

If yes I would prefer to stay with the old rev as a known working one until the
root cause is found and fixed. If it does not even build we could go ahead and
bump the rev as it does make things not even worse.

Side note for others: Personally I know nobody who ever installed the gen-blob
produced with OE on his phone. All people who did it used a precompiled version
from Wyrm, Antonio or me or compiled it by hand. So this one should not bring to
much harm.

regards
Stefan Schmidt

Re: [PATCH 4/5] ezx: update ezx-gen-blob version

[Antonio Ospite]

[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]

On Thu, 25 Mar 2010 18:42:40 +0100
Stefan Schmidt <stefan@datenfreihafen.org> wrote:

> Hello.
> 
> On Thu, 2010-03-25 at 18:19, Antonio Ospite wrote:
> > NOTE: this version builds fine but the resulting binaries do not seem to
> > be correct, their size is about 300KiB instead of the expected 64KiB.
> > 
> > Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
> 
> I would need some more information before acking this one. Does the old rev
> still build with the gcc in OE?
> 
> If yes I would prefer to stay with the old rev as a known working one until the
> root cause is found and fixed. If it does not even build we could go ahead and
> bump the rev as it does make things not even worse.
>

The current version doesn't even build, so bumping the revision is good
even if doesn't solve the size issue.

> Side note for others: Personally I know nobody who ever installed the gen-blob
> produced with OE on his phone. All people who did it used a precompiled version
> from Wyrm, Antonio or me or compiled it by hand. So this one should not bring to
> much harm.
>

As you may guess, even compiling it manually "doesn't work" anymore with
a recent toolchain...  to be more precise: I've tried running the
big binary loading it via usb, it seems to work but it is just not
suitable to be flashed because of its size.

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH 4/5] ezx: update ezx-gen-blob version

[Stefan Schmidt]

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

Hello.

On Thu, 2010-03-25 at 19:13, Antonio Ospite wrote:
> On Thu, 25 Mar 2010 18:42:40 +0100
> Stefan Schmidt <stefan@datenfreihafen.org> wrote:
> 
> > On Thu, 2010-03-25 at 18:19, Antonio Ospite wrote:
> > > NOTE: this version builds fine but the resulting binaries do not seem to
> > > be correct, their size is about 300KiB instead of the expected 64KiB.
> > > 
> > > Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
> > 
> > I would need some more information before acking this one. Does the old rev
> > still build with the gcc in OE?
> > 
> > If yes I would prefer to stay with the old rev as a known working one until the
> > root cause is found and fixed. If it does not even build we could go ahead and
> > bump the rev as it does make things not even worse.
> >
> 
> The current version doesn't even build, so bumping the revision is good
> even if doesn't solve the size issue.
> 
> > Side note for others: Personally I know nobody who ever installed the gen-blob
> > produced with OE on his phone. All people who did it used a precompiled version
> > from Wyrm, Antonio or me or compiled it by hand. So this one should not bring to
> > much harm.
> >
> 
> As you may guess, even compiling it manually "doesn't work" anymore with
> a recent toolchain...  to be more precise: I've tried running the
> big binary loading it via usb, it seems to work but it is just not
> suitable to be flashed because of its size.

Interesting. It is stripped, right? Anyway, as the old one does not build and
the new one "works" you have my

Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>

regards
Stefan Schmidt

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

Re: [PATCH 4/5] ezx: update ezx-gen-blob version

[Antonio Ospite]

[-- Attachment #1: Type: text/plain, Size: 1626 bytes --]

On Thu, 25 Mar 2010 19:30:50 +0100
Stefan Schmidt <stefan@datenfreihafen.org> wrote:

> Hello.
> 
> On Thu, 2010-03-25 at 19:13, Antonio Ospite wrote:
> > On Thu, 25 Mar 2010 18:42:40 +0100
> > Stefan Schmidt <stefan@datenfreihafen.org> wrote:
> > 
> > > On Thu, 2010-03-25 at 18:19, Antonio Ospite wrote:
> > > > NOTE: this version builds fine but the resulting binaries do not seem to
> > > > be correct, their size is about 300KiB instead of the expected 64KiB.
[...]
> > > Side note for others: Personally I know nobody who ever installed the gen-blob
> > > produced with OE on his phone. All people who did it used a precompiled version
> > > from Wyrm, Antonio or me or compiled it by hand. So this one should not bring to
> > > much harm.
> > >
> >
> > As you may guess, even compiling it manually "doesn't work" anymore with
> > a recent toolchain...  to be more precise: I've tried running the
> > big binary loading it via usb, it seems to work but it is just not
> > suitable to be flashed because of its size.
> 
> Interesting. It is stripped, right?

Yep.

> Anyway, as the old one does not build and
> the new one "works" you have my
>
> Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>
> 

Thanks.
Stefan are you also going to push these changes?

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH 4/5] ezx: update ezx-gen-blob version

[Stefan Schmidt]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

Hello.

On Thu, 2010-03-25 at 20:06, Antonio Ospite wrote:
> 
> Stefan are you also going to push these changes?

Yes. I want to give others a moment to comment before pushing this in. Will do
it on friday or saturday.

Thanks for your work on this.

regards
Stefan Schmidt

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

Re: [PATCH 4/5] ezx: update ezx-gen-blob version

[Stefan Schmidt]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

Hello.

On Thu, 2010-03-25 at 20:10, Stefan Schmidt wrote:
> 
> On Thu, 2010-03-25 at 20:06, Antonio Ospite wrote:
> > 
> > Stefan are you also going to push these changes?
> 
> Yes. I want to give others a moment to comment before pushing this in. Will do
> it on friday or saturday.

Just tested and pushed the changes.

regards
Stefan Schmidt

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]

[PATCH 5/5] ezx: update device_table-ezx.txt

[Antonio Ospite]

Update mux nodes to be used with the ts27010mux driver.
Fix names for ttyIPC0 and video0 nodes.

Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>
---
 files/device_table-ezx.txt |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/files/device_table-ezx.txt b/files/device_table-ezx.txt
index f477a67..7246bc8 100644
--- a/files/device_table-ezx.txt
+++ b/files/device_table-ezx.txt
@@ -8,7 +8,7 @@
 #    b	Block special device file
 #    p	Fifo (named pipe)
 
-/dev/mux	c	660	0	5	250	0	1	1	8
-/dev/ttyIPC	c	660	0	5	251	0	-	-	-
+/dev/mux	c	660	0	5	234	0	0	1	9
+/dev/ttyIPC0	c	660	0	5	251	0	-	-	-
 /dev/input/uinput	c	660 	0	0	10	223	-	-	-
-/dev/video	c	660	0	44	81	0	-	-	-
+/dev/video0	c	660	0	44	81	0	-	-	-
-- 
1.7.0.3

Re: [PATCH 5/5] ezx: update device_table-ezx.txt

[Stefan Schmidt]

Hello.

On Thu, 2010-03-25 at 18:19, Antonio Ospite wrote:
> Update mux nodes to be used with the ts27010mux driver.
> Fix names for ttyIPC0 and video0 nodes.
> 
> Signed-off-by: Antonio Ospite <ospite@studenti.unina.it>

Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>

regards
Stefan Schmidt

Re: [PATCH 0/5] Misc updates for EZX bits in OE

[Khem Raj]

On (25/03/10 18:19), Antonio Ospite wrote:
> Hi,
> 
> here are some updates for EZX bits in OE.
> 
> With these changes we have a working image to experiment with ts27010mux
> driver and ezxd, no fso support yet. Tested on Motorola A780.
> 
> Note that although ezx-gen-blob builds fine now, it seems to have issues with
> GCC 4.4: the binary size is about 300KiB instead of the expected 64KiB, if
> anyone has a clue please let me know.

I can help you here. If you can give me the two images with symbols and
your linking script it uses. Secondly are you using same binutils/ld in
both cases ?

-Khem

Re: [PATCH 0/5] Misc updates for EZX bits in OE

[Antonio Ospite]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

On Thu, 25 Mar 2010 13:39:00 -0700
Khem Raj <raj.khem@gmail.com> wrote:

> On (25/03/10 18:19), Antonio Ospite wrote:
[...]
> > Note that although ezx-gen-blob builds fine now, it seems to have issues with
> > GCC 4.4: the binary size is about 300KiB instead of the expected 64KiB, if
> > anyone has a clue please let me know.
> 
> I can help you here. If you can give me the two images with symbols and
> your linking script it uses. Secondly are you using same binutils/ld in
> both cases ?
>

I'll dig for an older toolchain in order to replicate the two
scenarios, and get back here to get your help.
Many thanks for your offer Khem.

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH 0/5] Misc updates for EZX bits in OE

[Antonio Ospite]

[-- Attachment #1.1: Type: text/plain, Size: 1868 bytes --]

On Thu, 25 Mar 2010 13:39:00 -0700
Khem Raj <raj.khem@gmail.com> wrote:

> On (25/03/10 18:19), Antonio Ospite wrote:
> > Hi,
> > 
> > here are some updates for EZX bits in OE.
> > 
> > With these changes we have a working image to experiment with ts27010mux
> > driver and ezxd, no fso support yet. Tested on Motorola A780.
> > 
> > Note that although ezx-gen-blob builds fine now, it seems to have issues with
> > GCC 4.4: the binary size is about 300KiB instead of the expected 64KiB, if
> > anyone has a clue please let me know.
> 
> I can help you here. If you can give me the two images with symbols and
> your linking script it uses. Secondly are you using same binutils/ld in
> both cases ?
>

Here are more details:
A gcc-4.1.2 toolchain[1] produces the expected result,
the current gcc-4.4.2 toolchain[2] from 'minimal' distro does not.

I am using the very ld the toolchain provides, so I they are
different, and I noted than the 4.4.2 one gives this warning:
.../arm-oe-linux-gnueabi/bin/ld:
warning: section `.bss' type changed to PROGBITS

The problem seems to rise during linking indeed, the size difference
of .o files produced by the two toolchains is ~ 3 KiB overall, it does
not seem to justify the bump I have after linking to more than 200KiB.

I am attaching here the two binaries before stripping, but also some
scripts to easily recreate the entire scenario, since I am not sure of
what you exactly need to find out what's happening.
The command used for linking is attached as well.

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: __01_replicate_gen-blob_issue.sh --]
[-- Type: text/x-sh; name="__01_replicate_gen-blob_issue.sh", Size: 2067 bytes --]

#!/bin/sh

# Location of a recent kernel configured with ARCH=arm
ARM_KERNEL_DIR=/home/ao2/Proj/EZX/src/kernel/2.6/openezx/

# Build gen-blob with gcc-4.1.2
wget -nc http://ezxdev.org/qtopia/sdk/arm-angstrom-linux-gnueabi-4.1.2.tar.bz2
tar xjvf arm-angstrom-linux-gnueabi-4.1.2.tar.bz2
svn co http://svn.openezx.org/trunk/src/blob/gen-blob/ gen-blob-with-gcc-4.1.2
cd gen-blob-with-gcc-4.1.2
. `pwd`/setenv3
PATH=$PATH:`pwd`/../usr/local/angstrom/arm/bin \
  ./configure \
  --with-board=lubbock \
  --with-cpu=pxa262 \
  --with-linux-prefix=$ARM_KERNEL_DIR \
  --enable-usb 2>&1 | tee ../configure-with-gcc-4.1.2.log
PATH=$PATH:`pwd`/../usr/local/angstrom/arm/bin \
  make 2>&1 | tee ../build-with-gcc-4.1.2.log
cp src/blob/blob-rest-elf32 ../blob-rest-elf32-with-gcc-4.1.2
cd ..

PATH=$PATH:`pwd`/usr/local/angstrom/arm/bin \
  arm-angstrom-linux-gnueabi-objcopy \
  -O binary \
  -R .note \
  -R .comment \
  -S blob-rest-elf32-with-gcc-4.1.2 blob-rest-with-gcc-4.1.2



# Build gen-blob with gcc-4.4.2
wget -nc http://people.openezx.org/ao2/deploy/sdk/minimal-dev-snapshot-20100323-x86_64-linux-armv5te-linux-gnueabi-toolchain.tar.bz2
tar xjvf minimal-dev-snapshot-20100323-x86_64-linux-armv5te-linux-gnueabi-toolchain.tar.bz2
svn co http://svn.openezx.org/trunk/src/blob/gen-blob/ gen-blob-with-gcc-4.4.2
cd gen-blob-with-gcc-4.4.2
. `pwd`/setenv4
PATH=$PATH:`pwd`/../usr/local/minimal/arm/bin \
  ./configure \
  --with-board=lubbock \
  --with-cpu=pxa262 \
  --with-linux-prefix=$ARM_KERNEL_DIR \
  --enable-usb 2>&1 | tee ../configure-with-gcc-4.4.2.log
PATH=$PATH:`pwd`/../usr/local/minimal/arm/bin \
  make 2>&1 | tee ../build-with-gcc-4.4.2.log
cp src/blob/blob-rest-elf32 ../blob-rest-elf32-with-gcc-4.4.2
cd ..

PATH=$PATH:`pwd`/usr/local/minimal/arm/bin \
  arm-oe-linux-gnueabi-objcopy \
  -O binary \
  -R .note \
  -R .comment \
  -S blob-rest-elf32-with-gcc-4.4.2 blob-rest-with-gcc-4.4.2



# Compare file sizes in bytes
./__02_obj-files-size-comparison.sh > obj-files-size-comparison.dat

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: __02_obj-files-size-comparison.sh --]
[-- Type: text/x-sh; name="__02_obj-files-size-comparison.sh", Size: 802 bytes --]

#!/bin/sh

printf "%-30s" "# obj file"
printf " %10s" "size-4.1.2"
printf " %10s" "size-4.4.2"
printf " %10s" "difference"
printf "\n"

TOT1=0
TOT2=0
TOTDIFF=0

FILES=$(find gen-blob-with-gcc-4.1.2/ -name "*.o")
for file in $FILES;
do 
  NAME=$(echo $file | cut -d '/' -f 2-)
  SIZE1=$(stat -c "%s" gen-blob-with-gcc-4.1.2/$NAME)
  SIZE2=$(stat -c "%s" gen-blob-with-gcc-4.4.2/$NAME)
  DIFF=$(expr -- $SIZE2 - $SIZE1)

  TOT1=$(expr -- $TOT1 + $SIZE1)
  TOT2=$(expr -- $TOT2 + $SIZE2)
  TOTDIFF=$(expr -- $TOTDIFF + $DIFF)

  printf "%-30s" "$NAME"
  printf " %10d" "$SIZE1"
  printf " %10d" "$SIZE2"
  printf " %10d" "$DIFF"
  printf "\n"
done

printf "\n"
printf "%-30s" "TOTAL"
printf " %10d" "$TOT1"
printf " %10d" "$TOT2"
printf " %10d" "$TOTDIFF"
printf "\n"

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.4: __03_link_cmd.sh --]
[-- Type: text/x-sh; name="__03_link_cmd.sh", Size: 1311 bytes --]

#!/bin/sh

# NOTE: Run this in gen-blob-x.x.x/src/blob
# Changing the PREFIX and CROSS you can use another linker and see
# the difference in size for the generated binary.

ARM_KERNEL_DIR=/home/ao2/Proj/EZX/src/kernel/2.6/openezx/

PREFIX=/home/ao2/Proj/EZX/OE/gen-blob-test/usr/local/angstrom/arm/bin/
CROSS=arm-angstrom-linux-gnueabi-

#PREFIX=/home/ao2/Proj/EZX/OE/gen-blob-test/usr/local/minimal/arm/bin/
#CROSS=arm-oe-linux-gnueabi-


OBJS="trampoline.o flashasm.o stack.o testmem2.o bootldrpart.o linux.o main.o
initcalls.o memory.o param_block.o printlcd_8bit.o flash.o pcap.o keypad.o
SW_init.o HW_init.o handshake.o boot_modes.o usb-mot1.o bl_cmds_handler.o
bl_parser.o bl_utility.o mmc.o vsprintf.o ctype.o part.o part_dos.o file.o
fat.o menu.o usb_ctl.o usb_ep0.o usb_ep1.o usb_ep2.o lubbock.o intel16.o"

${PREFIX}/${CROSS}gcc \
  -Os \
  -I${ARM_KERNEL_DIR}/include \
  -I${ARM_KERNEL_DIR}/arch/arm/include \
  -Wall \
  -march=armv4 -mtune=strongarm1100 -mno-thumb-interwork \
  -fomit-frame-pointer -fno-builtin -nostdinc \
  -DCPU_pxa262 -DMBM -DHAINAN \
  -static -nostdlib \
  -o blob-rest-elf32 \
  -Wl,-T,rest-ld-script \
  $OBJS \
  -L../../src/lib -lblob -lgcc -lc

${PREFIX}/${CROSS}objcopy -O binary -R .note -R .comment -S blob-rest-elf32 blob-rest

[-- Attachment #1.5: blob-rest-elf32-with-gcc-4.1.2 --]
[-- Type: application/octet-stream, Size: 110220 bytes --]

[-- Attachment #1.6: blob-rest-elf32-with-gcc-4.4.2 --]
[-- Type: application/octet-stream, Size: 333310 bytes --]

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH 0/5] Misc updates for EZX bits in OE

[Antonio Ospite]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

On Fri, 26 Mar 2010 16:17:24 +0100
Antonio Ospite <ospite@studenti.unina.it> wrote:

> Here are more details:
> A gcc-4.1.2 toolchain[1] produces the expected result,
> the current gcc-4.4.2 toolchain[2] from 'minimal' distro does not.
> 

Forgot the refs in previous mail even if they were in the attached
script. And I hope the attached 600KB didn't annoy people _too_much_

Regards,
   Antonio

[1]
http://ezxdev.org/qtopia/sdk/arm-angstrom-linux-gnueabi-4.1.2.tar.bz2
[2]
http://people.openezx.org/ao2/deploy/sdk/minimal-dev-snapshot-20100323-x86_64-linux-armv5te-linux-gnueabi-toolchain.tar.bz2

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: [PATCH 0/5] Misc updates for EZX bits in OE

[Antonio Ospite]

[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]

On Fri, 26 Mar 2010 16:17:24 +0100
Antonio Ospite <ospite@studenti.unina.it> wrote:

> On Thu, 25 Mar 2010 13:39:00 -0700
> Khem Raj <raj.khem@gmail.com> wrote:
> 
> > On (25/03/10 18:19), Antonio Ospite wrote:
> > > Hi,
> > > 
> > > here are some updates for EZX bits in OE.
> > > 
> > > With these changes we have a working image to experiment with ts27010mux
> > > driver and ezxd, no fso support yet. Tested on Motorola A780.
> > > 
> > > Note that although ezx-gen-blob builds fine now, it seems to have issues with
> > > GCC 4.4: the binary size is about 300KiB instead of the expected 64KiB, if
> > > anyone has a clue please let me know.
> > 
> > I can help you here. If you can give me the two images with symbols and
> > your linking script it uses. Secondly are you using same binutils/ld in
> > both cases ?
> >
> 
> Here are more details:
> A gcc-4.1.2 toolchain[1] produces the expected result,
> the current gcc-4.4.2 toolchain[2] from 'minimal' distro does not.
>

Hi Khem, would you be able to take a look at this?
The attachments I sent in the old mail are still available here:
http://thread.gmane.org/gmane.comp.handhelds.openembedded/31488/focus=31520

Thanks,
   Antonio

> I am using the very ld the toolchain provides, so I they are
> different, and I noted than the 4.4.2 one gives this warning:
> .../arm-oe-linux-gnueabi/bin/ld:
> warning: section `.bss' type changed to PROGBITS
> 
> The problem seems to rise during linking indeed, the size difference
> of .o files produced by the two toolchains is ~ 3 KiB overall, it does
> not seem to justify the bump I have after linking to more than 200KiB.
> 
> I am attaching here the two binaries before stripping, but also some
> scripts to easily recreate the entire scenario, since I am not sure of
> what you exactly need to find out what's happening.
> The command used for linking is attached as well.
> 
> Thanks,
>    Antonio
> 

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: gen-blob size with gcc-4.4.2 SOLVED? (was: [PATCH 0/5] Misc updates for EZX bits in OE)

[Antonio Ospite]

[-- Attachment #1: Type: text/plain, Size: 5654 bytes --]

WARNING:
This was going to be a
  "I didn't know what I was doing but it worked"
kind of post, but then I did some homework and now I think I know a bit
more about what I did :)

The post below is quite lengthy as it contains all the steps I went
through in order to come to some conclusions.

On Fri, 26 Mar 2010 16:17:24 +0100
Antonio Ospite <ospite@studenti.unina.it> wrote:

> On Thu, 25 Mar 2010 13:39:00 -0700
> Khem Raj <raj.khem@gmail.com> wrote:
> 
> > On (25/03/10 18:19), Antonio Ospite wrote:
[...]
> > > Note that although ezx-gen-blob builds fine now, it seems to have issues with
> > > GCC 4.4: the binary size is about 300KiB instead of the expected 64KiB, if
> > > anyone has a clue please let me know.
> >

Comparing the section sizes for the two binaries:
   text    data     bss     dec     hex filename
  40212   20764  244356  305332   4a8b4 blob-rest-elf32-with-gcc-4.1.2
  39595  265124       4  304723   4a653 blob-rest-elf32-with-gcc-4.4.2

So something fishing about the data and bss sections. After reading
a bit about what ELF sections are[0,1] I'd guess gcc-4.4.2 might be
forcing initializations for uninitialized data putting it in the
binary image and that makes the object file size grow.

This explanation would also help me to understand more the warning
message:
.../arm-oe-linux-gnueabi/bin/ld:
warning: section `.bss' type changed to PROGBITS

> > I can help you here. If you can give me the two images with symbols and
> > your linking script it uses. Secondly are you using same binutils/ld in
> > both cases ?
> >
>

I also had to learn what a linker script[2] is, it can be used to
define sections properties and object files layout, right?
The one used by blob/gen-blob is here:
http://svn.openezx.org/trunk/src/blob/gen-blob/src/blob/rest-ld-script.in

Now, looking at the bss section, I noted that there is a "nested"
"stack" section, this is different from the other sections, so as a
first naive/blind try I changed that from:
	. = ALIGN(4);
	.bss : {
		__bss_start = .;
		/* first the real BSS data */
		*(.bss) 

		/* and next the stack */
		. = ALIGN(4);
		__stack_start = .;
		*(.stack)
		__stack_end = .;
		__bss_end = .;
	}
to
	/* the BSS section should *always* be the last section */
	. = ALIGN(4);
	.bss : {
		__bss_start = .;
		/* first the real BSS data */
		*(.bss) 
		__bss_end = .;
	}

	/* and next the stack */
	. = ALIGN(4);
	.stack : {
		__stack_start = .;
		*(.stack)
		__stack_end = .;
	}

And the binary sizes is now:
   text    data     bss     dec     hex filename
  40212   20764  244356  305332   4a8b4 blob-rest-elf32-with-gcc-4.1.2
  39595   20772  227972  288339   46653 blob-rest-elf32-with-gcc-4.4.2

The "strange thing" is that after this blind change from a very rough
guess-work the binary even seemed to work... so I did some more research
to figure out a more "correct" solution.

I found out somewhere on the interwebs that the "nesting" shouldn't be a
problem, and that stack size can be defined directly inside the
linker script, like in [3], so I tried with this change (getting the
actual stack size from src/blob/stack.S):

Index: gen-blob-with-gcc-4.4.2/src/blob/rest-ld-script.in
===================================================================
--- gen-blob-with-gcc-4.4.2.orig/src/blob/rest-ld-script.in
+++ gen-blob-with-gcc-4.4.2/src/blob/rest-ld-script.in
@@ -97,7 +97,8 @@
                /* and next the stack */
                . = ALIGN(4);
                __stack_start = .;
-               *(.stack)
+               /* allocate a 16kB stack */
+               . = . + 16 * 1024;
                __stack_end = .;
                __bss_end = .;


Sizes are now:
   text    data     bss     dec     hex filename
  40212   20764  244356  305332   4a8b4 blob-rest-elf32-with-gcc-4.1.2
  39595   20772  244356  304723   4a653 blob-rest-elf32-with-gcc-4.4.2

bss size matches, this a good sign, not a coincidence, isnt'it? And
the binary still works. Is that really ok?

[...]
> I am using the very ld the toolchain provides, so I they are
> different, and I noted than the 4.4.2 one gives this warning:
> .../arm-oe-linux-gnueabi/bin/ld:
> warning: section `.bss' type changed to PROGBITS
>

This warning goes away with either the changes above.

So the last patch above would look ok to me, I think I figured out WHAT
was happening, but I don't understand WHY this change is necessary.
Is that the section name ".stack" defined in stack.S is not recognized?
If so, why?

Khem I am now only asking you if you can help me understand why newer
GCCs don't behave in the same way as older ones wrt. this aspect.
Thanks.

> The problem seems to rise during linking indeed, the size difference
> of .o files produced by the two toolchains is ~ 3 KiB overall, it does
> not seem to justify the bump I have after linking to more than 200KiB.
>

After several hours spent on this, but with at least some XP gained :)
Yours truly,
   Antonio

[0]
http://infocenter.arm.com/help/topic/com.arm.doc.dui0101a/DUI0101A_Elf.pdf
[1]
http://www.tortall.net/projects/yasm/manual/html/objfmt-elf-section.html
[2] http://www.math.utah.edu/docs/info/ld_toc.html#SEC4
[3] http://sourceware.org/ml/binutils/2007-11/msg00016.html

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]

Re: gen-blob size with gcc-4.4.2 SOLVED? (was: [PATCH 0/5] Misc updates for EZX bits in OE)

[Khem Raj]

On Fri, Apr 23, 2010 at 5:28 AM, Antonio Ospite
<ospite@studenti.unina.it> wrote:
> WARNING:
> This was going to be a
>  "I didn't know what I was doing but it worked"
> kind of post, but then I did some homework and now I think I know a bit
> more about what I did :)
>
> The post below is quite lengthy as it contains all the steps I went
> through in order to come to some conclusions.
>
> On Fri, 26 Mar 2010 16:17:24 +0100
> Antonio Ospite <ospite@studenti.unina.it> wrote:
>
>> On Thu, 25 Mar 2010 13:39:00 -0700
>> Khem Raj <raj.khem@gmail.com> wrote:
>>
>> > On (25/03/10 18:19), Antonio Ospite wrote:
> [...]
>> > > Note that although ezx-gen-blob builds fine now, it seems to have issues with
>> > > GCC 4.4: the binary size is about 300KiB instead of the expected 64KiB, if
>> > > anyone has a clue please let me know.
>> >
>
> Comparing the section sizes for the two binaries:
>   text    data     bss     dec     hex filename
>  40212   20764  244356  305332   4a8b4 blob-rest-elf32-with-gcc-4.1.2
>  39595  265124       4  304723   4a653 blob-rest-elf32-with-gcc-4.4.2
>
> So something fishing about the data and bss sections. After reading
> a bit about what ELF sections are[0,1] I'd guess gcc-4.4.2 might be
> forcing initializations for uninitialized data putting it in the
> binary image and that makes the object file size grow.
>
> This explanation would also help me to understand more the warning
> message:
> .../arm-oe-linux-gnueabi/bin/ld:
> warning: section `.bss' type changed to PROGBITS
>
>> > I can help you here. If you can give me the two images with symbols and
>> > your linking script it uses. Secondly are you using same binutils/ld in
>> > both cases ?
>> >
>>
>
> I also had to learn what a linker script[2] is, it can be used to
> define sections properties and object files layout, right?
> The one used by blob/gen-blob is here:
> http://svn.openezx.org/trunk/src/blob/gen-blob/src/blob/rest-ld-script.in
>
> Now, looking at the bss section, I noted that there is a "nested"
> "stack" section, this is different from the other sections, so as a
> first naive/blind try I changed that from:
>        . = ALIGN(4);
>        .bss : {
>                __bss_start = .;
>                /* first the real BSS data */
>                *(.bss)
>
>                /* and next the stack */
>                . = ALIGN(4);
>                __stack_start = .;
>                *(.stack)
>                __stack_end = .;
>                __bss_end = .;
>        }
> to
>        /* the BSS section should *always* be the last section */
>        . = ALIGN(4);
>        .bss : {
>                __bss_start = .;
>                /* first the real BSS data */
>                *(.bss)
>                __bss_end = .;
>        }
>
>        /* and next the stack */
>        . = ALIGN(4);
>        .stack : {
>                __stack_start = .;
>                *(.stack)
>                __stack_end = .;
>        }
>
> And the binary sizes is now:
>   text    data     bss     dec     hex filename
>  40212   20764  244356  305332   4a8b4 blob-rest-elf32-with-gcc-4.1.2
>  39595   20772  227972  288339   46653 blob-rest-elf32-with-gcc-4.4.2
>
> The "strange thing" is that after this blind change from a very rough
> guess-work the binary even seemed to work... so I did some more research
> to figure out a more "correct" solution.
>
> I found out somewhere on the interwebs that the "nesting" shouldn't be a
> problem, and that stack size can be defined directly inside the
> linker script, like in [3], so I tried with this change (getting the
> actual stack size from src/blob/stack.S):
>
> Index: gen-blob-with-gcc-4.4.2/src/blob/rest-ld-script.in
> ===================================================================
> --- gen-blob-with-gcc-4.4.2.orig/src/blob/rest-ld-script.in
> +++ gen-blob-with-gcc-4.4.2/src/blob/rest-ld-script.in
> @@ -97,7 +97,8 @@
>                /* and next the stack */
>                . = ALIGN(4);
>                __stack_start = .;
> -               *(.stack)
> +               /* allocate a 16kB stack */
> +               . = . + 16 * 1024;
>                __stack_end = .;
>                __bss_end = .;
>


you already have this in stack.S so its not needed. The correct fix would be to
classify the output segment as NOLOAD explicitly like this

	.bss(NOLOAD) : {
		__bss_start = .;
		/* first the real BSS data */
		*(.bss)

		/* and next the stack */
		. = ALIGN(4);
		__stack_start = .;
		*(.stack)
		__stack_end = .;
		__bss_end = .;
	}

you should not need any other changes.

>
> Sizes are now:
>   text    data     bss     dec     hex filename
>  40212   20764  244356  305332   4a8b4 blob-rest-elf32-with-gcc-4.1.2
>  39595   20772  244356  304723   4a653 blob-rest-elf32-with-gcc-4.4.2
>
> bss size matches, this a good sign, not a coincidence, isnt'it? And
> the binary still works. Is that really ok?
>
> [...]
>> I am using the very ld the toolchain provides, so I they are
>> different, and I noted than the 4.4.2 one gives this warning:
>> .../arm-oe-linux-gnueabi/bin/ld:
>> warning: section `.bss' type changed to PROGBITS
>>

The problem is the .stack is
not a special nobits section like .bss is so when you club is together
in .bss then
there is a mismatch and hence the warning.


>
> This warning goes away with either the changes above.
>
> So the last patch above would look ok to me, I think I figured out WHAT
> was happening, but I don't understand WHY this change is necessary.
> Is that the section name ".stack" defined in stack.S is not recognized?
> If so, why?
>
> Khem I am now only asking you if you can help me understand why newer
> GCCs don't behave in the same way as older ones wrt. this aspect.
> Thanks.
>
>> The problem seems to rise during linking indeed, the size difference
>> of .o files produced by the two toolchains is ~ 3 KiB overall, it does
>> not seem to justify the bump I have after linking to more than 200KiB.
>>
>
> After several hours spent on this, but with at least some XP gained :)
> Yours truly,
>   Antonio
>
> [0]
> http://infocenter.arm.com/help/topic/com.arm.doc.dui0101a/DUI0101A_Elf.pdf
> [1]
> http://www.tortall.net/projects/yasm/manual/html/objfmt-elf-section.html
> [2] http://www.math.utah.edu/docs/info/ld_toc.html#SEC4
> [3] http://sourceware.org/ml/binutils/2007-11/msg00016.html
>
> --
> Antonio Ospite
> http://ao2.it
>
> PGP public key ID: 0x4553B001
>
> A: Because it messes up the order in which people normally read text.
>   See http://en.wikipedia.org/wiki/Posting_style
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>

Re: gen-blob size with gcc-4.4.2 SOLVED? (was: [PATCH 0/5] Misc updates for EZX bits in OE)

[Antonio Ospite]

[-- Attachment #1: Type: text/plain, Size: 3364 bytes --]

On Fri, 23 Apr 2010 09:45:04 -0700
Khem Raj <raj.khem@gmail.com> wrote:

> On Fri, Apr 23, 2010 at 5:28 AM, Antonio Ospite
> <ospite@studenti.unina.it> wrote:
[...]
> > On Fri, 26 Mar 2010 16:17:24 +0100
> > Antonio Ospite <ospite@studenti.unina.it> wrote:
> >
> >> On Thu, 25 Mar 2010 13:39:00 -0700
> >> Khem Raj <raj.khem@gmail.com> wrote:
> >>
> >> > On (25/03/10 18:19), Antonio Ospite wrote:
> > [...]
> >> > > Note that although ezx-gen-blob builds fine now, it seems to have issues with
> >> > > GCC 4.4: the binary size is about 300KiB instead of the expected 64KiB, if
> >> > > anyone has a clue please let me know.
> >> >
> >
> > Comparing the section sizes for the two binaries:
> >   text    data     bss     dec     hex filename
> >  40212   20764  244356  305332   4a8b4 blob-rest-elf32-with-gcc-4.1.2
> >  39595  265124       4  304723   4a653 blob-rest-elf32-with-gcc-4.4.2
> >
> > So something fishing about the data and bss sections. After reading
> > a bit about what ELF sections are[0,1] I'd guess gcc-4.4.2 might be
> > forcing initializations for uninitialized data putting it in the
> > binary image and that makes the object file size grow.
> >
[...]
> >
> > Index: gen-blob-with-gcc-4.4.2/src/blob/rest-ld-script.in
> > ===================================================================
> > --- gen-blob-with-gcc-4.4.2.orig/src/blob/rest-ld-script.in
> > +++ gen-blob-with-gcc-4.4.2/src/blob/rest-ld-script.in
> > @@ -97,7 +97,8 @@
> >                /* and next the stack */
> >                . = ALIGN(4);
> >                __stack_start = .;
> > -               *(.stack)
> > +               /* allocate a 16kB stack */
> > +               . = . + 16 * 1024;
> >                __stack_end = .;
> >                __bss_end = .;
> >
> 
> 
> you already have this in stack.S so its not needed. The correct fix would be to
> classify the output segment as NOLOAD explicitly like this
> 
> 	.bss(NOLOAD) : {
> 		__bss_start = .;
> 		/* first the real BSS data */
> 		*(.bss)
> 
> 		/* and next the stack */
> 		. = ALIGN(4);
> 		__stack_start = .;
> 		*(.stack)
> 		__stack_end = .;
> 		__bss_end = .;
> 	}
> 
> you should not need any other changes.
> 

This works in fact. Thanks a lot.

> >> I am using the very ld the toolchain provides, so I they are
> >> different, and I noted than the 4.4.2 one gives this warning:
> >> .../arm-oe-linux-gnueabi/bin/ld:
> >> warning: section `.bss' type changed to PROGBITS
> >>
> 
> The problem is the .stack is
> not a special nobits section like .bss is so when you club is together
> in .bss then
> there is a mismatch and hence the warning.
> 

I see, so when using a recent binutils: being .stack considered progbits
by default, .bss —containing it— is changed to progbits as well if we
don't specify otherwise. While with older binutils .bss was kept nobits
in any case?

Thanks again.

Best wishes,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[-- Attachment #2: Type: application/pgp-signature, Size: 205 bytes --]