Re: [yocto] Not booting on BeagleBoard xM 0x2
On 13/06/12 03:34, Bruce Ashfield wrote: > On Tue, Jun 12, 2012 at 7:38 PM, Ryan Julian wrote: >> Hi Bruce, >> >> The build I'm using already includes Denys' patch. >> >> I was referring to Tomas' original problem, in which the MMC card >> successfully initialized, but the kernel still panics while trying to mount >> mmcblk0p2. These two seem unrelated, unless I'm mistaken. > > The two issues that we worked with ended up both being resolved by the preempt > disable patch. Both stemmed from the MMC card not being recognized, and that > was due to in kernel preemption. IIRC, both of these went away with a kernel update, but I am now using a kernel from meta-ti, so I can't verify that. Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Not booting on BeagleBoard xM 0x2
On Tue, Jun 12, 2012 at 7:38 PM, Ryan Julian wrote: > Hi Bruce, > > The build I'm using already includes Denys' patch. > > I was referring to Tomas' original problem, in which the MMC card > successfully initialized, but the kernel still panics while trying to mount > mmcblk0p2. These two seem unrelated, unless I'm mistaken. The two issues that we worked with ended up both being resolved by the preempt disable patch. Both stemmed from the MMC card not being recognized, and that was due to in kernel preemption. So we may be seeing something different yet again here .. Cheers, Bruce > > On Tue, Jun 12, 2012 at 4:10 PM, Bruce Ashfield > wrote: >> >> On Tue, Jun 12, 2012 at 7:00 PM, Ryan Julian >> wrote: >> > Tomas Frydrych writes: >> >> This is a different issue. I get this too with one particular MMC card, >> >> but with 2.6.37 kernel, if I unplug this card and plug it back in the >> >> boot resumes and completes successfully. If I do this with the 3.0.2 >> >> kernel, the bug I described with the associated kernel panic then kicks >> >> in. >> >> >> >> Tomas >> >> >> >> > >> >> > >> >> > >> >> > ___ >> >> > yocto mailing list >> >> > yocto@... >> >> > https://lists.yoctoproject.org/listinfo/yocto >> >> >> >> >> > >> > Bruce and Tomas, >> > Did you ever find a solution to this issue? >> > >> > I'm encountering the same issue on the BB-xM Rev C. I've tested on two >> > different >> > boards from different production runs, both with an error identical to >> > Tomas'. >> > I'd be happy to run tests/provide logs if given instructions. >> >> We did. Denys provided us a fix, the only one that was available at the >> time: >> >> commit a49b0ec1356bb15a6a8c76b76c464ab3f1f61840 >> Author: Bruce Ashfield >> Date: Tue Apr 17 13:45:47 2012 -0400 >> >> meta/beagleboard: disable CONFIG_PREEMPT >> >> The boot hangs with the message: >> mmc0: error -110 whilst initialising SD card >> >> The MMC driver has issues initializing when PREEMPT is enabled >> (either forced >> or voluntary). Unplugging and then plugging the card back will reset >> the >> driver and continue booting. Alternatively, disable preemption. >> >> Signed-off-by: Denys Dmytriyenko >> Signed-off-by: Bruce Ashfield >> >> :00 100644 000... 0cbeb5a... A bsp/beagleboard/no-preempt.cfg >> :00 100644 000... 1e75e15... A bsp/beagleboard/no-preempt.scc >> >> Cheers, >> >> Bruce >> >> > >> > Thanks! >> > >> > -Ryan >> > >> > >> > >> > ___ >> > yocto mailing list >> > yocto@yoctoproject.org >> > https://lists.yoctoproject.org/listinfo/yocto >> >> >> >> -- >> "Thou shalt not follow the NULL pointer, for chaos and madness await >> thee at its end" > > -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to build 32-bit x86 host 32-bit powerpc target cross compiler, on a 64-bit x86 host
Please set SDKMACHINE to "i686" in your local.conf when you building the cross canadian compiler. Best Regards, Lianhao From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Elvis Dowson Sent: Tuesday, June 12, 2012 11:15 PM To: Yocto Discussion Mailing List Subject: [yocto] How to build 32-bit x86 host 32-bit powerpc target cross compiler, on a 64-bit x86 host Hi, I am running Ubuntu 12.04 LTS 64-bit. I have a colleague who doesn't have a 64-bit linux installation. What I'd like to be able to do is to build a 32-bit host 32-bit powerpc target cross compiler, on my 64-bit machine. How can I configure Yocto to do this? At the moment, I've already generated a meta-toolchain SDK, which installs into : /opt/poky/1.2+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/ppc440-poky-linux/ How can I generate a the 32-bit hosted cross compiler on my 64-bit yocto build machine? I really didn't quite understand the term canadian-cross compiler, until now!! ;-) Now I know!! Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH x32 Edison 0/2] Fixes for meta-x32 edison branch
> -Original Message-
> From: Joshua Lock [mailto:joshua.l...@intel.com]
> Sent: Tuesday, June 05, 2012 5:46 PM
> To: yocto@yoctoproject.org
> Cc: Joshua Lock; Kamble, Nitin A
> Subject: [PATCH x32 Edison 0/2] Fixes for meta-x32 edison branch
>
> The following patches are required to use the edison branch of meta-x32
> with the current edison branch of Poky.
>
> The first change is required because the edison branch updated its openssl
> version some time ago for security fixes.
>
> The gmp change is required so that gmp-native can be used by ppl.
>
> Regards,
> Joshua
>
> CC: Nitin Kamble
>
> The following changes since commit
> 78a8f65718b7ad7c93103a82026575687271cf5d:
>
> gmp: also built libgmpxx for gmp-native (2011-10-14 10:30:03 -0700)
>
> are available in the git repository at:
> git://github.com/incandescant/meta-x32.git josh/edison
> https://github.com/incandescant/meta-x32
>
> Joshua Lock (2):
> openssl: update bbappend to match version in poky edison
> gmp: Fix EXTRA_OECONF for native target
>
Merged these 2 commits in to Edison branch of the meta-x32 layer.
Nitin
> gmp/gmp_5.0.2.bbappend |2 +-
> ...ssl_0.9.8r.bbappend => openssl_0.9.8s.bbappend} |0
> 2 files changed, 1 insertions(+), 1 deletions(-) rename
> openssl/{openssl_0.9.8r.bbappend => openssl_0.9.8s.bbappend} (100%)
>
> --
> 1.7.7.6
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Not booting on BeagleBoard xM 0x2
On Tue, Jun 12, 2012 at 7:00 PM, Ryan Julian wrote: > Tomas Frydrych writes: >> This is a different issue. I get this too with one particular MMC card, >> but with 2.6.37 kernel, if I unplug this card and plug it back in the >> boot resumes and completes successfully. If I do this with the 3.0.2 >> kernel, the bug I described with the associated kernel panic then kicks in. >> >> Tomas >> >> > >> > >> > >> > ___ >> > yocto mailing list >> > yocto@... >> > https://lists.yoctoproject.org/listinfo/yocto >> >> > > Bruce and Tomas, > Did you ever find a solution to this issue? > > I'm encountering the same issue on the BB-xM Rev C. I've tested on two > different > boards from different production runs, both with an error identical to Tomas'. > I'd be happy to run tests/provide logs if given instructions. We did. Denys provided us a fix, the only one that was available at the time: commit a49b0ec1356bb15a6a8c76b76c464ab3f1f61840 Author: Bruce Ashfield Date: Tue Apr 17 13:45:47 2012 -0400 meta/beagleboard: disable CONFIG_PREEMPT The boot hangs with the message: mmc0: error -110 whilst initialising SD card The MMC driver has issues initializing when PREEMPT is enabled (either forced or voluntary). Unplugging and then plugging the card back will reset the driver and continue booting. Alternatively, disable preemption. Signed-off-by: Denys Dmytriyenko Signed-off-by: Bruce Ashfield :00 100644 000... 0cbeb5a... A bsp/beagleboard/no-preempt.cfg :00 100644 000... 1e75e15... A bsp/beagleboard/no-preempt.scc Cheers, Bruce > > Thanks! > > -Ryan > > > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Not booting on BeagleBoard xM 0x2
Tomas Frydrych writes: > This is a different issue. I get this too with one particular MMC card, > but with 2.6.37 kernel, if I unplug this card and plug it back in the > boot resumes and completes successfully. If I do this with the 3.0.2 > kernel, the bug I described with the associated kernel panic then kicks in. > > Tomas > > > > > > > > > ___ > > yocto mailing list > > yocto@... > > https://lists.yoctoproject.org/listinfo/yocto > > Bruce and Tomas, Did you ever find a solution to this issue? I'm encountering the same issue on the BB-xM Rev C. I've tested on two different boards from different production runs, both with an error identical to Tomas'. I'd be happy to run tests/provide logs if given instructions. Thanks! -Ryan ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] denzil bug status.
On Tue, 12 Jun 2012, Scott Garman wrote: > On 06/12/2012 11:20 AM, Robert P. J. Day wrote: > > On Tue, 12 Jun 2012, Scott Garman wrote: > > > > > Hello, > > > > > > As we are less than a week from our intended release candidate freeze > > > date (June 18) for the denzil point-release, I had a meeting with > > > Richard Purdie and Saul Wold to go over the final bug list and assess > > > the remaining work. Here is a summary of the results of that meeting. > > > > > > The bug numbers I'm referring to can be found on the Yocto Project > > > bugzilla site: https://bugzilla.yoctoproject.org > > > > ... snip ... > > > >was someone working on a fix for downloading tarballs that contain a > > "+" in the filename, to prevent them from being downloaded repeatedly? > > recall the recent issue i reported WRT the "gtk+" tarball, which was > > continually downloaded despite it being in my local mirror. > > Looks like bug #2546 is tracking this: > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=2546 ah, got it. obviously, it's not a serious issue. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] denzil bug status.
On 06/12/2012 11:20 AM, Robert P. J. Day wrote: On Tue, 12 Jun 2012, Scott Garman wrote: Hello, As we are less than a week from our intended release candidate freeze date (June 18) for the denzil point-release, I had a meeting with Richard Purdie and Saul Wold to go over the final bug list and assess the remaining work. Here is a summary of the results of that meeting. The bug numbers I'm referring to can be found on the Yocto Project bugzilla site: https://bugzilla.yoctoproject.org ... snip ... was someone working on a fix for downloading tarballs that contain a "+" in the filename, to prevent them from being downloaded repeatedly? recall the recent issue i reported WRT the "gtk+" tarball, which was continually downloaded despite it being in my local mirror. Looks like bug #2546 is tracking this: https://bugzilla.yoctoproject.org/show_bug.cgi?id=2546 It has not been assigned a milestone, perhaps Richard can clarify if the fix is intended/appropriate for 1.2.1. Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] denzil bug status.
On Tue, 12 Jun 2012, Scott Garman wrote: > Hello, > > As we are less than a week from our intended release candidate freeze > date (June 18) for the denzil point-release, I had a meeting with > Richard Purdie and Saul Wold to go over the final bug list and assess > the remaining work. Here is a summary of the results of that meeting. > > The bug numbers I'm referring to can be found on the Yocto Project > bugzilla site: https://bugzilla.yoctoproject.org ... snip ... was someone working on a fix for downloading tarballs that contain a "+" in the filename, to prevent them from being downloaded repeatedly? recall the recent issue i reported WRT the "gtk+" tarball, which was continually downloaded despite it being in my local mirror. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] denzil bug status.
Hello, As we are less than a week from our intended release candidate freeze date (June 18) for the denzil point-release, I had a meeting with Richard Purdie and Saul Wold to go over the final bug list and assess the remaining work. Here is a summary of the results of that meeting. The bug numbers I'm referring to can be found on the Yocto Project bugzilla site: https://bugzilla.yoctoproject.org Bug 1258 - [crownbay] Xorg eats lots of CPU time after standby STATUS: Still in progress NOTES: Tom Zanussi needs hardware to reproduce the bug, and expects to have a crownbay system in the next day or two. We will revisit this bug once he's had a chance to investigate and assess its impact. Bug 1465 - bitbake cannot fetch local files from SRC_URI when -b is used STATUS: Patch under review on oe-core ML NOTES: A patch for this was just sent out to the oe-core ML this morning, so a fix is under review. Bug 1823 - [Bealgeboard C4] keyboard could not work with 20111207 build STATUS: Just needs documentation NOTES: This appears to be a documentation issue; we will mention the required boot parameters in the release notes for 1.2.1 Bug 2069 - Clutter run failed in qemux86/qemux86_64 on ubuntu/Opensuse/Fedora STATUS: Deferred to 1.3 NOTES: This appears to be a qemugl issue rather than a bug in clutter. The fix for this is likely to be too invasive and the bug has been moved to the next major release. Bug 2328 - Some RPM package file format is not correct on Beagleboard platform STATUS: Deferred to 1.3, document case in release notes NOTES: The fixes required for this are definitely too invasive for a point-release. Rather we will document this case in the release notes. Bug 2329 - Forwarding only sometimes works from qemu connman-based images STATUS: Patch under review on oe-core ML NOTES: This is ready and in my sgarman/denzil-next branch, will be included in my next denzil pull request later today. Bug 2336 - Proxy sanity check message is getting burried STATUS: Patch under review on oe-core ML NOTES: This is ready and in my sgarman/denzil-next branch, will be included in my next denzil pull request later today. Bug 2363 - duplicated bash causes do_rootfs failed on Fedora 17 STATUS: Still in progress NOTES: Saul agreed to try to reproduce the bug on a new Fedora 17 system he's setting up today. Bug 2374 - [eglibc] mtrace should be packaged on it's own STATUS: Still in progress NOTES: We have half a fix for this but it breaks poky-tiny. Richard suggested a fix that could be applied to the poky-tiny distro config that would resolve the second half. Will be testing this ASAP. Bug 2384 - Update distro version warning to not warn about new Ubuntu/Fedora/OpenSUSE releases STATUS: Still in progress NOTES: This is a trivial fix I should have a patch out for soon. Bug 2452 - qemu Unable to find pseudo binary in /usr/bin/ STATUS: Still in progress NOTES: I need to reproduce this issue and get a closer look at it. There is some risk we may need to defer if the fix is complex. Bug 2477 - yocto-7-denzil : core-image-sato doesn't work with Atom N550 STATUS: Still in progress NOTES: Due to inactivity on this bug I have sent an email to the reporter asking for a status update. Depending on the outcome of that we may still be able to resolve it, but there is high risk we won't. Bug 2503 - task-base-extended depends on libc6 >=2.15, 2.13 is built STATUS: Still in progress NOTES: Richard has been assigned this bug and will look into it tomorrow. Significant risk we may need to defer it if the fix is complex. -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/1] remove snb rc6 patches from v3.4 kernel repository
> > Bruce, > > I think these rc6 patches are still needed for linux-yocto_3.2.bbappend. > And they are referenced in the sugarbay bsp 3.2 Yocto kernel as you note > above. The commit I sent is for for v3.4 yocto kernel tree. > > Yes, of course it's for 3.4 .. that's where I merged it :) > > http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.4/log/?h=meta > > > Are you saying about dropping rc6 patches from the 3.2 kernel tree as well? > > I was more reminding for any updates to the BSP to 3.4 .. i.e. don't forget to > drop it from the recipes when updating, sine it will thrown an error during > patching. > > Cheers, > > Bruce I see your point now. I have dropped them from 3.4 kernel recipe 1st to avoid patch application errors. Then we realized that these patches are not needed in the v3.4 kernel repository. Nitin ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to build 32-bit x86 host 32-bit powerpc target cross compiler, on a 64-bit x86 host
On Tue, Jun 12, 2012 at 8:14 AM, Elvis Dowson wrote: > Hi, > I am running Ubuntu 12.04 LTS 64-bit. I have a colleague who doesn't > have a 64-bit linux installation. What I'd like to be able to do is to build > a 32-bit host 32-bit powerpc target cross compiler, on my 64-bit machine. > > How can I configure Yocto to do this? > > At the moment, I've already generated a meta-toolchain SDK, which installs > into : > > /opt/poky/1.2+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/ppc440-poky-linux/ > > How can I generate a the 32-bit hosted cross compiler on my 64-bit yocto > build machine? I really didn't quite understand the term canadian-cross > compiler, until now!! ;-) Now I know!! set SDKMACHINE=i686 > > Best regards, > > Elvis Dowson > > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to build 32-bit x86 host 32-bit powerpc target cross compiler, on a 64-bit x86 host
Hi, I am running Ubuntu 12.04 LTS 64-bit. I have a colleague who doesn't have a 64-bit linux installation. What I'd like to be able to do is to build a 32-bit host 32-bit powerpc target cross compiler, on my 64-bit machine. How can I configure Yocto to do this? At the moment, I've already generated a meta-toolchain SDK, which installs into : /opt/poky/1.2+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/ppc440-poky-linux/ How can I generate a the 32-bit hosted cross compiler on my 64-bit yocto build machine? I really didn't quite understand the term canadian-cross compiler, until now!! ;-) Now I know!! Best regards, Elvis Dowson___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] qemux86 Image won't boot from CF
On Tue, Jun 12, 2012 at 2:04 PM, Andrea Adami wrote: > On Tue, Jun 12, 2012 at 1:07 PM, Jürgen Messerer > wrote: >> Hi everybody. >> >> >> >> The following problem occurs when I try to start a x86 linux system from >> CF-Card. >> >> >> >> I have generate a qemux86 core-image-minimal image with the latest pokey. >> >> After that I have copied everything on a CF including >> bzImage-3.2.1-yocto-standard >> >> Grub was already installed from an old linux version. >> >> >> >> I configured grubs menu.lst. >> >> Ther kernel starts perfectly util it like to finde the rootfs. >> >> Only one ext2 partion exist on the CF-Card. >> >> If have tried hda1 hdb1 hdc1 sda1 sdb1 sdc1 for the to root option. Same >> problem. >> > > Surely it is /dev/sdX since 2.6.3x > Do you have all the necessary config options set for boot from CF? > You need the block (pcmcia, pata, ..) devices and the filesystems > built in kernel. Ah, pls. add 'rootwait' to cmdline when booting from those kind of removable media. Cheers Andrea > > Cheers > > Andrea > >> I also tried initrd. Same problem. >> >> I also tried rootfs from narcissus. Same problem. >> >> >> >> I appreciate any help. >> >> >> >> Thanks. >> >> >> >> Regards >> >> >> >> Juergen >> >> >> >> >> >> Menu.lst : >> >> >> >> serial --unit=0 --speed=57600 >> >> terminal --timeout=1 serial console >> >> default 0 >> >> >> >> # tell grub to find the kernel on /dev/hda1 >> >> root (hd0,0) >> >> savedefault >> >> >> >> # start menu entry with title >> >> title OpenEmbedded GNU/Linux >> >> >> >> title New OE serial console >> >> root (hd0,0) >> >> kernel /boot/bzImage-3.2.11-yocto-standard serialconsole root=/dev/hdb1 >> init=/sbin/init console=tty0 console=ttyS0,57600n8 >> >> savedefault >> >> >> >> >> >> >> >> KERNEL Output: >> >> >> >> Booting 'New OE serial console' >> >> >> >> root (hd0,0) >> >> Filesystem type is ext2fs, partition type 0x83 >> >> kernel /boot/bzImage-3.2.11-yocto-standard serialconsole root=/dev/hdb1 >> init=/s >> >> bin/init console=tty0 console=ttyS0,57600n8 >> >> [Linux-bzImage, setup=0x3a00, size=0x441020] >> >> savedefault >> >> >> >> Initializing cgroup subsys cpuset >> >> Initializing cgroup subsys cpu >> >> Linux version 3.2.11-yocto-standard (blabla@blabla-virtual-machine) (gcc >> version 4.6.4 20120303 (prerelea2 >> >> BIOS-provided physical RAM map: >> >> BIOS-e820: - 0009e000 (usable) >> >> BIOS-e820: 0009e000 - 000a (reserved) >> >> BIOS-e820: 000f - 0010 (reserved) >> >> BIOS-e820: 0010 - 0f7c (usable) >> >> BIOS-e820: - 0001 (reserved) >> >> Notice: NX (Execute Disable) protection missing in CPU! >> >> DMI 2.2 present. >> >> last_pfn = 0xf7c0 max_arch_pfn = 0x10 >> >> init_memory_mapping: -0f7c >> >> ACPI Error: A valid RSDP was not found (20110623/tbxfroot-219) >> >> 0MB HIGHMEM available. >> >> 247MB LOWMEM available. >> >> mapped low ram: 0 - 0f7c >> >> low ram: 0 - 0f7c >> >> Zone PFN ranges: >> >> DMA 0x0010 -> 0x1000 >> >> Normal 0x1000 -> 0xf7c0 >> >> HighMem empty >> >> Movable zone start PFN for each node >> >> early_node_map[2] active PFN ranges >> >> 0: 0x0010 -> 0x009e >> >> 0: 0x0100 -> 0xf7c0 >> >> Using APIC driver default >> >> SMP: Allowing 1 CPUs, 0 hotplug CPUs >> >> No local APIC present or hardware disabled >> >> APIC: disable apic facility >> >> APIC: switched to apic NOOP >> >> Allocating PCI resources starting at f7c (gap: f7c:f083) >> >> setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1 >> >> PERCPU: Embedded 13 pages/cpu @cf00 s29056 r0 d24192 u4194304 >> >> Built 1 zonelists in Zone order, mobility grouping on. Total pages: 62814 >> >> Kernel command line: serialconsole root=/dev/hdb1 init=/sbin/init >> console=tty0 console=ttyS0,57600n8 >> >> PID hash table entries: 1024 (order: 0, 4096 bytes) >> >> Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) >> >> Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) >> >> Initializing CPU#0 >> >> allocated 1014528 bytes of page_cgroup >> >> please try 'cgroup_disable=memory' option if you don't want memory cgroups >> >> Initializing HighMem for node 0 (:) >> >> Memory: 241100k/253696k available (5440k kernel code, 12140k reserved, 2458k >> data, 492k init, 0k highmem) >> >> virtual kernel memory layout: >> >> fixmap : 0xfff17000 - 0xf000 ( 928 kB) >> >> pkmap : 0xff80 - 0xffc0 (4096 kB) >> >> vmalloc : 0xcffc - 0xff7fe000 ( 760 MB) >> >> lowmem : 0xc000 - 0xcf7c ( 247 MB) >> >> .init : 0xc17b7000 - 0xc1832000 ( 492 kB) >> >> .data : 0xc1550219 - 0xc17b6a80 (2458 kB) >> >> .text : 0x
Re: [yocto] qemux86 Image won't boot from CF
On Tue, Jun 12, 2012 at 1:07 PM, Jürgen Messerer wrote: > Hi everybody. > > > > The following problem occurs when I try to start a x86 linux system from > CF-Card. > > > > I have generate a qemux86 core-image-minimal image with the latest pokey. > > After that I have copied everything on a CF including > bzImage-3.2.1-yocto-standard > > Grub was already installed from an old linux version. > > > > I configured grubs menu.lst. > > Ther kernel starts perfectly util it like to finde the rootfs. > > Only one ext2 partion exist on the CF-Card. > > If have tried hda1 hdb1 hdc1 sda1 sdb1 sdc1 for the to root option. Same > problem. > Surely it is /dev/sdX since 2.6.3x Do you have all the necessary config options set for boot from CF? You need the block (pcmcia, pata, ..) devices and the filesystems built in kernel. Cheers Andrea > I also tried initrd. Same problem. > > I also tried rootfs from narcissus. Same problem. > > > > I appreciate any help. > > > > Thanks. > > > > Regards > > > > Juergen > > > > > > Menu.lst : > > > > serial --unit=0 --speed=57600 > > terminal --timeout=1 serial console > > default 0 > > > > # tell grub to find the kernel on /dev/hda1 > > root (hd0,0) > > savedefault > > > > # start menu entry with title > > title OpenEmbedded GNU/Linux > > > > title New OE serial console > > root (hd0,0) > > kernel /boot/bzImage-3.2.11-yocto-standard serialconsole root=/dev/hdb1 > init=/sbin/init console=tty0 console=ttyS0,57600n8 > > savedefault > > > > > > > > KERNEL Output: > > > > Booting 'New OE serial console' > > > > root (hd0,0) > > Filesystem type is ext2fs, partition type 0x83 > > kernel /boot/bzImage-3.2.11-yocto-standard serialconsole root=/dev/hdb1 > init=/s > > bin/init console=tty0 console=ttyS0,57600n8 > > [Linux-bzImage, setup=0x3a00, size=0x441020] > > savedefault > > > > Initializing cgroup subsys cpuset > > Initializing cgroup subsys cpu > > Linux version 3.2.11-yocto-standard (blabla@blabla-virtual-machine) (gcc > version 4.6.4 20120303 (prerelea2 > > BIOS-provided physical RAM map: > > BIOS-e820: - 0009e000 (usable) > > BIOS-e820: 0009e000 - 000a (reserved) > > BIOS-e820: 000f - 0010 (reserved) > > BIOS-e820: 0010 - 0f7c (usable) > > BIOS-e820: - 0001 (reserved) > > Notice: NX (Execute Disable) protection missing in CPU! > > DMI 2.2 present. > > last_pfn = 0xf7c0 max_arch_pfn = 0x10 > > init_memory_mapping: -0f7c > > ACPI Error: A valid RSDP was not found (20110623/tbxfroot-219) > > 0MB HIGHMEM available. > > 247MB LOWMEM available. > > mapped low ram: 0 - 0f7c > > low ram: 0 - 0f7c > > Zone PFN ranges: > > DMA 0x0010 -> 0x1000 > > Normal 0x1000 -> 0xf7c0 > > HighMem empty > > Movable zone start PFN for each node > > early_node_map[2] active PFN ranges > > 0: 0x0010 -> 0x009e > > 0: 0x0100 -> 0xf7c0 > > Using APIC driver default > > SMP: Allowing 1 CPUs, 0 hotplug CPUs > > No local APIC present or hardware disabled > > APIC: disable apic facility > > APIC: switched to apic NOOP > > Allocating PCI resources starting at f7c (gap: f7c:f083) > > setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1 > > PERCPU: Embedded 13 pages/cpu @cf00 s29056 r0 d24192 u4194304 > > Built 1 zonelists in Zone order, mobility grouping on. Total pages: 62814 > > Kernel command line: serialconsole root=/dev/hdb1 init=/sbin/init > console=tty0 console=ttyS0,57600n8 > > PID hash table entries: 1024 (order: 0, 4096 bytes) > > Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) > > Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) > > Initializing CPU#0 > > allocated 1014528 bytes of page_cgroup > > please try 'cgroup_disable=memory' option if you don't want memory cgroups > > Initializing HighMem for node 0 (:) > > Memory: 241100k/253696k available (5440k kernel code, 12140k reserved, 2458k > data, 492k init, 0k highmem) > > virtual kernel memory layout: > > fixmap : 0xfff17000 - 0xf000 ( 928 kB) > > pkmap : 0xff80 - 0xffc0 (4096 kB) > > vmalloc : 0xcffc - 0xff7fe000 ( 760 MB) > > lowmem : 0xc000 - 0xcf7c ( 247 MB) > > .init : 0xc17b7000 - 0xc1832000 ( 492 kB) > > .data : 0xc1550219 - 0xc17b6a80 (2458 kB) > > .text : 0xc100 - 0xc1550219 (5440 kB) > > Checking if this processor honours the WP bit even in supervisor mode...Ok. > > SLUB: Genslabs=15, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 > > Preemptible hierarchical RCU implementation. > > NR_IRQS:2304 nr_irqs:256 16 > > Console: colour VGA+ 80x25 > > console [tty0] enabled > > console [ttyS0] enabled > > Fast TSC calibration using PIT > > De
Re: [yocto] RaspberryPi Kernel - sometimes it works, sometimes it doesn't
On 2012-06-12 05:26, Paul Eggleton wrote: On Tuesday 12 June 2012 08:23:54 Tomas Frydrych wrote: Over years of working with Poky I have developed this sort of a normal work flow: bitbake -c devshell < do some tweaking> bitbake -c compile -f bitbake < this pulls package from sstate!!! scp ... < test, repeat> This no longer works, even after a forced recompile, Poky just pulls a package out of sstate. It seems the only reliable way to force a package rebuild is either to cleansstate or bump the PR, neither of which is viable an option in the above scenario. What am I missing? Is this really intended? I was surprised because this was not behaviour I would expect either, however that is indeed what it does here when I try that sequence. I'm not sure why it is behaving this way but I think it is a bug. FWIW, we will be looking at fixing this exact workflow pretty soon although it may involve an extra explicit step to invalidate the stamps. IMO, if you run a specific step like "-c compile -f", this should automatically invalidate any stamps and sstate info for the package that depend on that step. In this case, it should invalidate "install, package, ..." - everything that normally happens after "compile". This would fix the observed weirdness above. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RaspberryPi Kernel - sometimes it works, sometimes it doesn't
On Tuesday 12 June 2012 08:23:54 Tomas Frydrych wrote: > Over years of working with Poky I have developed this sort of a normal > work flow: > > bitbake -c devshell > < do some tweaking > > bitbake -c compile -f > bitbake < this pulls package from sstate!!! > scp ... > < test, repeat> > > This no longer works, even after a forced recompile, Poky just pulls a > package out of sstate. It seems the only reliable way to force a package > rebuild is either to cleansstate or bump the PR, neither of which is > viable an option in the above scenario. What am I missing? Is this > really intended? I was surprised because this was not behaviour I would expect either, however that is indeed what it does here when I try that sequence. I'm not sure why it is behaving this way but I think it is a bug. FWIW, we will be looking at fixing this exact workflow pretty soon although it may involve an extra explicit step to invalidate the stamps. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] qemux86 Image won't boot from CF
Hi everybody. The following problem occurs when I try to start a x86 linux system from CF-Card. I have generate a qemux86 core-image-minimal image with the latest pokey. After that I have copied everything on a CF including bzImage-3.2.1-yocto-standard Grub was already installed from an old linux version. I configured grubs menu.lst. Ther kernel starts perfectly util it like to finde the rootfs. Only one ext2 partion exist on the CF-Card. If have tried hda1 hdb1 hdc1 sda1 sdb1 sdc1 for the to root option. Same problem. I also tried initrd. Same problem. I also tried rootfs from narcissus. Same problem. I appreciate any help. Thanks. Regards Juergen Menu.lst : serial --unit=0 --speed=57600 terminal --timeout=1 serial console default 0 # tell grub to find the kernel on /dev/hda1 root (hd0,0) savedefault # start menu entry with title title OpenEmbedded GNU/Linux title New OE serial console root (hd0,0) kernel /boot/bzImage-3.2.11-yocto-standard serialconsole root=/dev/hdb1 init=/sbin/init console=tty0 console=ttyS0,57600n8 savedefault KERNEL Output: Booting 'New OE serial console' root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /boot/bzImage-3.2.11-yocto-standard serialconsole root=/dev/hdb1 init=/s bin/init console=tty0 console=ttyS0,57600n8 [Linux-bzImage, setup=0x3a00, size=0x441020] savedefault Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 3.2.11-yocto-standard (blabla@blabla-virtual-machine) (gcc version 4.6.4 20120303 (prerelea2 BIOS-provided physical RAM map: BIOS-e820: - 0009e000 (usable) BIOS-e820: 0009e000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0f7c (usable) BIOS-e820: - 0001 (reserved) Notice: NX (Execute Disable) protection missing in CPU! DMI 2.2 present. last_pfn = 0xf7c0 max_arch_pfn = 0x10 init_memory_mapping: -0f7c ACPI Error: A valid RSDP was not found (20110623/tbxfroot-219) 0MB HIGHMEM available. 247MB LOWMEM available. mapped low ram: 0 - 0f7c low ram: 0 - 0f7c Zone PFN ranges: DMA 0x0010 -> 0x1000 Normal 0x1000 -> 0xf7c0 HighMem empty Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x0010 -> 0x009e 0: 0x0100 -> 0xf7c0 Using APIC driver default SMP: Allowing 1 CPUs, 0 hotplug CPUs No local APIC present or hardware disabled APIC: disable apic facility APIC: switched to apic NOOP Allocating PCI resources starting at f7c (gap: f7c:f083) setup_percpu: NR_CPUS:8 nr_cpumask_bits:8 nr_cpu_ids:1 nr_node_ids:1 PERCPU: Embedded 13 pages/cpu @cf00 s29056 r0 d24192 u4194304 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 62814 Kernel command line: serialconsole root=/dev/hdb1 init=/sbin/init console=tty0 console=ttyS0,57600n8 PID hash table entries: 1024 (order: 0, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Initializing CPU#0 allocated 1014528 bytes of page_cgroup please try 'cgroup_disable=memory' option if you don't want memory cgroups Initializing HighMem for node 0 (:) Memory: 241100k/253696k available (5440k kernel code, 12140k reserved, 2458k data, 492k init, 0k highmem) virtual kernel memory layout: fixmap : 0xfff17000 - 0xf000 ( 928 kB) pkmap : 0xff80 - 0xffc0 (4096 kB) vmalloc : 0xcffc - 0xff7fe000 ( 760 MB) lowmem : 0xc000 - 0xcf7c ( 247 MB) .init : 0xc17b7000 - 0xc1832000 ( 492 kB) .data : 0xc1550219 - 0xc17b6a80 (2458 kB) .text : 0xc100 - 0xc1550219 (5440 kB) Checking if this processor honours the WP bit even in supervisor mode...Ok. SLUB: Genslabs=15, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Preemptible hierarchical RCU implementation. NR_IRQS:2304 nr_irqs:256 16 Console: colour VGA+ 80x25 console [tty0] enabled console [ttyS0] enabled Fast TSC calibration using PIT Detected 499.922 MHz processor. Calibrating delay loop (skipped), value calculated using timer frequency.. 999.84 BogoMIPS (lpj=1999688) pid_max: default: 32768 minimum: 301 Security Framework initialized Mount-cache hash table entries: 512 Initializing cgroup subsys debug Initializing cgroup subsys cpuacct Initializing cgroup subsys memory Initializing cgroup subsys devices Initializing cgroup subsys freezer Initializing cgroup subsys blkio SMP alternatives: switching to UP code Freeing SMP alternatives: 20k freed ftrace: allocating 22469 entries in 44 pages weird, boot CPU (#0) not listed by the BIOS. SMP motherboard not detected. Local APIC not detected. Using dummy APIC emulation. SMP disabled Performanc
Re: [yocto] RaspberryPi Kernel - sometimes it works, sometimes it doesn't
On 11/06/12 17:29, Paul Eggleton wrote: > On Monday 11 June 2012 06:53:32 Khem Raj wrote: >> On 6/11/2012 12:29 AM, Tomas Frydrych wrote: >>> I find that -c clean does not work very well, afterward the package >>> gets recompiled but instead of the actual package packages being >>> rebuilt, an earlier version of the packages gets pulled out of >>> sstate into the image. I definitely saw this behaviour with Yocto >>> kernels, but I think happens with other packages as well; I always >>> do -c cleansstate now to avoid this. >> >> yes thats the intended behavior if nothing changed that ensues a >> recompile then it will use precompiled sstate for the package > > To clarify, it's designed to be able to determine when the recipe has changed > in such a way that it needs to be rebuilt (by building up dependencies > between > variables and computing a checksum of the value of each one, which ends up in > a checksum for each task); if it sees no change then the previous task output > will be used from the sstate cache. It's worth noting however that until > recently (post-1.2) we did not handle when local files referred to in SRC_URI > changed. There also still may be other circumstances under which changes to > the recipe or variables which it refers to will not change the sstate > checksums; if you come across a situation where you made a change and sstate > was re-used when you expected it to be rebuilt, please raise it. Over years of working with Poky I have developed this sort of a normal work flow: bitbake -c devshell < do some tweaking > bitbake -c compile -f bitbake < this pulls package from sstate!!! scp ... < test, repeat> This no longer works, even after a forced recompile, Poky just pulls a package out of sstate. It seems the only reliable way to force a package rebuild is either to cleansstate or bump the PR, neither of which is viable an option in the above scenario. What am I missing? Is this really intended? Tomas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
