Date
1 - 20 of 25
Does Edison work with Beagleboard & linux-yocto-3.0 kernel?
|
Brian Hutchinson <b.hutchman@...>
Hi,
I followed the example in the "Yocto Project Development Manual" for setting up a local kernel repo and it didn't go so well. A month or two ago I checked out Edison and was able to build all the images required for Beagleboard and it booted fine (using command line ... not hob. Tried hob but couldn't get it to work). So then I checked out linux-yocto-3.0 kernel and setup a local kernel git repo and went through the process of setting up poky-extras, modifying bblayers.conf etc. to point to my local repo. Any time I try to build core-image-minimal it looks like it always wants to use the 2.6.37 recipe instead of finding my 3.0 repo. I've tried everything I can think of and I must me missing something. So, I guess my questions are: 1. Will linux-yocto-3.0 work with Beagleboard? 2. Is the example for setting up for kernel modification in the development manual still valid for Edison? Regards, Brian |
|
|
|
Bruce Ashfield <bruce.ashfield@...>
On 12-01-11 09:41 AM, Brian Hutchinson wrote:
Hi,It will. I sent patches recently to make that the preferred version in the master branch. Cherry picking that change would probably be all you would need. 2. Is the example for setting up for kernel modification in theShould be. Bruce
|
|
|
|
Brian Hutchinson <b.hutchman@...>
On Wed, Jan 11, 2012 at 9:57 AM, Bruce Ashfield
<bruce.ashfield@...> wrote: It will. I sent patches recently to make that the preferred versionWould I get that change if I just did a git pull or do I have to do something else? I did a git pull to update my Edison checkout last night realizing that I hadn't done one in a while and then ran a new clean build and still ran into the same problem. After triple checking my work I figured it was time to post. Regards, Brian |
|
|
|
Jack Mitchell <ml@...>
On 11/01/12 15:20, Brian Hutchinson wrote:
On Wed, Jan 11, 2012 at 9:57 AM, Bruce Ashfield <bruce.ashfield@...> wrote:It will. I sent patches recently to make that the preferred version in the master branch. Cherry picking that change would probably be all you would need.2. Is the example for setting up for kernel modification in the development manual still valid for Edison?Should be.Would I get that change if I just did a git pull or do I have to do something else? I did a git pull to update my Edison checkout last night realizing that I hadn't done one in a while and then ran a new clean build and still ran into the same problem. After triple checking my work I figured it was time to post. Regards, Brian _______________________________________________ yocto mailing list yocto@... https://lists.yoctoproject.org/listinfo/yocto I can chime in here. I am currently trying to get my Beagleboard running on the master branch, and it is pulling in kernel 3.0.12. However I cannot get it to boot, I get as far as here: Texas Instruments X-Loader 1.5.0 (Jan 11 2012 - 14:06:12) Beagle xM Reading boot sector Loading u-boot.bin from mmc U-Boot 2011.06 (Jan 11 2012 - 14:15:11) OMAP3630/3730-GP ES2.1, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0 *** Warning - readenv() failed, using default environment In: serial Out: serial Err: serial Beagle unknown 0x02 No EEPROM on expansion board Die ID #0ed800229ff800000163810c15007017 Hit any key to stop autoboot: 0 SD/MMC found on device 0 reading uEnv.txt ** Unable to read "uEnv.txt" from mmc 0:1 ** reading uImage 3106580 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 82000000 ... Image Name: Linux-3.0.12-yocto-standard+ Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3106516 Bytes = 3 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Where it hangs and won't go any further. I am watching it over serial using a baud rate of 115200. It's a bit worrying that uBoot doesn't pick up the Beagle revision... I'm sure it used to when I was doing testing a few months ago. Cheers, Jack. |
|
|
|
Bruce Ashfield <bruce.ashfield@...>
On 12-01-11 10:20 AM, Brian Hutchinson wrote:
On Wed, Jan 11, 2012 at 9:57 AM, Bruce AshfieldJust so I'm clear. You are asking about the switch to 3.0 as the default ? If so, that was only done in master for the upcoming 1.2 release and not on the edison branch, so you wouldn't pick it up by pulling. Cheers, Bruce
|
|
|
|
Bruce Ashfield <bruce.ashfield@...>
On 12-01-11 10:24 AM, Jack Mitchell wrote:
On 11/01/12 15:20, Brian Hutchinson wrote:Interesting. You can open a bug on this, boot and sanity/peripheral testsOn Wed, Jan 11, 2012 at 9:57 AM, Bruce AshfieldI can chime in here. I am currently trying to get my Beagleboard running were performed before I made the switch. So if this is broken, that's a bug and we can look into it. As you hinted, including the uboot build/information would be useful, since perhaps that has gotten out of sync. Cheers, Bruce
|
|
|
|
Brian Hutchinson <b.hutchman@...>
On Wed, Jan 11, 2012 at 10:29 AM, Bruce Ashfield
<bruce.ashfield@...> wrote: Just so I'm clear. You are asking about the switch to 3.0 as theThanks! I did a git checkout -b master origin/master and will try again. Regards, Brian |
|
|
|
Brian Hutchinson <b.hutchman@...>
<bruce.ashfield@...> wrote:Thanks Bruce for pointing me in the right direction. I just wanted toJust so I'm clear. You are asking about the switch to 3.0 as theThanks! I did a git checkout -b master origin/master and will try again. follow up. I switched to master branch and did a clean build for Beagleboard. I can confirm that it worked. I blew my SD Card away and put freshly built yocto images of MLO, u-boot.bin & uImage and my Beagleboard xM boots fine (one last question after this output below): Texas Instruments X-Loader 1.5.0 (Jan 11 2012 - 12:41:55) Beagle xM Reading boot sector Loading u-boot.bin from mmc U-Boot 2011.06 (Jan 11 2012 - 12:41:50) OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz OMAP3 Beagle board + LPDDR/NAND I2C: ready DRAM: 512 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 In: serial Out: serial Err: serial Beagle xM Rev A No EEPROM on expansion board Die ID #335000001bf00000015739ea07035019 Hit any key to stop autoboot: 0 SD/MMC found on device 0 reading uEnv.txt ** Unable to read "uEnv.txt" from mmc 0:1 ** reading uImage 3106612 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 82000000 ... Image Name: Linux-3.0.12-yocto-standard+ Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 3106548 Bytes = 3 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Yocto (Built by Poky 6.0) 1.1+snapshot-20120111 beagleboard ttyO2 beagleboard login: root root@beagleboard:~# ls root@beagleboard:~# uptime 19:06:08 up 0 min, load average: 1.08, 0.30, 0.10 root@beagleboard:~# uname -a Linux beagleboard 3.0.12-yocto-standard+ #1 PREEMPT Wed Jan 11 13:53:06 EST 2012 armv7l GNU/Linux root@beagleboard:~# ... so now I'm back to trying to get poky to use my local linux-yocto-3.0 git repo. One more question. When I setup linux-yocto_3.0.bbappend in poky-extras/meta-kernel-dev/recipies-kernel/linux, do I use "yocto/standard/beagleboard" for KMACHINE? Thanks again, Brian |
|
|
|
Bruce Ashfield <bruce.ashfield@...>
On 12-01-11 03:35 PM, Brian Hutchinson wrote:
Excellent!<bruce.ashfield@...> wrote:Thanks Bruce for pointing me in the right direction. I just wanted toJust so I'm clear. You are asking about the switch to 3.0 as theThanks! I did a git checkout -b master origin/master and will try again. If you still want the default (which you likely do here), you can leave KMACHINE untouched in your bbappend and the inherited value from the core layers will take care of everything. Get that working on your local clone, and then try tweaking things :) Cheers, Bruce
|
|
|
|
Joshua Lock <josh@...>
On 11/01/12 06:41, Brian Hutchinson wrote:
Hi,In meta-yocto/conf/distro/poky.conf there's a line which sets: PREFERRED_VERSION_linux-yocto ?= "2.6.37+git%" Which is then overridden for the qemu machines to: PREFERRED_VERSION_linux-yocto_qemuppc ?= "3.0%" If you add a similar line for beagleboard to a conf file, such as local.conf, it would look for a 3.0 kernel version and use your tree. PREFERRED_VERSION_linux-yocto_beagleboard ?= "3.0%" I know you've switched to master but I wanted to help you understand the system is doing what it is. Cheers, Joshua -- Joshua Lock Yocto Project "Johannes factotum" Intel Open Source Technology Centre |
|
|
|
Brian Hutchinson <b.hutchman@...>
On Wed, Jan 11, 2012 at 3:46 PM, Bruce Ashfield
<bruce.ashfield@...> wrote: Will do. I also have a C3 Beagleboard around here somewhere and I'llStarting kernel ... verify that the images I built today work on that platform too. Regards, Brian |
|
|
|
Brian Hutchinson <b.hutchman@...>
On Wed, Jan 11, 2012 at 3:47 PM, Joshua Lock <josh@...> wrote:
In meta-yocto/conf/distro/poky.conf there's a line which sets:Ah, very good! Yes, good to know information. I'm coming from OE-Angstrom/Arago and so far most things have been pretty familiar but it always helps to know how it fits together. I need to make several BSP's for TI processors and this helps me understand things a bit better. I still have an old checkout that has 2.6.37 so I might play with that more. I had working images there I didn't want to mess up (edison). Regards, Brian |
|
|
|
Brian Hutchinson <b.hutchman@...>
Yet another follow up. I finally found my C3 Beagleboard and the
default kernel built off master yesterday works on that platform too. I was able to do another build with the tips you guys gave and it looks like it is picking up the kernel from my local git repo now. I did the "calibrate" example and while I couldn't see the printk's due to the silent boot being turned on somehow, uname -a was different than the default image .... mine is now: root@beagleboard:~# uname -a Linux beagleboard 3.0.14-yocto-standard+ #1 PREEMPT Thu Jan 12 08:45:10 EST 2012 armv7l GNU/Linux And just for sanity, I made another copy of my bare clone and verified that I pushed the "calibrate" changes correctly. So it looks like I'm good now thanks to your help! Do I have to do a cleanall every time I'm finished pushing changes back to my local kernel repo? Is there a document that gives clues as to how to setup a local u-boot repo for making changes to it? Is is simply changing the u-boot recipe SRC_URI to use my local u-boot git repo in poky/meda/recipes-bsp/u-boot or is it more involved than that? Is there a u-boot dev layer like the poky-extras/meta-kernel-dev? Regards, Brian |
|
|
|
Jack Mitchell <ml@...>
On 12/01/12 15:21, Brian Hutchinson wrote:
Yet another follow up. I finally found my C3 Beagleboard and theBrian, What image are you building, as I cannot get core-image-minimal to boot at all on my xM. I am currently trying to fix a hosed sd card (who knows what happened to it!) and then I will see if it has made any difference. Cheers, Jack. |
|
|
|
Bruce Ashfield <bruce.ashfield@...>
On 12-01-12 10:21 AM, Brian Hutchinson wrote:
Yet another follow up. I finally found my C3 Beagleboard and theThe bitbake AUTOREV code should take care of updating the clone of your local repo in downloads/git2. I take it that this isn't happening ? It should be (largely) as simple as that. We could create something simple and throw it in with the meta-kernel-dev layer if there's any interest in adding it. Cheers, Bruce
|
|
|
|
Brian Hutchinson <b.hutchman@...>
On Thu, Jan 12, 2012 at 11:00 AM, Bruce Ashfield
<bruce.ashfield@...> wrote: The bitbake AUTOREV code should take care of updating the clone... haven't tried ... was just sticking to the example in the documentation which says to push changes and do a cleanall. The spin time on my dev machine wasn't too bad but long enough to get old quick if I had to do it often. It should be (largely) as simple as that. We could create somethingJust wanting to know what the "best practice" is as I have lots of platforms to support. Regards, Brian |
|
|
|
Bruce Ashfield <bruce.ashfield@...>
On 12-01-12 11:20 AM, Brian Hutchinson wrote:
On Thu, Jan 12, 2012 at 11:00 AM, Bruce AshfieldGood point. I hadn't noticed that it was in there. Worth trying without it, and raising a bug if it isn't required. It's bitbake internals rather than kernel at play here, so I'm far from authoritative about what should or shouldn't work. time on my dev machine wasn't too bad but long enough to get old quickAgreed! I prefer to work this way, since managing patches in a source gitIt should be (largely) as simple as that. We could create somethingJust wanting to know what the "best practice" is as I have lots of repository is much easier for me. If you only have a few patches, then they can just be pushed on top and added to the SRC_URI, but you'd be doing more development under tmp/work/ in that case .. and I'm paranoid about losing things :) Cheers, Bruce
|
|
|
|
Brian Hutchinson <b.hutchman@...>
On Thu, Jan 12, 2012 at 10:56 AM, Jack Mitchell <ml@...> wrote:
Brian,Probably the same images as you. I switched my branch to master and the default kernel built was 3.0.12. You might have to smoke your SD card (re-partition it for boot & root) and copy MLO first, then u-boot.bin and uImage. Copying MLO first is key. I know this can be a pain. Google for beagleboard SD Card script to find one of the scripts that automates setting up the SD Card. They just create the partitions etc., you still have to copy the contents to the card in the right order. MLO is the first you copy on the boot partition, the order the rest are copied don't matter AFAIK. I also have a boot.scr with: setenv bootcmd 'mmc init; fatload mmc 0:1 0x80300000 uImage; bootm 0x80300000' setenv setenv bootargs 'console=ttyO2,115200n8 root=/dev/mmcblk0p2 rootwait rootfstype=ext3 rw' boot Hope that helps! Regards, Brian |
|
|
|
Brian Hutchinson <b.hutchman@...>
On Thu, Jan 12, 2012 at 11:24 AM, Bruce Ashfield
<bruce.ashfield@...> wrote: I prefer to work this way, since managing patches in a source gitI know it probably isn't the best way (did it mostly because I was in a hurry and never took the time to think about the "right" way to do it) but I've made changes to the kernel & u-boot before in the tmp directories (with Angstrom and Arago) and build images manually (make uImage etc.) and that was OK for quick/dirty things but I've gotten burned before by forgetting my changes and doing a bitbake build and wiping out my changes. I like the method of pointing yocto to local git repos and think that is better for long term development as it will contain history and would be easy to determine what changed etc. I'd like to do something similar with u-boot and thought you guys had worked out a defacto standard way but in looking through all the docs it doesn't look that way. Regards, Brian |
|
|
|
Bruce Ashfield <bruce.ashfield@...>
On 12-01-12 11:48 AM, Brian Hutchinson wrote:
On Thu, Jan 12, 2012 at 11:24 AM, Bruce AshfieldAh yes. Nothing in particular. I was a non-oe import to yocto, so a lot of what I've done is from being bitten in the past and making sure that it didn't happen to me in a new environment. Of course, I'm all for general solutions and getting feedback as well! Cheers, Bruce
|
|
|