Re: [yocto] Unable to get serial console login prompt - PowerPC 440 Virtex 5 processor
Hi Khem,
On Aug 19, 2012, at 10:36 AM, Elvis Dowson wrote:
> What should I do to enable multilib in gcc-4.7?
>
> I think at the moment, in gcc-configure-common.inc, it is disabled.
>
> If I were to re-enable it as follows, based on what I've diff'd from the Denx
> ELDK repo, what how does the GCCMULTILIB variable evaluate?
>
> -GCCMULTILIB = "--disable-multilib"
> +GCCMULTILIB = '${@base_contains("MULTILIB_ARCH_LIST", "${TARGET_ARCH}",
> "--enable-multilib", "--disable-multilib",d)}'
>
> I think multilib has to be enabled, no?
>
> In file gcc/config/rs6000/t-ppcos.c
>
> # Multilibs for a powerpc hosted ELF target (linux, SVR4)
>
> MULTILIB_OPTIONS = msoft-float
> MULTILIB_DIRNAMES = nof
> MULTILIB_EXTRA_OPTS = fPIC mstrict-align
> MULTILIB_EXCEPTIONS =
>
> MULTILIB_MATCHES = ${MULTILIB_MATCHES_FLOAT}
>
>
> Here is the full patch, which I am assuming enables multilib, and get libgcc
> to generate the nof libraries to the target:
>
> diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc
> b/meta/recipes-devtools/gcc/gcc-configure-common.inc
> index 908ad3e..a3fa294 100644
> --- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
> +++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
> @@ -25,7 +25,7 @@ EXTRA_OECONF_PATHS ?= ""
> EXTRA_OECONF_INITIAL ?= ""
> EXTRA_OECONF_INTERMEDIATE ?= ""
>
> -GCCMULTILIB = "--disable-multilib"
> +GCCMULTILIB = '${@base_contains("MULTILIB_ARCH_LIST", "${TARGET_ARCH}",
> "--enable-multilib", "--disable-multilib",d)}'
>
> EXTRA_OECONF = "${@['--enable-clocale=generic', ''][d.getVar('USE_NLS',
> True) != 'no']} \
> --with-gnu-ld \
> diff --git a/meta/recipes-devtools/gcc/libgcc_4.7.bb
> b/meta/recipes-devtools/gcc/libgcc_4.7.bb
> index c796253..aac81f6 100644
> --- a/meta/recipes-devtools/gcc/libgcc_4.7.bb
> +++ b/meta/recipes-devtools/gcc/libgcc_4.7.bb
> @@ -18,7 +18,9 @@ FILES_${PN} = "${base_libdir}/libgcc*.so.*"
> FILES_${PN}-dev = " \
>${base_libdir}/libgcc*.so \
>${libdir}/${TARGET_SYS}/${BINV}/*crt* \
> - ${libdir}/${TARGET_SYS}/${BINV}/libgcc*"
> + ${libdir}/${TARGET_SYS}/${BINV}/libgcc* \
> + ${libdir}/${TARGET_SYS}/${BINV}/nof/crt* \
> + ${libdir}/${TARGET_SYS}/${BINV}/nof/libgcc*"
> FILES_libgcov${PKGSUFFIX}-dev = " \
>${libdir}/${TARGET_SYS}/${BINV}/libgcov.a \
>"
Hmm, that didn't work, and no nof libraries were generated on the target.
zImage starting: loaded at 0x0080 (sp: 0x018cdfb0)
Allocating 0x542f0c bytes for kernel ...
gunzipping (0x <- 0x0080f000:0x00a1886f)...done 0x4255c0 bytes
Attached initrd image at 0x00a19000-0x018ccf92
initrd head: 0x1f8b0808
Linux/PowerPC load: console=ttyS0,9600n8 ip=off root=/dev/ram rw rootwait
init=/bin/sh
Finalizing device tree... flat tree at 0x18da0e0
PM: Adding info for No Bus:ttyv9
[0.582992] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[0.588287] 83e0.serial: ttyS0 at MMIO 0x83e01003 (irq = 20) is a 16550
[0.783785] console [ttyS0] enabled
[0.829080] brd: module loaded
[0.875518] loop: module loaded
[0.912757] xsysace 8360.sysace: Xilinx SystemACE revision 1.0.12
[0.989471] xsysace 8360.sysace: No CF in slot
[1.048455] Xilinx SystemACE device driver, major=254
[1.109414] xilinx_emaclite 8100.ethernet: Device Tree Probing
[1.182945] xilinx_emaclite 8100.ethernet: error registering MDIO bus
[1.264024] xilinx_emaclite 8100.ethernet: MAC address is now
00:0a:35:b7:78:00
[1.357651] xilinx_emaclite 8100.ethernet: Xilinx EmacLite at 0x8100
mapped to 0xD10A, irq=17
[1.472557] xilinx_ps2 8148.ps2: Device Tree Probing 'ps2'
[1.541805] xilinx_ps2 8148.ps2: Xilinx PS2 at 0x8148 mapped to
0xd1036000, irq=22
[1.641181] xilinx_ps2 81481000.ps2: Device Tree Probing 'ps2'
[1.710886] xilinx_ps2 81481000.ps2: Xilinx PS2 at 0x81481000 mapped to
0xd1038000, irq=23
[1.811438] mousedev: PS/2 mouse device common for all mice
[1.879037] i2c /dev entries driver
[1.920644] Device Tree Probing 'i2c'
[1.964913] xilinx-iic #0 at 0x8160 mapped to 0xD10C, irq=18
[2.042572] TCP cubic registered
[2.080419] NET: Registered protocol family 17
[2.874354] atkbd serio0: keyboard reset failed on xilinxps2/serio at
8148
[3.358644] RAMDISK: gzip image found at block 0
[3.882546] input: AT Raw Set 2 keyboard as
/devices/plb.0/xps-ps2.1/81481000.ps2/serio1/input/input0
[6.370713] EXT2-fs (ram0): warning: mounting unchecked fs, running e2fsck
is recommended
[6.468154] VFS: Mounted root (ext2 filesystem) on device 1:0.
[6.538666] Freeing unused kernel memory: 152k freed
/bin/sh: can't access tty; job control turned off
[6.682471] Kernel panic - not syncing: Attempted to kill init!
[6.752622] Rebooting in 180 seconds..
Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/li
[yocto] Distributing yocto builds onto an Ubuntu 12.04 LTS cluster
Hi, Has anyone been able to successfully distribute yocto builds onto an Ubuntu 12.04 LTS cluster? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Installing Kernel Modules
Hello All, I currently have a modules*.tgz in my tmp/images/deploy directory that contains all of the kernel modules built. What's the yocto way to pull only the modules I care about into the rootfs image? Thanks, Seth ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Unable to get serial console login prompt - PowerPC 440 Virtex 5 processor
On Sat, Aug 18, 2012 at 11:36 PM, Elvis Dowson wrote:
> Hi Khem,
> What should I do to enable multilib in gcc-4.7?
>
> I think at the moment, in gcc-configure-common.inc, it is disabled.
>
> If I were to re-enable it as follows, based on what I've diff'd from the
> Denx ELDK repo, what how does the GCCMULTILIB variable evaluate?
just for tests. append --enable-multilib to EXTRA_OECONF in
gcc-cross_4.7.bb something like EXTRA_OECONF_append = " xxx "
>
> -GCCMULTILIB = "--disable-multilib"
> +GCCMULTILIB = '${@base_contains("MULTILIB_ARCH_LIST", "${TARGET_ARCH}",
> "--enable-multilib", "--disable-multilib",d)}'
>
> I think multilib has to be enabled, no?
>
> In file gcc/config/rs6000/t-ppcos.c
>
> # Multilibs for a powerpc hosted ELF target (linux, SVR4)
>
> MULTILIB_OPTIONS = msoft-float
> MULTILIB_DIRNAMES = nof
> MULTILIB_EXTRA_OPTS = fPIC mstrict-align
> MULTILIB_EXCEPTIONS =
>
> MULTILIB_MATCHES = ${MULTILIB_MATCHES_FLOAT}
>
>
> Here is the full patch, which I am assuming enables multilib, and get libgcc
> to generate the nof libraries to the target:
>
> diff --git a/meta/recipes-devtools/gcc/gcc-configure-common.inc
> b/meta/recipes-devtools/gcc/gcc-configure-common.inc
> index 908ad3e..a3fa294 100644
> --- a/meta/recipes-devtools/gcc/gcc-configure-common.inc
> +++ b/meta/recipes-devtools/gcc/gcc-configure-common.inc
> @@ -25,7 +25,7 @@ EXTRA_OECONF_PATHS ?= ""
> EXTRA_OECONF_INITIAL ?= ""
> EXTRA_OECONF_INTERMEDIATE ?= ""
>
> -GCCMULTILIB = "--disable-multilib"
> +GCCMULTILIB = '${@base_contains("MULTILIB_ARCH_LIST", "${TARGET_ARCH}",
> "--enable-multilib", "--disable-multilib",d)}'
>
> EXTRA_OECONF = "${@['--enable-clocale=generic', ''][d.getVar('USE_NLS',
> True) != 'no']} \
> --with-gnu-ld \
> diff --git a/meta/recipes-devtools/gcc/libgcc_4.7.bb
> b/meta/recipes-devtools/gcc/libgcc_4.7.bb
> index c796253..aac81f6 100644
> --- a/meta/recipes-devtools/gcc/libgcc_4.7.bb
> +++ b/meta/recipes-devtools/gcc/libgcc_4.7.bb
> @@ -18,7 +18,9 @@ FILES_${PN} = "${base_libdir}/libgcc*.so.*"
> FILES_${PN}-dev = " \
>${base_libdir}/libgcc*.so \
>${libdir}/${TARGET_SYS}/${BINV}/*crt* \
> - ${libdir}/${TARGET_SYS}/${BINV}/libgcc*"
> + ${libdir}/${TARGET_SYS}/${BINV}/libgcc* \
> + ${libdir}/${TARGET_SYS}/${BINV}/nof/crt* \
> + ${libdir}/${TARGET_SYS}/${BINV}/nof/libgcc*"
> FILES_libgcov${PKGSUFFIX}-dev = " \
>${libdir}/${TARGET_SYS}/${BINV}/libgcov.a \
>"
>
> Best regards,
>
> Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Distributing yocto builds onto an Ubuntu 12.04 LTS cluster
On Sun, Aug 19, 2012 at 5:15 AM, Elvis Dowson wrote: > Has anyone been able to successfully distribute yocto builds onto an Ubuntu > 12.04 LTS cluster? master works fine ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Distributing yocto builds onto an Ubuntu 12.04 LTS cluster
Hi Khem, On Aug 19, 2012, at 20:09, Khem Raj wrote: > On Sun, Aug 19, 2012 at 5:15 AM, Elvis Dowson wrote: >> Has anyone been able to successfully distribute yocto builds onto an Ubuntu >> 12.04 LTS cluster? > > master works fine I couldnt get icecc to work. Could you share your settings to get it to work please? Best regards, Elvis Dowson ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Installing Kernel Modules
On Sun, Aug 19, 2012 at 6:53 AM, Seth Bollinger wrote: > I currently have a modules*.tgz in my tmp/images/deploy directory that > contains all of the kernel modules built. What's the yocto way to pull only > the modules I care about into the rootfs image? Every kernel module gets split out into its own binary package. Inspect tmp/deploy/ipk/*/kernel-module-*.ipk, for example, if you're using package_ipk. -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] linux-yocto and private topic branches
On 12-08-17 5:33 PM, Marc Ferland wrote: Bruce Ashfield writes: On 12-08-17 04:21 PM, Marc Ferland wrote: Hi, I'm maintaining a BSP based on crownbay and I would like to change my current kernel recipe from a custom one to linux-yocto_3.2.bb. I'm just heading out for the weekend, but I can pick this up in more detail layer. That would be great! Reading the kernel-yocto.bbclass, I see that it is possible to provide a list of patches and configuration fragments but also (not sure about that) to provide an "external branch". In the denzil (3.2 kernel) that is the case, in the yocto 1.3 (3.4) kernel, it isn't even called an external branch, since the tools are more tolerant of a branch not being present at validation time. BTW, I am using denzil. Since we maintain several private topic branches in-house this would be the perfect solution. I could "inherit" from crownbay (available on linux-yocto) and just merge my topic branches to produce the final kernel source tree. My question: Is this currently possible? If so, are there any examples available? You can do this, but you do need to host your own kernel repository that is based off linux-yocto. In that repository, you can have your own branches, that are easily referenced from the recipes. Is this what you are currently doing with your custom recipe ? We indeed host our own kernel repo but it is based off kernel.org. The recipe just defines the SRC_URI of that repo along with a defconfig. ... and some patches carried out of tree ? So first step for us is to rebase our stuff on linux-yocto! I assumed the patches existing, since you mentioned rebasing something :) I'm stating the obvious, since if you want to clone a tree with your branch .. there must be a tree somewhere with that branch :) The yocto-bsp tools are using the external branches to manage new BSPs that aren't already in linux-yocto. There are other tricks that can be played where smaller, pruned git trees are used, and they are cloned and have their alternates pointed at the main kernel tree repository, gluing the two together. But there's nothing within the current models that supports it directly (you need reference clones, scripts, etc). Can these changes be kept in "recipe-space"? Most everything that can be done in a tree, with branches and meta data can also happen in recipe space. The yocto-bsp scripts are again a good example of this. Ok. I'll definitively have a look at these yocto-bsp scripts. Keeping everything in recipe space will be easier since all changes will be concentrated in one place. Depending on the scale of your patches, how you need to share/reuse them, then keeping them in recipe space is a good starting point. If you scale up to multiple BSPs, with conflicting features, fragments, etc, etc, then going with a repository based on linux-yocto (or some other base) is the next thing to look at. Cheers, Bruce Thanks for all the info! Marc ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
