Re: [yocto] Tested host distros for 1.1
On 21/09/2011 18:13, Paul Eggleton wrote: On Tuesday 23 August 2011 16:42:49 Paul Eggleton wrote: We now have the mechanism for fixing bug #1096 [1] i.e. showing a warning if the user is running a build on a distro that has not been tested; however to make this work what we now need is a list of distributions we want to consider tested. What distros specifically are we going to list for 1.1? [1] http://bugzilla.pokylinux.org/show_bug.cgi?id=1096 So thanks to Jiajun we now have a wiki page to track tested host distros: https://wiki.yoctoproject.org/wiki/Distribution_Support If you're successfully building Yocto on a host distro that's not currently listed, could you reply here with the information we're collecting on that page (or if you prefer, add it to the wiki page yourself)? Many thanks, Paul I'm building on an ArchLinux 64bit host here. Can't remember the exact packages that were required to install but I retrieved them all easily from offical and possibly one from an unofficial repository. One thing to note though is that I could only have Python2 installed and I had to symlink it to python, as ArchLinux has Python3 linked to python by default. Regards, Jack. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] poky consume all memory on redhat-based linux in virtualbox
Hi all, When I tried to build image on Fedora and Scientific , I encountered same problem that poky consume all memory and then system became very slow. The poky process also moved on hardly. After killing poky process, memory wasn’t freed. I had noticed that some process like “cc1” brought up by poky process were still alive. Anybody know what’s the problem? Another trouble, toolchain built on Ubuntu can’t work well on Fedora. Qemu fail to mount nfs , but it can work on Ubuntu. Best regards Feye 蔡振军 网新技术有限公司物联网事业部 杭州天目山路226号网新大厦 电话-138 6745 1910 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] poky consume all memory on redhat-based linux in virtualbox
On 22 Sep 2011, at 10:28, 蔡振军 wrote: Hi all, When I tried to build image on Fedora and Scientific , I encountered same problem that poky consume all memory and then system became very slow. The poky process also moved on hardly. After killing poky process, memory wasn’t freed. I had noticed that some process like “cc1” brought up by poky process were still alive. Anybody know what’s the problem? How much memory do you have? I've seen the build process peak at something like 2.5GB. I started running with a VM that only had 1GB allocated and had the same problem as this caused lots of swap file activity. It was mainly the compiler/linker that was using most of the memory, which would explain why you see 'cc1'. Don't forget that the build process fires off multiple processes. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] 答复: poky consume all memory on redhat-based linux in virtualbox
Hi Chris, The VM has 1GB memory. Normally 400-500MB is consumed on Ubuntu ,so I think it is enough. Does redhat-based linux need more memory? Because I had closed terminal running poky, all process of poky should quit. 发件人: Chris Tapp [mailto:opensou...@keylevel.com] 发送时间: 2011年9月22日 18:02 收件人: 蔡振军 抄送: yocto@yoctoproject.org 主题: Re: [yocto] poky consume all memory on redhat-based linux in virtualbox On 22 Sep 2011, at 10:28, 蔡振军 wrote: Hi all, When I tried to build image on Fedora and Scientific , I encountered same problem that poky consume all memory and then system became very slow. The poky process also moved on hardly. After killing poky process, memory wasn’t freed. I had noticed that some process like “cc1” brought up by poky process were still alive. Anybody know what’s the problem? How much memory do you have? I've seen the build process peak at something like 2.5GB. I started running with a VM that only had 1GB allocated and had the same problem as this caused lots of swap file activity. It was mainly the compiler/linker that was using most of the memory, which would explain why you see 'cc1'. Don't forget that the build process fires off multiple processes. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] image_types_uboot
maybe somethings wrong, after add "INHERIT += image_types_uboot" in the local.conf, I got that: ERROR: cannot map 'allarch' to a linux kernel architecture Any suggestion? On Thu, 2011-09-22 at 13:09 +0800, 倪庆亮 wrote: > THANKS! > > On Thu, 2011-09-22 at 12:33 +0800, McClintock Matthew-B29882 wrote: > > On Wed, Sep 21, 2011 at 8:56 PM, Ni Qingliang > > wrote: > > > Hello, All: > > > > > > when using "IMAGE_FSTYPES="ext2.gz.u-boot", I can't get what was > > > expected. > > > > > > I can found it in "image_types_uboot.bbclass", but "image.bbclass" only > > > "inherit image_types", not "image_types_uboot". > > > > > > what can I do? How about substitute the "inherit image_types" by > > > "inherit image_types_uboot" in "image.bbclass"? > > > > You can add: > > > > INHERIT += "image_types_uboot" > > > > to your local.conf to enable these types. At some point it would be > > good if we do this by default. > > > > -M > > -- > Yi Qingliang > niqingli...@insigma.com.cn > http://niqingliang2003.wordpress.com > > -- Yi Qingliang niqingli...@insigma.com.cn http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] image_types_uboot
On Thu, Sep 22, 2011 at 8:16 PM, Ni Qingliang wrote: > maybe somethings wrong, after add "INHERIT += image_types_uboot" in the > local.conf, I got that: > ERROR: cannot map 'allarch' to a linux kernel architecture > > Any suggestion? Interesting. I have been seeing this same error and did not yet know what was causing it. It has not caused any problems with the actual build so far, but it's nice to know what is causing it. It's on my list and I plan on looking into it. -M ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] image_types_uboot
I had modified the "image.bbclass", and can generate ext2.gz.u-boot and have new problem, when booting, I got that: /etc/udhcpc.d/50default: line 63: /etc/resolv.conf: No space left on device after login, I execute "echo -n > /etc/resolv.conf" success, and I can't find file /var/log/messages, there is only "wtmp" in "/var/log". On Fri, 2011-09-23 at 09:20 +0800, McClintock Matthew-B29882 wrote: > On Thu, Sep 22, 2011 at 8:16 PM, Ni Qingliang > wrote: > > maybe somethings wrong, after add "INHERIT += image_types_uboot" in the > > local.conf, I got that: > > ERROR: cannot map 'allarch' to a linux kernel architecture > > > > Any suggestion? > > Interesting. I have been seeing this same error and did not yet know > what was causing it. It has not caused any problems with the actual > build so far, but it's nice to know what is causing it. It's on my > list and I plan on looking into it. > > -M -- Yi Qingliang niqingli...@insigma.com.cn http://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] image_types_uboot
attachement is the bootlog on serial console. I'm using mpc8314, I'm using the official kernel 3.0.4, and linux-libc-headers also is 3.0.4, update the udev to 173. On Fri, 2011-09-23 at 11:51 +0800, 倪庆亮 wrote: > I had modified the "image.bbclass", and can generate ext2.gz.u-boot > > and have new problem, when booting, I got that: > > /etc/udhcpc.d/50default: line 63: /etc/resolv.conf: No space left on > device > > after login, I execute "echo -n > /etc/resolv.conf" success, and I can't > find file /var/log/messages, there is only "wtmp" in "/var/log". > > On Fri, 2011-09-23 at 09:20 +0800, McClintock Matthew-B29882 wrote: > > On Thu, Sep 22, 2011 at 8:16 PM, Ni Qingliang > > wrote: > > > maybe somethings wrong, after add "INHERIT += image_types_uboot" in the > > > local.conf, I got that: > > > ERROR: cannot map 'allarch' to a linux kernel architecture > > > > > > Any suggestion? > > > > Interesting. I have been seeing this same error and did not yet know > > what was causing it. It has not caused any problems with the actual > > build so far, but it's nice to know what is causing it. It's on my > > list and I plan on looking into it. > > > > -M > > -- > Yi Qingliang > niqingli...@insigma.com.cn > http://niqingliang2003.wordpress.com > > -- Yi Qingliang niqingli...@insigma.com.cn http://niqingliang2003.wordpress.com ## Booting kernel from Legacy Image at fc10 ... Image Name: Linux-3.0.4 Created: 2011-09-21 8:45:32 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:2262322 Bytes = 2.2 MB Load Address: Entry Point: Verifying Checksum ... OK ## Loading init Ramdisk from Legacy Image at fc50 ... Image Name: core-image-sa735-sa735-201109230 Created: 2011-09-23 3:35:58 UTC Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size:4311933 Bytes = 4.1 MB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at fc0e Booting using the fdt blob at 0xfc0e Uncompressing Kernel Image ... OK Loading Ramdisk to 0faf5000, end 0ff11b7d ... OK Loading Device Tree to 007fa000, end 007ff4ed ... OK Using MPC831x RDB machine description Linux version 3.0.4 (ll@myhost) (gcc version 4.6.1 20110627 (prerelease) (GCC) ) #1 Wed Sep 21 16:45:26 CST 2011 Found initrd at 0xcfaf5000:0xcff11b7d bootconsole [udbg0] enabled setup_arch: bootmem mpc831x_rdb_setup_arch() Found FSL PCI host bridge at 0xe0008500. Firmware bus number: 0->0 PCI host bridge /pci@e0008500 (primary) ranges: MEM 0x9000..0x9fff -> 0x9000 MEM 0x8000..0x8fff -> 0x8000 Prefetch IO 0xe030..0xe03f -> 0x arch: exit Zone PFN ranges: DMA 0x -> 0x0001 Normal empty Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x -> 0x0001 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024 Kernel command line: root=/dev/ram rw ramdisk_size=65535 console=ttyS1,115200 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) Memory: 249928k/262144k available (4392k kernel code, 12216k reserved, 156k data, k bss, 172k init) Kernel virtual memory layout: * 0xfffdf000..0xf000 : fixmap * 0xfdefd000..0xfe00 : early ioremap * 0xd100..0xfdefd000 : vmalloc & ioremap NR_IRQS:512 nr_irqs:512 16 IPIC (128 IRQ sources) at d1000700 clocksource: timebase mult[781] shift[22] registered pid_max: default: 32768 minimum: 301 Mount-cache hash table entries: 512 devtmpfs: initialized NET: Registered protocol family 16 PCI: Probing PCI hardware bio: create slab at 0 Freescale Elo / Elo Plus DMA driver vgaarb: loaded usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb Switching to clocksource timebase NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered UDP hash table entries: 256 (order: 0, 4096 bytes) UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) NET: Registered protocol family 1 RPC: Registered named UNIX socket transport module. RPC: Registered udp transport module. RPC: Registered tcp transport module. RPC: Registered tcp NFSv4.1 backchannel transport module. Trying to unpack rootfs image as initramfs... rootfs image is not initramfs (no cpio magic); looks like an initrd Freeing initrd memory: 4212k freed WDT driver for MPC8xxx initialized. mode:reset timeout=65535 (32 seconds) fsl-elo-dma e00082a8.dm
