[oe] [2011.03-maintenance] Problem building gcc

[Steffen Sledz]

I've problems building gcc from the 2011.03-maintenance branch. The do_install 
step fails with

| + mv 
'/home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/image/usr/lib/libstdc++.so.*-gdb.py*'
 
/home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/image/usr/share/gdb/auto-load/usr/lib
| mv: cannot stat 
`/home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/image/usr/lib/libstdc++.so.*-gdb.py*':
 No such file or directory
NOTE: package gcc-4.3.3-r24.1: task do_install: Failed
ERROR: Function 'do_install' failed (see 
/home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/temp/log.do_install.14408
 for further information)
ERROR: Task 2 
(/home/sledz/work/angstrom-setup-scripts/sources/openembedded/recipes/gcc/gcc_4.3.3.bb,
 do_install) failed with exit code '1'
ERROR: 
'/home/sledz/work/angstrom-setup-scripts/sources/openembedded/recipes/gcc/gcc_4.3.3.bb'
 failed

A way to reproduce the problem is using the current Ångström oebb.sh script:

  MACHINE=beagleboard ./oebb.sh bitbake gcc

My build host is running a 64-bit openSUSE 11.4.

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [2011.03-maintenance] Problem building gcc

[Koen Kooi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Op 28-07-11 08:42, Steffen Sledz schreef:
 I've problems building gcc from the 2011.03-maintenance branch. The 
 do_install step fails with
 
 | + mv 
 '/home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/image/usr/lib/libstdc++.so.*-gdb.py*'
 /home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/image/usr/share/gdb/auto-load/usr/lib
  | mv: cannot stat
 `/home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/image/usr/lib/libstdc++.so.*-gdb.py*':
  No such file or directory NOTE: package gcc-4.3.3-r24.1: task do_install: 
 Failed ERROR: Function 'do_install' failed (see
 /home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/temp/log.do_install.14408
  for further information) ERROR: Task 2 
 (/home/sledz/work/angstrom-setup-scripts/sources/openembedded/recipes/gcc/gcc_4.3.3.bb,
  do_install) failed with
 exit code '1' ERROR: 
 '/home/sledz/work/angstrom-setup-scripts/sources/openembedded/recipes/gcc/gcc_4.3.3.bb'
  failed
 
 A way to reproduce the problem is using the current Ångström oebb.sh script:
 
 MACHINE=beagleboard ./oebb.sh bitbake gcc
 
 My build host is running a 64-bit openSUSE 11.4.
 

Can you try:

diff --git a/recipes/gcc/gcc-package-target.inc 
b/recipes/gcc/gcc-package-target.inc
index 33567da..7d3f4ae 100644
- --- a/recipes/gcc/gcc-package-target.inc
+++ b/recipes/gcc/gcc-package-target.inc
@@ -171,5 +171,5 @@ GROUP ( libgcc_s.so.1 libgcc.a )  
${D}${libdir}/libgcc_s.so
rm -rf ${D}${includedir}/c++/${BINV}/${TARGET_SYS}/bits/*.gch
# move the gdb python helpers to gdb auto-load directory
install -d ${D}${datadir}/gdb/auto-load/${libdir}
- -   mv ${D}${libdir}/libstdc++.so.*-gdb.py* 
${D}${datadir}/gdb/auto-load${libdir}
+   mv ${D}${libdir}/libstdc++.so.*-gdb.py* 
${D}${datadir}/gdb/auto-load${libdir} || true
 }
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFOMRINMkyGM64RGpERAmHUAJ9ujUhTt4aw9jT49EaNRY7cUuD7hgCeOsBJ
vcTtJYmXd5igGAygUTQr5Og=
=nwkq
-END PGP SIGNATURE-


___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [2011.03-maintenance] Problem building gcc

[Steffen Sledz]

On 28.07.2011 09:38, Koen Kooi wrote:
 Op 28-07-11 08:42, Steffen Sledz schreef:
 I've problems building gcc from the 2011.03-maintenance branch. The 
 do_install step fails with
 
 | + mv 
 '/home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/image/usr/lib/libstdc++.so.*-gdb.py*'
  
 /home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/image/usr/share/gdb/auto-load/usr/lib
  | mv: cannot stat 
 `/home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/image/usr/lib/libstdc++.so.*-gdb.py*':
  No such file or directory NOTE: package gcc-4.3.3-r24.1: task do_install: 
 Failed ERROR: Function 'do_install' failed (see 
 /home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/temp/log.do_install.14408
  for further information) ERROR: Task 2 
 (/home/sledz/work/angstrom-setup-scripts/sources/openembedded/recipes/gcc/gcc_4.3.3.bb,
  do_install) failed with exit code '1' ERROR:
 '/home/sledz/work/angstrom-setup-scripts/sources/openembedded/recipes/gcc/gcc_4.3.3.bb'
  failed
 
 A way to reproduce the problem is using the current Ångström oebb.sh script:
 
 MACHINE=beagleboard ./oebb.sh bitbake gcc
 
 My build host is running a 64-bit openSUSE 11.4.
 
 
 Can you try:
 
 diff --git a/recipes/gcc/gcc-package-target.inc 
 b/recipes/gcc/gcc-package-target.inc index 33567da..7d3f4ae 100644 --- 
 a/recipes/gcc/gcc-package-target.inc +++ b/recipes/gcc/gcc-package-target.inc 
 @@ -171,5 +171,5 @@ GROUP ( libgcc_s.so.1 libgcc.a )  
 ${D}${libdir}/libgcc_s.so rm -rf 
 ${D}${includedir}/c++/${BINV}/${TARGET_SYS}/bits/*.gch # move the gdb python 
 helpers to gdb auto-load directory install -d 
 ${D}${datadir}/gdb/auto-load/${libdir} -   mv 
 ${D}${libdir}/libstdc++.so.*-gdb.py* ${D}${datadir}/gdb/auto-load${libdir} +  
  mv ${D}${libdir}/libstdc++.so.*-gdb.py* 
 ${D}${datadir}/gdb/auto-load${libdir} || true }

Yepp. This works.

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH v2] packaged-staging: fixed fetching from PSTAGE_MIRROR with file:// uri

[Aeschbacher, Fabrice]

Hi,

Would it be possible for someone having write access to commit this patch:

http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-July/033967.html

With kind regards,
Fabrice

 -Ursprüngliche Nachricht-
 Von: openembedded-devel-boun...@lists.openembedded.org 
 [mailto:openembedded-devel-boun...@lists.openembedded.org] Im 
 Auftrag von Tom Rini
 Gesendet: Montag, 18. Juli 2011 00:58
 An: openembedded-devel@lists.openembedded.org
 Betreff: Re: [oe] [PATCH v2] packaged-staging: fixed fetching 
 from PSTAGE_MIRROR with file:// uri
 
  Signed-off-by: Fabrice Aeschbacher 
...
  Acked-by: Paul Menzel paulepan...@users.sourceforge.net
...
 Acked-by: Tom Rini tom_r...@mentor.com

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] [2011.03-maintenance] gcc-package-target: fix for gcc 4.3.x

[Koen Kooi]

Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
 recipes/gcc/gcc-package-target.inc |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/recipes/gcc/gcc-package-target.inc 
b/recipes/gcc/gcc-package-target.inc
index 33567da..7d3f4ae 100644
--- a/recipes/gcc/gcc-package-target.inc
+++ b/recipes/gcc/gcc-package-target.inc
@@ -171,5 +171,5 @@ GROUP ( libgcc_s.so.1 libgcc.a )  
${D}${libdir}/libgcc_s.so
rm -rf ${D}${includedir}/c++/${BINV}/${TARGET_SYS}/bits/*.gch
# move the gdb python helpers to gdb auto-load directory
install -d ${D}${datadir}/gdb/auto-load/${libdir}
-   mv ${D}${libdir}/libstdc++.so.*-gdb.py* 
${D}${datadir}/gdb/auto-load${libdir}
+   mv ${D}${libdir}/libstdc++.so.*-gdb.py* 
${D}${datadir}/gdb/auto-load${libdir} || true
 }
-- 
1.6.6.1


___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [PATCH v2] packaged-staging: fixed fetching from PSTAGE_MIRROR with file:// uri

[Paul Menzel]

Dear Fabrice,


Am Donnerstag, den 28.07.2011, 10:44 +0200 schrieb Aeschbacher, Fabrice:

 Would it be possible for someone having write access to commit this patch:
 
 http://lists.linuxtogo.org/pipermail/openembedded-devel/2011-July/033967.html

[…]

I am sorry for the delay. I will push your patch as soon as possible.


Thanks,

Paul


signature.asc
Description: This is a digitally signed message part
___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] Populating meta-oe with new patches on oe.dev

[Phil Blundell]

On Tue, 2011-07-26 at 18:11 +0100, Paul Eggleton wrote:
 On Sunday 17 July 2011 17:12:51 Paul Menzel wrote:
  3. I find the `recipe-*section*/` directories difficult to handle to
  finding a recipe. Before I would use `recipe/` and then tab completion
  and now I have to search for it. Are others uncomfortable with this?
 
 I'm used to it now but it did feel a bit strange to begin with. 

I've been using oe-core for a while now and I do still find it a bit
annoying when you have to search in multiple directories to try to find
the recipe that you're looking for.  In some cases it's obvious and
there's no problem (eg it's fairly easy to guess that gcc would be in
devtools) but the split between some of the other directories
(particularly -core/-support/-extended/-connectivity and
-graphics/-gnome/-sato) often seems a bit arbitrary.

However, emacs seems to be able to do tab completion across multiple
levels of hierarchy nowadays, so I can just type
meta/recipes-/net-toolsTAB and it automatically figures out that
recipes-extended is the right thing.  So in practice this is not too big
a deal for me most of the time.  And I agree that having a single
massive directory of recipes is not such a great thing either, so the
current arrangement probably is a reasonable compromise.

  4. What images are available in/for oe-core/meta-openembedded? I liked
  for example `minimal{,-uclibc}`? `find . -name minimal*` in `oe-core` or
  `meta-oe` did not give any result. Not to mention the images for
  BeagleBoard or `micro-image` for the recently sent patches for payload
  creation for coreboot

micro-image itself doesn't currently exist for the oe-core world.
However, micro-base-image (which always seemed the more useful one) is
in the meta-micro layer, see:

http://cgit.openembedded.org/cgit.cgi/meta-micro/tree/recipes/images

If you wanted to submit a patch to reinstate micro-image, with a
suitable rationale for why it's useful, then that would be welcome.

p.



___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] how to apply bbappend selectively

[Jaap de Jong]

Hi All,

I.m creating a special image with for instance a modified udev package.
I've created a udev-xxx.bbappend for that purpose.
But for all the other images I build for other hardware I still want to 
use the original udev-xxx.

There is probably a simple solution but I don't see it...
Any ideas?

Thanks in advance!
Jaap

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] how to apply bbappend selectively

[Paul Eggleton]

On Thursday 28 July 2011 10:56:28 Jaap de Jong wrote:
 I.m creating a special image with for instance a modified udev package.
 I've created a udev-xxx.bbappend for that purpose.
 But for all the other images I build for other hardware I still want to
 use the original udev-xxx.

Usually this is just done with machine overrides within the bbappend.

e.g.

SRC_URI_append_somemachine = file://somefile.patch
SOMEVARIABLE_somemachine = value1
ANOTHERVARIABLE_somemachine = value2

That way building for all other machines will be unaffected.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [2011.03-maintenance] gcc-package-target: fix for gcc 4.3.x

[Steffen Sledz]

On 28.07.2011 11:10, Koen Kooi wrote:
 Signed-off-by: Koen Kooi k...@dominion.thruhere.net
 ---
  recipes/gcc/gcc-package-target.inc |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/recipes/gcc/gcc-package-target.inc 
 b/recipes/gcc/gcc-package-target.inc
 index 33567da..7d3f4ae 100644
 --- a/recipes/gcc/gcc-package-target.inc
 +++ b/recipes/gcc/gcc-package-target.inc
 @@ -171,5 +171,5 @@ GROUP ( libgcc_s.so.1 libgcc.a )  
 ${D}${libdir}/libgcc_s.so
   rm -rf ${D}${includedir}/c++/${BINV}/${TARGET_SYS}/bits/*.gch
   # move the gdb python helpers to gdb auto-load directory
   install -d ${D}${datadir}/gdb/auto-load/${libdir}
 - mv ${D}${libdir}/libstdc++.so.*-gdb.py* 
 ${D}${datadir}/gdb/auto-load${libdir}
 + mv ${D}${libdir}/libstdc++.so.*-gdb.py* 
 ${D}${datadir}/gdb/auto-load${libdir} || true
  }

Acked-by: Steffen Sledz sl...@dresearch-fe.de

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] how to apply bbappend selectively

[Paul Eggleton]

On Thursday 28 July 2011 12:13:23 Jaap de Jong wrote:
 But it will still create processor-related packages instead of
 machine-related.
 I probably need some magic flag set to get it machine-related (or
 perhaps better: image-related)?

Well, PACKAGE_ARCH_somemachine = ${MACHINE_ARCH} will do that; although if 
you're manipulating SRC_URI then it's supposed to set that automatically.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] Kernel boot problems

[Gary Thomas]

On 2011-07-27 20:20, Bernard Mentink wrote:


Hi Guys,

I have got a bit further with my efforts to boot linux on an imx31 based
platform using u-boot.

My console output is now:


uboot  bootm 8010
## Booting kernel from Legacy Image at 8010 ...
Image Name:   Angstrom/2.6.36/mx31ads
Created:  2011-07-28   2:03:27 UTC
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:1586172 Bytes = 1.5 MiB
Load Address: 8f00
Entry Point:  8f00
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
---

So it seems to be getting to the 1st part of the kernel boot process,
then hangs (I presume the last line comes from kernel code.)
I don't know if the kernel is hanging, or if I don't have any more
serial out 
I am passing console=ttymxc0,115200 to the kernel ..
Can someone confirm:
A) If I have the correct Entry point, or does this need to be offset
into the kernel? ..
B) Is the serial console parameters correct?
C) What is the correct way to set up the memory map? (my ram starts at
0x8000, ends at 0x8fff)
D) Is there a way to debug initial kernel stuff with serial output?
In the above, I have decompressed the kernel to the top of the 256M ram,
but have only advertised 120M via the bootloader   ... for now, not
knowing what is correct and not wanting the kernel
to stomp all over itself running in ram.


Analyzing this failure can be hard.  If you have some sort of JTAG setup
you might be able to break in at this point, figure out where it's hanging
up, etc.

Even if you don't have JTAG, there might be some crumbs left around for
you to look at.  Linux keeps everything that goes to the console in
a circular buffer __log_buf[].  Look up that symbol in System.map (which
will be found in your linux build tree).  Here's the tricky part - the
map will show a logical address, but U-Boot only knows physical addresses.
Normally the mapping is pretty easy, e.g. on my OMAP/3530 I might see:
  $ grep __log_buf linux-2.6.37/System.map
  c0527058 b __log_buf
So in U-Boot, I would look at the buffer like this:
  U-Boot md 0x80527058
  80527058: 4c3e353c 78756e69 72657620 6e6f69735Linux version
  80527068: 362e3220 2e37332e 67282033 6d6f6874 2.6.37.3 (gthom
  80527078: 74407361 6e617469 67282029 76206363as@titan) (gcc v
  80527088: 69737265 34206e6f 312e362e 31303220ersion 4.6.1 201
  80527098: 32363031 70282037 65726572 7361656c10627 (prereleas
  805270a8: 28202965 29434347 23202920 72462031e) (GCC) ) #1 Fr
  805270b8: 754a2069 3232206c 3a393020 303a3135i Jul 22 09:51:0
 ...

Keep looking through this buffer until it stops with useful characters.
That may tell you where the kernel got hung up and why.  If you find
only garbage, it may be more difficult to tell.

Note: hopefully your board has a RESET button which you can use to
get back into U-Boot once the kernel boot process hangs.  Power cycling
to reset the board won't work as the contents of RAM will likely be
destroyed.


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world


___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] Kernel boot problems

[Andrea Adami]

On Thu, Jul 28, 2011 at 1:22 PM, Gary Thomas g...@mlbassoc.com wrote:
 On 2011-07-27 20:20, Bernard Mentink wrote:

 Hi Guys,

 I have got a bit further with my efforts to boot linux on an imx31 based
 platform using u-boot.

 My console output is now:

 
 uboot  bootm 8010
 ## Booting kernel from Legacy Image at 8010 ...
    Image Name:   Angstrom/2.6.36/mx31ads
    Created:      2011-07-28   2:03:27 UTC
    Image Type:   ARM Linux Kernel Image (uncompressed)
    Data Size:    1586172 Bytes = 1.5 MiB
    Load Address: 8f00
    Entry Point:  8f00
    Verifying Checksum ... OK
    Loading Kernel Image ... OK
 OK

 Starting kernel ...

 Uncompressing Linux... done, booting the kernel.
 ---

 So it seems to be getting to the 1st part of the kernel boot process,
 then hangs (I presume the last line comes from kernel code.)
 I don't know if the kernel is hanging, or if I don't have any more
 serial out 
 I am passing console=ttymxc0,115200 to the kernel ..
 Can someone confirm:
 A) If I have the correct Entry point, or does this need to be offset
 into the kernel? ..
 B) Is the serial console parameters correct?
 C) What is the correct way to set up the memory map? (my ram starts at
 0x8000, ends at 0x8fff)
 D) Is there a way to debug initial kernel stuff with serial output?
 In the above, I have decompressed the kernel to the top of the 256M ram,
 but have only advertised 120M via the bootloader   ... for now, not
 knowing what is correct and not wanting the kernel
 to stomp all over itself running in ram.

cut

In answer to D) there is earlyprintk using a custom-compiled debug-kernel

Regards

Andrea

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] [2011.03-maintenance] Pull request

[Steffen Sledz]

Tom,

Please pull the 10 commits from here:

URI: git://git.openembedded.org/openembedded
Branch: sledz/maintenance

Eric Bénard (1):
  apr-util: add 1.3.10

Mario Schuknecht (3):
  udev: avoid udev stopping persistent pppd connections
  linux-2.6.24: enable tun device support (hipox machine only)
  linux-2.6.24: fix deadlock situation in gmac driver (hipox machine only)

Steffen Sledz (6):
  linux-2.6.24: fix diff pathes in hipox machine specific patch file
  linux-2.6.24: fix a buggy patch file for hipox machine
  ppp-2.4.5: own package for PPPoL2TP plugin
  ppp-2.4.5: remove `DP = -1`
  iotop: add missing runtime dependency
  apr-util: disable odbc support to avoid QA error

All of them are in oe master. The linux commits are specific to our hipox 
machine. All others are bugfixes only.

Thx,
Steffen

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058

___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] [2011.03-maintenance] Problem building gcc

[Khem Raj]

On Thu, Jul 28, 2011 at 12:38 AM, Koen Kooi k...@dominion.thruhere.net wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Op 28-07-11 08:42, Steffen Sledz schreef:
 I've problems building gcc from the 2011.03-maintenance branch. The 
 do_install step fails with

 | + mv 
 '/home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/image/usr/lib/libstdc++.so.*-gdb.py*'
 /home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/image/usr/share/gdb/auto-load/usr/lib
  | mv: cannot stat
 `/home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/image/usr/lib/libstdc++.so.*-gdb.py*':
  No such file or directory NOTE: package gcc-4.3.3-r24.1: task do_install: 
 Failed ERROR: Function 'do_install' failed (see
 /home/sledz/work/angstrom-setup-scripts/build/tmp-angstrom_2008_1/work/armv7a-angstrom-linux-gnueabi/gcc-4.3.3-r24.1/temp/log.do_install.14408
  for further information) ERROR: Task 2 
 (/home/sledz/work/angstrom-setup-scripts/sources/openembedded/recipes/gcc/gcc_4.3.3.bb,
  do_install) failed with
 exit code '1' ERROR: 
 '/home/sledz/work/angstrom-setup-scripts/sources/openembedded/recipes/gcc/gcc_4.3.3.bb'
  failed

 A way to reproduce the problem is using the current Ångström oebb.sh script:

 MACHINE=beagleboard ./oebb.sh bitbake gcc

 My build host is running a 64-bit openSUSE 11.4.


 Can you try:

 diff --git a/recipes/gcc/gcc-package-target.inc 
 b/recipes/gcc/gcc-package-target.inc
 index 33567da..7d3f4ae 100644
 - --- a/recipes/gcc/gcc-package-target.inc
 +++ b/recipes/gcc/gcc-package-target.inc
 @@ -171,5 +171,5 @@ GROUP ( libgcc_s.so.1 libgcc.a )  
 ${D}${libdir}/libgcc_s.so
        rm -rf ${D}${includedir}/c++/${BINV}/${TARGET_SYS}/bits/*.gch
        # move the gdb python helpers to gdb auto-load directory
        install -d ${D}${datadir}/gdb/auto-load/${libdir}
 - -       mv ${D}${libdir}/libstdc++.so.*-gdb.py* 
 ${D}${datadir}/gdb/auto-load${libdir}
 +       mv ${D}${libdir}/libstdc++.so.*-gdb.py* 
 ${D}${datadir}/gdb/auto-load${libdir} || true
  }

so these are not generated for gcc 4.3 ? in any case this patch seems ok to me

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.5 (Darwin)

 iD8DBQFOMRINMkyGM64RGpERAmHUAJ9ujUhTt4aw9jT49EaNRY7cUuD7hgCeOsBJ
 vcTtJYmXd5igGAygUTQr5Og=
 =nwkq
 -END PGP SIGNATURE-


 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] Kernel boot problems

[Daniel Smith]

On 7/27/2011 10:20 PM, Bernard Mentink wrote:

Hi Guys,

I have got a bit further with my efforts to boot linux on an imx31 based
platform using u-boot.

My console output is now:


uboot  bootm 8010
## Booting kernel from Legacy Image at 8010 ...
Image Name:   Angstrom/2.6.36/mx31ads
Created:  2011-07-28   2:03:27 UTC
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:1586172 Bytes = 1.5 MiB
Load Address: 8f00
Entry Point:  8f00
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
---

So it seems to be getting to the 1st part of the kernel boot process,
then hangs (I presume the last line comes from kernel code.)
I don't know if the kernel is hanging, or if I don't have any more
serial out 
I am passing console=ttymxc0,115200 to the kernel ..
Can someone confirm:
A) If I have the correct Entry point, or does this need to be offset
into the kernel? ..
B) Is the serial console parameters correct?
C) What is the correct way to set up the memory map? (my ram starts at
0x8000, ends at 0x8fff)
D) Is there a way to debug initial kernel stuff with serial output?
In the above, I have decompressed the kernel to the top of the 256M ram,
but have only advertised 120M via the bootloader   ... for now, not
knowing what is correct and not wanting the kernel
to stomp all over itself running in ram.

Many Thanks,
Bernie


For (A), I ran into a similar issue cns3xxx which has a similar core as 
your imx31. You can see the thread here (http://goo.gl/HEOVK). Basically 
go look in the Makefile.boot for your sub-arch and see what is set for 
the zreladdr. If it is different than 0x20008000, then in your kernel 
recipe you need to set the UBOOT_ENTRYPOINT and UBOOT_LOADADDRESS to 
your zreladdr.


Hope that helps!

V/r,
Daniel P. Smith


___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] Kernel load address issue

[Chris Verges]

Apologies for the top posting on this one ...

You can easily generate a zImage.  If you have devshell enabled, type
bitbake linux -c devshell and browse under arch/*/boot/... to find
your vmlinux image.

Try bootm 0x84A0.  This works on my system.

Chris

On Wed, Jul 27, 2011 at 12:22 PM, Bernard Mentink
bernard_ment...@trimble.com wrote:
 Hi Chris,

 Many thanks for that. However I only have a uImage in my build, no zImage so 
 can't do a diff to find the offset, is there another way to find that out?
 Maybe you or someone else knows what script in openembedded calls the mkimage 
 utility so I can find what parameters are passed ..

 By the way, I set UBOOT_LOADADDRESS and UBOOT_ENTRYPOINT to be the same 
 (0x8040, a bit past u-boot and the environment) in my config file, I am 
 not sure if the entry point should be the same as the load address.

 Cheers,
 Bernie

 --
 I want to die peacefully in my sleep, like my grandfather, not screaming and 
 yelling like the passengers in his car.

 -Original Message-
 From: openembedded-devel-boun...@lists.openembedded.org 
 [mailto:openembedded-devel-boun...@lists.openembedded.org] On Behalf Of Chris 
 Verges
 Sent: Thursday, 28 July 2011 2:12 a.m.
 To: openembedded-devel@lists.openembedded.org
 Subject: Re: [oe] Kernel load address issue

 On Wed, Jul 27, 2011 at 06:00:07AM +, Mats Kärrman wrote:
 Starting kernel ...

 And there it hangs ... I don't know who printed out the Starting
 kernel was it uboot or the kernel?  If uboot, how do I pass kernel
 arguments (i.e the console serial params) with this method of booting?

 Hi Bernie,

 I've experienced this before when the UBOOT_LOADADDRESS and UBOOT_ENTRYPOINT 
 values in the machine config file for OpenEmbedded aren't properly set to the 
 correct value.  You may want to double check those values.

 Also, try setting your bootm address just a tag higher in memory than the 
 actual UBOOT_ENTRYPOINT.  I forgot what the exact uboot-mkimage header put on 
 the uImage is, but you can do a hex diff between the zImage and uImage files 
 to figure it out.  That offset can sometimes cause some odd booting problems.

 So if your ENTRYPOINT is 0x830 and the uboot-mkimage offset is 0xC0, for 
 example, you'd need to bootm 0x83000C0.  (Again, double check the 
 uboot-mkimage offset.)

 Good luck,
 Chris


 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

 ___
 Openembedded-devel mailing list
 Openembedded-devel@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] image level user manipulation

[George C. Huntington III]

are there any classes or layers that let you create users on an image
for the 2011.03-maintenance branch?

i want to create some custom users and home directories.  I think I can
do it via the ROOTFS_POSTPROCESS_COMMAND, but it feels like there should
be a better way.  is there a way to run the addgroup and adduser tools
natively but in such a way that they work their magic on the root
filesystem being created?


___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[oe] [2011.03-maintenance]

[Ben Gardiner]

Cherry-pick: f1d24b5a986233f869364eb109476f5184e76d10
Tested-by: Ben Gardiner bengardi...@nanometrics.ca

please add this to the 2011.03-maintenance branch

Ben Gardiner (1):
  raptor: add libxml2 DEPENDS

 recipes/raptor/raptor_1.4.21.bb |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

-- 
1.7.4.1


___
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: [oe] Kernel boot problems

[Bernard Mentink]

Many thanks for that,

I had a look through the buffer and I see pretty much normal bootup text
... It just isn't coming out of the serial port ..

The only error I saw was the following:
-
8030cf80:  0001 3a534656 6e614320VFS: Can
8030cf90: 20746f6e 6e65706f 6f6f7220 65642074not open root de
8030cfa0: 65636976 6e282220 296c6c75 726f2022vice (null) or
8030cfb0: 6b6e7520 6e776f6e 6f6c622d 32286b63 unknown-block(2
8030cfc0: 64646100 3d72  303a.addr=:0
8030cfd0: 69202c31 2d3d7172 000a2931 203938301, irq=-1)..089
8030cfe0: 30373178 2a29 30307830 63313938x170).. 0x00891c
8030cff0: 203a 7830202d 6566 30303030..0 - 0xfffe
8030d000: 28202020 36393820 29426b20 2020200a   ( 896 kB).
8030d010: 414d4420 20202020 30203a20 6378 DMA : 0xffc
8030d020: 30303030 202d2030 7830 303030650 - 0xffe000
8030d030: 20203030 20202820 4d203220 200a294200   (   2 MB).
8030d040: 76202020 6c6c616d 3a20636f 63783020   vmalloc : 0xc
8030d050: 30303834 20303030 7830202d 30303466480 - 0xf400
8030d060: 30303030 28202020 30363720 29424d20   ( 760 MB)
8030d070: 2020200a 776f6c20 206d656d 30203a20.lowmem  : 0
8030d080: 30306378 30303030 202d2030 34637830xc000 - 0xc4
8030d090: 30303030 20203030 20202820 4d20343600   (  64 M
8030d0a0: 200a2942 6d202020 6c75646f 3a207365B).modules :
8030d0b0: 62783020 30303066 20303030 7830202d 0xbf00 - 0x
8030d0c0: 30303063 30303030 28202020 36312020c000   (  16
8030d0d0: 29424d20 2020200a 2e202020 74696e69 MB).  .init
8030d0e0: 30203a20 30306378 30303830 202d2030 : 0xc0008000 -
8030d0f0: 30637830 30653130 20203030 202028200xc001e000   (
8030d100: 6b203838 200a2942 20202020 65742e2088 kB).  .te
8030d110: 3a207478 63783020 65313030 20303030xt : 0xc001e000
8030d120: 7830202d 65323063 30303031 28202020- 0xc02e1000   (
8030d130: 38323832 29426b20 2020200a 2e2020202828 kB).  .
8030d140: 61746164 30203a20 32306378 30303666data : 0xc02f600
8030d150: 202d2030 30637830 36633033 202030650 - 0xc030c6e0
8030d160: 20202820 6b203039 000a2942  (  90 kB)..


A bit futher down the buffer I saw normal printout ..

__

8030d380:    
8030d390:    4c3e353c5L
8030d3a0: 78756e69 72657620 6e6f6973 362e3220inux version 2.6
8030d3b0: 2e36332e 62282031 746e656d 406b6e69.36.1 (bmentink@
8030d3c0: 68637241 29786f42 63672820 65762063ArchBox) (gcc ve
8030d3d0: 6f697372 2e34206e 20332e35 31313032rsion 4.5.3 2011
8030d3e0: 31313330 72702820 6c657265 657361650311 (prerelease
8030d3f0: 47282029 20294343 31232029 45525020) (GCC) ) #1 PRE
8030d400: 54504d45 69724620 6c754a20 20393220EMPT Fri Jul 29
8030d410: 303a3830 36313a31 535a4e20 3032205408:01:16 NZST 20
8030d420: 3c0a3131 50433e34 41203a55 36764d5211.4CPU: ARMv6
8030d430: 6d6f632d 69746170 20656c62 636f7270-compatible proc
8030d440: 6f737365 345b2072 62373031 5d343633essor [4107b364]
8030d450: 76657220 6f697369 2034206e 4d524128 revision 4 (ARM
8030d460: 45543676 202c294a 303d7263 33356330v6TEJ), cr=00c53
8030d470: 0a663738 433e343c 203a5550 5450495687f.4CPU: VIPT
8030d480: 6e6f6e20 61696c61 676e6973 74616420 nonaliasing dat
8030d490: 61632061 2c656863 50495620 6f6e2054a cache, VIPT no
8030d4a0: 696c616e 6e697361 6e692067 75727473naliasing instru
8030d4b0: 6f697463 6163206e 0a656863 4d3e343cction cache.4M
8030d4c0: 69686361 203a656e 69676f4c 20445063achine: LogicPD
8030d4d0: 584d2e69 53203133 3c0a4d4f 654d3e34i.MX31 SOM.4Me
8030d4e0: 79726f6d 6c6f7020 3a796369 43434520mory policy: ECC
8030d4f0: 73696420 656c6261 44202c64 20617461 disabled, Data
8030d500: 68636163 72772065 62657469 0a6b6361cache writeback.
8030d510: 4f3e373c 6f6e206e 30206564 746f74207On node 0 tot
8030d520: 61706c61 3a736567 33363120 3c0a3438alpages: 16384.
8030d530: 72663e37 615f6565 5f616572 74696e697free_area_init
8030d540: 646f6e5f 6e203a65 2065646f 70202c30_node: node 0, p
8030d550: 74616467 33306320 64306330 6e202c38gdat c030c0d8, n
8030d560: 5f65646f 5f6d656d 2070616d 32333063ode_mem_map c032
8030d570: 30303031 3e373c0a 6f4e2020 6c616d721000.7  Normal
8030d580: 6e6f7a20 31203a65 70203832 73656761 zone: 128 pages
8030d590: 65737520 6f662064 656d2072 70616d6d used for memmap
8030d5a0: 3e373c0a 6f4e2020 6c616d72 6e6f7a20.7  Normal zon
8030d5b0: 30203a65 67617020 72207365 72657365e: 0 pages reser
8030d5c0: 0a646576 203e373c 726f4e20 206c616dved.7  Normal
--

I am not sure why it is not printing out the port, my boot param =
console=ttymxc0,115200
And 

Re: [oe] Kernel boot problems

[Gary Thomas]

On 2011-07-28 14:51, Bernard Mentink wrote:

Many thanks for that,

I had a look through the buffer and I see pretty much normal bootup text
... It just isn't coming out of the serial port ..

The only error I saw was the following:
-
8030cf80:  0001 3a534656 6e614320VFS: Can
8030cf90: 20746f6e 6e65706f 6f6f7220 65642074not open root de
8030cfa0: 65636976 6e282220 296c6c75 726f2022vice (null) or
8030cfb0: 6b6e7520 6e776f6e 6f6c622d 32286b63 unknown-block(2
8030cfc0: 64646100 3d72  303a.addr=:0
8030cfd0: 69202c31 2d3d7172 000a2931 203938301, irq=-1)..089
8030cfe0: 30373178 2a29 30307830 63313938x170).. 0x00891c
8030cff0: 203a 7830202d 6566 30303030..0 - 0xfffe
8030d000: 28202020 36393820 29426b20 2020200a   ( 896 kB).
8030d010: 414d4420 20202020 30203a20 6378 DMA : 0xffc
8030d020: 30303030 202d2030 7830 303030650 - 0xffe000
8030d030: 20203030 20202820 4d203220 200a294200   (   2 MB).
8030d040: 76202020 6c6c616d 3a20636f 63783020   vmalloc : 0xc
8030d050: 30303834 20303030 7830202d 30303466480 - 0xf400
8030d060: 30303030 28202020 30363720 29424d20   ( 760 MB)
8030d070: 2020200a 776f6c20 206d656d 30203a20.lowmem  : 0
8030d080: 30306378 30303030 202d2030 34637830xc000 - 0xc4
8030d090: 30303030 20203030 20202820 4d20343600   (  64 M
8030d0a0: 200a2942 6d202020 6c75646f 3a207365B).modules :
8030d0b0: 62783020 30303066 20303030 7830202d 0xbf00 - 0x
8030d0c0: 30303063 30303030 28202020 36312020c000   (  16
8030d0d0: 29424d20 2020200a 2e202020 74696e69 MB).  .init
8030d0e0: 30203a20 30306378 30303830 202d2030 : 0xc0008000 -
8030d0f0: 30637830 30653130 20203030 202028200xc001e000   (
8030d100: 6b203838 200a2942 20202020 65742e2088 kB).  .te
8030d110: 3a207478 63783020 65313030 20303030xt : 0xc001e000
8030d120: 7830202d 65323063 30303031 28202020- 0xc02e1000   (
8030d130: 38323832 29426b20 2020200a 2e2020202828 kB).  .
8030d140: 61746164 30203a20 32306378 30303666data : 0xc02f600
8030d150: 202d2030 30637830 36633033 202030650 - 0xc030c6e0
8030d160: 20202820 6b203039 000a2942  (  90 kB)..


A bit futher down the buffer I saw normal printout ..

__

8030d380:    
8030d390:    4c3e353c5L
8030d3a0: 78756e69 72657620 6e6f6973 362e3220inux version 2.6
8030d3b0: 2e36332e 62282031 746e656d 406b6e69.36.1 (bmentink@
8030d3c0: 68637241 29786f42 63672820 65762063ArchBox) (gcc ve
8030d3d0: 6f697372 2e34206e 20332e35 31313032rsion 4.5.3 2011
8030d3e0: 31313330 72702820 6c657265 657361650311 (prerelease
8030d3f0: 47282029 20294343 31232029 45525020) (GCC) ) #1 PRE
8030d400: 54504d45 69724620 6c754a20 20393220EMPT Fri Jul 29
8030d410: 303a3830 36313a31 535a4e20 3032205408:01:16 NZST 20
8030d420: 3c0a3131 50433e34 41203a55 36764d5211.4CPU: ARMv6
8030d430: 6d6f632d 69746170 20656c62 636f7270-compatible proc
8030d440: 6f737365 345b2072 62373031 5d343633essor [4107b364]
8030d450: 76657220 6f697369 2034206e 4d524128 revision 4 (ARM
8030d460: 45543676 202c294a 303d7263 33356330v6TEJ), cr=00c53
8030d470: 0a663738 433e343c 203a5550 5450495687f.4CPU: VIPT
8030d480: 6e6f6e20 61696c61 676e6973 74616420 nonaliasing dat
8030d490: 61632061 2c656863 50495620 6f6e2054a cache, VIPT no
8030d4a0: 696c616e 6e697361 6e692067 75727473naliasing instru
8030d4b0: 6f697463 6163206e 0a656863 4d3e343cction cache.4M
8030d4c0: 69686361 203a656e 69676f4c 20445063achine: LogicPD
8030d4d0: 584d2e69 53203133 3c0a4d4f 654d3e34i.MX31 SOM.4Me
8030d4e0: 79726f6d 6c6f7020 3a796369 43434520mory policy: ECC
8030d4f0: 73696420 656c6261 44202c64 20617461 disabled, Data
8030d500: 68636163 72772065 62657469 0a6b6361cache writeback.
8030d510: 4f3e373c 6f6e206e 30206564 746f74207On node 0 tot
8030d520: 61706c61 3a736567 33363120 3c0a3438alpages: 16384.
8030d530: 72663e37 615f6565 5f616572 74696e697free_area_init
8030d540: 646f6e5f 6e203a65 2065646f 70202c30_node: node 0, p
8030d550: 74616467 33306320 64306330 6e202c38gdat c030c0d8, n
8030d560: 5f65646f 5f6d656d 2070616d 32333063ode_mem_map c032
8030d570: 30303031 3e373c0a 6f4e2020 6c616d721000.7   Normal
8030d580: 6e6f7a20 31203a65 70203832 73656761 zone: 128 pages
8030d590: 65737520 6f662064 656d2072 70616d6d used for memmap
8030d5a0: 3e373c0a 6f4e2020 6c616d72 6e6f7a20.7   Normal zon
8030d5b0: 30203a65 67617020 72207365 72657365e: 0 pages reser
8030d5c0: 0a646576 203e373c 726f4e20 206c616dved.7   Normal
--

I am not sure why it is not printing out the port, 

Re: [oe] Kernel boot problems

[Bernard Mentink]

Hi Gary,

Further down I see a confirmation of the boot params ... i.e
console=ttymxc0,115200

8030d600: 73747369 206e6920 656e6f5a 64726f20ists in Zone ord
8030d610: 202c7265 69626f6d 7974696c 6f726720er, mobility gro
8030d620: 6e697075 6e6f2067 5420202e 6c61746fuping on.  Total
8030d630: 67617020 203a7365 31353233 353c0a32 pages: 32512.5
8030d640: 72654b3e 206c656e 6d6d6f63 20646e61Kernel command
8030d650: 656e696c 6f63203a 6c6f736e 74743d65line: console=tt
8030d660: 63786d79 31312c30 30303235 3e363c0aymxc0,115200.6
8030d670: 20444950 68736168 62617420 6520656cPID hash table e
8030d680: 6972746e 203a7365 20323135 64726f28ntries: 512 (ord
8030d690: 203a7265 202c312d 38343032 74796220er: -1, 2048 byt
8030d6a0: 0a297365 443e363c 72746e65 61632079es).6Dentry ca
8030d6b0: 20656863 68736168 62617420 6520656cche hash table e
8030d6c0: 6972746e 203a7365 38333631 6f282034ntries: 16384 (o
8030d6d0: 72656472 2c34203a 35353620 62203633rder: 4, 65536 b
8030d6e0: 73657479 363c0a29 6f6e493e 632d6564ytes).6Inode-c
8030d6f0: 65686361 73616820 61742068 20656c62ache hash table

The only mention of serial port is:

8030df00: 20656e69 69676572 72657473 3c0a6465ine registered.
8030df10: 6f693e36 68637320 6c756465 632072656io scheduler c
8030df20: 72207166 73696765 65726574 64282064fq registered (d
8030df30: 75616665 0a29746c 533e363c 61697265efault).6Seria
8030df40: 49203a6c 6420584d 65766972 353c0a72l: IMX driver.5
8030df50: 7968703e 70616d73 616c7020 726f6674physmap platfor
8030df60: 6c66206d 20687361 69766564 203a6563m flash device:
8030df70: 30303230 30303030 20746120 303030610200 at a000
8030df80: 30303030 3e363c0a 73796870 2d70616d.6physmap-
8030df90: 73616c66 3a302e68 756f4620 3120646eflash.0: Found 1
8030dfa0: 36317820 76656420 73656369 20746120 x16 devices at
8030dfb0: 20307830 31206e69 69622d36 616220740x0 in 16-bit ba
8030dfc0: 202e6b6e 756e614d 74636166 72657275nk. Manufacturer
8030dfd0: 20444920 30307830 39383030 69684320 ID 0x89 Chi
8030dfe0: 44492070 30783020 31393830 353c0a63p ID 0x00891c.5
8030dff0: 7075533e 74726f70 726f6620 6d6f6320Support for com

.. And yes I did turn on early debug in the kernel config .. But I don't
see any extra messages out the serial port.
How can I check that my .config changes have propagated through ok? ..


Regards,
bernie
 



--
I want to die peacefully in my sleep, like my grandfather, not screaming
and yelling like the passengers in his car.

-Original Message-
From: Gary Thomas [mailto:g...@mlbassoc.com] 
Sent: Friday, 29 July 2011 9:40 a.m.
To: Bernard Mentink
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Kernel boot problems

On 2011-07-28 14:51, Bernard Mentink wrote:
 Many thanks for that,

 I had a look through the buffer and I see pretty much normal bootup 
 text ... It just isn't coming out of the serial port ..

 The only error I saw was the following:
 -
 8030cf80:  0001 3a534656 6e614320VFS: Can
 8030cf90: 20746f6e 6e65706f 6f6f7220 65642074not open root de
 8030cfa0: 65636976 6e282220 296c6c75 726f2022vice (null) or
 8030cfb0: 6b6e7520 6e776f6e 6f6c622d 32286b63 unknown-block(2
 8030cfc0: 64646100 3d72  303a.addr=:0
 8030cfd0: 69202c31 2d3d7172 000a2931 203938301, irq=-1)..089
 8030cfe0: 30373178 2a29 30307830 63313938x170).. 0x00891c
 8030cff0: 203a 7830202d 6566 30303030..0 - 0xfffe
 8030d000: 28202020 36393820 29426b20 2020200a   ( 896 kB).
 8030d010: 414d4420 20202020 30203a20 6378 DMA : 0xffc
 8030d020: 30303030 202d2030 7830 303030650 - 0xffe000
 8030d030: 20203030 20202820 4d203220 200a294200   (   2 MB).
 8030d040: 76202020 6c6c616d 3a20636f 63783020   vmalloc : 0xc
 8030d050: 30303834 20303030 7830202d 30303466480 - 0xf400
 8030d060: 30303030 28202020 30363720 29424d20   ( 760 MB)
 8030d070: 2020200a 776f6c20 206d656d 30203a20.lowmem  : 0
 8030d080: 30306378 30303030 202d2030 34637830xc000 - 0xc4
 8030d090: 30303030 20203030 20202820 4d20343600   (  64 M
 8030d0a0: 200a2942 6d202020 6c75646f 3a207365B).modules :
 8030d0b0: 62783020 30303066 20303030 7830202d 0xbf00 - 0x
 8030d0c0: 30303063 30303030 28202020 36312020c000   (  16
 8030d0d0: 29424d20 2020200a 2e202020 74696e69 MB).  .init
 8030d0e0: 30203a20 30306378 30303830 202d2030 : 0xc0008000 -
 8030d0f0: 30637830 30653130 20203030 202028200xc001e000   (
 8030d100: 6b203838 200a2942 20202020 65742e2088 kB).  .te
 8030d110: 3a207478 63783020 65313030 20303030xt : 0xc001e000
 8030d120: 7830202d 65323063 30303031 28202020- 0xc02e1000   (
 8030d130: 38323832 29426b20 2020200a 2e2020202828 kB).  

Re: [oe] Kernel boot problems

[Gary Thomas]

On 2011-07-28 16:10, Bernard Mentink wrote:

Hi Gary,

Further down I see a confirmation of the boot params ... i.e
console=ttymxc0,115200

8030d600: 73747369 206e6920 656e6f5a 64726f20ists in Zone ord
8030d610: 202c7265 69626f6d 7974696c 6f726720er, mobility gro
8030d620: 6e697075 6e6f2067 5420202e 6c61746fuping on.  Total
8030d630: 67617020 203a7365 31353233 353c0a32 pages: 32512.5
8030d640: 72654b3e 206c656e 6d6d6f63 20646e61Kernel command
8030d650: 656e696c 6f63203a 6c6f736e 74743d65line: console=tt
8030d660: 63786d79 31312c30 30303235 3e363c0aymxc0,115200.6
8030d670: 20444950 68736168 62617420 6520656cPID hash table e
8030d680: 6972746e 203a7365 20323135 64726f28ntries: 512 (ord
8030d690: 203a7265 202c312d 38343032 74796220er: -1, 2048 byt
8030d6a0: 0a297365 443e363c 72746e65 61632079es).6Dentry ca
8030d6b0: 20656863 68736168 62617420 6520656cche hash table e
8030d6c0: 6972746e 203a7365 38333631 6f282034ntries: 16384 (o
8030d6d0: 72656472 2c34203a 35353620 62203633rder: 4, 65536 b
8030d6e0: 73657479 363c0a29 6f6e493e 632d6564ytes).6Inode-c
8030d6f0: 65686361 73616820 61742068 20656c62ache hash table

The only mention of serial port is:

8030df00: 20656e69 69676572 72657473 3c0a6465ine registered.
8030df10: 6f693e36 68637320 6c756465 632072656io scheduler c
8030df20: 72207166 73696765 65726574 64282064fq registered (d
8030df30: 75616665 0a29746c 533e363c 61697265efault).6Seria
8030df40: 49203a6c 6420584d 65766972 353c0a72l: IMX driver.5
8030df50: 7968703e 70616d73 616c7020 726f6674physmap platfor
8030df60: 6c66206d 20687361 69766564 203a6563m flash device:
8030df70: 30303230 30303030 20746120 303030610200 at a000
8030df80: 30303030 3e363c0a 73796870 2d70616d.6physmap-
8030df90: 73616c66 3a302e68 756f4620 3120646eflash.0: Found 1
8030dfa0: 36317820 76656420 73656369 20746120 x16 devices at
8030dfb0: 20307830 31206e69 69622d36 616220740x0 in 16-bit ba
8030dfc0: 202e6b6e 756e614d 74636166 72657275nk. Manufacturer
8030dfd0: 20444920 30307830 39383030 69684320 ID 0x89 Chi
8030dfe0: 44492070 30783020 31393830 353c0a63p ID 0x00891c.5
8030dff0: 7075533e 74726f70 726f6620 6d6f6320Support for com

.. And yes I did turn on early debug in the kernel config .. But I don't
see any extra messages out the serial port.
How can I check that my .config changes have propagated through ok? ..


Do you have CONFIG_SERIAL_IMX_CONSOLE in your config?  You can just grep
for 'SERIAL_IMX_CONSOLE' in .config

You could also edit drivers/serial/imx.c and put some printk() messages
in serial_imx_probe() to see if it's being called to register your device.
Of course, you'll have to look at the log_buf to read the messages :-)

I notice that your bootargs don't specify a file system.  Perhaps if you
added that the system could actually make it up to multi-user and you
could log in (serial, SSH, ...)



--
I want to die peacefully in my sleep, like my grandfather, not screaming
and yelling like the passengers in his car.

-Original Message-
From: Gary Thomas [mailto:g...@mlbassoc.com]
Sent: Friday, 29 July 2011 9:40 a.m.
To: Bernard Mentink
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Kernel boot problems

On 2011-07-28 14:51, Bernard Mentink wrote:

Many thanks for that,

I had a look through the buffer and I see pretty much normal bootup
text ... It just isn't coming out of the serial port ..

The only error I saw was the following:
-
8030cf80:  0001 3a534656 6e614320VFS: Can
8030cf90: 20746f6e 6e65706f 6f6f7220 65642074not open root de
8030cfa0: 65636976 6e282220 296c6c75 726f2022vice (null) or
8030cfb0: 6b6e7520 6e776f6e 6f6c622d 32286b63 unknown-block(2
8030cfc0: 64646100 3d72  303a.addr=:0
8030cfd0: 69202c31 2d3d7172 000a2931 203938301, irq=-1)..089
8030cfe0: 30373178 2a29 30307830 63313938x170).. 0x00891c
8030cff0: 203a 7830202d 6566 30303030..0 - 0xfffe
8030d000: 28202020 36393820 29426b20 2020200a   ( 896 kB).
8030d010: 414d4420 20202020 30203a20 6378 DMA : 0xffc
8030d020: 30303030 202d2030 7830 303030650 - 0xffe000
8030d030: 20203030 20202820 4d203220 200a294200   (   2 MB).
8030d040: 76202020 6c6c616d 3a20636f 63783020   vmalloc : 0xc
8030d050: 30303834 20303030 7830202d 30303466480 - 0xf400
8030d060: 30303030 28202020 30363720 29424d20   ( 760 MB)
8030d070: 2020200a 776f6c20 206d656d 30203a20.lowmem  : 0
8030d080: 30306378 30303030 202d2030 34637830xc000 - 0xc4
8030d090: 30303030 20203030 20202820 4d20343600   (  64 M
8030d0a0: 200a2942 6d202020 6c75646f 3a207365B).modules :
8030d0b0: 62783020 30303066 20303030 7830202d 0xbf00 - 0x
8030d0c0: 30303063 30303030 

Re: [oe] Kernel boot problems

[Bernard Mentink]

 
Hi Gary,

Yes, I have CONFIG_SERIAL_IMX_CONSOLE=y in my .config and I have
confirmed it is being used.

I will try the printk in the serial driver ... Thanks, was looking for
where that was ..

I want to get the kernal up and running before I introduce the root file
system  .. But if I get stuck on this serial issue, I may do as you
suggest.

Thanks,
bernie


--
I want to die peacefully in my sleep, like my grandfather, not screaming
and yelling like the passengers in his car.

-Original Message-
From: Gary Thomas [mailto:g...@mlbassoc.com] 
Sent: Friday, 29 July 2011 10:42 a.m.
To: Bernard Mentink
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Kernel boot problems

On 2011-07-28 16:10, Bernard Mentink wrote:
 Hi Gary,

 Further down I see a confirmation of the boot params ... i.e 
 console=ttymxc0,115200

 8030d600: 73747369 206e6920 656e6f5a 64726f20ists in Zone ord
 8030d610: 202c7265 69626f6d 7974696c 6f726720er, mobility gro
 8030d620: 6e697075 6e6f2067 5420202e 6c61746fuping on.  Total
 8030d630: 67617020 203a7365 31353233 353c0a32 pages: 32512.5
 8030d640: 72654b3e 206c656e 6d6d6f63 20646e61Kernel command
 8030d650: 656e696c 6f63203a 6c6f736e 74743d65line: console=tt
 8030d660: 63786d79 31312c30 30303235 3e363c0aymxc0,115200.6
 8030d670: 20444950 68736168 62617420 6520656cPID hash table e
 8030d680: 6972746e 203a7365 20323135 64726f28ntries: 512 (ord
 8030d690: 203a7265 202c312d 38343032 74796220er: -1, 2048 byt
 8030d6a0: 0a297365 443e363c 72746e65 61632079es).6Dentry ca
 8030d6b0: 20656863 68736168 62617420 6520656cche hash table e
 8030d6c0: 6972746e 203a7365 38333631 6f282034ntries: 16384 (o
 8030d6d0: 72656472 2c34203a 35353620 62203633rder: 4, 65536 b
 8030d6e0: 73657479 363c0a29 6f6e493e 632d6564ytes).6Inode-c
 8030d6f0: 65686361 73616820 61742068 20656c62ache hash table

 The only mention of serial port is:

 8030df00: 20656e69 69676572 72657473 3c0a6465ine registered.
 8030df10: 6f693e36 68637320 6c756465 632072656io scheduler c
 8030df20: 72207166 73696765 65726574 64282064fq registered (d
 8030df30: 75616665 0a29746c 533e363c 61697265efault).6Seria
 8030df40: 49203a6c 6420584d 65766972 353c0a72l: IMX driver.5
 8030df50: 7968703e 70616d73 616c7020 726f6674physmap platfor
 8030df60: 6c66206d 20687361 69766564 203a6563m flash device:
 8030df70: 30303230 30303030 20746120 303030610200 at a000
 8030df80: 30303030 3e363c0a 73796870 2d70616d.6physmap-
 8030df90: 73616c66 3a302e68 756f4620 3120646eflash.0: Found 1
 8030dfa0: 36317820 76656420 73656369 20746120 x16 devices at
 8030dfb0: 20307830 31206e69 69622d36 616220740x0 in 16-bit ba
 8030dfc0: 202e6b6e 756e614d 74636166 72657275nk. Manufacturer
 8030dfd0: 20444920 30307830 39383030 69684320 ID 0x89 Chi
 8030dfe0: 44492070 30783020 31393830 353c0a63p ID 0x00891c.5
 8030dff0: 7075533e 74726f70 726f6620 6d6f6320Support for com

 .. And yes I did turn on early debug in the kernel config .. But I 
 don't see any extra messages out the serial port.
 How can I check that my .config changes have propagated through ok? ..

Do you have CONFIG_SERIAL_IMX_CONSOLE in your config?  You can just grep
for 'SERIAL_IMX_CONSOLE' in .config

You could also edit drivers/serial/imx.c and put some printk() messages
in serial_imx_probe() to see if it's being called to register your
device.
Of course, you'll have to look at the log_buf to read the messages :-)

I notice that your bootargs don't specify a file system.  Perhaps if you
added that the system could actually make it up to multi-user and you
could log in (serial, SSH, ...)

 --
 --
 --
 I want to die peacefully in my sleep, like my grandfather, not 
 screaming and yelling like the passengers in his car.

 -Original Message-
 From: Gary Thomas [mailto:g...@mlbassoc.com]
 Sent: Friday, 29 July 2011 9:40 a.m.
 To: Bernard Mentink
 Cc: openembedded-devel@lists.openembedded.org
 Subject: Re: [oe] Kernel boot problems

 On 2011-07-28 14:51, Bernard Mentink wrote:
 Many thanks for that,

 I had a look through the buffer and I see pretty much normal bootup 
 text ... It just isn't coming out of the serial port ..

 The only error I saw was the following:
 -
 8030cf80:  0001 3a534656 6e614320VFS: Can
 8030cf90: 20746f6e 6e65706f 6f6f7220 65642074not open root de
 8030cfa0: 65636976 6e282220 296c6c75 726f2022vice (null) or
 8030cfb0: 6b6e7520 6e776f6e 6f6c622d 32286b63 unknown-block(2
 8030cfc0: 64646100 3d72  303a.addr=:0
 8030cfd0: 69202c31 2d3d7172 000a2931 203938301, irq=-1)..089
 8030cfe0: 30373178 2a29 30307830 63313938x170).. 0x00891c
 8030cff0: 203a 7830202d 

Re: [oe] Kernel boot problems

[Bernard Mentink]

Hi Gary,

Did as you suggested .. no printout from serial_imx_probe() is seen, so
I guess it isn't been called, will have to trace it back to see why not.
This is going to be tedious ..

Thanks,
bernie 



--
I want to die peacefully in my sleep, like my grandfather, not screaming
and yelling like the passengers in his car.

-Original Message-
From: Gary Thomas [mailto:g...@mlbassoc.com] 
Sent: Friday, 29 July 2011 10:42 a.m.
To: Bernard Mentink
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Kernel boot problems

On 2011-07-28 16:10, Bernard Mentink wrote:
 Hi Gary,

 Further down I see a confirmation of the boot params ... i.e 
 console=ttymxc0,115200

 8030d600: 73747369 206e6920 656e6f5a 64726f20ists in Zone ord
 8030d610: 202c7265 69626f6d 7974696c 6f726720er, mobility gro
 8030d620: 6e697075 6e6f2067 5420202e 6c61746fuping on.  Total
 8030d630: 67617020 203a7365 31353233 353c0a32 pages: 32512.5
 8030d640: 72654b3e 206c656e 6d6d6f63 20646e61Kernel command
 8030d650: 656e696c 6f63203a 6c6f736e 74743d65line: console=tt
 8030d660: 63786d79 31312c30 30303235 3e363c0aymxc0,115200.6
 8030d670: 20444950 68736168 62617420 6520656cPID hash table e
 8030d680: 6972746e 203a7365 20323135 64726f28ntries: 512 (ord
 8030d690: 203a7265 202c312d 38343032 74796220er: -1, 2048 byt
 8030d6a0: 0a297365 443e363c 72746e65 61632079es).6Dentry ca
 8030d6b0: 20656863 68736168 62617420 6520656cche hash table e
 8030d6c0: 6972746e 203a7365 38333631 6f282034ntries: 16384 (o
 8030d6d0: 72656472 2c34203a 35353620 62203633rder: 4, 65536 b
 8030d6e0: 73657479 363c0a29 6f6e493e 632d6564ytes).6Inode-c
 8030d6f0: 65686361 73616820 61742068 20656c62ache hash table

 The only mention of serial port is:

 8030df00: 20656e69 69676572 72657473 3c0a6465ine registered.
 8030df10: 6f693e36 68637320 6c756465 632072656io scheduler c
 8030df20: 72207166 73696765 65726574 64282064fq registered (d
 8030df30: 75616665 0a29746c 533e363c 61697265efault).6Seria
 8030df40: 49203a6c 6420584d 65766972 353c0a72l: IMX driver.5
 8030df50: 7968703e 70616d73 616c7020 726f6674physmap platfor
 8030df60: 6c66206d 20687361 69766564 203a6563m flash device:
 8030df70: 30303230 30303030 20746120 303030610200 at a000
 8030df80: 30303030 3e363c0a 73796870 2d70616d.6physmap-
 8030df90: 73616c66 3a302e68 756f4620 3120646eflash.0: Found 1
 8030dfa0: 36317820 76656420 73656369 20746120 x16 devices at
 8030dfb0: 20307830 31206e69 69622d36 616220740x0 in 16-bit ba
 8030dfc0: 202e6b6e 756e614d 74636166 72657275nk. Manufacturer
 8030dfd0: 20444920 30307830 39383030 69684320 ID 0x89 Chi
 8030dfe0: 44492070 30783020 31393830 353c0a63p ID 0x00891c.5
 8030dff0: 7075533e 74726f70 726f6620 6d6f6320Support for com

 .. And yes I did turn on early debug in the kernel config .. But I 
 don't see any extra messages out the serial port.
 How can I check that my .config changes have propagated through ok? ..

Do you have CONFIG_SERIAL_IMX_CONSOLE in your config?  You can just grep
for 'SERIAL_IMX_CONSOLE' in .config

You could also edit drivers/serial/imx.c and put some printk() messages
in serial_imx_probe() to see if it's being called to register your
device.
Of course, you'll have to look at the log_buf to read the messages :-)

I notice that your bootargs don't specify a file system.  Perhaps if you
added that the system could actually make it up to multi-user and you
could log in (serial, SSH, ...)

 --
 --
 --
 I want to die peacefully in my sleep, like my grandfather, not 
 screaming and yelling like the passengers in his car.

 -Original Message-
 From: Gary Thomas [mailto:g...@mlbassoc.com]
 Sent: Friday, 29 July 2011 9:40 a.m.
 To: Bernard Mentink
 Cc: openembedded-devel@lists.openembedded.org
 Subject: Re: [oe] Kernel boot problems

 On 2011-07-28 14:51, Bernard Mentink wrote:
 Many thanks for that,

 I had a look through the buffer and I see pretty much normal bootup 
 text ... It just isn't coming out of the serial port ..

 The only error I saw was the following:
 -
 8030cf80:  0001 3a534656 6e614320VFS: Can
 8030cf90: 20746f6e 6e65706f 6f6f7220 65642074not open root de
 8030cfa0: 65636976 6e282220 296c6c75 726f2022vice (null) or
 8030cfb0: 6b6e7520 6e776f6e 6f6c622d 32286b63 unknown-block(2
 8030cfc0: 64646100 3d72  303a.addr=:0
 8030cfd0: 69202c31 2d3d7172 000a2931 203938301, irq=-1)..089
 8030cfe0: 30373178 2a29 30307830 63313938x170).. 0x00891c
 8030cff0: 203a 7830202d 6566 30303030..0 - 0xfffe
 8030d000: 28202020 36393820 29426b20 2020200a   ( 896 kB).
 8030d010: 414d4420 20202020 30203a20 6378 DMA 

Re: [oe] Kernel boot problems

[Bernard Mentink]

 


Hi Gary,

Did as you suggested .. no printout from serial_imx_probe() is seen, so
I guess it isn't been called, will have to trace it back to see why not.
This is going to be tedious ..

EDIT: However the function imx_serial_init() is being called and
completes without errors, so I don't know why the probe is not being
called ..
Any ideas?

Thanks,
bernie 



--
I want to die peacefully in my sleep, like my grandfather, not screaming
and yelling like the passengers in his car.

-Original Message-
From: Gary Thomas [mailto:g...@mlbassoc.com]
Sent: Friday, 29 July 2011 10:42 a.m.
To: Bernard Mentink
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [oe] Kernel boot problems

On 2011-07-28 16:10, Bernard Mentink wrote:
 Hi Gary,

 Further down I see a confirmation of the boot params ... i.e 
 console=ttymxc0,115200

 8030d600: 73747369 206e6920 656e6f5a 64726f20ists in Zone ord
 8030d610: 202c7265 69626f6d 7974696c 6f726720er, mobility gro
 8030d620: 6e697075 6e6f2067 5420202e 6c61746fuping on.  Total
 8030d630: 67617020 203a7365 31353233 353c0a32 pages: 32512.5
 8030d640: 72654b3e 206c656e 6d6d6f63 20646e61Kernel command
 8030d650: 656e696c 6f63203a 6c6f736e 74743d65line: console=tt
 8030d660: 63786d79 31312c30 30303235 3e363c0aymxc0,115200.6
 8030d670: 20444950 68736168 62617420 6520656cPID hash table e
 8030d680: 6972746e 203a7365 20323135 64726f28ntries: 512 (ord
 8030d690: 203a7265 202c312d 38343032 74796220er: -1, 2048 byt
 8030d6a0: 0a297365 443e363c 72746e65 61632079es).6Dentry ca
 8030d6b0: 20656863 68736168 62617420 6520656cche hash table e
 8030d6c0: 6972746e 203a7365 38333631 6f282034ntries: 16384 (o
 8030d6d0: 72656472 2c34203a 35353620 62203633rder: 4, 65536 b
 8030d6e0: 73657479 363c0a29 6f6e493e 632d6564ytes).6Inode-c
 8030d6f0: 65686361 73616820 61742068 20656c62ache hash table

 The only mention of serial port is:

 8030df00: 20656e69 69676572 72657473 3c0a6465ine registered.
 8030df10: 6f693e36 68637320 6c756465 632072656io scheduler c
 8030df20: 72207166 73696765 65726574 64282064fq registered (d
 8030df30: 75616665 0a29746c 533e363c 61697265efault).6Seria
 8030df40: 49203a6c 6420584d 65766972 353c0a72l: IMX driver.5
 8030df50: 7968703e 70616d73 616c7020 726f6674physmap platfor
 8030df60: 6c66206d 20687361 69766564 203a6563m flash device:
 8030df70: 30303230 30303030 20746120 303030610200 at a000
 8030df80: 30303030 3e363c0a 73796870 2d70616d.6physmap-
 8030df90: 73616c66 3a302e68 756f4620 3120646eflash.0: Found 1
 8030dfa0: 36317820 76656420 73656369 20746120 x16 devices at
 8030dfb0: 20307830 31206e69 69622d36 616220740x0 in 16-bit ba
 8030dfc0: 202e6b6e 756e614d 74636166 72657275nk. Manufacturer
 8030dfd0: 20444920 30307830 39383030 69684320 ID 0x89 Chi
 8030dfe0: 44492070 30783020 31393830 353c0a63p ID 0x00891c.5
 8030dff0: 7075533e 74726f70 726f6620 6d6f6320Support for com

 .. And yes I did turn on early debug in the kernel config .. But I 
 don't see any extra messages out the serial port.
 How can I check that my .config changes have propagated through ok? ..

Do you have CONFIG_SERIAL_IMX_CONSOLE in your config?  You can just grep
for 'SERIAL_IMX_CONSOLE' in .config

You could also edit drivers/serial/imx.c and put some printk() messages
in serial_imx_probe() to see if it's being called to register your
device.
Of course, you'll have to look at the log_buf to read the messages :-)

I notice that your bootargs don't specify a file system.  Perhaps if you
added that the system could actually make it up to multi-user and you
could log in (serial, SSH, ...)

 --
 --
 --
 I want to die peacefully in my sleep, like my grandfather, not 
 screaming and yelling like the passengers in his car.

 -Original Message-
 From: Gary Thomas [mailto:g...@mlbassoc.com]
 Sent: Friday, 29 July 2011 9:40 a.m.
 To: Bernard Mentink
 Cc: openembedded-devel@lists.openembedded.org
 Subject: Re: [oe] Kernel boot problems

 On 2011-07-28 14:51, Bernard Mentink wrote:
 Many thanks for that,

 I had a look through the buffer and I see pretty much normal bootup 
 text ... It just isn't coming out of the serial port ..

 The only error I saw was the following:
 -
 8030cf80:  0001 3a534656 6e614320VFS: Can
 8030cf90: 20746f6e 6e65706f 6f6f7220 65642074not open root de
 8030cfa0: 65636976 6e282220 296c6c75 726f2022vice (null) or
 8030cfb0: 6b6e7520 6e776f6e 6f6c622d 32286b63 unknown-block(2
 8030cfc0: 64646100 3d72  303a.addr=:0
 8030cfd0: 69202c31 2d3d7172 000a2931 203938301, irq=-1)..089
 8030cfe0: 30373178 2a29 30307830 63313938x170).. 0x00891c
 8030cff0: 203a 7830202d 

Re: [oe] Kernel boot problems

[Charles Manning]

 Hi Gary,

 Did as you suggested .. no printout from serial_imx_probe() is seen, so
 I guess it isn't been called, will have to trace it back to see why not.
 This is going to be tedious ..

 EDIT: However the function imx_serial_init() is being called and
 completes without errors, so I don't know why the probe is not being
 called ..
 Any ideas?

The serial initialisation probably happens twice:
Once for the early console stuff to give to the tracing before the
uncompressing.
Then again for setting up the real device tree when the decompressed
kernel is being booted.

I think the  probing is only during the second.



 Thanks,
 bernie


 
 --
 I want to die peacefully in my sleep, like my grandfather, not screaming
 and yelling like the passengers in his car.

 -Original Message-
 From: Gary Thomas [mailto:g...@mlbassoc.com]
 Sent: Friday, 29 July 2011 10:42 a.m.
 To: Bernard Mentink
 Cc: openembedded-devel@lists.openembedded.org
 Subject: Re: [oe] Kernel boot problems

 On 2011-07-28 16:10, Bernard Mentink wrote:
 Hi Gary,

 Further down I see a confirmation of the boot params ... i.e
 console=ttymxc0,115200

 8030d600: 73747369 206e6920 656e6f5a 64726f20    ists in Zone ord
 8030d610: 202c7265 69626f6d 7974696c 6f726720    er, mobility gro
 8030d620: 6e697075 6e6f2067 5420202e 6c61746f    uping on.  Total
 8030d630: 67617020 203a7365 31353233 353c0a32     pages: 32512.5
 8030d640: 72654b3e 206c656e 6d6d6f63 20646e61Kernel command
 8030d650: 656e696c 6f63203a 6c6f736e 74743d65    line: console=tt
 8030d660: 63786d79 31312c30 30303235 3e363c0a    ymxc0,115200.6
 8030d670: 20444950 68736168 62617420 6520656c    PID hash table e
 8030d680: 6972746e 203a7365 20323135 64726f28    ntries: 512 (ord
 8030d690: 203a7265 202c312d 38343032 74796220    er: -1, 2048 byt
 8030d6a0: 0a297365 443e363c 72746e65 61632079    es).6Dentry ca
 8030d6b0: 20656863 68736168 62617420 6520656c    che hash table e
 8030d6c0: 6972746e 203a7365 38333631 6f282034    ntries: 16384 (o
 8030d6d0: 72656472 2c34203a 35353620 62203633    rder: 4, 65536 b
 8030d6e0: 73657479 363c0a29 6f6e493e 632d6564    ytes).6Inode-c
 8030d6f0: 65686361 73616820 61742068 20656c62    ache hash table

 The only mention of serial port is:

 8030df00: 20656e69 69676572 72657473 3c0a6465    ine registered.
 8030df10: 6f693e36 68637320 6c756465 63207265    6io scheduler c
 8030df20: 72207166 73696765 65726574 64282064    fq registered (d
 8030df30: 75616665 0a29746c 533e363c 61697265    efault).6Seria
 8030df40: 49203a6c 6420584d 65766972 353c0a72    l: IMX driver.5
 8030df50: 7968703e 70616d73 616c7020 726f6674physmap platfor
 8030df60: 6c66206d 20687361 69766564 203a6563    m flash device:
 8030df70: 30303230 30303030 20746120 30303061    0200 at a000
 8030df80: 30303030 3e363c0a 73796870 2d70616d    .6physmap-
 8030df90: 73616c66 3a302e68 756f4620 3120646e    flash.0: Found 1
 8030dfa0: 36317820 76656420 73656369 20746120     x16 devices at
 8030dfb0: 20307830 31206e69 69622d36 61622074    0x0 in 16-bit ba
 8030dfc0: 202e6b6e 756e614d 74636166 72657275    nk. Manufacturer
 8030dfd0: 20444920 30307830 39383030 69684320     ID 0x89 Chi
 8030dfe0: 44492070 30783020 31393830 353c0a63    p ID 0x00891c.5
 8030dff0: 7075533e 74726f70 726f6620 6d6f6320Support for com

 .. And yes I did turn on early debug in the kernel config .. But I
 don't see any extra messages out the serial port.
 How can I check that my .config changes have propagated through ok? ..

 Do you have CONFIG_SERIAL_IMX_CONSOLE in your config?  You can just grep
 for 'SERIAL_IMX_CONSOLE' in .config

 You could also edit drivers/serial/imx.c and put some printk() messages
 in serial_imx_probe() to see if it's being called to register your
 device.
 Of course, you'll have to look at the log_buf to read the messages :-)

 I notice that your bootargs don't specify a file system.  Perhaps if you
 added that the system could actually make it up to multi-user and you
 could log in (serial, SSH, ...)

 --
 --
 --
 I want to die peacefully in my sleep, like my grandfather, not
 screaming and yelling like the passengers in his car.

 -Original Message-
 From: Gary Thomas [mailto:g...@mlbassoc.com]
 Sent: Friday, 29 July 2011 9:40 a.m.
 To: Bernard Mentink
 Cc: openembedded-devel@lists.openembedded.org
 Subject: Re: [oe] Kernel boot problems

 On 2011-07-28 14:51, Bernard Mentink wrote:
 Many thanks for that,

 I had a look through the buffer and I see pretty much normal bootup
 text ... It just isn't coming out of the serial port ..

 The only error I saw was the following:
 -
 8030cf80:  0001 3a534656 6e614320    VFS: Can
 8030cf90: 20746f6e 6e65706f 6f6f7220 65642074    not open root de
 8030cfa0: 65636976 6e282220 296c6c75 726f2022    vice (null) or