Re: [yocto] meta-raspberrypi systemd rpi0-w bluetooth startup
FWIW: Dengke's email caused me to wonder why the RDEPENDS in bluez hadn't
triggered the inclusion of udev-rules-rpi in the first place. I now
suspect that when I tried to switch from 'rocko' to 'master', the steps I
took to force a rebuild were insufficient, and bluez5 was not recompiled
with the new patches, including the patch to increase the timeout. I'm not
able to check it at the moment, but will try to retrace my steps when I get
a chance.
John
On Tue, Mar 20, 2018 at 10:13 AM r10kindsofpeople <
r10kindsofpeo...@gmail.com> wrote:
> Thanks Dengke, I thought I tried using the line "After=dev-ttyAMA0.device"
> and referring to /dev/ttyAMA0 in the hciattach command and the
> brcm43438.service was still being triggered before the /dev/ttyAMA0 device
> was actually available on some boots, but I may have had something else
> wrong at that point, or I may be recalling incorrectly. If it works for
> you, great.
>
> It doesn't make sense to me that we'd need the udev-rules-rpi for bluez,
> but then refer to /dev/ttyAMA0 in the service. I thought the point of the
> 99-com.rules file created by udev-rules-rpi was to create a symbolic link
> equating /dev/ttyAMA0 and /dev/serial1 on the rpi0w.
>
> It's my impression that the move to use /dev/serial1 (as an alias for
> /dev/ttyAMA0) is an attempt to make software written for the Raspberry Pi
> more portable across all variants of the Pi, since some variants swap the
> role of /dev/ttyS0 and /dev/ttyAMA0 for the console or swap which one is
> available on the GPIO expansion. Or perhaps the goal was portablilty from
> Raspbian to Yocto and back. The steps I outlined retain that, and still
> seem to work reliably. I'm not entirely comfortable with relying on the
> udev script to trigger the service that runs hciattach, (and all of bluez
> dependent on that), but acknowledge that I don't know enough about systemd
> and udev to know "proper" from "improper".
>
> John
>
> On Mon, Mar 19, 2018 at 11:01 PM Dengke Du <dengke...@windriver.com>
> wrote:
>
>> Raspberry pi have two built-in UARTs, PL011 and mini UART
>>
>> by default: /dev/ttyS0 refers to the mini UART, /dev/ttyAMA0 refers to
>> the PL011
>>
>> https://www.raspberrypi.org/documentation/configuration/uart.md
>>
>> So I think the brcm43438 service should use the /dev/ttyAMA0.
>>
>> On 2018年03月20日 10:41, Dengke Du wrote:
>>
>> For rpi0-w bluetooth, before the commit:
>>
>>
>> https://github.com/agherzan/meta-raspberrypi/commit/6235b0a8543bcf6704d0fe0156ab2b847a4ea0bc#diff-70e4910388c3702c52118d7acf7556e7
>>
>> the brcm43438.service always failed, because it depends on
>> /dev/ttyAMA0,after that commit, the 'udev-rules-rpi' added to the RDEPENDS
>> for rpi0-w,we
>>
>> can check it here:
>>
>>
>> https://github.com/agherzan/meta-raspberrypi/commit/6235b0a8543bcf6704d0fe0156ab2b847a4ea0bc#diff-3b2568c620828b0ba653c1070041318aR52
>>
>> for service brcm43438, but I still use the /dev/ttyAMA0 in it, not
>> /dev/serial1(when I use /dev/serial1, the service failed), the service can
>> start everytime correctly.
>>
>> On 2018年03月19日 02:10, r10kindsofpeople wrote:
>>
>> Update: I suspect this is not the proper way to do this, but in case it
>> provides useful information toward a better solution...
>> 1) systemctl disable brcm43438.service
>> 2) modified 99-com.rules to include TAG+="systemd" and
>> ENV{SYSTEMD_WANTS}="device-brcm43438.service"
>> 3) cp /lib/systemd/system/brcm43438.service
>> /etc/systemd/system/device-brcm43438.service
>> 4) modified device-brcm43438.service to be as follows:
>> [Unit]
>> Description=Broadcom BCM43438 bluetooth HCI
>>
>> [Service]
>> Type=simple
>> ExecStart=/usr/bin/hciattach -n /dev/serial1 bcm43xx 921600 noflow -
>> Restart=on-failure
>>
>> note removal of Before, After, ConditionPath, Install sections and
>> addition of Restart=on-failure. This last was to cope with an intermittent
>> timeout in hciattach. Suppose I should have tried increasing the timeout
>> first.
>>
>> This seems to have gotten me to the point of it starting up at least 10
>> times successfully. Bottom line, in my opinion, is that brcm43438.service
>> is somehow running before the udev script can create the symbolic link for
>> /dev/serial1 -> /dev/ttyAMA0 despite the "After=dev-serial1.device"
>> clause.
>>
>> John
>>
>>
>> On Sat, Mar 17, 2018 at 12:32 PM r10kindsofpeople <
>> r10kindsofpeo...@gmail.com> wrote:
>>
>>> Background: I'm tryin
Re: [yocto] meta-raspberrypi systemd rpi0-w bluetooth startup
Thanks Dengke, I thought I tried using the line "After=dev-ttyAMA0.device"
and referring to /dev/ttyAMA0 in the hciattach command and the
brcm43438.service was still being triggered before the /dev/ttyAMA0 device
was actually available on some boots, but I may have had something else
wrong at that point, or I may be recalling incorrectly. If it works for
you, great.
It doesn't make sense to me that we'd need the udev-rules-rpi for bluez,
but then refer to /dev/ttyAMA0 in the service. I thought the point of the
99-com.rules file created by udev-rules-rpi was to create a symbolic link
equating /dev/ttyAMA0 and /dev/serial1 on the rpi0w.
It's my impression that the move to use /dev/serial1 (as an alias for
/dev/ttyAMA0) is an attempt to make software written for the Raspberry Pi
more portable across all variants of the Pi, since some variants swap the
role of /dev/ttyS0 and /dev/ttyAMA0 for the console or swap which one is
available on the GPIO expansion. Or perhaps the goal was portablilty from
Raspbian to Yocto and back. The steps I outlined retain that, and still
seem to work reliably. I'm not entirely comfortable with relying on the
udev script to trigger the service that runs hciattach, (and all of bluez
dependent on that), but acknowledge that I don't know enough about systemd
and udev to know "proper" from "improper".
John
On Mon, Mar 19, 2018 at 11:01 PM Dengke Du <dengke...@windriver.com> wrote:
> Raspberry pi have two built-in UARTs, PL011 and mini UART
>
> by default: /dev/ttyS0 refers to the mini UART, /dev/ttyAMA0 refers to the
> PL011
>
> https://www.raspberrypi.org/documentation/configuration/uart.md
>
> So I think the brcm43438 service should use the /dev/ttyAMA0.
>
> On 2018年03月20日 10:41, Dengke Du wrote:
>
> For rpi0-w bluetooth, before the commit:
>
>
> https://github.com/agherzan/meta-raspberrypi/commit/6235b0a8543bcf6704d0fe0156ab2b847a4ea0bc#diff-70e4910388c3702c52118d7acf7556e7
>
> the brcm43438.service always failed, because it depends on
> /dev/ttyAMA0,after that commit, the 'udev-rules-rpi' added to the RDEPENDS
> for rpi0-w,we
>
> can check it here:
>
>
> https://github.com/agherzan/meta-raspberrypi/commit/6235b0a8543bcf6704d0fe0156ab2b847a4ea0bc#diff-3b2568c620828b0ba653c1070041318aR52
>
> for service brcm43438, but I still use the /dev/ttyAMA0 in it, not
> /dev/serial1(when I use /dev/serial1, the service failed), the service can
> start everytime correctly.
>
> On 2018年03月19日 02:10, r10kindsofpeople wrote:
>
> Update: I suspect this is not the proper way to do this, but in case it
> provides useful information toward a better solution...
> 1) systemctl disable brcm43438.service
> 2) modified 99-com.rules to include TAG+="systemd" and
> ENV{SYSTEMD_WANTS}="device-brcm43438.service"
> 3) cp /lib/systemd/system/brcm43438.service
> /etc/systemd/system/device-brcm43438.service
> 4) modified device-brcm43438.service to be as follows:
> [Unit]
> Description=Broadcom BCM43438 bluetooth HCI
>
> [Service]
> Type=simple
> ExecStart=/usr/bin/hciattach -n /dev/serial1 bcm43xx 921600 noflow -
> Restart=on-failure
>
> note removal of Before, After, ConditionPath, Install sections and
> addition of Restart=on-failure. This last was to cope with an intermittent
> timeout in hciattach. Suppose I should have tried increasing the timeout
> first.
>
> This seems to have gotten me to the point of it starting up at least 10
> times successfully. Bottom line, in my opinion, is that brcm43438.service
> is somehow running before the udev script can create the symbolic link for
> /dev/serial1 -> /dev/ttyAMA0 despite the "After=dev-serial1.device"
> clause.
>
> John
>
>
> On Sat, Mar 17, 2018 at 12:32 PM r10kindsofpeople <
> r10kindsofpeo...@gmail.com> wrote:
>
>> Background: I'm trying to bring up the pi zero w's bluetooth using
>> systemd. Started with rocko and then moved to 'master' of meta-raspberry
>> pi, sync'd about a week ago after noticing that there were some recent
>> updates in this area.
>>
>> There was an initial problem with /dev/serial1 not showing up...I found
>> udev-rules-rpi.bb, added it to my layer, and when it still didn't show
>> up in my rootfs, I punted and installed it in /etc/udev/rules.d by hand and
>> now /dev/serial1 shows up. Given time, I can probably fix the recipe on my
>> own, so moving on.
>>
>> But brcm43438.service still fails on boot. Despite having
>> "After=dev-serial1.device" in the service Unit section, it fails with:
>>
>> Mar 17 16:21:13 raspberrypi0-wifi systemd[1]: Started Broadcom BCM43438
>> bluetooth HCI.
>> Mar 17 16:21:14 raspberrypi0-wifi hciattach[105]:
Re: [yocto] meta-raspberrypi systemd rpi0-w bluetooth startup
Update: I suspect this is not the proper way to do this, but in case it
provides useful information toward a better solution...
1) systemctl disable brcm43438.service
2) modified 99-com.rules to include TAG+="systemd" and
ENV{SYSTEMD_WANTS}="device-brcm43438.service"
3) cp /lib/systemd/system/brcm43438.service
/etc/systemd/system/device-brcm43438.service
4) modified device-brcm43438.service to be as follows:
[Unit]
Description=Broadcom BCM43438 bluetooth HCI
[Service]
Type=simple
ExecStart=/usr/bin/hciattach -n /dev/serial1 bcm43xx 921600 noflow -
Restart=on-failure
note removal of Before, After, ConditionPath, Install sections and addition
of Restart=on-failure. This last was to cope with an intermittent timeout
in hciattach. Suppose I should have tried increasing the timeout first.
This seems to have gotten me to the point of it starting up at least 10
times successfully. Bottom line, in my opinion, is that brcm43438.service
is somehow running before the udev script can create the symbolic link for
/dev/serial1 -> /dev/ttyAMA0 despite the "After=dev-serial1.device"
clause.
John
On Sat, Mar 17, 2018 at 12:32 PM r10kindsofpeople <
r10kindsofpeo...@gmail.com> wrote:
> Background: I'm trying to bring up the pi zero w's bluetooth using
> systemd. Started with rocko and then moved to 'master' of meta-raspberry
> pi, sync'd about a week ago after noticing that there were some recent
> updates in this area.
>
> There was an initial problem with /dev/serial1 not showing up...I found
> udev-rules-rpi.bb, added it to my layer, and when it still didn't show up
> in my rootfs, I punted and installed it in /etc/udev/rules.d by hand and
> now /dev/serial1 shows up. Given time, I can probably fix the recipe on my
> own, so moving on.
>
> But brcm43438.service still fails on boot. Despite having
> "After=dev-serial1.device" in the service Unit section, it fails with:
>
> Mar 17 16:21:13 raspberrypi0-wifi systemd[1]: Started Broadcom BCM43438
> bluetooth HCI.
> Mar 17 16:21:14 raspberrypi0-wifi hciattach[105]: Can't open serial port:
> No such file or directory
> Mar 17 16:21:14 raspberrypi0-wifi hciattach[105]: Can't initialize device:
> No such file or directory
> Mar 17 16:21:14 raspberrypi0-wifi systemd[1]: [[0;1;39mbrcm43438.service:
> Main process exited, code=exited, status=1/FAILURE[[0m
> Mar 17 16:21:14 raspberrypi0-wifi systemd[1]: [[0;1;39mbrcm43438.service:
> Unit entered failed state.[[0m
> Mar 17 16:21:14 raspberrypi0-wifi systemd[1]: [[0;1;39mbrcm43438.service:
> Failed with result 'exit-code'.[[0m
>
> If, after booting and ssh'ing into pi, I restart the service, it starts
> successfully.
>
> Any hints about what I might change to get the brcm43438.service to start
> correctly the first time (every time)?
>
> John
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-raspberrypi systemd rpi0-w bluetooth startup
Background: I'm trying to bring up the pi zero w's bluetooth using systemd. Started with rocko and then moved to 'master' of meta-raspberry pi, sync'd about a week ago after noticing that there were some recent updates in this area. There was an initial problem with /dev/serial1 not showing up...I found udev-rules-rpi.bb, added it to my layer, and when it still didn't show up in my rootfs, I punted and installed it in /etc/udev/rules.d by hand and now /dev/serial1 shows up. Given time, I can probably fix the recipe on my own, so moving on. But brcm43438.service still fails on boot. Despite having "After=dev-serial1.device" in the service Unit section, it fails with: Mar 17 16:21:13 raspberrypi0-wifi systemd[1]: Started Broadcom BCM43438 bluetooth HCI. Mar 17 16:21:14 raspberrypi0-wifi hciattach[105]: Can't open serial port: No such file or directory Mar 17 16:21:14 raspberrypi0-wifi hciattach[105]: Can't initialize device: No such file or directory Mar 17 16:21:14 raspberrypi0-wifi systemd[1]: [[0;1;39mbrcm43438.service: Main process exited, code=exited, status=1/FAILURE[[0m Mar 17 16:21:14 raspberrypi0-wifi systemd[1]: [[0;1;39mbrcm43438.service: Unit entered failed state.[[0m Mar 17 16:21:14 raspberrypi0-wifi systemd[1]: [[0;1;39mbrcm43438.service: Failed with result 'exit-code'.[[0m If, after booting and ssh'ing into pi, I restart the service, it starts successfully. Any hints about what I might change to get the brcm43438.service to start correctly the first time (every time)? John -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Krogoth, Beaglebone Black, LCD...seeking direction
My overall goal is to get the 4D 4.3" LCD cape working on the BBB, with Yocto and Qt5 linuxfb. I've got Krogoth/core-image-sato booting on the BBB using the standard Yocto BSP, but there's no sign of activity on the LCD. I'm more than a bit confused about the direction in which I should proceed; it seems like there are several options but all/some are obsolete or losing favor. Recognizing that much of this is a matter of opinion, I'm looking for the path of least resistance to accomplish my goal and have something that's maintainable. Are the "cape manager" and "device trees" opposing solutions to enabling the operating system to recognize and access the LCD ? Which should I pursue on the Krogoth 4.4 kernel? Any good reference links available to configure either? I like the idea of a minimal build and adding in only what's necessary, but am I shooting myself in the foot by going with the reference BSP instead of something like the TI SDK? or Angstrom? John -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] SATO on Intel DN2800MT
I'm trying to experiment with the SATO build on a DN2800MT with a VGA monitor, but can't seem to get going. The binaries from Daisy and genericX86 get as far as the Yocto progress bar complete, and then go black. Any quick hints? I note also that genericX86 looks like a complete Yocto tree rather than just BSP layers. Am I right, and are there hints on how to combine this with a generic Daisy tree for other processors/projects? Yocto_11_0_0/genericx86-daisy-11.0.0/meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config/genericx86/xorg.conf is a zero length file. ? John -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SATO on Intel DN2800MT
On Thu, May 8, 2014 at 12:39 PM, Chris Tapp opensou...@keylevel.com wrote: Hi John, On 8 May 2014, at 16:25, r10kindsofpeople r10kindsofpeo...@gmail.com wrote: I'm trying to experiment with the SATO build on a DN2800MT with a VGA monitor, but can't seem to get going. The binaries from Daisy and genericX86 get as far as the Yocto progress bar complete, and then go black. Any quick hints? Have a look in the README file for the cedartrail BSP. At the bottom you will find: Work Around for VGA and LVDS Display issue in PVR driver The PVR driver has a issue that for some systems it causes it to incorrectly assume that a LVDS display is connected while infact a VGA display is connected and Vice Versa. If your VGA or LVDS display does not work with cedartrail MACHINE, then if you have connected a VGA display, add the following to the kernel command line: video=LVDS-1:d video=VGA-1:e snip I suspect it's this. Watch out if you use HDMI as well - the VGA fix seems to break HDMI. On my systems the VGA then works, but the HDMI pauses a lot running the same image! I think you can use similar magic for HDMI (or did I just take it out?). I note also that genericX86 looks like a complete Yocto tree rather than just BSP layers. Am I right, and are there hints on how to combine this with a generic Daisy tree for other processors/projects? Yocto_11_0_0/genericx86-daisy-11.0.0/meta-yocto-bsp/recipes-graphics/xorg-xserver/xserver-xf86-config/genericx86/xorg.conf is a zero length file. ? John -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto Chris Tapp opensou...@keylevel.com www.keylevel.com Chris, Thanks! What version Yocto are you using? I ask because you suggest I check the README file for the cedartrail BSP, but I've been unable to FIND a cedartrail BSP in anything newer than Denzil, and that only by searching the git trees. genericX86 is said to cover cedartrail, but it does seem, well, generic, with nothing particularly specific to cedartrail, and much more than what I'm used to in a Yocto BSP. At any rate, I'll try what you suggest in terms of the kernel command line. Thanks again, John -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] CAN bus protocol error
With the caution that I'm a bit clumsy at Yocto myself, here's how I did it, using kernel fragments. So in meta-myboard/recipes-kernel/linux/ I have something like the attached .bbappend file. Then in meta-myboard/recipes-kernel/linux/linux-yocto is the can-socket-support-kernel.cfg file. The version number in the bbappend name should match the kernel version you're building. You can add other .cfg files if you need other configuration changes, and still keep them separated by function, just add them to the list in the bbappend file My build bblayers.conf file includes the meta-myboard directory in the BBLAYERS ?= line. I'm using bitbake -c cleansstate linux-yocto bitbake -c compile linux-yocto bitbake linux-yocto to do a clean build of the kernel. FWIW, John On Fri, Jan 3, 2014 at 8:34 AM, wuteng wu wuten...@gmail.com wrote: Hi, I think i have just found where to do the configure, under the dir: /poky/meta-atmel/recipes-kernel/linux/files/sama5d3xek, i will try out your config file, thanks alot. 2014/1/3 wuteng wu wuten...@gmail.com Hi, could you tell me how to clean and rebuild the kernel? I'm newbie to yocto, i have done something like linux-menuconfig when i used the build-root, bu which i can config the kernel configuration, but i don't know how to do it in yocto, at least i didn't find any reference in ref-manual. 2014/1/3 Søren Holm s...@sgh.dk Hi Wuteng I've attached a working defconfig for you to look at. But it seems alright what you are doing. Have you tried doing a cleanall to ensure a complete rebuild with your configuration? Fredag den 3. januar 2014 15:11:56 skrev wuteng wu: Hi, I have cross compiled the canutils and installed it into the target rootfs, but when i tried to test the CAN bus by using the candump command as below: candump can0 interface = can0, family = 29, type = 3, proto = 1 *socket: Protocol not supported* I got the socket: Protocol not supported error msg, i have searched and found the related solution somewhere said that the 'can-raw protocol module' need to be included into the kernel. but how should i do that in yocto ? the needed driver has to be loaded by executing the commands: *modprobe canmodprobe can-devmodprobe can-raw* but only the module can is build-in. It might be possible that the can-dev is also necessary. anyone have experience to share with me ? -- Søren Holm ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto can-socket-support-kernel.cfg Description: Binary data linux-yocto_3.8.bbappend Description: Binary data ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] poky-tiny, boot and filesystems
I've been beating my head for a few days now, and would love a little guidance. Acknowledging that there are multiple ways to skin the cat, my immediate goal is to reduce the boot time, presumably using poky-tiny. I have poky-tiny building for my hardware under dora. I have it booting on crownbay hardware by copying the .ext2 image onto the sdcard, installing grub, copying the .cpio.gz file on to the card, and using grub to load the kernel image and initrd the filesystem. I'm wondering if that last bit about initrd is the 'best' option, or if I should be overlaying a write-able filesystem on top of the original .ext2 file system? How? And I'm pretty sure I've not got something right...I figured out how to .bbappend the tiny-init recipe and get my own edits into 'init' and 'rc.local', but it appears those files and changes made it into both the ext2 file system and the .cpio.gz initrd file system. On one hand, I'm grateful since it works, but 'both' seems to point at me getting something wrong. Any links to clear tutorials would be greatly appreciated. There's a wealth of information available on this topic, but none that seems comprehensive (that I've found), and as I've said, each seems to take a different approach, leaving out a step or two along the way. John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] poky-tiny, boot and filesystems
Rudi, From a first view, my problem is that my embedded Yocto-Linux device takes too long from the application of power to the time that it is first able to a) signal the user that the device is waking up and b) respond to events from I/O (Ethernet and CAN). (40+ seconds prior to shifting to poky-tiny, not counting BIOS delays) From another view, my problem is a lack of understanding about the processes involved during that time, and how the poky-tiny distro is intended to be applied to resolve the 'first view' problem. Yes, poky-tiny produces an image that is both smaller and starts fewer services. It also uses tiny-init which I believe is neither SysV init nor systemd. Outside of the scope of poky-tiny, I need some way to boot my hardware, and the poky-tiny guides seem to stop once they're able to boot qemu. If I simply create an ext2 boot partition on my sdcard and copy the poky-tiny.ext2 image to it, nothing boots. If I also install grub to that partition and provide a grub.cfg, I can boot. (The selection of grub as my boot loader may be my first mistake ?) In that grub.cfg are two critical lines: 1) linux /boot/bzImage root=/dev/mmcblk0p1 and 2) initrd /boot/core-image-minimal-crownbay.cpio.gz If I just do 1), I can boot quickly, but I can't do much else because the file system is mounted read-only. I _want_ most of the file system to be read-only, but need to be able to start the network and do some other 'normal' tasks that require write access to some areas of the file system. Once my user space application is running, my app will use another (USB) device for persistent data storage. If I also do 2), more works and I can start the network, but of course the system takes a bit longer while it's loading the ramdisk. If this is the expected and optimal mode of operation, then I'm done. But am I wrong in thinking that the contents of the .cpio.gz file replaces all of what is in the .ext2 image once it is loaded? I'm confused by the fact that files I added to the tiny-init recipe end up in both the .ext2 file image (just stage 1) and the resulting file system after both 1) 2). It's not that the recipe doesn't work, or that the system is not functional in the end, but a question of whether there's a duplication of effort involved or if there's just a better way to do it for my specific requirements. I understand that these questions stray well beyond the scope of this mailing list, but at the same time, any references to the poky-tiny distro probably won't be understood outside it. Thanks, John On Wed, Dec 18, 2013 at 12:18 PM, Rudolf Streif rstr...@linuxfoundation.org wrote: John, What is your actual problem? You appended the tiny-init recipe and your changes do or do not get put into the rootfs? If you could post your recipe then folks can look at it. As far as boot time is concerned, you need to distinguish boot loader and kernel boot from user space. It looks as if you are trying to optimize your user space boot time by using an image that starts less services. What services you need of course depends on your application. To optimize user space boot process you may also want to investigate systemd instead of SysV init. Rudi On Wed, Dec 18, 2013 at 8:26 AM, r10kindsofpeople r10kindsofpeo...@gmail.com wrote: I've been beating my head for a few days now, and would love a little guidance. Acknowledging that there are multiple ways to skin the cat, my immediate goal is to reduce the boot time, presumably using poky-tiny. I have poky-tiny building for my hardware under dora. I have it booting on crownbay hardware by copying the .ext2 image onto the sdcard, installing grub, copying the .cpio.gz file on to the card, and using grub to load the kernel image and initrd the filesystem. I'm wondering if that last bit about initrd is the 'best' option, or if I should be overlaying a write-able filesystem on top of the original .ext2 file system? How? And I'm pretty sure I've not got something right...I figured out how to .bbappend the tiny-init recipe and get my own edits into 'init' and 'rc.local', but it appears those files and changes made it into both the ext2 file system and the .cpio.gz initrd file system. On one hand, I'm grateful since it works, but 'both' seems to point at me getting something wrong. Any links to clear tutorials would be greatly appreciated. There's a wealth of information available on this topic, but none that seems comprehensive (that I've found), and as I've said, each seems to take a different approach, leaving out a step or two along the way. John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] poky-tiny breaks at ncurses and perl (Dylan 9.0.1)
On Fri, Dec 6, 2013 at 3:08 PM, Tom Zanussi tom.zanu...@intel.com wrote: On Fri, 2013-12-06 at 14:08 -0500, r10kindsofpeople wrote: After some success building my system (crownbay), I'm now trying to optimize boot time, so I read up on poky-tiny, created a new layer and am trying to build. I think I've pulled most of my system changes out so that I can at least bitbake core-image-minimal, but I'm still not able to get past ncurses config and perl. (ncurses reports autoconf errors in widec, perl has undefined references to gcvt, I'm also getting complaints about multiple providers for the kernel, etc.) Is poky-tiny still active and tested? What are the odds of this being resolved in Dora versus the odds of running into other migration issues? I haven't tried poky-tiny with dylan, but I have with dora and didn't run into any build problems - the build errors you're running into aren't things I've seen either. So maybe you can try with dora and see what happens - if you still run into problems, please provide some more details on your setup. Thanks, Tom...using Dora, I was able to get the basic system to build. Adding some features (dhcp-server, for instance) still breaks the build, but I suspect that's just a consequence of -tiny doing it's thing. John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] poky-tiny breaks at ncurses and perl (Dylan 9.0.1)
On Mon, Dec 9, 2013 at 4:24 PM, Saul Wold s...@linux.intel.com wrote:
On 12/09/2013 11:51 AM, r10kindsofpeople wrote:
On Fri, Dec 6, 2013 at 3:08 PM, Tom Zanussi tom.zanu...@intel.com
mailto:tom.zanu...@intel.com wrote:
On Fri, 2013-12-06 at 14:08 -0500, r10kindsofpeople wrote:
After some success building my system (crownbay), I'm now trying to
optimize boot time, so I read up on poky-tiny, created a new
layer and
am trying to build. I think I've pulled most of my system
changes out
so that I can at least bitbake core-image-minimal, but I'm still
not
able to get past ncurses config and perl. (ncurses reports
autoconf
errors in widec, perl has undefined references to gcvt, I'm also
getting complaints about multiple providers for the kernel, etc.)
Is poky-tiny still active and tested? What are the odds of this
being
resolved in Dora versus the odds of running into other migration
issues?
I haven't tried poky-tiny with dylan, but I have with dora and didn't
run into any build problems - the build errors you're running into
aren't things I've seen either.
So maybe you can try with dora and see what happens - if you still run
into problems, please provide some more details on your setup.
Thanks, Tom...using Dora, I was able to get the basic system to build.
Adding some features (dhcp-server, for instance) still breaks the build,
but I suspect that's just a consequence of -tiny doing it's thing.
John, that's probably correct, the tiny configuration uses uclibc and if
you see bug number 5431 (https://bugzilla.yoctoproject.org/show_bug.cgi?
id=5431), there are a number of recipes that will not build correctly
with the full uclibc, but that was with a full uclibc, where as the tiny
configuration cuts down ulibc to just support the bare minimum.
Hope that helps with your efforts.
Sau!
Thanks, Saul, I'll take a look.
A FWIW for any and all...to get qemu to work with the tiny image, I had
to do a menuconfig for busybox and add setsid and cttyhack, otherwise I
was getting not found and error 127 loops on startup.
(hints on how to do this without menuconfig are welcome...I tried creating
my own recipe and adding package ${PN}-setsid or including my own (edited)
defconfig, but neither seemed to work.
John
___
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] poky-tiny breaks at ncurses and perl (Dylan 9.0.1)
After some success building my system (crownbay), I'm now trying to optimize boot time, so I read up on poky-tiny, created a new layer and am trying to build. I think I've pulled most of my system changes out so that I can at least bitbake core-image-minimal, but I'm still not able to get past ncurses config and perl. (ncurses reports autoconf errors in widec, perl has undefined references to gcvt, I'm also getting complaints about multiple providers for the kernel, etc.) Is poky-tiny still active and tested? What are the odds of this being resolved in Dora versus the odds of running into other migration issues? John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] denzil to dylan, netbase recipe broken?
On Tue, Jul 30, 2013 at 11:29 AM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
Hi John,
On Tuesday 30 July 2013 11:15:26 r10kindsofpeople wrote:
Under Denzil 7.0.1, I had a recipe
mylayer/recipes-core/netbase/netbase_4.47.bbappend that contained:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
SRC_URI += file://interfaces \
To put my own interface file in the root file system from
mylayer/recipes-core/netbase/netbase/interfaces
Under Dylan 9.0.1, I tried the same technique, except renaming to
netbase_5.0.bbappend, but I don't get my copy of interfaces, I get some
default.
I've hacked at the recipe a bit, trying to add a do_install step (based
on
the recipe in meta), and know at least that the recipe is getting parsed,
because of the errors I created. I was able to clear up the errors, but
still don't get my copy. Right now, the recipe reads:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
SRC_URI_prepend = file://interfaces \
do_install_append () {
install -d ${D}/${sysconfdir}/network
install -m 0644 ${WORKDIR}/interfaces
${D}${sysconfdir}/network/interfaces
}
PRINC := ${@int(PRINC) + 1}
Can anyone help me understand why the old recipe no longer works, and
what
needs to be done to remedy?
The functionality for starting interfaces has been moved to a separate
init-ifupdown recipe for dylan. This should have been noted in the
migration
information in the reference manual but did not make it in in time; I
hadn't
realised it still hasn't been updated in the current version of the
documentation on the website and the dylan branch so I will now make sure
that
happens.
Basically you just need to move your bbappend across to init-ifupdown and
it
should work.
Cheers,
Paul
Thanks, Paul, that worked.
John
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] ADT 1.4.1 can't get i686-nativesdk?
...continuing the process of updating to dylan, trying to use the released packages... I tried installing the ADT from the tarball, modifying the .conf to only install for x86, minimal-dev. YOCTOADT_REPO=http://adtrepo.yoctoproject.org/1.4.1; With luck the whole .conf file is attached. I'm getting the following error...help, please? Is is possible that one of the scripts isn't using the YOCTOADT_REPO setting? Or do I have it set incorrectly? John Start installing selected native ADT for archs: x86... Successfully create directory /opt/poky/1.4.1//var/lib/opkg. Updating opkg... Downloading http://adtrepo-dev.yoctoproject.org//1.4.1-73f103bf9b2cdf985464dc53bf4f1cfd71d4531f-dylan/adt-ipk/i686-nativesdk/Packages . Collected errors: * opkg_download: Failed to download http://adtrepo-dev.yoctoproject.org//1.4.1-73f103bf9b2cdf985464dc53bf4f1cfd71d4531f-dylan/adt-ipk/i686-nativesdk/Packages, wget returned 8. opkg update process ended... Installing pseudo nativesdk ... Unknown package 'nativesdk-pseudo'. Collected errors: * opkg_install_cmd: Cannot install package nativesdk-pseudo. adt_installer.conf Description: Binary data ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to get released BSP that contains meta-intel ?
Thanks, Tom, FWIW, I did try to confirm by renaming and running my build, but I ran into another issue not apparently related to the BSP that deserves its own thread. John On Thu, Jul 18, 2013 at 3:40 PM, Tom Zanussi tom.zanu...@intel.com wrote: On Thu, 2013-07-18 at 10:01 -0500, Tom Zanussi wrote: Hi, On Thu, 2013-07-18 at 10:21 -0400, r10kindsofpeople wrote: I've been working with denzil, but decided to try and upgrade to dylan... Downloading and installing poky-dylan-9.0.1.tar.bz2 went fine. Finding and downloading meta-crownbay-dylan-9.0.0.tar.bz2 was easy enough. But neither of these give me meta-intel. Actually, what's in the meta-crownbay-dylan tarball is meta-intel, with just the meta-crownbay BSP included. But it looks like there's a problem with the naming of the top-level directory in the tarball: $ ls meta-crownbay binary common conf MAINTAINERS meta-crownbay meta-tlk README whereas after untarring, I should have been able to do: $ ls meta-intel binary common conf MAINTAINERS meta-crownbay meta-tlk README Beth or Nitin, can you please fix the tarballs so that the top-level directory isn't the meta-BSPname but meta-intel (like they are for the previous releases). So the central question is: how do I find and download a released package that contains meta-intel that's required by meta-crownbay? A If you just rename the top-level directory to meta-intel rather than meta-crownbay, things should be fine.. Filed bug 4868 for this. https://bugzilla.yoctoproject.org/show_bug.cgi?id=4868 Tom second question is whether I'd have had problems anyway, given that dylan is 9.0.1 and the BSP is 9.0.0. No, you shouldn't have problems - a given BSP should be good for the same major release and all its point releases... Thanks, Tom I can do a git of meta-intel, but that apparently gives me a snapshot that doesn't play well with the released poky. I can do a git of poky, then a git of meta-intel...I still needed to do a bit of tweaking but I could bitbake core-image-minimal. Now I'm having problems with adt_install, apparently because the scripts all think my release is 1.4+snapshot, which breaks the repository links and the opkg install. I seem to have gotten around these, too, but if someone has something for me to test using released packages, I'm willing, at the moment, to start from scratch. John ___ 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] 9.0.1 release tarball requires bitbake 1.19.1 but provides 1.18.0?
I've run into another issue when trying to upgrade my system from Denzil to Dylan using the released packages. I extracted the 9.0.1 released tarball, added the crownbay BSP, then moved my layers over from Denzil. Sourced the build directory, then modified bblayers.conf and local.conf to merge my specifics with the new formats. 'bitbake core-image-minimal' results in an error... OE-core's config sanity checker detected a potential misconfiguration. and Bitbake version 1.19.1 is required and version 1.18.0 was found. A contributing factor may be that I also have a git snapshot from 2 days ago on the same system (that builds), but I've tried to keep them in separate directories and be careful about running the source script in it's own shell. Is this a problem with the release tarball or a PICNIC problem? John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 9.0.1 release tarball requires bitbake 1.19.1 but provides 1.18.0?
On Fri, Jul 19, 2013 at 11:09 AM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Friday 19 July 2013 07:52:03 Flanagan, Elizabeth wrote: On Fri, Jul 19, 2013 at 6:07 AM, r10kindsofpeople r10kindsofpeo...@gmail.com wrote: I've run into another issue when trying to upgrade my system from Denzil to Dylan using the released packages. I extracted the 9.0.1 released tarball, added the crownbay BSP, then moved my layers over from Denzil. Sourced the build directory, then modified bblayers.conf and local.conf to merge my specifics with the new formats. 'bitbake core-image-minimal' results in an error... OE-core's config sanity checker detected a potential misconfiguration. and Bitbake version 1.19.1 is required and version 1.18.0 was found. A contributing factor may be that I also have a git snapshot from 2 days ago on the same system (that builds), but I've tried to keep them in separate directories and be careful about running the source script in it's own shell. Is this a problem with the release tarball or a PICNIC problem? It shouldn't be a problem with the tarball as the download tarball is http://downloads.yoctoproject.org/releases/yocto/yocto-1.4.1/poky-73f103bf9b 2cdf985464dc53bf4f1cfd71d4531f.tar.bz2 which corresponds with the tagged release at: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dylanid=73f103bf9b 2cdf985464dc53bf4f1cfd71d4531f I just validated the tarball and can't reproduce so my guess is that this is probably a dirty env issue. It does sound that way. John, you haven't perhaps changed the path to the metadata but re-used the build directory, such that BBLAYERS in bblayers.conf still points to the development snapshot? Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre Thanks, Paul and Elizabeth. Once I had a working bblayers.conf in the snapshot, I just copied that file to the build directory of the release, and forgot to change the paths inside. Building now, sorry for the distraction... John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to get released BSP that contains meta-intel ?
I've been working with denzil, but decided to try and upgrade to dylan... Downloading and installing poky-dylan-9.0.1.tar.bz2 went fine. Finding and downloading meta-crownbay-dylan-9.0.0.tar.bz2 was easy enough. But neither of these give me meta-intel. So the central question is: how do I find and download a released package that contains meta-intel that's required by meta-crownbay? A second question is whether I'd have had problems anyway, given that dylan is 9.0.1 and the BSP is 9.0.0. I can do a git of meta-intel, but that apparently gives me a snapshot that doesn't play well with the released poky. I can do a git of poky, then a git of meta-intel...I still needed to do a bit of tweaking but I could bitbake core-image-minimal. Now I'm having problems with adt_install, apparently because the scripts all think my release is 1.4+snapshot, which breaks the repository links and the opkg install. I seem to have gotten around these, too, but if someone has something for me to test using released packages, I'm willing, at the moment, to start from scratch. John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] lmsensors-apps builds, but not in final image?
I'm hoping someone can quickly spot my mistake. I'm attempting to use this recipe: http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/tree/recipes-extended/lm_sensors/lmsensors-apps_3.3.2.bb with my meta-intel/crownbay build under denzil 7.0.1. I put the recipe in my layer, and added lmsensors-apps to my IMAGE_INSTALL_append in my layer's layer.conf. The software builds, and I can see the files in tmp/work/crownbay-poky-linux/lmsensors-apps-3.3.2-r2. But it doesn't make it into tmp/work/core-image-minimal-1.0-r0/rootfs or the .hddimage file. Help, please? John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] lmsensors-apps builds, but not in final image?
Thanks, Marc, that's got me moving forward. However, it may not be
strictly true that lmsensors-apps is empty or at least has no effect. So
far, I'm up to lmsensors lmsensors-scripts lmsensors-apps with the last
being needed {sufficient?} to get strict.pm, needed to do sensors-detect.
Now I'm off to find module cpuid. Thanks again,
John
On Thu, Jan 31, 2013 at 2:20 PM, Marc Ferland ferla...@sonatest.com wrote:
r10kindsofpeople r10kindsofpeo...@gmail.com writes:
I'm hoping someone can quickly spot my mistake. I'm attempting to use
this recipe:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/tree/recipes-extended/lm_
sensors/lmsensors-apps_3.3.2.bb
with my meta-intel/crownbay build under denzil 7.0.1.
I put the recipe in my layer, and added lmsensors-apps to my
IMAGE_INSTALL_append in my layer's layer.conf.
The software builds, and I can see the files in
tmp/work/crownbay-poky-linux/lmsensors-apps-3.3.2-r2.
But it doesn't make it into tmp/work/core-image-minimal-1.0-r0/rootfs
or the .hddimage file.
You have to use one of the packages specified in the recipe. Like
'libsensors' or 'lmsensors-sensors'. lmsensors-apps is empty.
Marc
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] dhcp-server and init scripts
I seem to have figured out how to add the dhcp-server to my image,
including my own dhcpd.conf and default-server files by creating a
dhcp_4.2.4-P1.bbappend recipe. Everything works, except the dhcp-server
doesn't run on boot.
If I login and run update-rc.d dhcp-server defaults on the target, then
it creates the entries in /etc/rc0.d (etc) and the service starts on the
next boot.
The question is, how can I get bitbake to create those entries when it
creates the image? I'm open to completely different ways of going about
this as well. Looking at other recipes, I thought this recipe would do,
but it doesn't:
{named dhcp_4.2.4-P1.bbappend}
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
inherit update-rc.d
INITSCRIPT_NAME = dhcp-server
INITSCRIPT_PARAMS = defaults
# Not sure this is needed, since I'm not adding files, just replacing the
default copies
SRC_URI += file://dhcpd.conf \
file://default-server \
{end file}
I'm using the 8.0 danny release with Crown-bay BSP. The layer.conf
file includes IMAGE_INSTALL_append = dhcp-server (among other things).
Thanks in advance for any assistance you can offer,
John
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dhcp-server and init scripts
Thanks, Gary! That did the trick.
John
On Mon, Dec 3, 2012 at 2:13 PM, Gary Thomas g...@mlbassoc.com wrote:
On 2012-12-03 12:01, r10kindsofpeople wrote:
I seem to have figured out how to add the dhcp-server to my image,
including my own dhcpd.conf and default-server files by creating a
dhcp_4.2.4-P1.bbappend recipe. Everything
works, except the dhcp-server doesn't run on boot.
If I login and run update-rc.d dhcp-server defaults on the target, then
it creates the entries in /etc/rc0.d (etc) and the service starts on the
next boot.
The question is, how can I get bitbake to create those entries when it
creates the image? I'm open to completely different ways of going about
this as well. Looking at other
recipes, I thought this recipe would do, but it doesn't:
{named dhcp_4.2.4-P1.bbappend}
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
inherit update-rc.d
INITSCRIPT_NAME = dhcp-server
INITSCRIPT_PARAMS = defaults
# Not sure this is needed, since I'm not adding files, just replacing the
default copies
SRC_URI += file://dhcpd.conf \
file://default-server \
{end file}
I'm using the 8.0 danny release with Crown-bay BSP. The layer.conf
file includes IMAGE_INSTALL_append = dhcp-server (among other things).
Thanks in advance for any assistance you can offer,
You just missed one piece. I have this working using these extra lines in
my .bbappend:
inherit update-rc.d
INITSCRIPT_PACKAGES = dhcp-server
INITSCRIPT_NAME = dhcp-server
INITSCRIPT_PARAMS = start 50 S . stop 50 0 6 1 .
--
--**--
Gary Thomas | Consulting for the
MLB Associates |Embedded world
--**--
__**_
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.**org/listinfo/yoctohttps://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Crownbay .hddimg partition is corrupt...but works?
I've been following with interest the thread on creating multiple partitions, but before I get there, I seem to have a stumbling block. I've been using dd to copy the .hddimg onto an SDCard and booting from there. It works fine. The core-image-minimal image is about 32MB, copied onto a 16GB card. When 'boot' is mounted under Ubuntu 12.04, I see the 5 files totaling about 31 MB with about 1 MB free. But when I run 'parted' on /dev/mmcblk0, I see one 16GB partition using the fat16 file system. 'parted check' warns me that Partition 1 is 16.0GB, but the file system is 32.2MB. GParted basically throws up its hands in frustration and gives up. It seems to me that before I start trying to get a class created that will create the partitions automatically, I ought to first figure out how to create the partitions by hand, but I'm not convinced that the .hddimg is giving me a solid foundation to start with. Can anyone give me clues to the why/wherefore of the partition that the build system is creating? If I create my own partitions on the card first, won't the 'dd' operation simply wipe that out and replace it with the current situation? I'm using the Crownbay emgd layer, Denzil 7.0.1. John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Crownbay .hddimg partition is corrupt...but works?
On Fri, Oct 19, 2012 at 8:48 AM, r10kindsofpeople r10kindsofpeo...@gmail.com wrote: I've been following with interest the thread on creating multiple partitions, but before I get there, I seem to have a stumbling block. I've been using dd to copy the .hddimg onto an SDCard and booting from there. It works fine. The core-image-minimal image is about 32MB, copied onto a 16GB card. When 'boot' is mounted under Ubuntu 12.04, I see the 5 files totaling about 31 MB with about 1 MB free. But when I run 'parted' on /dev/mmcblk0, I see one 16GB partition using the fat16 file system. 'parted check' warns me that Partition 1 is 16.0GB, but the file system is 32.2MB. GParted basically throws up its hands in frustration and gives up. It seems to me that before I start trying to get a class created that will create the partitions automatically, I ought to first figure out how to create the partitions by hand, but I'm not convinced that the .hddimg is giving me a solid foundation to start with. Can anyone give me clues to the why/wherefore of the partition that the build system is creating? If I create my own partitions on the card first, won't the 'dd' operation simply wipe that out and replace it with the current situation? I'm using the Crownbay emgd layer, Denzil 7.0.1. John Right. Amazing what a cup of coffee can do... So of course .hddimg has no knowledge of the drive size that I'm using, so I can understand why the file system and the partition size don't agree. So I think what I want to create is an image class that: 1) creates an msdos partition table 2) creates a fat16 partition called 'boot' sized for the original .hddimg (or larger) with the boot flag on 3) creates any additional partitions 4) puts the syslinux mbr in the first 440 bytes of the new disk image 5) puts the original .hddimg in the fat16 partition Sound about right? This seems to work by hand. I'm using syslinux to boot into a ramdisk loaded rootfs, I suspect others might want different steps if they're booting into an ext3 image, etc. John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Raspberry Pi mailing list?
There was some discussion of setting up a mailing list for Raspberry PI back in May...did anything come of this? Or is this [Yocto] the best place to post build questions regarding meta-raspberrypi ? John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Raspberry Pi mailing list?
On Mon, Jul 9, 2012 at 10:56 AM, Khem Raj raj.k...@gmail.com wrote: On Monday, July 9, 2012, r10kindsofpeople r10kindsofpeo...@gmail.com wrote: There was some discussion of setting up a mailing list for Raspberry PI back in May...did anything come of this? Or is this [Yocto] the best place to post build questions regarding meta-raspberrypi ? Build related makes sense for yocto to ml I think I suspect they're more tightly related to the meta-raspberrypi than general Yocto, but here goes with an example. (Apologies in advance if I have terminology wrong, I'm still getting up to speed with Yocto). To begin, I did a git clone of the Yocto master, then a git-clone of meta-raspberrypi from github djwillis, then (after setting MACHINE and DISTRO per readme) bitbake rpi-hwup-image. Is this a silly thing to do? Should I be using an earlier release of Yocto? Or...? The first sign of trouble was an error message saying there were no recipes for netbase-4.7 (for which meta-raspberrypi had a .bbappend). Noting that meta was at netbase-5.0 and that the .bbappend at a glance did not look to be version specific, I renamed the meta-raspberrypi recipe and directory to netbase-5.0, and the build was off and running. Now I'm getting fetch failures for a variety of libraries, and, I think kernel-3.1.9. I can probably sort out some of these using the same process, but the larger question is whether I'm on the right track. John ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
