dcsimg
Skip to end of metadata
Go to start of metadata

This is the comments page for the BeagleBone.

For all new topics please use: TechXchange Community

  • No labels

246 Comments

  1. The build the kernel procedure fails for me at "git checkout origin/am33x_v3.2 -b am33x_v3.2" with "fatal: git checkout: updating paths in incompatible with switching branches."

    1. In the linux-dev directory, rerun both "git pull" and "git fetch"...

      1. I ran "git pull" and "git fetch", but the behavior was the same.  Any other ideas?  Thanks.

        dave@lucy:~/bone/linux-dev$ git pull
        Already up-to-date.
        dave@lucy:~/bone/linux-dev$ git fetch
        dave@lucy:~/bone/linux-dev$ git checkout origin/am33x_v3.2 -b am33x_v3.2
        fatal: git checkout: updating paths is incompatible with switching branches.
        Did you intend to checkout 'origin/am33x_v3.2' which can not be resolved as commit?
        
        1. Maybe a "git checkout -f master" might help, otherwise what version of git are you using and what distro?

          It works fine here, and there's nothing special with the git commands used..

          voodoo@hades:/opt/eewiki$ lsb_release -a
          No LSB modules are available.
          Distributor ID: Debian
          Description:    Debian GNU/Linux testing (wheezy)
          Release:        testing
          Codename:       wheezy
          
          voodoo@hades:/opt/eewiki$ git --version
          git version 1.7.10
          
          voodoo@hades:/opt/eewiki$ git clone git://github.com/RobertCNelson/linux-dev.git
          Cloning into 'linux-dev'...
          remote: Counting objects: 7683, done.
          remote: Compressing objects: 100% (3297/3297), done.
          remote: Total 7683 (delta 4490), reused 7577 (delta 4384)
          Receiving objects: 100% (7683/7683), 5.63 MiB | 188 KiB/s, done.
          Resolving deltas: 100% (4490/4490), done.
          
          voodoo@hades:/opt/eewiki$ cd linux-dev/
          voodoo@hades:/opt/eewiki/linux-dev$ cat .git/config 
          [core]
                  repositoryformatversion = 0
                  filemode = true
                  bare = false
                  logallrefupdates = true
          [remote "origin"]
                  fetch = +refs/heads/*:refs/remotes/origin/*
                  url = git://github.com/RobertCNelson/linux-dev.git
          [branch "master"]
                  remote = origin
                  merge = refs/heads/master
          
          voodoo@hades:/opt/eewiki/linux-dev$ git checkout origin/am33x-v3.2 -b am33x-v3.2
          Branch am33x-v3.2 set up to track remote branch am33x-v3.2 from origin.
          Switched to a new branch 'am33x-v3.2'
          

          Regards,

  2. Thanks for the instructions. Worked like a charm.

    However, the new kernel I've built + rootfs combination (Squeeze) doesn't list eth0 anymore when I do an ifconfig.

    Do I need to load a specific kernel module or force a special driver to be included in the kernel?

    1. Hi Francis,

      With the kernel config in this git repo build script, it's enabled by default..

      [*]   Texas Instruments (TI) devices
       < >     TI DaVinci EMAC Support
       -*-     TI DaVinci MDIO Support
       -*-     TI DaVinci CPDMA Support
       <*>     TI CPSW Switch Support
      

      Any chance is this an A4 board? Please take a look at: http://beagleboard.org/static/beaglebone/latest/README.htm

      Specifically the Revision section under "A4" resistor/100Mbit ethernet.

      Regards,

      1. Hi,

        I have an A6 board and the stock Angstrom release works with regards to Ethernet. The modules listed above are effectively built-in the kernel.

        more modules.builtin
        kernel/drivers/net/ethernet/smsc/smc91x.ko
        kernel/drivers/net/ethernet/smsc/smsc911x.ko
        kernel/drivers/net/ethernet/ti/davinci_mdio.ko
        kernel/drivers/net/ethernet/ti/davinci_cpdma.ko
        kernel/drivers/net/ethernet/ti/ti_cpsw.ko

        root@devel:/proc# ifconfig
        lo        Link encap:Local Loopback
                  inet addr:127.0.0.1  Mask:255.0.0.0
                  inet6 addr: ::1/128 Scope:Host
                  UP LOOPBACK RUNNING  MTU:16436  Metric:1
                  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
                  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
                  collisions:0 txqueuelen:0
                  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

        root@devel:/proc# dmesg | grep davinci
        [    1.682803] davinci_mdio davinci_mdio.0: davinci mdio revision 1.6
        [    1.689256] davinci_mdio davinci_mdio.0: detected phy mask fffffffe
        [    1.696640] davinci_mdio.0: probed
        [    1.700191] davinci_mdio davinci_mdio.0: phy[0]: device 0:00, driver SMSC LAN8710/LAN8720

        apparently I'm missing an entry for cpsw such as:

        [   12.512462] CPSW phy found : id is : 0x7c0f1
        [   12.513232] PHY 0:01 not found
        [   12.536693] ADDRCONF(NETDEV_UP): eth0: link is not ready
        [   15.512047] PHY: 0:00 - Link is Up - 100/Full
        [   15.512287] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

        Any clue of what could cause this?

        1. Hi Francis,

          Strange, I haven't personally seen any A6's in the field yet, can you please pastebin.com your full dmesg with 3.2-psp17 release I tagged last night.. (head of the am33x-v3.2 branch)

          fyi: Angstrom and this script share the same kernel source, just a slight modification to the defconfig..

          Regards,

          1. Hi Robert,
            I've moved to the new release and I've noticed the same issue.

            http://pastebin.com/u2aP2kRp
            (converted to pastebin by: Robert Nelson)

            1. Hi Francis,

              I think I'll need to pick up an A6.. My A5, doesn't show that issue at all..

              A5 boot: http://pastebin.com/kgHNYS9r

              diff (A5 is the +): http://pastebin.com/26RCWdTw

              Nothing really stands out...

              fyi: for verification, I just powered my A5, via usb to more match your config, no change, Ethernet works just fine..

              BTW: if you have time, can you replace the patches/defconfig with this file from angstrom; ( https://github.com/beagleboard/kernel/blob/beaglebone-3.2/patches/beaglebone/defconfig ).. Then you'll be building the exact same kernel as Angstrom's.. It would be useful in figuring out what config broke the A6..

              Regards,

              1. I'm rebuilding wit the new defconfig (had to modify the build script to pause after it copies the defconfig file so I could overwrite it) though the diff is very minimal. I'll let you know the result.

                Otherwise, at this point, I think the issue resides with the cpsw driver as it is not loaded in my case. I'll investigate if I have the time. Meanwhile I'll try to progress on other other fronts for my project.

                thx

                1. Actually just copy it right over patches/defconfig before running "./build_kernel.sh" or "./tools/rebuild.sh" as the git tree is setup for that release...

                  So with a brand new A6, (using the same sd card as yesterday), it's working here:

                  http://pastebin.com/qjD6Kvn6

                  Very, very strange...

                  Regards,

  3. Hmmm. So for the linux kernel source I'm using the omap branch. your instructions lists 2 kernel sources: Linus' and omap. which one do you use as in the setup process we need to change the config to refer to that directory.

    1. Hi Francis,

      Thanks for noticing, I had forgotten to document where most of the am33x linux patchset came from. I've now updated the kernel source list with a link to the TI arago project tree. Moving forward, for a normal mainline based kernel, we might be able to finally move to v3.6-rc1 (after the arm-soc merge) for the BeagleBone. (it will of course be using device tree's)

      Regards,

  4. Actually, the Kernel fetching / building process is not clear and that may be the cause of the issue I have.

    For U-Boot, if someone follows the instructions as is everything works fine.

    Now for the Kernel it is a different story. I if clone you project, checkout the branch and launch build_kernel.sh I get the following error: need to copy system.sh and configure it.

    From that file I concluded I had to at least clone the kernel project and update the path in the system.sh file. There are however 3 references to the kernel at the top of your page so it is not clear which one we should clone the kernel from (if it matters). Also the links aren't git:// urls so someone must be minimally knowledgeable to understand how to get that url from the web page you reference.

    So I think it would be beneficial if you could provide the exact instructions as for u-boot about how to clone the right kernel, modify the system.sh file before someone attempts to launch a kernel build.

    Hope this will solve my problem and help others.

    Here is what I'm trying after trashing my previous kernel:git clone git://github.com/RobertCNelson/linux-dev.gitcd linux-dev/
    git checkout origin/am33x-v3.2 -b am33x-v3.2

    cd ..; git clone git://arago-project.org/git/projects/linux-am33x.git

    cd linux-dev; cp system.sh.sample system.sh

    modify LINUX_GIT=~/linux-stable/ in system.sh to point to the location of the linux-am3x directory

    ./build_kernel.sh

    1. The git repo behind "LINUX_GIT" really doesn't matter, as it's just a starting point. The build_kernel.sh script will use "LINUX_GIT" as a "git clone --shared" reference and pull in tags from the linus and linux-stable tree's to checkout a pristine starting point.. (in this branch v3.2)

      What I want users todo is:

      cd ~/
      git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
      cd -
      cp system.sh.sample system.sh
      nano system.sh 
      edit "LINUX_GIT=~/linux-stable/"
      

      This is shown when it errors out the first time when running "./build_kernel.sh"

      https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.2/build_kernel.sh#L76

      I'm not sure how I can make this clearer without doing it on my own in the script, which i have a couple reasons for not doing it automatically..

      1: For me, I have 3 repo's.. linux-dev (ti development), stable-kernel (ti stable), and imx-devel (freescale devel/stable).. Having 3 identical "linux-stable" repo's is a waste of space.

      2: Most kernel dev's have already cloned linus's tree at once, so no reason to re-download another massive git tree, when it's can be easily linked.

      Regards,

      1. Ok. Didn't initially pulled from linux-stable.

        should work now. will let you know.

    2. got this error:

      Debug: LINUX_GIT setup...
      /home/r48910/linux/manual/kernel/linux-am33x
      [core]
          repositoryformatversion = 0
          filemode = true
          bare = false
          logallrefupdates = true
      [remote "origin"]
          fetch = +refs/heads/*:refs/remotes/origin/*
          url = git://arago-project.org/git/projects/linux-am33x.git
      [branch "master"]
          remote = origin
          merge = refs/heads/master
      Updating LINUX_GIT tree via: git fetch
      /home/r48910/linux/manual/kernel/linux-dev
      Cloning into '/home/r48910/linux/manual/kernel/linux-dev/KERNEL'...
      done.
      Resolve operation not in progress, we are not resuming.
      git tree is clean...
      [master 805545e] empty cleanup commit
       Committer: ubuntu <r48910@ubuntu.(none)>
      Your name and email address were configured automatically based
      on your username and hostname. Please check that they are accurate.
      You can suppress this message by setting them explicitly:

          git config --global user.name "Your Name"
          git config --global user.email you@example.com

      After doing this, you may fix the identity used for this commit with:

          git commit --amend --reset-author

      Branch tmp-master set up to track remote branch master from origin.
      Switched to a new branch 'tmp-master'
      Branch master set up to track remote branch master from origin.
      Switched to a new branch 'master'
      Already up-to-date.
      fatal: git checkout: updating paths is incompatible with switching branches.
      Did you intend to checkout 'v3.2' which can not be resolved as commit?

      1. Thanks for your support.

        After fetching the right Linux project and rebuilding the kernel I could see eth0 with ifconfig -a.

        After updating the /etc/network/interfaces file, eth0 is now powering up automatically.

  5. Thanks for a great job and clearer than usual instructions on setting things up.  I've got an A6 Beaglebone running your Ubuntu 12.04 system with kernel 3.2.23-psp18, everything seems to work.

    But git protocol is blocked here so I'm having a hard time figuring out how to get the kernel source/headers so I can cross compile a driver module to install on the BeagleBone.

    Are there any alternatives?

    For my purposes I don't much care if I run Angstrom 3.2.25#1 or Ubuntu 12.04 3.2.23-psp18 as with both systems I've been able to compile local sample programs and run cross-compiled sample programs transfered via USB stick.

    I thought I could compile my module on the BeagleBone out of tree if I could get the kernel headers,  using the procedure described here (stackoverflow.com/questions/4025320/building-out-of-tree-kernel-modules-depmod-and-why-reboot) but:

    sudo apt-get install kernel-headers-$(uname -r)

    didn't work: Unable to locate package kernel-headers-3.2.23-psp18

    1. Hello,

      Yeah, your not going to find my custom kernel in the ubuntu repo's...

      To get the kernel/header source, without using git, for BeagleBone's 3.2.23-psp18, first download:

      wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.tar.bz2
      wget http://rcn-ee.net/deb/precise-armhf/v3.2.23-psp18/patch-3.2-psp18.diff.gz
      wget http://rcn-ee.net/deb/precise-armhf/v3.2.23-psp18/defconfig
      

      Then, just:

      tar xvjf linux-3.2.tar.bz2
      cd linux-3.2/
      zcat ../patch-3.2-psp18.diff.gz | patch -p1
      cp ../defconfig .config
      

      Regards,

      1. Thank you so much for this solution.

        Before I attempt to cross-compile, I'd like to try installing the kernel headers to my BeagleBone SD card and trying the out of tree module build on the running kernel.  Is there a convenient way to just extract the headers from the linux-3.2 tree (like the way Debian/Ubuntu packages them up) or is it best to just copy the entire source tree even though I will only need the headers?

        Will renaming the linux-3.2 directory to say linux-3.2.23-psp18 break anything?

        I haven't had to do kernel building (other than the "Debian way" of :  fakeroot debian/rules clean ; dpkg-buildpackage -B -uc -us) since RedHat 6, linux 2.2.14 when I was setting up rtlinux a long time ago,  I recall once patching started things got pretty fragile.  Hopefully the process has improved.

        1. Hello,

          Unfortunately, with the arm arch the simplified 'kernel headers' are almost useless at this point. Alot of the SOC specific (sub-arch) headers doesn't get pulled into the package.

          The best thing to do is, just copy the fully patched kernel source and add two symlinks to that source directory from:

          /lib/modules/`uname -r`/source
          /lib/modules/`uname -r`/build
          
          • Really, only one is needed just don't remember which one specifically off hand...

          For building, unless you want to share the image in a nice *.deb package, don't bother with the debian pkg scripts. (there is nice in kernel make deb-pkg (wink))

          make ARCH=arm CROSS_COMPILE= zImage modules
          
          • On native arm builds an empty CROSS_COMPILE= is still needed...

          Regards,

  6. Hi Robert,

    when I used "make menuconfig" to enable "device drivers->usb support-> USB Gadget Support-> USB Gadget Drivers -> Compile HID Gadget as Module", then running with "make"  would give me error as

    CC [M]  drivers/mtd/nand/nand_base.o
    drivers/mtd/nand/nand_base.c: In function ‘nand_command_lp’:
    drivers/mtd/nand/nand_base.c:728:3: error: implicit declaration of function ‘dmb’ [-Werror=implicit-function-declaration]
    cc1: some warnings being treated as errors
    make[3]: *** [drivers/mtd/nand/nand_base.o] Error 1
    make[2]: *** [drivers/mtd/nand] Error 2
    make[1]: *** [drivers/mtd] Error 2
    make: *** [drivers] Error 2

    later on, then I fix the problem by defining "#define dmb() _asm_ _volatile_ ("" : : : "memory")" into nand_base.c and make again, it gave me error as

      LD      arch/x86/built-in.o
      CHK     kernel/config_data.h
      CC [M]  drivers/usb/musb/musb_procfs.o
    drivers/usb/musb/musb_procfs.c:39:35: fatal error: mach/hardware.h: No such file or directory
    compilation terminated.

    so I have to remove the line "include <mach/hardware.h>" from musb_procfs.c. But make again, gave me

    LD      .tmp_vmlinux1
    drivers/built-in.o: In function `d_can_plat_probe':
    d_can_platform.c:(.devinit.text+0x4324): undefined reference to `clk_get'
    d_can_platform.c:(.devinit.text+0x444c): undefined reference to `clk_get_rate'
    d_can_platform.c:(.devinit.text+0x44fd): undefined reference to `clk_put'
    make: *** [.tmp_vmlinux1] Error 1

    if you can help me with this would be much appreciated.

    I am using ubuntu Precise on a virtual box.

    Cheers,

    1. Hi Damien,

      Unless your more specific on what you actually changed.. git diff

      diff --git a/patches/defconfig b/patches/defconfig
      index c0bef54..dbbf652 100644
      --- a/patches/defconfig
      +++ b/patches/defconfig
      @@ -1,6 +1,6 @@
       #
       # Automatically generated file; DO NOT EDIT.
      -# Linux/arm 3.2.23 Kernel Configuration
      +# Linux/arm 3.2.25 Kernel Configuration
       #
       CONFIG_ARM=y
       CONFIG_HAVE_PWM=y
      @@ -3321,7 +3321,7 @@ CONFIG_USB_GADGET_MUSB_HDRC=y
       CONFIG_USB_GADGET_DUALSPEED=y
       # CONFIG_USB_ZERO is not set
       # CONFIG_USB_AUDIO is not set
      -CONFIG_USB_ETH=y
      +CONFIG_USB_ETH=m
       # CONFIG_USB_ETH_RNDIS is not set
       # CONFIG_USB_ETH_EEM is not set
       # CONFIG_USB_G_NCM is not set
      

      Build just fine using...

      Debug Using: arm-linux-gnueabi-gcc (Linaro GCC 4.6-2012.05) 4.6.4 20120508 (prerelease)
      

      PS.. Remember this is massive fork based on 3.2.x stable, so not every config option will build...

      Regards,

  7. Hi Robert,

    I got the compilation problem fixed. But now, I changed somthing on the "board-am335xevm.c" file. However, everytime when I run the "build_kernel.sh", my changes would get lost. Is there any way that I can put my change into a patch file and get applied everything when running the "build_kernel.sh".

    Please note, you have a patch file to "board-am335xevm.c" already, how can I apply your patch first, then follow with my one?

    Cheers,

    1. Hi Damien,

      Yes there is... After you've first run the ./build_kernel.sh script to initially setup the KERNEL directory... Make your changes, then run ./tool/rebuild.sh to just rebuild the kernel image... Once your satisfied with your patch, just run:

      git commit -a -m 'ARM: OMAP: BeagleBone <something descriptive>' -s
      git format-patch -1 -o ../patches/
      

      and then add that *.patch to patch.sh script so that it will get automatically added when running ./build_kernel.sh...

      Regards,

      1. Thanks Robert, the commands you gave works fine.

        Now, I have a few more questions.

        1) Are the patch files generated with command above transferable? I mean, can I bring the patch files with the modified pathch.sh file to different computer without any other files - since other files can be get with commands listed on this page.

        2) I built the hid module with the kernel source referred on the page, but when I insmod into my kernel, I got "insmod: error inserting './g_hid.ko': -1 Invalid module format" error. Checked with syslog file, it says "./syslog:Sep  3 21:29:16 bone2 kernel: [430281.750457] g_hid: disagrees about version of symbol module_layout", I am thinking this may due to my kernel is 3.2.23-psp18, while the kernel source referred at this page is 3.2.28-xxxx, so, I followed the steps stated a couple of conversation above to build the HID module with 3.2.23, but this time, when I insmod the module, I got error as "insmod: error inserting 'g_hid.ko': -1 No such device", what could be wrong?

        To build the hid module, there is no source code change, all my changes are:

        diff --git a/patches/defconfig b/patches/defconfig
        index 999f67f..19bda00 100644
        --- a/patches/defconfig
        +++ b/patches/defconfig
        @@ -3321,7 +3321,7 @@ CONFIG_USB_GADGET_MUSB_HDRC=y
         CONFIG_USB_GADGET_DUALSPEED=y
         # CONFIG_USB_ZERO is not set
         # CONFIG_USB_AUDIO is not set
        -CONFIG_USB_ETH=y
        +CONFIG_USB_ETH=m
         # CONFIG_USB_ETH_RNDIS is not set
         # CONFIG_USB_ETH_EEM is not set
         # CONFIG_USB_G_NCM is not set
        @@ -3336,7 +3336,7 @@ CONFIG_USB_ETH=y
         # CONFIG_USB_G_NOKIA is not set
         # CONFIG_USB_G_ACM_MS is not set
         # CONFIG_USB_G_MULTI is not set
        -# CONFIG_USB_G_HID is not set
        +CONFIG_USB_G_HID=m
         # CONFIG_USB_G_DBGP is not set
         # CONFIG_USB_G_WEBCAM is not set

        Cheers,

        1. Hi Damien,

          Remember, this kernel tree for the BeagleBone is a massive fork based on v3.2.x so not everything works at the moment... Right now the BeagleBone developers are working on a v3.6.x based replacement, but it's not even close for general use at this point in time...

          ubuntu@omap:~$ uname -a
          Linux omap 3.2.28-psp21 #1 Tue Sep 4 08:52:13 CDT 2012 armv7l armv7l armv7l GNU/Linux
          ubuntu@omap:~$ lsmod
          Module                  Size  Used by
          snd_soc_tlv320aic3x    32650  0 
          spidev                  4652  0
          
          ubuntu@omap:~$ sudo depmod -a
          
          ubuntu@omap:~$ sudo modprobe g_hid
          FATAL: Error inserting g_hid (/lib/modules/3.2.28-psp21/kernel/drivers/usb/gadget/g_hid.ko): No such device
          
          ubuntu@omap:~$ sudo insmod /lib/modules/3.2.28-psp21/kernel/drivers/usb/gadget/g_hid.ko 
          insmod: error inserting '/lib/modules/3.2.28-psp21/kernel/drivers/usb/gadget/g_hid.ko': -1 No such device
          
          ubuntu@omap:~$ sudo modprobe g_ether
          ubuntu@omap:~$ lsmod
          Module                  Size  Used by
          g_ether                26693  0 
          snd_soc_tlv320aic3x    32650  0 
          spidev                  4652  0 
          

          Thus: I had it set as: # CONFIG_USB_G_HID is not set

          Regards,

          1. Hi Robert,

            If this is the situation, can I know the insturctions to build with kernel "2.6.32"? - because someone on the net said, this kernel is alright.

            If you can previous install instructions and links to a prebuilt ubuntu with 2.6.32 kernel would be much appreciated.

            Cheers,

            1. Hi Damien,

              2.6.32 was release on Dec 3, 2009, whereas the BeagleBone was announced in Nov of 2011... So unless you back-port it yourself, that is not going to happen. Instead it would be more useful for the community for you to debug the driver with both v3.2.x using any patches/diff from v3.6-rc4 and report it to kernel.org bugzilla...

              Regards,

          2. Hi Robert,

            I am just coming back from other projects and downloaded the 3.2.33-psp26.1 kernel. I realized that CONFIG_USB_G_HID is settable within this kernel now. Does it means that the issue of inserting of module g_hid.ko mentioned above been addressed?

            Cheers,

  8. Hi Robert,

    How can I patch this Kernel to Real-Time. If I patch same Kernel to Real-Time and then use your scripts "build_kernel.sh", support RT is disappear. How I must it properly?

    Or can you tell me how to compile kernel with RT patch on BeagleBone (with am3359)?

    1. Hi Maslak,

      ./build_kernel.sh will always reset the KERNEL directory to a known working (or whatever is in patch.sh at the time of running).. So once you run that script to setup the tree, stop the build process, then apply the Real Time patch set. Once your patch is applied, run ./tools/rebuild.sh as this other script will only build what is in the KERNEL directory...

      Regards,

      1. Thanks for your help.

        Your script work good, but I have some question. Did you run Basic RT on BeagleBone? I'm trying but I keep encounter when I choose 'Basic RT' option in "Kernel features > Preemption model".

        Under is my logs. Do you know what I must check or uncheck?

        log.txt

        1. Hi Maslak,

          I've seen that same error from a another user with the rt42 patchset, seems to be a regression. (I've only boot tested the rt38 patchset on the BeagleBone..).. Can you share your "git diff patches/defconfig" and i'll take a look at this again..

          Regards,

          1. Hi Robert,

            I've tried it with rt38 patch and I have the same situation.

            I upload my "git diff patches/defconfig" under:

            diff.txt

          2. Sorry I've given you not all "git diff patches/defconfig". Under I actualize "diff.txt" and add log from run BeagleBone with RT (which doesn't start) and without RT (which work good). When I build Kernel without RT I change only one option (in Kernel features > Preemption model) and it works.

            diff-a.txt

            log-withoutRT.txt

            log-withRT.txt

            Do you have some idea, what I should change?

            Regards,

            1. Hi Maslak,

              I just rebased the repo on v3.2.29, a few angstrom patches and the rt42 patchset. (the rt42 patchset isn't enabled by default, so make sure you enable it at the bottom of patch.sh) So far I've only tested with this enabled:

              v3.2.29 + rt42 patchset:
              https://raw.github.com/RobertCNelson/linux-dev/am33x-v3.2/patches/rt/config.diff

              v3.2.29 + rt42 patchset + CONFIG_PREEMPT__LL=y
              https://raw.github.com/RobertCNelson/linux-dev/am33x-v3.2/patches/rt/CONFIG_PREEMPT__LL.diff

              In the past, on omap we've had problems with enabling certain levels of preemption.

              So don't currently go beyond CONFIG_PREEMPT__LL=y as,
              v3.2.29 + rt42 patchset + CONFIG_PREEMPT_RT_BASE=y
              Just fails with lots of ext4 errors...

              Regards,

  9. Hi Robert,

    when i switch on FULL RT the kernel will not be build. So, what can i do to get a kernel with full RT support ?

    Is it possible to change your scripts to get an older version of linux with RT patch running ?

    Regards,

    1. Hi Erol,

      Patches welcome, see above about the discussion on the RT patchset, currently anything beyond CONFIG_PREEMPT__LL will not boot with the current v3.2.x fork..

      Regards,

  10. Great guide! Worked as expected.

    Thank you!

  11. Cannot make /dev/fb1 to appear. :(

    config has:

    CONFIG_FB_OMAP2_NUM_FBS=3

    CONFIG_FB_OMAP2_DEBUG_SUPPORT=y

    CONFIG_OMAP2_DSS_DEBUG_SUPPORT=y

    Kernel command line:

    vram=8M omapfb.vram=0:4M,1:4M,2:4M omapfb.debug=y omapfb.test=y omapdss.debug=y

    During booting:

    - my display is recognized.

    - NO omapfb ot omapdss debug prints.

    After boot-up:

    /dev/fb0 device is avaiable and I can even play videos on it using "mplayer2"

    - no /dev/fb1, /dev/fb2 devices.

    How to make /dev/fb1 or /dev/fb1 to appear?

    1. Hi Pavel,

      Well that's expected as the BeagleBone is based on the TI am335x family, which doesn't have the OMAP2 based display hardware, it has the DaVinci display hardware... So "omapfb.*" boot args and kernel configs are not utilized...

      Take a look at the da8xx-fb driver: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=drivers/video/da8xx-fb.c;hb=HEAD

      Regards,

      1. Hi Robert,

        Thank you for the answer.

        I have another question:

        I'm trying to play a video file H.264, 1280x720 on 800x480 display.

        I'm using mplayer and gstreamer to do that.

        With or without scaling the playback performance is quite poor:

        - gstreamer with NN-scaling : 16 FPS

        - mplayer with fast bilinear : 17 FPS

        It looks like the HW video acceleration support is missing.

        My target is to get around 30-40 FPS, wich seems to be quite unreacheable.

        Is there any way to enable HW accelerated decoding or scaling on beaglebone?

        Or it is already enabled?

        1. Hi Pavel,

          To my current knowledge, TI has not released any HW based Video Acceleration for playback on the am335x used on the BeagleBone.. There is SGX acceleration (OpenGL ES,etc): http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/gfxsdk/ but I have not tried using it yet..

          Regards,

  12. Hi Robert,

    I am trying to build a kernel with Xenomai real time support. Compiling the kernel using your procedure works on my virtual machine, however I have a couple of (newbie/simple) questions.

    1) The resulting build is of a 3.6.x kernel, is that now supported for the beaglebone (in the comments you mention that only 3.2.x is currently supported)?

    2) I need to compile a 3.2.23 kernel since that is the latest version supported by Xenomai. I am unsure exactly how to do that since the build_kernel.sh script seems to update to the latest version automatically. How can I check out that particular version via git and how to prevent the script from updating it?

    3) Am I correct in thinking that after the initial build_kernel run, I need to apply the Xenomai patch to the kernel source files located in /linux-dev/KERNEL and then run the rebuild.sh script?

    Thanks!

    1. Hi Stefan,

      1. I'm not planning on replacing v3.2.x with v3.6.x at this point in time, but there is really no future for v3.2.x in mainline as much of the code that we have written for it will get thrown out, but v3.2.x will get replaced eventually by v3.6+i.x. (it'll probally be v3.7: as we now have a capebus https://github.com/beagleboard/kernel/commit/044bde86ed265c387e4757fbb82b49ccb20dd1ac)
      2. Every release is tagged, so you can easily checkout one of the v3.2.23 tags, but I'd recommend you actually port Xenomai to v3.2.31 as the diff v3.2.23..v3.2.31 is just driver fixes...
      3. Correct, use ./build_kernel.sh to setup the tree, apply your work in progress patch, and rebuild with ./tools/rebuild.sh till you get yoru patch-set working right..

      Regards,

      1. Hi Robert,

        First off -- thanks for the quick reply!

        I've checked out v3.2.21 by doing "git checkout v3.2.21", as well as commented out the application of the 3.2.30 patches in the patch.sh file. However, I still end up with the following error while trying to patch Xenomai in:

        prepare-kerne.sh: Unable to patch kernel 3.2.29 with ipipe-core-3.2.21-arm-1.patch

        This should mean that I am trying to patch the Xenomai patch against a v3.2.29 kernel. Where is this upgrade from the checked out 3.2.21 happening and how can I prevent it?

        EDIT: After the above error, I went in the version.sh file and changed KERNEL_REL to 3.2.21 and BUILD to psp16, which I thought should bring the kernel to the required version to be compatible with the Xenomai patch. However, now when I run ./build_kernel.sh I get an error out of the git pull $GIT_OPTS git://github.com/RobertCNelson/linux.git ti_am33x_v3.2-staging_7 :

        Automatic merge failed; fix conflicts and then commit the result.

        Am I right in thinking this is happening because that particular patch is incompatible with that kernel? If so, is there an older version of that patch that I can use?

        EDIT2: I disabled the above git pull command and all the patches after the libertas ones (since they were failing due to the ti_am33_x not going through) and the Xenomai patch goes through. However, I get an error during compilation for drivers/built-in.o

        So this makes me think that the ti_am33_x is necessary (which I would think it is anyway). I'll try to use an earlier version, but I've tried a couple with no luck.

        Thanks again for your help!

        Kind Regards,

        Stefan

        1. Hi Stefan

          I'm really not sure why everyone goes with the perceived easy way "easily checkout one of the v3.2.23 tags" when in reality, forward porting the patchset is actually easier. As there are more things to take in consideration then just the patchset your trying to include...

          First, the kernel we are using for the Beaglebone is massive fork based on v3.2.0, there is simply no way (we tried) to easily merge the arago v3.2-staging and the mainline "3.2.x" stable branch... So DON'T change KERNEL_REL, and don't disable the ti_am33_x pull (unless you don't care about booting the Bone..)..

          So now for the good news, I pushed a patch with the ipipe-core-3.2.21-arm-1.patch re-diffed onto the BeagleBone 3.2-psp24 release commit (3.2.31)

          https://github.com/RobertCNelson/linux-dev/commit/f6ffc6e46dee99ca875318b2c7a8d1a548519a3b

          So if you enable the patchset in patch.sh and copy the defconfig over from "./patches/xenomai/defconfig" to "./patches/defconfig" it will build.. (had to disable pwm, otherwise a custom defconfig is not needed)

          But, it fails to boot. So since I have zero personal interest in xenomai, i'm leaving this support completely up to you. (wink) Once you can get it too boot with a simple patch/config change let me know...

          Regards,

          1. Hi Robert,

            Massive thank you for taking the time to look into this. I'll try to get that going on Monday.

            However, I am wondering if this is going to be the easier way -- I am guessing there is a reason why the Xenomai folks are not supporting anything above v3.2.21. Are you sure that is not the reason why it is not booting? Would it not be easier for me (or anyone else who wants to support Xenomai) to simply checkout your work from its state in July (which I think is roundabout when you were supporting v3.2.21), and build it like that (which is what I think I will try if I fail at making the patch you included work).

            Anyway, thanks once again for helping out, will update you on my progress.

            Kind Regards,

            1. Hi Stefan,

              I think v3.2 is just maintenance for them at this point, as they are also supporting v3.4/v3.5:
              http://git.denx.de/?p=ipipe-2.6.git;a=summary

              Maybe... I just don't remember how well that older kernel supported the Bone, we are always moving forward in kernel versions for fixes... So who knows. the other option, at some point ipipe will move to v3.6/v3.7 and right now the Bone will boot off those and most of the massive kernel fork is now mainline...

              Regards,

              1. Hi Robert,

                After some initial failures and delays, I am finally starting serious work on this.

                I've just verified the ability of my set up to compile the vanilla kernel and run it on the bone. I am almost done compiling the Xenomai capable one, and will test shortly. I expect to have a few questions related to setting up debugging for the kernel (passing some flags for the compilation process and possibly an inline one during the boot process) -- thought I should let you know. 

                I am expecting the following error:

                Kernel stops after "Uncompressing Linux… done, booting the kernel."

                This means that the kernel crashes before the console is enabled. You should enable the CONFIG_EARLY_PRINTK option. For some architectures (blackfin, x86, arm), enabling this option also requires passing the earlyprintk parameter on the kernel command line. See Documentation/kernel-parameters.txt for possible values.

                For the ARM architecture, you have to enable CONFIG_DEBUG_KERNEL and CONFIG_DEBUG_LL in order to be able to enable CONFIG_EARLY_PRINTK.

                How does one go about setting up these flags -- edit the config file directly?

                Kind Regards,

                1. Hi Stefan,

                  Please be more specific, when you reference "vanilla kernel" what is your actual kernel version base?

                  That is correct, with the Xenomai patch I pushed to the v3.2.x branch in the repo a few days ago, it will lock up after "Uncompressing Linux... done, booting the kernel."

                  To use earlyprintk: first add "debug earlyprintk" to your bootargs.

                  For the kernel config, load up menuconfig,

                  Kernel hacking  --->
                  [*] Kernel low-level debugging functions (read help!)
                  [*]   Early printk
                  

                  Of course, this directions will not work if your using v3.6/v3.7 with device tree.

                  Regards,

                  1. Robert,

                    When I say vanilla kernel -- I mean the kernel that is compiled when using your directions above i.e. v3.2.31-psp24. I guess it's very far from the commonly used definition of vanilla.

                    When you say add "debug earlyprintk" to your bootargs do you mean:

                    mmcargs=setenv bootargs console=${console} root=${mmcroot} rootfstype=${mmcrootfstype} debug earlyprintk

                    Kind Regards,

                    Stefan

                    1. Hi Stefan,

                      Okay, then earlyprintk should work with v3.2.x, other then reading the theory on making it work with v3.6/v3.7 device tree's I haven't been personally tried it yet. (it's a lot different)

                      Correct, that's the bootargs variable...

                      Regards,

                      1. Thanks! I am compiling with the correct config now (decided against testing the non-early debug enabled kernel), should be done in a couple of hrs (kinda slow on my virtual machine).

                        UPDATE: Compiled and tested the kernel -- it seems the issue is with the way the interrupt clock frequency is handled, and some flow controller (or smth of the sort) within the Xenomai codebase. It seems it's something the guys over on the Xenomai mailing list have tackled before. I am waiting for them to respond with a concrete patch which I hope will not be too long from now. 

                        Fingers crossed, I should be able to provide you with a new config file and an updated patch that should work!

                        1. Hi Stefan and Robert,

                          first of all, thanks a lot @Robert for your work!

                          @Stefan: have you manged to achieve your purpose? I am trying to to compile a Xenomai enabled kernel.

                          Regards

                          Davide

                          1. Hi Davide,

                            I have a running Xenomai kernel. However, I went a slightly different way about it.

                            I merged the Arago repository with mainline kernel v3.2.21, and then applied the Xenomai patch.

                            After fixing some timer issues and some interrupt handlers in the codebase, it's working well so far.

                        2. Hallo Stefan,

                          wonder how the Xenomai kernel is turning out - I'd be very interested as wel

                          btw I have Xenomai 2.6.1/3.2.21 running on a raspberry following these instructions:

                          http://diy.powet.eu/2012/07/25/raspberry-pi-xenomai/

                          they had to massage timers into work too, here's the broadcom-specific patch - maybe it's some inspiration:

                          http://powet.eu/raspberrypi/rpi-linux-3.2.21-xenomai-2.6.1.patch

                          - Michael

                          1. Hi Michael,

                            The idea is pretty much the same. If you see my reply to Davide above, the way to get it to run is very similar.

                            I will try to find time this week to go back to this kernel fork and try to get it to run, so that people have an easy way to run Xenomai on the Bone. It took me the better part of 1 week to get the kernel to run on mine, as I had to piece information from many different sources.

  13. Did anybody try to get the RT_PREEMPT patches working on the beaglebone kernel?

    looking at http://www.kernel.org/pub/linux/kernel/projects/rt/3.6/ I think the patch for v3.6.7 is the closest match

    now in  https://github.com/RobertCNelson/linux-dev/commits/am33x-v3.6&nbsp; we have am33x-v3.6 which I think stands at  base v3.6.2

    how should I go about it - take am33x-v3.6, apply v3.6.2...v3.6.7 and then the RT_PREEMPT 3.6.7 patch?

    thanks

    - Michael

    1. Hi Michael,

      I've updated the am33x-v3.6 branch to v3.6.8 and added the real time patchset:

      https://github.com/RobertCNelson/linux-dev/commit/e36c4596350c17baf38501ecba39afc08aa2fbac

      It's disabled by default, so just enable it via uncommenting out "#rt_patchset" in patch.sh.

      It's untested.

      Regards,

      1. Hi Robert,

        thanks - having that in place is really valuable

        Background: I'm adapting the RT parts of the linuxcnc.org platform for ARM processors and non-RTAI based RT kernels; the major options being RT_PREEMPT and Xenomai.

        re Xenomai: there are now several reports of a Xenomai beaglebone working and I have two pointers to (different) patchsets. I note there was an attempt at bringing the ipipe and Xenomai patches in which was backed out. How do you feel about a second attempt after I get it to work reproducibly?

        A second option I was suggested is to post and document Xenomai pre and post patches on the xenomai site, which obviously must refer to a beaglebone kernel commit as a starting point.

        -Michael

        1. Hi Michael,

          I have no problems un-backing out the v3.2.x Xenomai/RealTime patches. However I do have to ask as the v3.2.x branch is pretty much abandoned at this point by the BeagleBoard.org community.

          Any chance do you guys have a v3.7-rcX based patchset?

          As the community is rapidly moving to a v3.7.x based kernel. Our unified tree is here: https://github.com/beagleboard/kernel/tree/3.7

          You can see an early version of this unified tree in my am33x-v3.7 branch as I'm spending some time re-testing a lot of the BeagleBone Capes.

          Regards,

      2. Dear Robert,

        Untill now I was using your 3.2.30-rt45-psp23 kernel version on BeagleBone. As I wanted to move to newer kernel version, I successfully compiled the branch am33x-v3.6 from 

        https://github.com/RobertCNelson/linux-dev

        and also installed it on the Bone.

        But the board is not booting at all. I don't' see any heartbeat of user LEDs. What could be the problem ?

        1. Hi Kaushik,

          Did you follow the v3.6.x directions when installing the kernel from the am33x-v3.6 branch? As going forward we are not using board files, but instead using device trees http://omappedia.org/wiki/Device_Tree

          However if you did follow the v3.6.x directions, it should have booted, can you please log your full serial boot log and copy to http://pastebin.com and I'll take a look at it..

          Regards,

          1. Hello Robert,

            Thanks for your quick reply.

            I didn't find any difference in the way am33x-v3.2 or v3.6 should be compiled. Correct me if I am wrong. For v3.6, I followed the same steps that I used for building v3.2 kernel. Only additional thing I did now is to enable the Ftrace functionality in kernel configuration. Please find attached serial boot log here. As you can see from the output, kernel doesn't start. I am bit stuck now as I wanted to test the RT patch with beaglebone 3.6 kernel

            boot-log-beaglebone-v3.6.x.txt

            Also attached the only modified files which are patch.sh and system.sh

            system.sh

            patch.sh 

            Let me know if you have any suggestions.

            Regards

            Kaushik

            1. Hi Kaushik,

              With v3.6.x and greater this is expected, please reread the http://eewiki.net/display/linuxonarm/BeagleBone?replyToComment=11665670&#BeagleBone-uEnv.txtv3.6.xdevicetreebasedbootscript section.

              Specifically this part:

              xyz_mmcboot=run mmc_load_image; run mmc_load_dtb; echo Booting from mmc ...
              loaduimage=run xyz_mmcboot; run mmcargs; bootz 0x80300000 - 0x815f0000
              

              Where we are loading the device tree binary "am335x-bone.dtb"...

              BTW: you should also really upgrade your version of u-boot, there's known issues with loading device tree binaries with that version..

              Regards,

              1. I am running the Angstrom flavour on BeagleBone. Are these above mentioned steps applicable for Angstrom also ?

                1. Hi Kaushik,

                  It actually doesn't matter what Linux based OS your running on the Bone. If you don't edit your "uEnv.txt" to properly boot the *.dtb file as shown in this wiki, it's just not going to boot with my kernel build scripts...

                  BTW, i just pushed an update of the rt patchset:
                  https://github.com/RobertCNelson/linux-dev/commit/4ca144074cd260819e9eff6d2f43181cde39f331

                  Regards,

                  1. Hello Robert,

                    I have edited uEnv.txt and also updated the u-boot.  But now I get the following message continuously after booting and the shell prompt doesn't come up

                    musb_bus_suspend 2308: trying to suspend as a_wait_bcon while active

                    See the attached boot log

                    file.txt

                    1. Hi Kaushik,

                      For reference, v3.6.x will never be production ready, as all developers are working on v3.8-rc...

                      But it should still boot, as it does here..

                      Looking at your bootlog, are you using an external usb drive? If not, your boot args are wrong..

                      [    0.000000] Kernel command line: console=ttyO0,115200n8 root=/dev/sdb2 ro rootfstype=ext4 rootwait fixrtc
                      
                      [    2.765466] Waitindevice /dev/sdb2...
                      [    2.780663] mmc0: host does not support reading read-only switch. assuming write-enable.
                      [    2.794164] mmc0: new high speed SDHC card at address aaaa
                      [    2.800644] mmcblk0: mmc0:aaaa SU04G 3.69 GiB 
                      [    2.810899]  mmcblk0: p1 p2
                      

                      Change:

                      root=/dev/sdb2 -> root=/dev/mmcblk0p2 in uEnv.txt
                      

                      Regards,

                      1. For installing the image on SD card, I am using an external USB card reader. But after installinng the image, I place it back into the micro SD slot of BeagleBone. My question is how BeagleBone will see this SD card while booting - whether as /dev/sdx or as /dev/mmcblk0p2. I tried changing to /dev/mmcblk0p2 in uEnv.txt. But then, I don't see any output in my serial terminal which is /dev/ttyUSB1.

                        Also I have one more question. The console is metioned as /dev/ttyO0 in uEnv.txt, but I am able to see boot log in /dev/ttyUSB1 ? How is that possible.

                        Let me know if I am troubling you too much with questions. I really need to get this RT patch working as I want to see how the real time features work on BeagleBone

                        1. Hi Kaushik,

                          Your confusing the device names used by the drivers used on two different systems.

                          On the BeagleBone, the device name /dev/mmcblk is used by the omap/mmc kernel driver when accessing the mmc card, (/dev/mmcblkp2) in this case..

                          On the BeagleBone, the device name /dev/ttyO is used by the omap/serial kernel driver when accessing the serial port, (/dev/ttyO0) in this case..

                          Regards,

                          1. Hello Robert,

                            Thanks for the reply. I have changed from root=/dev/sdb2 -> root=/dev/mmcblk0p2 in uEnv.txt.

                            But still no success and I still get the same message.

                            musb_bus_suspend 2308: trying to suspend as a_wait_bcon while active

                            I don't know what is causing this problem.

                            Are you going to provide RT patch support in v3.8. I will wait till then. At present, I am stuck at v3.2 RT patch through which only low latency desktop preemption model can be enabled.

                            1. Hi Kaushik,

                              musb_bus_suspend 2308: trying to suspend as a_wait_bcon while active

                              Is a known issue with the am335-v3.6 branch, patches welcome...

                              Back to the console problem, Angstrom is not supported here, if you were to follow the wiki directions as is, this would be the result:

                              beaglebone-v2013.01-v3.6.11-bone0.4.txt

                              Regards,

                              1. Thanks. Now I have put the kernel update on hold. 

                                I tried to execute cyclictest for latency check on 3.2 RT kernel. But it says "unable to change scheduling policy. Run as super user"

                                But even if I run as super user cyclictest doesn't run.

                                Have you ever tried Cyclictest on the 3.2 kernel for BeagleBone

    2. Should anyone succeed in building a 3.6 real-time system who is interested in using /dev/spidev (userspace spi driver) I'd appreciate if you'd download, compile, and run the test program for the Pandaboard I've posted here:

      https://groups.google.com/forum/?fromgroups=#!topic/pandaboard/00wxMmGw1AE

      and report the results.

      On a 3.4.7-rt Pandaboard system I'm finding spidev breaks realtime performance with latencies 3-15 mS when used in a 1 mS servo loop to write a waveform to an spi D/A chip (only 192 bits per sample need be shifed out the spi port which should take maybe 8 uS).  Basically spidev on Pandaboard seems unusable for anything that requires less than about 25 mS servo loop.  If anything, the RT_PREEMPT patches made things a little worse. :(

      The test program generates a 500Hz square wave with essentially perfect performance when toggling a GPIO bit every 1 mS, but not when doing the ioctrl() to wirte the spidev 192 bit message :(

      Of course you'll have to edit the spidev name and gpio bit name strings to match the Beaglebone.

      The program runs without any real-time patches and the gpio square wave is pretty decent with about 200 uS peak "jitter" on the pandaboard.  The nature of the spidev means if you have the spidev.ko module compiled and installed you can run the program and shift out the bits without any spi hardware attached.  You can 'scope the CS CLK and MOSI pins to see it in action.

      I'll be glad to help with enabling the spidev on the Bonebone if you've not done it before.

      I'll be watching this thread for any success in running an RT_PREEMPT kernel on the Beaglebone so I can try it myself eventually.

      --wally.

  14. Hi Robert,

    apparently you are maintaining different kernels: 3.2, 3.6, 3.7 and also 3.8, since you said that all the developers are moving there.

    Just curious: do you have any priorities in terms of cape support ? 

    We know that the most complete is the 3.2, but which one is going to be, in you opinion the next kernel which will have a decent cape support?

    Davide

    1. Hi Davide,

      The priorities of the beagleboard.org project at the moment is to replace v3.2 with v3.8, including support for all capes...

      The main tree is here: https://github.com/beagleboard/kernel/tree/3.8

      Last I looked at it, we also need to build a newer/git version of the device-tree-compiler as the new cape support requires some new device tree features (overlays).

      Regards,

  15. Hi Robert,

    apparently I had a problem with u-boot but it was my fault. never mind

    Davide

  16. I have compiled a 3.2.33 kernel and u-boot and installed the kernel plus modules on a armel-rootfs-201301141020.tar SD card, but the boot hangs after mounting the rootfs partition.

    I have used a ext3 file system, but the result is identical with ext4 (the default).

    I have also tried to use the other two rootfs but with no success, they also hang during boot.

    My Beaglebone has a Breadboard attached and it boots fine from the same SD card if I download the standard images from www angstrom distribution org.

    [   10.144256] EXT3-fs (mmcblk0p2): mounted filesystem with ordered data mode
    [   10.151519] VFS: Mounted root (ext3 filesystem) readonly on device 179:2.
    [   10.162506] devtmpfs: mounted
    [   10.166168] Freeing init memory: 252K
    [info] Using makefile-style concurrent boot in runlevel S.
    [  240.332611] INFO: task startpar:59 blocked for more than 120 seconds.
    [  240.339385] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [  240.347656] startpar        D c04fd2a0     0    59     49 0x00000000
    [  240.354370] Backtrace:
    
    1. Hi Adam,

      How are you powering the BeagleBone, based on your error message, it looks like similar errors when powering via the otg usb plug? Please retry with a 5Volt DC adapter...

      Regards,

      1. Hi Robert,

        I have tried booting the http://www.angstrom-distribution.org images and they work fine without the 5 VDC adapter.

        Attaching a 5VDC adapter doesn't solve the problem in this instance.

        Is there a flag in the defconfig file I can switch on so I get better details in the error messages?

        Regards,

        1. Hi Adam,

          Nope, the error is very common for users powering their BeagleBone's via the usb-otg plug. Most users reported back that switching to 5 Vdc fixed the issue.. The other option is to try a different micro sd card...

          Btw, 3.2.x is pretty much considered legacy at this point, care to retest with v3.8.x? I'm about to push a few patches for usb support that i'm currently testing, so that's disabled right now in the repo..

          Regards,

          1. Well, I have only used 3.2.3N builds because that's what Beaglebone is shipped with per default and a colleague used a 3.2.NN kernel to get the D_CAN up and running. That is one of the purposes of this board. Basically I need:

            1) D_CAN up and running
            2) plus a functional opkg package installer in the rootfs so I can easily install things without having to cross-compile them. I cheat a bit by downloading libraries I need for the application to Beaglebone and compiling them natively there instead of cross-compiling them on my workstation.

            Oh, I need USB support for the application so I'm sorry, I can't use your 3.8.x build if it doesn't have USB support.

            I will try to reformat the SD card again with gparted and see what happens and make sure to use the 5VDC at all times in the future.

            / Adam

  17. Hi -

    I'm trying to get my beaglebone patched with xenomai - however I seem to have some issues with the versions that match.

    Any ideas?

    Just an update - I've patched the linux 3.2.21 kernel with xenomai. See the following link for (hopefully) thorough details:

    http://yapatel.org/wiki/index.php/Installing_Xenomai_on_a_beaglebone

    1. Hi Yogi,

      I produced a Xenomai kernel which we use for LinuxCNC development, you might try from here: http://git.mah.priv.at/gitweb/linuxcnc-kernel.git/shortlog/refs/heads/xenomai-3.2.21-bb-roosen-v3.2-staging-merged

      notice there's an open fatal error with that kernel which is currently discussed on the xenomai list, it looks I need to upgrade this to xenomai master from 2.6.1; other than that it should get you started.

      You might also want to check http://wiki.linuxcnc.org/cgi-bin/wiki.pl?BeagleboneDevsetup

      - Michael

      1. Hi,

        I noticed that there are other heads beaglebone-3.2.21-xenomai-2.6.2 and beaglebone-3.2.21-2.6.2-kappertz.

        Don't you suggest to use them? Will compiled images be available soon?

        Davide

        1. Davide,

          yes there are.

          The heads beaglebone-3.2.21-xenomai-2.6.2 is an upgrade of the http://git.mah.priv.at/gitweb/linuxcnc-kernel.git/shortlog/refs/heads/xenomai-3.2.21-bb-roosen-v3.2-staging-merged to use Xenomai 2.6.2. The linux-*z files here: http://static.mah.priv.at/public/beaglebone/ are built from that. If you are using the ubuntu rootfs image mentioned above, these tar files should be extracted into it to get the upgraded kernel. The original one has issues - it doesnt run the Xenomai regression tests properly; this one does.

          The  beaglebone-3.2.21-2.6.2-kappertz head is untried of yet, I got a config from Stephan and give it a try shortly.

          There is some major confusion as to what actually constitutes a sensible base kernel version to build Xenomai upon: you might want to read the emc-developers list and search for subjects like 'xenomai' and 'beaglebone'.

          - Michael

          1. meanwhile I've tried the Stephan Kappertz branch, it builds and runs: http://git.mah.priv.at/gitweb/linuxcnc-kernel.git/shortlog/refs/heads/beaglebone-3.2.21-2.6.2-kappertz

            I build binaries using my config from the other branch as a base

            binaries: http://static.mah.priv.at/public/beaglebone/linux-3.2.21-xeno-kappertz+.tar.gz

            the boot dmesg log: http://static.mah.priv.at/public/beaglebone/linux-3.2.21-xeno-kappertz+.dmesg.log

            not tested extensively, but NFS boots on abovementioned ubuntu rootfs image

            - Michael

      2. Does this linuxcnc system support /dev/spidev driver?

        I'm having problems with /dev/spidev breaking real-time performance trying to run a 1 mS servo loop.

        Attached is a simple test program to show the problem, real-time is essentially perfect writing to a GPIO pin, but breaks badly when writing to spidev instead. All the extra latency is in the spidev call.

        This test code is written for the PandaboardES so the GPIO and spidev names will need to be adjusted for the Beaglebone.

        swave_spidev.c

  18. Hi Robert,

    I need a couple of helps on the u-boot version 2013.0.0.1.

    1) I would like to enable fatwrite, so I defined CONFIG_FAT_WRITE into file am335x_emv.h and rebuild u-boot. Then I added:

    mmc_write_file=fatwrite mmc 0:1 0x80300000 fatwr 0x400
    xyz_mmcboot=run mmc_load_image; run mmc_write_file; echo Booting from mmc ...
    loaduimage=run xyz_mmcboot; run extra_args; run mmcargs; bootz 0x80300000
    

    to the uEnv.txt file and reboot the machine, I was expecting a file fatwr would be created at the time of bootup, but it doesn't. Is there anything wrong?

    2) I have a DVI-D expansion board with my beaglebone. How can I enable u-boot messages being displayed on the monitor that attached to the DVI expansion board?

    I had removed definition CONFIG_SYS_CONSOLE_INFO_QUIET from am335x_evm.h, but there is still nothing come up until Linux was up.

    Cheers,

    1. Hi Damien,

      Based on the u-boot docs, the changes you did to "uEnv.txt" should have written a block of data to fatwr from address 0x80300000 0x400 bytes long..

      fatwrite [interface] [dev:[part]] [addr] [filename] [bytes]
      

      Your best bet is to ask on the u-boot mailing list http://lists.denx.de/mailman/listinfo/u-boot and get some feedback from the fatwrite developers.

      Well, you'd have to interface with the da8xx-fb driver and finish porting it to am335x devices first.

      http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/video/da8xx-fb.c;hb=HEAD

      Regards,

      1. Thanks Robert for the message.

        Regarding the fatwrite issue, after investigation, I believe the problem can be fixed at function "set_cluster" within file fat_write.c under directory /fs/fat (patch file is
        given at below).

        The reason of the issue is: If function "set_cluster" was called with size equals ZERO, then the function would only issue the write instruction to MMC driver without data, this caused the MMC to be in a wait state for data and inhibiting further commands. As all subsequent commands to MMC would first check whether MMC is in inhibit state before actual command being issued, this check would always fail and time out occur.

        diff \-cr u-boot-original/u-boot/fs/fat/fat_write.c
        u-boot-test/u-boot/fs/fat/fat_write.c
        \**\* u-boot-original/u-boot/fs/fat/fat_write.c    2013-02-07 14:47:33.314732999 \+1100
        \--\- u-boot-test/u-boot/fs/fat/fat_write.c    2013-02-28 15:36:24.551861920 \+1100
        \**************\*
        \**\* 562,596 \***\*
          {
              int idx = 0;
              __u32 startsect;
        \!
        \!     if (clustnum > 0)
        \!         startsect = mydata->data_begin +
        \!                 clustnum * mydata->clust_size;
        \!     else
        \!         startsect = mydata->rootdir_sect;
        \!
        \!     debug("clustnum: %d, startsect: %d\n", clustnum, startsect);
        \!
        \!     if (disk_write(startsect, size / mydata->sect_size, buffer) < 0) {
        \!         debug("Error writing data\n");
        \!         return \-1;
        \!     }
        \!
        \!     if (size % mydata->sect_size) {
        \!         __u8 tmpbuf\[mydata->sect_size\];
        \!
        \!         idx = size / mydata->sect_size;
        \!         buffer \+= idx * mydata->sect_size;
        \!         memcpy(tmpbuf, buffer, size % mydata->sect_size);
        \!
        \!         if (disk_write(startsect + idx, 1, tmpbuf) < 0) {
        \!             debug("Error writing data\n");
        \!             return \-1;
        \!         }
        \!
        \!         return 0;
        \!     }
        \!
              return 0;
          }
         
        \--\- 562,595 \---\-
          {
              int idx = 0;
              __u32 startsect;
        \!     if(size) //if there are data to be set
        \!     {
        \!         if (clustnum > 0)
        \!             startsect = mydata->data_begin +
        \!                     clustnum * mydata->clust_size;
        \!         else
        \!             startsect = mydata->rootdir_sect;
        \!
        \!         debug("clustnum: %d, startsect: %d\n", clustnum, startsect);
        \!
        \!         if (disk_write(startsect, size / mydata->sect_size, buffer) < 0) {
        \!             debug("Error writing data\n");
        \!             return \-1;
        \!         }
        \!
        \!         if (size % mydata->sect_size) {
        \!             \__u8 tmpbuf\[mydata->sect_size\];
        \!
        \!             idx = size / mydata->sect_size;
        \!             buffer \+= idx * mydata->sect_size;
        \!             memcpy(tmpbuf, buffer, size % mydata->sect_size);
        \!
        \!             if (disk_write(startsect + idx, 1, tmpbuf) < 0) {
        \!                 debug("Error writing data\n");
        \!                 return \-1;
        \!             }
        \!         }
        \!     }//end if data to be set
              return 0;
          }
        

        edit: rcn: it's more readable with code blocks...

        1. YUCK!! Never ever use "diff -cr" use "git diff" format.

          Please post u-boot patches to:
          http://lists.denx.de/mailman/listinfo/u-boot

          They will get lost and ignored in comment sections.

          Regards,

  19. Hello Robert,

    I am facing issues in booting up the linux kernel v3.8 on my beaglebone setup (Boardname: A335BONE, Board Rev: A6).

    I followed the steps mentioned in this link to download and build the uboot, kernel, ubuntu RFS. I created uEnv.txt and copied the uEnv.txt v3.6.x device tree based bootscript into it.

    When i power up the board, i get the following messages. I see my zImage and am335x-bone.dtb file placed inside /boot folder of the sd card.

    MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
    Warning - readenv() failed, using default environment
    
    musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
    musb-hdrc: MHDRC RTL version 2.0
    musb-hdrc: setup fifo_mode 4
    musb-hdrc: 28/31 max ep, 16384/16384 memory
    USB Peripheral mode controller at 47401000 using PIO, IRQ 0          ne.dtb; fi; if test $board_name
    musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
    musb-hdrc: MHDRC RTL version 2.0
    musb-hdrc: setup fifo_mode 4
    musb-hdrc: 28/31 max ep, 16384/16384 memory
    USB Host mode controller at 47401800 using PIO, IRQ 0
    Net:   cpsw, usb_ether
    Hit any key to stop autoboot:  0
    mmc0 is current device
    SD/MMC found on device 0
    reading uEnv.txt
    841 bytes read in 4 ms (205.1 KiB/s)
    Loaded environment from uEnv.txt
    Importing environment from mmc ...
    reading zImage
     **Unable to read file zImage
    reading /dtbs/am335x-bone.dtb
     **Unable to read file /dtbs/am335x-bone.dtb
    Booting from mmc ...
    Bad Linux ARM zImage magic\!
    
    1. Hi Rajkumar,

      Please reread http://eewiki.net/display/linuxonarm/BeagleBone#BeagleBone-CopyingKernelandrelatedfiles the boot files (zImage/dtb's) need to be installed in the boot partition /media/boot/, not the boot directory on the rootfs partition /media/rootfs/boot/..

      sudo mkdir -p /media/boot/
      sudo mount /dev/sdX1 /media/boot/
      sudo cp -v ./linux-dev/deploy/X.*zImage /media/boot/zImage
      
      sudo mkdir -p /media/boot/dtbs/
      sudo tar xfv ./linux-dev/deploy/X-dtbs.tar.gz -C /media/boot/dtbs/
      
      sync
      sudo umount /media/boot
      

      Where X= the current kernel version...

      Regards,

      1. Hello Robert,

        Thanks for your quick reply.

        I meant to say in my last post that i had actually placed the zImage under /media/boot/zImage and dtb file under /media/boot/dtbs/ path not /boot folder .

        Sorry for the typo. 

        Regards,

        T. Rajkumar

        1. Hi Rajkumar,

          Okay, then from u-boot, can you double check the files are present? (fatls mmc 0:1):

          U-Boot 2013.01.01-00006-gf1c06e5 (Feb 04 2013 - 10:59:41)
          
          U-Boot# fatls mmc 0:1
                      backup/
                      dtbs/
              82625   mlo 
             329672   u-boot.img 
            3090312   zimage 
            2307128   initrd.img 
                889   uenv.txt 
                320   soc.sh 
                      tools/
          
          6 file(s), 3 dir(s)
          
          U-Boot# 
          

          Regards,

          1. Hello Robert,

            I have the following files/folders only.

            1) dtbs/

            2) MLO

            3) u-boot.img

            4) uEnv.txt

            5) zImage

            It looks i miss initrd.img and soc.sh files and backup and tools directory. Where to find those files/folders?

            Regards,

            T. Rajkumar

            1. Those are not required for the directions on this wiki. They are just installed from the image I quickly flashed to my BeagleBone to quickly show the "fatls mmc 0:1" usage. BTW, what file sizes where shown when you ran the command.. (I was kinda of hoping you would have shown the same type printout as I had done..) If they are in the ballpark, that only leaves an error in "uEnv.txt" (please pastebin.com your version of that file) or an error in your compilation process of u-boot. As I already re-verified this page again on "Feb 18"...

              Edit: Your uEnv.txt looks fine... I'd really just try reformatting the microSD card and following the directions from scratch, something got corrupted.

              Regards,

              1. Hello Robert,

                U-Boot 2013.01.01-dirty (Feb27 2013 -16:12:29)
                
                U-Boot# fatls mmc 0:1
                            dtbs/
                    83993   mlo 
                   330208   u-boot.img 
                  3091400   zimage 
                      840   uenv.txt 
                 
                4 file(s), 1 dir(s)
                U-Boot#
                

                I didn't get any compilation errors while building u-boot.
                Regards,
                T.Rajkumar

                1. Hi Rajkumar,

                  Everything looks fine. I'll retry it again tonight.

                  Regards,

                  1. Hello Robert,

                    Thanks. Let me know after you retried.

                    I reformatted my SD card and retried again from scratch. This time i used setup_sdcard.sh found ubuntu-12-10.minimal-armhf-2013-02-17.tar.xz file. 

                    The command i used to run the setup_sdcard.sh is (sudo ./setup_sdcard.sh --mmc /dev/sdc --uboot bone).

                    I ended up with the same status as before. 

                    But when i check the uEnv.txt file inside my sd card, the contents looks different than what you specified under section uEnv.txt v3.6.x device tree based bootscript

                    which one i need to take? either the auto generated one from setup_sdcard.sh or the one given at section uEnv.txt v3.6.x device tree based bootscript.

                    Regards,

                    T. Rajkumar

                    1. Hi Rajkumar,

                      Odd, that image fails too? What OS are you running on your HOST system, virtual/arch/etc??? (Debian Wheezy amd64 here) Do you have a second system available? Of course with a second sd/mmc usb writer...

                      Well yes, it should look different as, (--uboot bone) actually corresponds with the v3.2.x directions on this wiki.

                      There's a second target included in that image (--uboot bone_dtb) that matches up with the v3.6.x based instructions.

                      BTW: Just so we do not go crazy, can you quickly retest this image using the same host system/sd/etc..

                      http://circuitco.com/support/index.php?title=BeagleBone#Image_Files

                      Update: The directions still work as. (made a few quick updates on the kernel version listed) Here's my bootlog:
                      bone_march1.log

                      Regards,

                      1. Hello Robert,

                        I had tried the http://circuitco.com/support/index.php?title=BeagleBone#Image_Files image. It works fine in my setup.

                        Then i went back i tried with bone_dtb (--ubot boot_dtb) in the setup_sdcard.sh. I still end up with the same issue.

                        Regarding the HOST system, i use Ubuntu 11.04 system.

                        Regards,

                        T. Rajkumar

                        1. Hi Rajkumar,

                          Thanks for testing the CircuitCo image, they use dd, so it's a good comparison and confirms your usb/sd/mmc adapter works correctly and your BeagleBone is operating correctly. So that leaves the userland tools we use to copy the files to the SD card.

                          Unfortunately, Ubuntu 11.04 (Natty) went eol (28 October 2012) please retest with either Ubuntu 12.04 LTS or Debian Wheezy.

                          Regards,

                          1. Dear Robert,

                            Is there any plan to support full RT(Real-Time) kernel for BeagleBone ? Currenly maximum CONFIG_PREEMPT__LL=y is supported

                            Regards

                            Kaushik

                            1. Hi Kaushik,

                              I am not one of the Real-Timer Kernel developers so I can't answer this question for them. Just note, the v3.2.x tree has been abandoned by me and all work is going on v3.8.x/v3.9-rcX...

                              It's not that a maximum of PREEMPT_LL is supported, it's just that a maximum of that actually works

                              Regards,

                            2. Hi, Kaushik -

                              I've patched the linux 3.2.21 kernel with xenomai. See the following link for (hopefully) thorough details:

                              http://yapatel.org/wiki/index.php/Installing_Xenomai_on_a_beaglebone

                              Email me if you run into any issues.

                          2. Hello Robert,

                            Just a dumb question. Are you referring to RFS or the host machine

                            where i run the serial console to get debug log. If it is RFS, i use 

                            ubuntu 12.10 (Quantal) given in this link.

                            Regards,

                            T. Rajkumar

                            1. Hi Rajkumar,

                              Regarding the HOST system, i use Ubuntu 11.04 system.

                              Unfortunately, Ubuntu 11.04 (Natty) went eol (28 October 2012) please retest with either Ubuntu 12.04 LTS or Debian Wheezy running on your HOST machine.

                              Regards,

                          3. Hello Robert,

                            I am trying to integrate drivers (from v3.2) for the camera cape into the 3.8 kernel build.

                            I see the driver folder is changed. i dont see /drivers/media/video folder. 

                            Instead i heard capemgr is used to scan the available cape and load firmware, 

                            instead of modifying the board file.

                            Since i am new to 3.8 kernel, please guide me how to integrate my camera patch

                            into 3.8 build.

                            Regards,

                            T. Rajkumar

                            1. Hi Rajkumar,

                              We are all pretty new to v3.8.x I'd recommend you post your current v3.2.x patch and question to the beagleboard google group: https://groups.google.com/forum/?fromgroups#!forum/beagleboard...

                              I'm still figuring out capemgr myself...

                              Regards,

                              1. Robert,

                                Thanks Robert. Do you have any documents/links on capemgr 

                                for me to start with. i didnt get any good material in google on this.

                                Regards,

                                T. Rajkumar

                                1. Hi Rajkumar,

                                  Google isn't going to find much, as capemgr is still in development. You can find the author's tree at: https://github.com/pantoniou/linux-bbxm and follow it's development.

                                  Regards,

  20. Hi,

    Build the kernel (and u-boot) for an vanilla beagle bone and getting this:

    reading uEnv.txt
    812 bytes read in 4 ms (198.2 KiB/s)
    Loaded environment from uEnv.txt
    Importing environment from mmc ...
    reading zImage
    3421280 bytes read in 396 ms (8.2 MiB/s)
    reading /dtbs/am335x-bonelt.dtb
    20443 bytes read in 10 ms (1.9 MiB/s)
    Booting from mmc ...
    ## Flattened Device Tree blob at 815f0000
       Booting using the fdt blob at 0x815f0000
       Loading Device Tree to 8fe3a000, end 8fe41fda ... OK
    Starting kernel ...

    Then nothing.

    Tried with both am335x-bone and bonelt. Having a real hard time finding info on the differences between these dtbs. Tried on a rev A01 and rev A06, with same results.

    Any ideas on how to debug why the kernel hangs??

    I should mention that I turned modules off and removed the keyword "modules" target from the build script. But I'm pretty sure I built-in all relevant hardware drivers before un-selecting modules in menuconfig (I'm old fashioned, like to have a kernel with all necessary hardware support and no modules). I suppose the next step would be to go back to the default config (which drives me insane because it compiles as modules just about everything on the face of the planet). Do you need an initrd to make it work with the defconfig+modules (i.e.: are there any essential drivers compiled as modules instead of linked in with the default config?)

    Appreciate any input.

    Thanks,
    Gilles
    .

    PS: Built from 3.7.10-x9 tag

    PS2: Built the rootfs with buildboot but I know it's good as it worked with the (older) kernel built by buildroot (besides, we're not getting anywhere near loading the rootfs). BTW: no blinking LEDs and the console is directed to ttyO0 as it should.

    1. Hi Giles,

      The am335x-bonelt.dtb is for unreleased hardware, so unless you have that hardware I wouldn't expect it to work.

      Since your not following the directions on this wiki (which accomplish this: bone_march1.log), please ask your questions at https://groups.google.com/forum/?fromgroups#!forum/beagleboard..

      The 3.7.10-x9 tag from the stable-kernel repo does not support BeagleBone Hardware. Support for the BeagleBone is only available under my linux-dev repo: http://eewiki.net/display/linuxonarm/BeagleBone#BeagleBone-LinuxBuildScript%3A

      Regards,

      1. Thank you Robert,

        I must admit it's is difficult for those of us who just begin in the ARM world (even seasoned Linux developers like myself) to figure out where things are. Google points to a multitude of places be it quilt or patches or even a git repo (which is in fact what I was looking for though that one had not been updated in a year so one thinks its not maintained)... Your posts have been the most helpful.

        To be honest, I did try to build from that other link you point me to but the u-boot would not load the kernel complaining that the signature was invalid. I suppose I can give it one more try. I think the reason why I gave up is because I saw a patch related to DTB and knew that DT weren't part of kernel v3.2 so I assumed it was the wrong u-boot instructions. Also, I hate to begin a project with an old version of the kernel knowing that other people are already using 3.6 or above. And I wanted to use DTBs because our hardware is going to be quite different when it's all said and done so we will have to create our own board support. Hate to create a platform today only to change it to a DTS later.

        I must say the instructions on this page created a wonderful git repo with tags for all sort of versions including pre 3. I was quite fond of the result. Would any of these tags work for the beaglebone? Is the lack of support for bone just a DTB issue? Could it be fixed by just adjusting the DTB or are the patches inadequate all together for the hardware?

        Anyway, I'm rambling. Thanks for the pointers. I'll post the result of my fresh recompilation on the other page.

        Cheers,

        Gilles

        .

        1. Hi Gilles,

          The signature was invalid can mean a few different things. For one, I've actually patched u-boot on this wiki to do some things that the default mainline u-boot for this target can not do. Hence why it is SO important to follow the directions. (As of today's date, the beaglebone u-boot config can only load/run uImage's, not the zImage's i use here. (there's a patch in Tom's queue, so it might be enabled by default in v2013.04-rc2))

          Careful, not every tag in the linux-dev repo will work on the BeagleBone, the repo is much older then the BeagleBone. In the past I used the master branch of linux-dev mainly as a staging area for my stable-kernel repo for the BeagleBoard/PandaBoard. Due to the shear size of the initial BeagleBone patchset, I just used a branch on this same repo, as much of the patches would be dumped in the merge churn..

          However for the BeagleBone, there are 5 branches available, in varying states:

          • am33x-v3.1 - Abandoned: do not use
          • am33x-v3.2 - Old Stable - Cape Support
          • am33x-v3.6 - Abandoned: do not use
          • am33x-v3.7 - Abandoned: do not use
          • am33x-v3.8 - New Stable - Limited Cape Support

          If you want pre v3.x kernel's for the BeagleBone good luck, as you'll just back port everything in a new kernel anyways... (wink)

          Regards,

  21. Hello Robert,

    thank you for your Git repro for beaglebone everything went fine and i installed a 3.8 kernel.

    I want to use the uart2 on the beaglebone and don't now where to start. Any idea where to get an example or explanation how to modify the am335x-bone-common.dtsi . Is it the right file and is it the only one to modify to use uart2 on the expansion connector.

    Thank you

    Pet

    1. Hi Peter,

      That's okay, with this wiki software, I'm actually trying to move all comments to a secondary page, (just like MediaWiki does with their talk page..) BeagleBone_Comments

      So, uart2 is actually defined in am33xx.dtsi:

      		uart2: serial@48022000 {
      			compatible = "ti,omap3-uart";
      			ti,hwmods = "uart2";
      			clock-frequency = <48000000>;
      			reg = <0x48022000 0x2000>;
      			interrupts = <73>;
      			status = "disabled";
      		};
      

      So to enable in am335x-bone-common.dtsi for am335x-bone.dts. Under ( ocp: ocp { ) add:

      		uart2: serial@48022000 {
      			status = "okay";
      		};
      

      Then under ( am33xx_pinmux: pinmux@44e10800 { ) you need to add: (I think, UNTESTED, so please confirm...)

      		uart2_pins: pinmux_uart2_pins {
      			pinctrl-single,pins = <
      				0x154 0x2f /* 21 UART2_TXD  spi0_d0.gpio0[3]       */
      				0x150 0x2f /* 22 UART2_RXD  spi0_sclk.gpio0[2]     */
      			>;
      		};
      

      Regards,

      1. Hi Robert,

        if i do it this way i get

        ......

        DTC     arch/arm/boot/dts/am335x-bone.dtb
         DTC     arch/arm/boot/dts/am335x-boneblack.dtb
        ERROR (duplicate_label): ERROR (duplicate_label): Duplicate label 'uart2' on /ocp/serial@4802200 and /ocp/serial@48022000

        .......

        But Uart1 looks indentical and there is no error?

        Regards,

        Pet

        1. Hi Peter,

          Give this a try: 0001-am335x-bone.dts-enable-usart2.patch only build tested. I based it off a few omap3/igepv2 patches heading mainline for v3.10. Still not 100% on the pinmux, but you can test it now..

          Regards,

  22. Hi Robert,

    stable v3.8 is not booting anymore on beaglebone. "It hangs after Uncompressing Linux... done, booting the kernel." ?? 2 days a go everything went fine.

    Regards,

    Peter

    1. Hi Peter,

      It's probably from the v3.8.4 stable merge, there is a few more patches in the community tree, so I'm going to sync my patchset this morning...

      Edit: Seems to boot just fine: bb-3.8.4-bone8.log

      Regards,

      1. Rebert,

        Would you mind posting the hash tag of the checkout which produced your working bb-3.8.4-bone8.log above?

        Now, was that one the new beagle bone with HDMI or would that same tag work on the older bone (A6 or similar)?

        Thanks,

        Gilles

        .

        1. Hi Gilles,

          git checkout 3.8.4-bone8 -b tmp
          

          So anytime I push out a dot 0 release, the tag gets automatically created.
          https://github.com/RobertCNelson/linux-dev/blob/master/tools/push-n-tag-release.sh

          That log was with a BeagleBone and a DVI Cape...

          Regards,

          1. Hi Robert,

            Sorry to be such a pain but I still can't get that 3.8.4-bone8 to work (get a kernel NULL pointer) and I'm a bit uncertain about what you meant above. What do you call a "dot 0" release? Is that a release you've tested as working and so gets tagged?

            Would the following log bring back "deja vu" with your experiments?

            [    1.665999] omap-sham 53100000.sham: hw accel on OMAP rev 4.3
            [    1.674708] omap-aes 53500000.aes: OMAP AES hw accel rev: 3.2
            [    1.681208] edma-dma-engine edma-dma-engine.0: allocated channel for 0:5
            [    1.688398] edma-dma-engine edma-dma-engine.0: allocated channel for 0:6
            [    1.697216] usbcore: registered new interface driver usbhid
            [    1.703130] usbhid: USB HID core driver
            [    1.709919] TCP: cubic registered
            [    1.713557] Initializing XFRM netlink socket
            [    1.718257] NET: Registered protocol family 17
            [    1.723114] NET: Registered protocol family 15
            [    1.728073] Key type dns_resolver registered
            [    1.732805] VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 3
            [    1.740925] ThumbEE CPU extension supported.
            [    1.745452] Registering SWP/SWPB emulation handler
            [    1.751893] registered taskstats version 1
            [    1.757378] Unable to handle kernel NULL pointer dereference at virtual address 00000014
            [    1.765923] pgd = c0004000
            [    1.768783] [00000014] *pgd=00000000
            [    1.772566] Internal error: Oops: 5 [#1] SMP ARM
            [    1.777392] Modules linked in:
            [    1.780597] CPU: 0    Not tainted  (3.8.4-bone8 #1)
            [    1.785718] PC is at dss_feat_get_num_ovls+0x8/0x14
            [    1.790828] LR is at omapdss_compat_init+0x30/0x2d0
            

            Thank you,
            Gilles
            .

            1. Hi Gilles,

              I remember seeing, this before

              [    1.780597] CPU: 0    Not tainted  (3.8.4-bone8 #1)
              [    1.785718] PC is at dss_feat_get_num_ovls+0x8/0x14
              [    1.790828] LR is at omapdss_compat_init+0x30/0x2d0
              

              In your git tree, when you run git diff does it indicate any modifications to patches/defconfig..

              Otherwise, you really should switch to the head commit of the am33x-v3.8 branch as i've been pushing a lot of fixes in.
              https://github.com/RobertCNelson/linux-dev/commits/am33x-v3.8

              From: "linux-dev"

              git checkout master -f
              git branch -D tmp || true
              git pull
              git fetch
              git checkout origin/am33x-v3.8 -b tmp
              

              Regards,

              1. Hi Robert,

                Yes, quite a lot of changes in fact. Here's just a summary:

                diff --git a/patches/defconfig b/patches/defconfig
                index 98e78dc..96f7e16 100644
                --- a/patches/defconfig
                +++ b/patches/defconfig
                @@ -1,6 +1,6 @@
                &nbsp;#
                &nbsp;# Automatically generated file; DO NOT EDIT.
                -# Linux/arm 3.8.2 Kernel Configuration
                +# Linux/arm 3.8.4 Kernel Configuration
                 #
                 CONFIG_ARM=y
                 CONFIG_SYS_SUPPORTS_APM_EMULATION=y
                @@ -926,120 +926,15 @@
                diff --git a/patches/defconfig b/patches/defconfig
                index 98e78dc..96f7e16 100644
                --- a/patches/defconfig
                +++ b/patches/defconfig
                @@ -1,6 +1,6 @@
                [...]
                @@ -926,120 +926,15 @@
                [...]
                @@ -1051,9 +946,6 @@
                [...]
                @@ -1068,32 +960,16 @@
                [...]
                @@ -1272,7 +1148,6 @@
                [...]
                @@ -1286,19 +1161,18 @@
                

                I will try the repo above. I'll try the 3.8.6-bone12.

                Thanks,
                Gilles
                .

                1. Hi Gilles,

                  With all those changes you were not truly running 3.8.4-bone8 then.

                  git reset HEAD --hard
                  

                  Would have reset your 3.8.4-bone8 back to default..

                  Regards,

      2. Hi Robert,

        I checked out 3.8.4-bone8 from linux-dev and it is booting. But 3.8.x from stable won't boot so i will work on dev.

        Thanks for testing.

        Regards,

        Pet

        1. Hi Peter,

          That is expected and is exactly why this page only references the "linux-dev" repo. The patch set is synced, but the .config is still different, those differences allow the BeagleBone to boot (and vice versa)...

          Regards,

          1. Hi Robert,

            Sorry, don't mean to interject here but may I say I noticed the .config and that is a very nice touch.

            There was almost nothing to be done in menu config where usually, one has to turn every option off on the face of the planet from the kernel.

            Thanks for this repo!

            Gilles

            .

  23. Hi Robert,

    I am trying the freshly baked RT Preempt Patch for kernel 3.8.4 and it works (apparently). On the other hand, I am not able to load my can bus on the new kernel 3.8 (I am using Wheezy).

    I used to follow the instruction I found on internet, i.e. commands like: 

    ip link set can0 up type can bitrate 125000

    gets the answer 

    Cannot find device "can0".

    But if I use the command

     ip link set can up type can

    I get something more juicy:

    [   51.518629] can: controller area network core (rev 20120528 abi 9)
    [   51.529052] NET: Registered protocol family 29
    [   51.538679] Loading kernel module for a network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias netdev-can instead.
    Cannot find device "can"

    Any clue?

    1. Hi Davide,

      Based on google, that looks to be a common error... I still have no idea either. It looks to be an old can userspace/application...

      Regards,

  24. Hi Robert,

    Congratulations for this fantastic content. I went through the steps using the Linux Build Script (v3.8.x) and the Ubuntu 12.10 as the FS. I did also created the microSD card. Everything worked great so i decided to set up an NFS server to load the kernel and the FS over the network to ease the development (u-boot and other bootloading files are stored on the SD since they won't change for now).

    So it was time to get my hands on the kernel hacking issue, i checked the Kernel Configuration under:

     System Type \->
           TI OMAP2/3/4 Specific Features \->
    

    And i saw that the following:

      │ │     [*] Typical OMAP configuration
      │ │     -\- OMAP2 SDRAM Controller support
      │ │     [ ] TI OMAP2
      │ │     [*] TI OMAP3
      │ │     [*] TI OMAP4
      │ │     [ ] TI OMAP5
      │ │     [*] OMAP3430 support
      │ │     [ ] TI81XX support
      │ │     [*] AM33XX support
      │ │     *** OMAP Board Type ***
      │ │     [*] Generic OMAP2\+ board
      │ │     [*] OMAP3 BEAGLE board
      │ │     [ ] DEVKIT8000 board
      │ │     [ ] OMAP3 LDP board
      │ │     [ ] OMAP3 Logic 3530 LV SOM board
      │ │     [ ] OMAP3 Logic 35x Torpedo board
      │ │     [ ] Gumstix Overo board
      │ │     [ ] OMAP 3530 EVM board
      │ │     [ ] OMAP3517/ AM3517 EVM board
      │ │     [ ] AM3517/05 CRANE board
      │ │     [ ] OMAP3 Pandora
      │ │     [ ] OMAP3 Touch Book
      │ │     [ ] OMAP 3430 SDP board
      │ │     [ ] Nokia N950 (RM-680) / N9 (RM-696) phones
      │ │     [ ] Nokia N900 (RX-51) phone
      │ │     [ ] OMAP3 Zoom2 board
      │ │     [ ] OMAP3630 Zoom3 board
      │ │     [ ] CompuLab CM-T35/CM-T3730 modules
      │ │     [ ] CompuLab CM-T3517 module
      │ │     [*] IGEP v2 board
      │ │     [ ] IGEP OMAP3 module
      │ │     [ ] OMAP3 SBC STALKER board
      │ │     [ ] OMAP3630 SDP board
      │ │     [ ] OMAP 4430 SDP board
      │ │     [*] OMAP4 Panda Board
      │ │     [ ] OMAP3 debugging peripherals
      │ │     [ ] Enable SDRC AC timing register changes
      │ │     [ ] OMAP4 errata: Async Bridge Corruption
    

    Three boards seem to be selected: OMAP3 BEAGLE board, IGEP v2 board and OMAP4 Panda Board. I need to know which code is being executed so i decided to put printks on the three of them to figure out which one was being executed. Well i did it but nothing, the board boots exactly as before, no changes (i'm rebuilding using the tools/rebuild.sh). I thought it was a bit weird so i decided to unset the three boards and see if there was something that i was missing. Once the three boards were deselected i was hoping the the kernel wouldn't boot but surprisingly it does so.

    I read that previously somebody mentioned the "board-am335xevm.c" but that's not on my kernel tree (3.8.4). Would you mind telling me if i'm missing something? Which board configuration file is loading?

    Regards,

    1. Hi Víctor,

      So, you must have missed Linus's rant 2 years ago.http://lwn.net/Articles/439314/

      What basically came out of it, board files where becoming an un-maintainable mess, and device tree's were selected to be the future http://elinux.org/Device_Trees. So after that, any board files posted for inclusion would be outright nak'ed. The BeagleBone, which was released after the rant, fell under that, so no board-am335xevm.c file was pushed mainline. Which is why this wiki has two direction paths, a v3.2.x board based kernel and an v3.6+ based device tree kernel...

      So the files that boot the BeagleBone that you are interested in are:

      arch/arm/mach-omap2/board-generic.c (device tree board file)
      arch/arm/boot/dts/am33xx.dtsi
      arch/arm/boot/dts/am335x-bone.dts
      arch/arm/boot/dts/am335x-bone-common.dtsi
      

      Regards,

      1. Robert,

        Thanks. That was it. Clearly I was outdated.

        Regards,

  25. Hi Robert,

    Thank you for your scripts. I have compiled and successfully installed kernel 3.8.

    As i can see, the cape manager use capes / slots mechanism, so registering a platform device such as tscadc is impossible without standard cape with eeprom on i2c. Would you recommend a way for breaking this mechanism so i can use the touchscreen functionality with custom cape (without eeprom) with display and touchscreen.

    Regards,

    1. Hi Toshe,

      Take a look at: arch/arm/boot/dts/am335x-bone-common.dtsi specifically:

      /* Beaglebone black has it soldered on */
       slot@4 {
      	ti,cape-override;
      	compatible = "ti,beaglebone-black";
      	board-name = "Bone-LT-eMMC-2G";
      	version = "00A0";
      	manufacturer = "Texas Instruments";
      	part-number = "BB-BONE-EMMC-2G";
       };
      

      From this, you can see when you have the "ti,beaglebone-black" it's creating a 4th slot, which loads the emmc-2g cape automatically on bootup.

      So look under "firmware/capes/" and do something similar for your device.

      If you dig into: drivers/misc/cape/beaglebone/capemgr.c & Documentation/devicetree/bindings/misc/capes-beaglebone.txt there are also bootargs available.

      Regards,

      1. Hi Robert,

        Thank you for pointing this out. Obviously I was blind for the Documentation folder and I didn't saw the comment header above the slots definition in arch/arm/boot/dts/am335x-bone-common.dtsi "... without an EEPROM".

        What I did:

        I wrote an override slot using the compatible=ti,beaglebone as trigger field for loading the firmware;

        Placed the device tree source file in firmware/capes and modified firmware/Makefile in order to compile it;

        Finally I placed the device tree filename in capemaps in arch/arm/boot/dts/am335x-bone-common.dtsi.

        Now I can see capemgr populating slot #4 and firmware is loaded successfully. Next I would try compatible = "kernel-command-line", "runtime"; to trigger loading firmware. That way seems more flexible.

        Regards,

  26. Thank you very much for the link, it really helped.

    Thanks,

    Mahanth

  27. Hi Robert,

    Can two USB gadget modules be loaded simultaneously? For example, running command "sudo insmod g_hid.ko"  and then followed with "sudo insmod g_ether.ko".

    Regards.

    Damien

    1. Hi Damien,

      You really should use modprobe over insmod as it also takes care of dependices.

      No, you would have to remove g_hid.ko before loading g_ether.ko... If you need more then one feature at a time, there are a two "multi" modules:
      https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/gadget/Kconfig#n862

      Jan also shows an example on this page:
      http://www.lvr.com/beaglebone.htm

      Regards,

  28. Hi Robert & everybody

    I do have a question:

    -I do have an BeagleBone for which I generated using Yocto Project and rootfs (kernel 3.8.5)

    -my "distribution" is working fine

    In my plan is to buy from CircuitCo and LCD4.

    For this LCD I don't know what modification I have to do in the kernel.

    I have to use an driver and I don't know which one, what are the option from kernel point of view, etc

    Can you be so king and guide me ?

    Thank you in advance and all the best

    Mihai M

    1. Hi Mihai,

      I'm not involved with the Yocto Project. BUT if they are using a kernel based on Koen's 3.8.x beaglebone branch the LCD4 should be working out of the box. (which is based on: https://github.com/beagleboard/kernel/tree/3.8)

      should: I don't have the LCD4 to test it myself (I have the LCD3/LCD7).

      Regards,

      1. Hi Robert

        I know that you are not involved with Yocto; anyway I don't know what branch they are using.

        Reading in more details all the messages I saw that BeagleBone use DaVinci driver, so I need to find in the kernel option regarding this driver driver. It OK in this way ?.  Any hint will be a great help-it could be for LCD3/7 also

        Regards,

        Mihai

        1. Hi Mihai,

          Actually the LCD3/LCD7 already works out of the box with the older v3.2.x based kernel shown on this wiki page. Look over the FAQ section for Backlight/Touch Screen userspace hints.

          No kernel options are needed, the LCD3/LCD4/LCD7 are auto detected on bootup and the kernel will setup the video settings. The v3.8.x branch is still be actively developed.

          BTW: CircuitCo (designers/builders of the LCD4) are also the maintainers of the beagleboard.org tree: https://github.com/beagleboard/kernel/tree/3.8

          Regards,

  29. I just finished following the instructions to set up an SD card building: kernel_version=3.8.6-bone12.1 with Ubuntu 12.10 rootfs, went as smooth as could be expected.

    My only issues with the instructions were that the fdisk EOF steps EOF didn't work with cut and paste (unlike all the other "code" sections) so I did them manually to create the two partitions, not clear at all what I was supposed to do here.  Also the section about shared SD card To always enable the Ethernet interface as eth0.. made no sense, so I skipped it, perhaps a link or an explanation as to what this is about would be helpful.

    Booting my new Beaglebone has two problems.  It didn't boot automatically on power up -- I had to give the bootz command in the serial console, maybe I've forgotten about a jumper or switch setting.

    But the showstopper for me is the kernel that was built has no /dev/spidev installed.  I wasted so much time trying to get the spidev to work editing the board files and now I've no earthy idea on how to do it with "device tree" and have found no clues via Google so far.

    Does anyone know how to get the userspace spidev driver working with these new device trees?

    The 3.2 kernels for Beaglebone and Pandaboard have problems with random long latencies in the spidev driver that break our application, trying a 3.8 kernel is the last step before junking the boards and moving to something else.

    I posted test code here that shows perfect timing if toggling a GPIO pin instead of calling spidev

    I haven't tested networking or anything else as at this point the board is scrap without the spidev userspace driver.

    Edit:

    My 3.2.23-psp18 SD card automatically booted, so its not forgotten switch or jumper on this board.

    1. Hi Mr Greene,

      Correct, every command should be cut and paste.. What version of fdisk do you have on your system? The directions on the wiki page assume:

      /sbin/fdisk -v
      fdisk (util-linux 2.20.1)
      

      aka: Debian Wheezy's default package...

      The modification to make sure udev always defines the interface as eth0 is only useful for people who move the same microSD card between multiple BeagleBone and expect ssh/apache to automatically startup on every board. Normally udev would see a different MAC address and define the interface as eth1 on the 2nd BeagleBone. This udev rule modification stops that.

      It should have booted automatically, this was from a few weeks ago and u-boot/uEnv.txt has not changed since then: bb-3.8.4-bone8.log So double check your uEnv.txt boot script. PS.. I've been re-writing the u-boot patches so only a minimal uEnv.txt file is required for out of the box. See http://eewiki.net/display/linuxonarm/BeagleBoard#BeagleBoard-UBootuserenviromentvariables%3AuEnv.txt you only "un-comment" things you actually use...

      The v3.8: spidev patches are currently being discussed here:
      https://groups.google.com/forum/?fromgroups=#!topic/beagleboard/-Lum76JL5VY

      Regards,

      1. Thanks for the quick reply.

        OK it looks like fdisk on my Ubuntu 10.04 is "old" and apparently I must have hit an extra <Enter> when I started the screen command for the USB serial port that interrupted the boot, as I tried it again and it did boot automatically.

        Adding your explanation about the udev thing to that section would have  left me feeling good about skipping that step, and would inform me that I should do it before I clone this card for another system.

        I'm trying to digest the spidev patch info in your link, but things like:

        Create a custom dtsi with the code snippet below, create a custom dts 
        which includes your custom dtsi, then add your dts to the Makefile. You 
        don't really want to be altering the beaglebone dts as it will interfere 
        with future updates.

        Are clear as mud right now, but its a start.

        To give my brain a rest for today, next I'll build the 3.8 for the Pandaboard following your similar instructions for it, and then dive into the dtsi stuff tomorrow with a fresh start.

        To clarify, I did all the building on Ubuntu 12.04 (hate the UI!) running in a virtual machine on my 10.04 system.  Then I used 10.04 to format and copy to the SD card, as I'd seen some references to problems writing the SD cards from a Parallels VM.

        Do you work for Digi-Key?  I've enjoyed watching them grow from a hobby parts supplier in the back of Popular Electronics into one of the largest distributors.  I left hardware for software in the late 80's but things like the Pi, Beaglebone, Pandaboard, etc. may draw me back in during my soon to happen retirement.

        --wally.

        1. Wally,

          You should read about device trees which are new to all of us who are used to deal with older kernels where the device platform board file was the only way to change which drivers were loaded. 

          What the "clear as mud" text is saying is that it is preferable to ADD your own DT (device tree) code in a separate file rather than modify the beaglebone existing files for the obvious reason of not having to make that change every time you upgrade. BTW: dsti are the files you edit and dst are the files that get compiled by the make command and used as the final device tree blob. If you search wiki on DT, this will all make sense. 

          Cheers,

          Gilles

          .

          1. Thanks,

            "BTW: dsti are the files you edit and dst are the files that get compiled by the make command and used as the final device tree blob."

            This is useful information at this point.  Although I'd rather a working recipe instead of a learning curve as I've nothing but hope that 3.8 will fix the latency issues.  

            I was shocked that a 3.4-rt  kernel for the Pandaboard didn't fix the problem.  That is when I wrote the test code to isolate the latency to the /dev/spidev write and show that is was not a userspace to kernel transition issue by showing perfect timing when toggling a GPIO pin instead.

            1. Hi Wally,

              One reason we do not have a working recipe right now, we are still effectively building the device tree infrastructure for the BeagleBone/CapeManager... (wink) Once we have it working, it will be easily enabled like the buddy=spidev option we have for BeagleBoard/PandaBoard...

              Regards,

              1. Thanks, useful info,  I'm building your Pandaboard 3.9 kernel now, I started with the Beaglebone as its worst case latencies were smaller so I guessed it might need smaller improvement to meet our needs.  I see the instructions for enabling spidev are in the Pandaboard wiki.

        2. Parallels:

          Yeah, we still haven't figured out a reliable way to create sd cards in that environment. Really any VM creates odd latencies when writing to the drive. When your stuck in that environment, sometimes it's easier to get one board up and running, and then over ssh use that board to create your other SD cards. That's one advantage of running a full distro such as ubuntu/debian on these devices.

          Regards,

  30. I got the Pandaboard ES setup and spidev enabled,  it'll be great when the Beaglebone is that easy!

    kernel-3.9 on the Pandaboard ES didn't seem to fix my spidev latency issue :(  Details in the Pandaboard wiki.

    At this point it doesn't seem its worth my effort to get spidev working on the Beaglebone 3.8 kernel since the Panadboard 3.9 still has the problems.

    Thanks for your help!

    Doing the cross-compiles in a virtual machine has the advantage of being able to quickly move the development tools to the machines where we can attach the Panda/Beagle hardware, we have idiotic networking restrictions that make life miserable for these kinds of things :(   But at least they pay my normal rate for wasting my time :)

    Its easy enough to export the the results from the VM to the host and write the SD card from the host,  I just wasn't aware of any significant differences with fdisk since Ubuntu 10.04

    --wally.

  31. removed question as I see it now on the google group.

    Thanks,

    Greg

    1. Hi Michael,

      The script relies on a specific starting point, look at version.sh/patch.sh after which every patch is based on the previous, so to add those two patches you need to find something common with both tree's.. PS, due to content in the 2nd patch you posted, this will not be trivial. as "baseboard-mityarm335x-devkit.c" defiantly doesn't exist in our shared beagleboard.org tree.

      Regards,

  32. Hello Robert,

    Thankyou for putting the beagle pages together.

    I am having a problem with :-

    sudo tar xofv ./linux-dev/deploy/${kernel_version}-dtbs.tar.gz -C /media/boot/dtbs/

    after the build I don't have a *-dtbs.tar file in /linux-dev/deploy

    The zImage has build


    I have rebuilt with ./tools/rebuild.sh

    and get:-

    +Detected build host [Ubuntu 12.04.2 LTS]
    
    make -j1 ARCH=arm LOCALVERSION=-psp27 CROSS_COMPILE="/home/ubuntu/rn/linux-dev/dl/gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_linux/bin/arm-linux-gnueabihf-"  
    dtbs
    make[1]: Nothing to be done for `arch/arm/boot/dtbs'.
    
    Building 3.2.42-psp27-firmware.tar.gz
    -----------------------------
    -----------------------------
    Script Complete
    eewiki.net: [user@localhost:~$ export kernel_version=3.2.42-psp27]

    I know your working on 3.8, but I was concerned with the usb status, as I need this to work so I used the 3.2 version.I have no *.dtb file in ./arch/arm/boot to copy into deploy/tmp dir, but the compile said it  has nothing to do?

    Thanks

    Paul S

    PS I was having problems with "git://" which I have changed to "http://" to solve.

    1. Hi Paul,

      dtb's didn't exist in the v3.2.x based branch for this target. I tried to document this in the kernel copying section via:

      Copy Kernel dtbs (Device Tree v3.6.x++):

      Regards,


      1. Hello Robert,

        Thanks, YES that worked I now have 3.2 kernel running, ethernet works, serial over usb works, but no USB mass storage.

        I do need USB mass storage to work, so I can start to interface with pcb.

        When I plug the std USB sick I get no devices in /dev.

        The boot trace indicates the support is there:-

        [    1.721923] USB Mass Storage support registered.

        If I boot with the stick in or insert after boot I get nothing, not trace, no device to mount and no light on the stick.

        Thanks

        Paul S

        1. Hi Paul,

          USB mass storage has always been enabled. Please verify that you are using a 5volt DC jack connector to power the beaglebone, try another USB storage device and that it is plugged in before power up on the old v3.2 based kernel.  Or you could just switch to the newer v3.8.x based branch which includes a lot of USB fixes for this target.

          Regards,

          1. Hello Robert,

            Thanks, looks like i had a 1 in 3 chance of this working and yes I picked the one stick that does not work.

            But my nxp code on our pcb does.

            thanks

            Paul S

  33. Hi...   I struggled for quite a while to get u-boot to load the 3.8 kernel on a BBW.  I think I found a bug in the uEnv.txt example, and specifically the 'bootz' command as shown.

     

    The text above calls out,

    #uenvcmd=run loaduimage; run loadfdt; run mmcargs; bootz 0x80200000 - 0x815f0000

     

    but the addresses going into bootz are incorrect so it does not find the device tree and u-boot complains with,

    reading /dtbs/am335x-bone.dtb
    23382 bytes read in 12 ms (1.9 MiB/s)
    ERROR: Did not find a cmdline Flattened Device Tree
    Could not find a valid device tree

    Instead, I used this text,

    uenvcmd=run loaduimage; run loadfdt; run mmcargs; bootz $loadaddr - $fdtaddr

    and now it takes right off.

     

    Chris

     

    1. Hi Chris,

      It's the 'fdtaddr' this is wrong...

      From: http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;h=ef00306a55ef09d8ecc78a7ca3dcdc4ad7d1bd3d;hb=d10f68ae47b67acab8b110b5c605dde4197a1820#l56

      loadaddr=0x80200000
      fdtaddr=0x80F80000
      so:
      bootz 0x80200000 - 0x815f0000
      needs to be:
      bootz 0x80200000 - 0x80F80000

      I had always defined "fdtaddr" myself with the uEnv.txt, so when i moved to simpler one, this address got over looked.

      Ah found where I coped it wrong:

      BeagleBone Black#uEnv.txtbasedbootscript

      Here I specified the address when loading and running the device tree blob... Then miscoped it over, going forward i need to transition to the mainline 0x80F80000

      Regards,

      1. Hi Robert,

        Just curious why it is better to hard code that address in the bootz command than to use the

        $fdtaddr environment variable?    Isn't the variable correctly filled in by u-boot according to where

        it is going to load that stuff?

         

        Chris

        1. Hi Chris,

          Either is fine... The better option is to drop v3.2.x support and leave those magic numbers inside u-boot. Then we just use 'uEnv.txt' to enable things like: http://eewiki.net/display/linuxonarm/BeagleBoard#BeagleBoard-U-Bootuserenviromentvariables:uEnv.txt

          Regards,

  34. Hi,

    Has anybody tried the TiWi-5E Chip Antenna Cape (http://beagleboardtoys.info/index.php?title=BeagleBone_TiWi-5E_w/_Chip_Antenna) with the 3.2.x kernel and the Ubuntu FS?.

    It seems it is currently working in Angstrom with the 3.2 version https://groups.google.com/forum/?fromgroups#!searchin/beagleboard/wifi$20cape$20ubuntu/beagleboard/V4Ql6yfrhbs/FPYX541XYWwJ.

     

    Regards,

     

    1. Hi Victor,

      So did you even test my am33x-v3.2 based tree?

      Support for that device, was the only reason, I pushed out "3.2-psp27" last April...

      https://github.com/RobertCNelson/linux-dev/commit/bc31070143b196db7d4ee7c33a8ce47d11e6eb48

      Regards,

      1. Robert,

         

        Thanks for your answer. I haven't tested anything yet. I was curious wether somebody went through the process and maybe had some specific instructions or tips.

        I will try what you suggest.

        Kind regards,


        1. Hi Victor,

          WiFi should work, the bluetooth stuff still needs some work. But I haven't personally tested since pushing that commit out in April..

          Regards,

  35. Hi,

    Thanks for putting together these easy to follow instructions, excellent work! I have built and tested various combinations, one combination that currently doesn't work in my setup is the 3.2 kernel and the Wheezy root file system. Took me a while to figure out what was going on, so I thought I'd share with other. The kernel boots fine but hangs right after passing over control to the init process, this only occurs though with the Beaglebone connected over USB to my Ubuntu 12.04 based host PC.

    These are the last few lines on the serial console;

    [    2.104431] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
    [    2.115081] devtmpfs: mounted
    [    2.118743] Freeing init memory: 248K
    [    2.311767]  gadget: high-speed config #1: CDC Ethernet (ECM)
    INIT: version 2.88 booting
    [info] Using makefile-style concurrent boot in runlevel S.

    If I unplug the USB connection to the PC the Beaglebone continues booting, and I can login over ssh. The same is true with the USB port connected to a Windows PC without the BB USB drivers loaded. While I haven't confirm this, my guess is that this is related to the USB Ethernet Gadget device support. The host PC does load the cdc_ether driver but that somehow seems to lock the kernel on the Beaglebone. This issue does not occur on the 3.8 series kernel.

    1. You can also issue:

      sudo ifconfig usb0 up

      on your linux system that is connected to the beaglebone over the usb client port, to resolve the lockup...

       

      1. Hi Robert,

        Thanks for the workaround, I'll try that or maybe disable the Ethernet gadget support in the kernel altogether.

        On another topic, I've spent a good part of the day trying to understand why I can't get sound working correctly on the 3.8.13 kernel together with a cape that I've built. For the parts that are related to the Linux kernel, my cape is identical to the BB-BONE-AUDI-01 cape, i.e. it uses  the same codec and uses the same pins on the Beaglebone expansion header. The cape works fine with the 3.2 series kernel, but with 3.8 there is mostly noise coming out but it is possible to hear music at some points. By using the Linux debug file system I have concluded that the codec registers have an identical setup when used together with both the 3.2 and 3.8 kernel, so the issue is likely elsewhere in the kernel than the codec driver. Where would be a good place to report this and get some help with further debugging? I've seen posts where other people have the same issues and symptoms with the "standard" BB-BONE-AUDI-01 cape so I'm pretty sure it is not related to my custom HW.

        Thanks
        Daniel

  36. Hi Robert,

    Hate to bug you about this but google searches are turning up very useless at best and I am having a very hard time getting the camera cape to work and I was wondering if you had any experience at all with it or any recommendations of which kernel version would be best for it.  After trying the "supposedly good" angstrom kernel, I went back to your 3.2.42-psp27.

    The boot log looks good but then any attempt to capture fails.  ffmpeg captures nothing and the capture test program times out on select. Does this bring back any memories? Any recommendations on a "better" version tag to check-out instead?

    Boot log:

    [    1.826599] Linux media interface: v0.10
    [    1.830871] lirc_dev: IR Remote Control driver registered, major 249
    [    1.837677] Linux video capture interface: v2.00
    [    1.844085] cssp-camera cssp-camera: reg_base_virt = 0xd08c0000
    [    1.850311] cssp-camera cssp-camera: CSSP Revision A0
    [    1.855712] cssp-camera cssp-camera: allocating channel for DMA succeeded, chan=20
    [    1.864654] mt9t112 3-003c: mt9t111 chip ID 2680
    [    1.869537] cssp-camera cssp-camera: client's name is: mt9t112
    [    1.876007] cssp_camera-000: V4L2 device registered as video0
    [    1.882110] Driver for 1-wire Dallas network protocol.
    [    1.888610] OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
    [    1.900024] cpuidle: using governor ladder

    Capture invoked as:

    [20:01]arm:~$ ./capture -h
    Usage: ./capture [options]
     
    Version 1.3
    Options:
    -d | --device name   Video device name [/dev/video0]
    -h | --help          Print this message
    -m | --mmap          Use memory mapped buffers [default]
    -r | --read          Use read() calls
    -u | --userp         Use application allocated buffers
    -o | --output        Outputs stream to stdout
    -f | --format        Force format to 640x480 YUYV
    -c | --count         Number of frames to grab [70]
    
    [20:01]arm:~$ ./capture -c 10
    select timeout

    Attempts to use the -f format option all returned errors from the V4L2 setfmt ioctl.

    The best link I found on google was a post mentioning that the driver didn't work unless the LCD 7" was present to properly setup an "important" pin configuration otherwise left un-configured with the camera cape alone but no information on what that pin was or what the configuration should be was offered.  Another post also suggested that this was only the case with a particular version of the LCD cape. I ordered a LCD 7" cape just to test this theory but have very little hope about the results.

    Again, sorry to bug you about this but any input you may have about the camera cape would be greatly appreciated should you have any experience with it. I don't see a lot of useful references to it.

    Thank you,

    Gilles.

    1. I've also had problems getting the camera cape working.  The first one I tried had a hardware problem and the replacement isn't working consistently.  

      Right now it will capture video for about 2 seconds before it locks up.  The kernel oops messages don't seem very consistent:

      Running the cheese program:

      [  379.287378] BUG: Bad page state in process video_source:sr  pfn:8413a
      [  387.203980] BUG: spinlock lockup suspected on CPU#0, video_source:sr/595
      [  387.210973]  lock: 0xc08f2c80, .magic: dead4ead, .owner: <none>/-1, .owner_cpu: -1
      [  387.219142] [<c000c1db>] (__irq_svc+0x3b/0x5c) from [<c002ca40>] (vprintk_emit+0x2ac/0x310)
      [  387.219153] BUG: recent printk recursion!
      [  387.219157] Internal error: Oops - bad mode: 0 [#1] SMP THUMB2


      And after rebooting and running it again:

      [  195.664635] Internal error: Oops - undefined instruction: 0 [#1] SMP THUMB2


      Running the simple video capture utility:

      root@beaglebone:~# capture-example -c 9000
      .................................................................................[  294.258090] U8
      [  294.266537] pgd = c0004000
      [  294.269357] [00000608] *pgd=00000000
      [  294.273083] Internal error: Oops: 17 [#1] SMP THUMB2


      Running linphone:

      [17:37]arm:~$ linphonec -C
      Ready
      linphonec> Registration on <sip:10.0.1.17> successful.
      linphonec> call sip:231@10.0.1.17
      Establishing call id to <sip:231@10.0.1.17>, assigned id 1
      Contacting <sip:231@10.0.1.17>
      linphonec> Call 1 to <sip:231@10.0.1.17> in progress.
      linphonec> Remote ringing.
      linphonec> Remote ringing...
      linphonec> Call 1 to <sip:231@10.0.1.17> ringing.
      Remote ringing.
      linphonec> Call 1 with <sip:231@10.0.1.17> connected.
      Call answered by <sip:231@10.0.1.17>.
      linphonec> ortp-error-no such method on filter MSV4L2Capture, fid=16390 method index=0
      ortp-error-no such method on filter MSX264Enc, fid=16392 method index=0
      x264 [warning]: VBV bitrate (1375) > level limit (768)
      x264 [info]: using cpu capabilities: ARMv6 NEON
      x264 [info]: profile Constrained Baseline, level 1.3
      Media streams established with <sip:231@10.0.1.17> for call 1 (video).
      [  296.258026] Unable to handle kernel NULL pointer dereference at virtual address 00000008
      [  296.266448] pgd = cf718000
      [  296.269256] [00000008] *pgd=8f2d2831, *pte=00000000, *ppte=00000000
      [  296.275787] Internal error: Oops: 17 [#1]


      I've tried compiling the kernel and various Angstrom images.   

      Do I have another bad unit?  Is there a problem with the kernel driver?

      1. Hi Nathan,

        Is this the v3.2.x or v3.8.x branch? (the v3.2.x is pretty much eol for me at this point..)

        I think i have one of the camera capes at home, so i'll need to test it tonight.

        Regards,

         

        1. I've tried both. 

          I compiled 3.2.42 and the Angstrom image I used had 3.8.13.

          I will try compiling 3.8 and report any changes.

           

          update:

          The capture utility is working with 3.8.13-bone24. 

          linphone doesn't work but I think this is a userspace issue.

           

          1. Hi Nathan,

            Have you had any success running Linphone on the BBB? I'm using both video and audio, and have been struggling with a combination that's stable and (reasonably) smooth.

            Thanks for any thoughts or suggestions you might have.

            Charles

            1. I had some success running the console version (linphonec -C) but I haven't looked at it for the last 6 months.  

              When I left off it was capturing video and audio but a bug in the audio/alsa routines was taking 50% of the CPU.  I didn't have time to figure out what was going wrong.

              I don't have the board with me right now but I remember I changed the h264 capture preset to use the fastest (lowest quality) encode method and I modified the linphone(?) code to do more iframes.  

               

               

              1. Hi Nathan,

                Thanks very much for your reply and insight. I'll give it a shot.

                Charles

  37. Thanks Robert for sharing and mantaining this info

    I've followed the recipy but my image doesn't boot:

    • no leds blinking (only the power-on led)
    • I can't connect opening a terminal (like sudo screen /dev/ttyUSB1 115200)
    • ifconfig in my host "sees" usb0. The Network Manager tries to activate that connection but fails. I can't activate i manually either, and therefore I can't open an ssh connection
    • the SD card, mounted all alone, shows the two expected partitions (boot and rootfs)
    • lsusb recognizes the board attached to the proper USB port

    I think the prob can be related with which follows (there's some related comment but it doesn't quite match my prob):

    Where you indicate:

    for: DISK=/dev/mmcblk0
    sudo mkfs.vfat -F 16 ${DISK}p1 -n boot
    sudo mkfs.ext4 ${DISK}p2 -L rootfs
     
    for: DISK=/dev/sdX
    sudo mkfs.vfat -F 16 ${DISK}1 -n boot
    sudo mkfs.ext4 ${DISK}2 -L rootfs
    My host is running CentOS 6.4. Since I don't have a /dev/mmcblok0 device, I assumed here that I should use /dev/sdb, and I used:
    sdb1 for /media/boot/ (the FAT partition)
    sdb2 for /media/rootfs/ (the Linux partition)
    I see that mmcblk0p{1,2} are required / used within the BBB, and that nEnv.txt just specifies the location of the rootfs this way:
    mmcroot=/dev/mmcblk0p2 ro
    (BTW I do also assume I should uncomment the command lines in uEnv.txt)
    I'll really appreciate any help, thanks in advance
    JL

     

    1. Hi Jose,

      Replacing /dev/mmcblk0 via /dev/sdb is exactly what you needed to do.  (/dev/mmcblk0 has the weird partition labels as is only usually used with built-in mmc adapters (non-usb))

      The usb-serial ftdi chip can have some issues on first connection.  On first connect, I usually connect 5 volt power first, then connect the usb cable, then keep repeating [screen /dev/ttyUSB1 115200] till it physically connects, sometimes hitting the reset button a few times helps.  Then once the serial port is physically connected and showing serial data, i can drop the 5 volt adapter.  Once you get the serial boot log, (use pastebin.com when uploading), we can take a look at what's going on.

      Regards,

      1. Thank you so much for answering so quickly

        Therefore, besides resorting to /dev/sdb{1,2} as I've done, shall I use this in nEnv.txt?

        mmcroot=/dev/sdb2 ro

        (which seems odd to me, since, apparently, the BBB image expects the rootfs to be located at /dev/mmcblk0p2)

        For the rest, I see what you mean...I don't have a 5v power source around 'cause I'm working at home, not at the lab (summer campus closure for energy-savings)... I'll try to get one on Mo

         

        1. Hi Jose,

          Nope, use /dev/mmcblk0p2.  Remember on your "desktop centos pc" the driver used for your something-to-mmc adapter is using '/dev/sdX' label.  However on the beaglebone, we are using the am335x mmc linux driver which defines the device as '/dev/mmcblkX'.

          If you do not have a 5volt power plug, just keep trying to connect via screen, on every failure to connect just keep trying to rerun 'screen', eventually it'll connect after 2-3 times.  BTW: this is one of the reasons why this 'usb-serial' chip was removed on the beaglebone black, as it was sometimes painful to initially connect.

          Regards,

          1. Hi Robert,

            The most I'm getting is a series of six to eight 'C' characters. The Network Manager gets busy, sometimes shortly and temporarily uplifting usb0, sometimes not

            I'm looking for a suitable board for a course on embedded OS/RTOS (an alt to Embest IDE) and I certainly guess I should go for the Beaglebone Black, not for the original...(I'm also trying to port uCOS-II to the board).

            I've also generated images following the procedure described in http://beagleboard.org/linux but using Linaro GCC as you do, but haven't fixed my problems with uboot yet.

            I'm supossed to take a vacation leave starting next Tu: I'll likely order a BB Black before leaving. I'll make you know about my progress. Thanks again!

            1. Hi Jose,

              Just a constant series of C's?  First thing I'd check, make sure the boot flag is set on your microSD

              voodoo@hades:/opt/github/stable-kernel$ sudo fdisk -l /dev/sdd
              Disk /dev/sdd: 3965 MB, 3965190144 bytes
              122 heads, 62 sectors/track, 1023 cylinders, total 7744512 sectors
              Units = sectors of 1 * 512 = 512 bytes
              Sector size (logical/physical): 512 bytes / 512 bytes
              I/O size (minimum/optimal): 512 bytes / 512 bytes
              Disk identifier: 0x0003a69e
                 Device Boot      Start         End      Blocks   Id  System
              /dev/sdd1   *        2048      133119       65536    e  W95 FAT16 (LBA)
              /dev/sdd2          133120     7743487     3805184   83  Linux

              The "sfdisk" directions here should set the boot flag automatically.  But does CentOS's version set it?

              BeagleBone#SetupmicroSD/SDcard

              2nd, In general MLO must be copied first, if anything is copied to the fat partition before MLO there is a chance (specially on older bootrom's) of the bootrom not finding it.

              BeagleBone#InstallBootloader

              Regards,

              1. I entirely formatted the SD card, and I went over the whole process once again (making sure I copied the MLO first etc), but I got to the same point (seeing the "C's")

                Yes, your sfdisk settings are ok in CentOS (the 1st partition is created with the boot flag set).

                The only remarkable things are that:

                • I commented out all the apt-get stuff in ./dtc.sh making sure I had the corresponding CentOS packages installed. Eventually, the script complained about the git branch --list option (strange though it might seem, this option doesn't exist in the CentOS git package) so I tried -a but finally removed it.
                • Again in /media/rootfs/etc/fstab I use /dev/sdb1

                Regards

              2. I entirely formatted the SD card, and I went over the whole process once again (making sure I copied the MLO first etc), but I got to the same point (seeing the "C's")

                Yes, your sfdisk settings are ok in CentOS (the 1st partition is created with the boot flag set).

                The only remarkable things are that:

                • I commented out all the apt-get stuff in ./dtc.sh making sure I had the corresponding CentOS packages installed. Eventually, the script complained about the git branch --list option (strange though it might seem, this option doesn't exist in the CentOS git package) so I tried -a but finally removed it.
                • Again in /media/rootfs/etc/fstab I use /dev/sdb1

                Regards

              3. I entirely formatted the SD card, and I went over the whole process once again (making sure I copied the MLO first etc), but I got to the same point (seeing the "C's")

                Yes, your sfdisk settings are ok in CentOS (the 1st partition is created with the boot flag set).

                The only remarkable things are that:
                - I commented out all the apt-get stuff in ./dtc.sh making sure I had the corresponding CentOS packages installed. Eventually, the script complained about the git branch --list option (strange though it might seem, this option doesn't exist in the CentOS git package) so I tried -a but finally removed it.
                - Again in /media/rootfs/etc/fstab I use /dev/sdb1

                Regards

  38. Robert,

    I'm currently working on an embedded device for commercial use and working on using roots instead of a distro rootfs. It has a few quirks and not exactly sys.V init.d but boots in less than 2 seconds instead of over 10. Would you be interested in starting a wiki page on adapting rootfs or is this something that should be discussed with the rootfs folks?

    Cheers. Gilles.

    1. "rootfs" I'm not familiar with that.  With the Wheezy image you can enable systemd and it does speed up boot time. https://wiki.debian.org/systemd 

      Regards,

  39. Robert, please allow me to ask a stupid question because I am still so confused with repos and proper places to get things. Ususally, a board would have a git repo somewhere (a git with a branch that evolves in parallel with the kernel master) and you are doing a great job at making sure that the kernel can have patches to make it work but that's not exactly a git branch we can checkout, update (without re-applying all the patches, so no branch continuity) and also no make menuconfig/make uImage options. Then there are places like http://wiki.beyondlogic.org/index.php/BeagleBoneBlack_Building_Kernel which appear to are maintained out of some other (beagle board) branch and different toolchains etc... Can you recommend of ONE beaglebone git repo WITH a continuous branch that developers like me could re-brach from and then, once in a while we could pull the branch with latest changes and use rebase to merge with our changes allowing for some continuity of development.

    And, it seems as you are really playing with the bleeding edge of the latest repo. Could you recommend ONE git repo (even if behind by a few tags) which would have one continuous beaglebone branch which parallels the kernel. One git repo, people like me could follow to stay up to date, rather than re-applying all the patches every time and re-building the whole kernel every time (not to mention integrating our changes back into Kconfigs/Makefiles every time). 

    I'd appreciate any input.

    Thanks,

    Gilles

    .

     

    1. Hi Gilles,

      For the BeagleBone project the master branch is: http://github.com/beagleboard/kernel/ (it's also a set of patches.)

      Considering right now we are always re-basing, I have no plans to push out a continuous branch, (your welcome to "push" the KERNEL directory yourself and maintain it..)  So until the "overlay" stuff is pushed mainline, followed by the "capemanager" and the "cape" firmware, the current patch system is just easier for me to maintain/rebase.  Otherwise we could go back to the days where we stayed on 2.6.32 forever..

      Regards,

      1. Robert,

         

        Considering right now we are always re-basing, I have no plans to push out a continuous branch, (your welcome to "push" the KERNEL directory yourself and maintain it..)

        That's great to know. I actually need to add support for a DAC121C085 (ADI) a ADS7823 (D/A) and a triple LED PWM driver NCP5623 but those kernel folks scare me I don't want to push it there so I'm doing it locally. Although there is no reason for these drivers to be architecture specific being I2C all 3 of them.

        So until the "overlay" stuff is pushed mainline, followed by the "capemanager" and the "cape" firmware, the current patch system is just easier for me to maintain/rebase.  Otherwise we could go back to the days where we stayed on 2.6.32 forever..

        Good point. It's thanks to you we're  even running 3.8.

         

        Let me ask you a question off subject, Is it mandatory to use the linario gcc 4.8 pre-release? I'm getting lost with all my VM's and I'm trying to start a fresh build on a VM I already have an older copy installed via apt-get install gcc-arm-linux-gnueabi

        ${CC}gcc --version

        arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
        Copyright (C) 2011 Free Software Foundation, Inc.
        This is free software; see the source for copying conditions. There is NO
        warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
         

        I guess I'll know the answer to this question soon but is it necessary to use the 4.8 pre-release as opposed to the 4.6 which (at least for u-boot) seemed to work really well. I guess I'll know soon, starting the kernel cross compile now using 4.6.3 stable

         

        Thanks,

        Gilles

        .

         

        1. Hi Gilles,

          If it helps, one of my co-workers just reminded me I did push out a branch for his Android build a couple weeks ago:

          https://github.com/eewiki/linux-android/tree/3.8.13-bone28

          and since i'm pretty much done with 3.8.x, well unless a big regression hits before we get 3.12.x in shape, it shouldn't change, and it might help you guys out.

          I actually run Debian Testing on all my development machines so I don't have access to ubuntu's gnueabi cross compiler (minus vm's i use for testing..), but you should not see any issues with that version.  Most of this wiki page assumes very little prior knowledge, so I've been trying to walk users thru each step, which assumes they have a fresh install with no development packages.

          edit: just a heads up, after v3.12.x, some users will have to upgrade gcc/binutils, as an example: http://www.spinics.net/lists/arm-kernel/msg284657.html

          Regards,

  40. Robert,

    I hate to ask such a noob question but I'm fighting a u-boot uEnv problem for tftp loading of the image+ftd and I'm really missing what the issue is. So I have a zImage and fdt built that work when loaded from the MMC. Actually, here's the boot console it produces for reference:

     

    U-Boot 2013.07-dirty (Nov 05 2013 - 13:48:31)
    I2C: ready
    DRAM: 256 MiB
    WARNING: Caches not enabled
    NAND: 0 MiB
    MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
    *** Warning - readenv() failed, using default environment
    musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
    musb-hdrc: MHDRC RTL version 2.0
    musb-hdrc: setup fifo_mode 4
    musb-hdrc: 28/31 max ep, 16384/16384 memory
    USB Peripheral mode controller at 47401000 using PIO, IRQ 0
    musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
    musb-hdrc: MHDRC RTL version 2.0
    musb-hdrc: setup fifo_mode 4
    musb-hdrc: 28/31 max ep, 16384/16384 memory
    USB Host mode controller at 47401800 using PIO, IRQ 0
    Net: <ethaddr> not set. Validating first E-fuse MAC
    cpsw, usb_ether
    Hit any key to stop autoboot: 0
    gpio: pin 53 (gpio 53) value is 1
    mmc0 is current device
    gpio: pin 54 (gpio 54) value is 1
    SD/MMC found on device 0
    reading uEnv.txt
    1201 bytes read in 4 ms (293 KiB/s)
    Importing environment from mmc ...
    gpio: pin 55 (gpio 55) value is 1
    Checking if uenvcmd is set ...
    gpio: pin 56 (gpio 56) value is 1
    Running uenvcmd ...
    reading zImage
    3332976 bytes read in 386 ms (8.2 MiB/s)
    reading /dtbs/am335x-bone.dtb
    24465 bytes read in 10 ms (2.3 MiB/s)
    Kernel image @ 0x80200000 [ 0x000000 - 0x32db70 ]
    ## Flattened Device Tree blob at 80f80000
    Booting using the fdt blob at 0x80f80000
    Using Device Tree in place at 80f80000, end 80f88f90
    Starting kernel ...
    Uncompressing Linux... done, booting the kernel.
    Debian GNU/Linux 7 arm ttyO0
    arm login:

     

    Then I tried to change uEnv to load that using tftp (both the zImage and the dtb. Even though it looks like both files are downloaded, it's missing something and I must claim ignorance on the problem. Here's the console boot log:

     

    U-Boot 2013.07-dirty (Nov 05 2013 - 13:48:31)
    I2C: ready
    DRAM: 256 MiB
    WARNING: Caches not enabled
    NAND: 0 MiB
    MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
    *** Warning - readenv() failed, using default environment
    musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
    musb-hdrc: MHDRC RTL version 2.0
    musb-hdrc: setup fifo_mode 4
    musb-hdrc: 28/31 max ep, 16384/16384 memory
    USB Peripheral mode controller at 47401000 using PIO, IRQ 0
    musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
    musb-hdrc: MHDRC RTL version 2.0
    musb-hdrc: setup fifo_mode 4
    musb-hdrc: 28/31 max ep, 16384/16384 memory
    USB Host mode controller at 47401800 using PIO, IRQ 0
    Net: <ethaddr> not set. Validating first E-fuse MAC
    cpsw, usb_ether
    Hit any key to stop autoboot: 0
    gpio: pin 53 (gpio 53) value is 1
    mmc0 is current device
    gpio: pin 54 (gpio 54) value is 1
    SD/MMC found on device 0
    reading uEnv.txt
    731 bytes read in 4 ms (177.7 KiB/s)
    Importing environment from mmc ...
    gpio: pin 55 (gpio 55) value is 1
    Checking if uenvcmd is set ...
    gpio: pin 56 (gpio 56) value is 1
    Running uenvcmd ...
    Booting from network ...
    cpsw Waiting for PHY auto negotiation to complete. done
    link up on port 0, speed 100, full duplex
    Using cpsw device
    TFTP from server 192.168.60.210; our IP address is 192.168.60.99
    Filename 'zImage'.
    Load address: 0x80200000
    Loading: #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #################################################################
    #
    347.7 KiB/s
    done
    Bytes transferred = 3332976 (32db70 hex)
    link up on port 0, speed 100, full duplex
    Using cpsw device
    TFTP from server 192.168.60.210; our IP address is 192.168.60.99
    Filename 'am335x-bone.dtb'.
    Load address: 0x80f80000
    Loading: #####
    231.4 KiB/s
    done
    Bytes transferred = 24465 (5f91 hex)
    Kernel image @ 0x80200000 [ 0x000000 - 0x32db70 ]
    Starting kernel ...
    Uncompressing Linux... done, booting the kernel.
    Error: unrecognized/unsupported machine ID (r1 = 0x00000e05).
    Available machine support:
    ID (hex) NAME
    ffffffff Generic OMAP4 (Flattened Device Tree)
    ffffffff Generic AM33XX (Flattened Device Tree)
    ffffffff Generic OMAP3-GP (Flattened Device Tree)
    ffffffff Generic OMAP3 (Flattened Device Tree)
    0000060a OMAP3 Beagle Board
    00000a9d IGEP OMAP3 module
    00000928 IGEP v2 board
    00000ae7 OMAP4 Panda board
    Please check your kernel config and/or bootloader.

     

    The only thing I changed in the uEnv.txt was to cause the load image and load dtb from tftp. Here's my uEnv.txt. Would you mind pointing out if you see something glaringly wrong with it? I'm not 100% comfortable with the dtb. Still trying to decrypt how it works (I'm a nostalgic of the platform board files pre-dtb).

     

    autoload=no
    hostname=SDM50_4458
    console=ttyO0,115200n8
    bootfile=zImage
    #fdtfile=am335x-boneblack.dtb
    ipaddr=192.168.60.99
    serverip=192.168.60.210
    netmask=255.255.255.0
    getway=192.168.60.1

    # RootFS
    mmcroot=/dev/mmcblk0p2 ro
    mmcrootfstype=ext4 rootwait fixrtc

    bootargs console=${console} root=${mmcroot} rootfstype=${mmcrootfstype}
    ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:off
    static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:off

    tftp_image=tftp ${loadaddr} ${bootfile};
    tftp_dtbfile=tftp ${fdtaddr} ${fdtfile};
    netboot=echo Booting from network ...; run tftp_image; run tftp_dtbfile;
    uenvcmd=run netboot; bootz ${loadaddr}

    Hate to as such a noob question. But the few posts I've seen on google (some by you) have to do with switching from platform to dtb. In this case I'm booting the exact same zImage and dtb files.

     

    Actually, allow me another question. How are the load addresses chosen? I see that the uBoot already has these addresses defined in the default parameters and I also see that your system.sh has a ZRELADDR=0x80008000 un-commented out which doesn't match the address at which the zImage is loaded bt uBoot (thought it works from mmc).

     

    And if you don't mind, one very last question. My current job is to get a home-made LCD display hardware (with no Serial EE cape signature) to be recognized. I know somehow I'll need to change the dtb to force the LCD pins to be in LCD mode without the serial EEProm to tell the cape manager how to do it. Could you recommend a good  howto about this. I'm fighting a lot of help about how to change a GPIO to a  LED and other simple stuff like that, but the display's just a tad more complicated. I must admit I miss the days of the platform boards (even thought it caused git updates to be a nightmare - but at least, there was one C file where the entire hardware got defined). Well it looks like DTBs are the same way, I just need to get used to it. The part I don't understand now is the relationship between slots and cape manager code.

     

    Thanks for being such a helpful pillar in this community!

     

    Cheers.

    Gilles

    .

     

    1. You forgot the dtb address in your uenvcmd..

      uenvcmd=run netboot; bootz ${loadaddr}

      Change it too..

      uenvcmd=run netboot; bootz ${loadaddr} - ${fdtaddr}

      Regards,

       

      1. Robert,

        You forgot the dtb address in your uenvcmd..

        That I did. Thanks. Though, now, it just seems stuck in a crash/reset loop. I am trying to get it to load the dtb from tftp (more than the image) so I can force add support for home made "capes" (no serial EE signatures).

        I'll keep on debugging... allow me to bug you again if I get stuck?

        Thanks so much for the help.

        Gilles

        1. If loading off mmc works but ethernet doesn't, sounds like a network bug in u-boot..

          Regards,

          1. Hi Robert,

            I got it working. I knew the network was working because you could see the hashtags during the download of the zImage and bootz did decompress it suggesting the file was not corrupt. No in this case, it's the monstrosity of u-boot that got me.  Anyway I'm sharing my uEnv.txt here in case someone tries to do the same thing. With this uEnv you can local or remote load both the image and/or DT. It is really convenient to just recompile a DT and just reset the board to test it via tftp.

            This said, what a monster this u-boot. I feel like the days of embedded systems are gone with this amalgam of conditional code testing for whatever hardware it's running on and trying to make decisions on which dt or mmc to use. I much prefer the simplicity of letting me define things in uEnv. After all, if one doesn't know which DT file to use... anyway, I can see how this could be helpful testing one code base on a a multitude of hardwares.

            So here the working uEnv. One can select independently to load the kernel/dt via either mmc or tftp (just uncomment dtbfile for any other hardware, u-boot will figure our which one to use). In the following example, I'm loading the kernel (which is larger and not changing in my case) from the mmc and the DTB from tftp.

             

            autoload=no
            hostname=SDM50_4458
            console=ttyO2,115200n8
            
            bootfile=zImage
            fdtfile=am335x-bone.dtb
            
            ipaddr=192.168.60.99
            serverip=192.168.60.210
            netmask=255.255.255.0
            getway=192.168.60.1
            
            
            # define rootfs
            mmcroot=/dev/mmcblk0p2 ro
            mmcrootfstype=ext4 rootwait fixrtc
            setbootargs=setenv bootargs console=${console} root=${mmcroot} rootfstype=${mmcrootfstype}
            
            
            # Select how to load files (mmc or tftp)
            #----------------------------------------
            loadmode_kernel=mmc
            loadmode_devtree=tftp
            
            
            
            # NO NEED TO CHANGE ANYTHING BELOW THIS POINT
            #---------------------------------------------
            ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:off
            static_ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:off
            mmc__zimage=echo Loading image from mmc...; load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bootfile}
            ftp__zimage=echo Loading image from tftp...; tftp ${loadaddr} ${bootfile}
            mmc__fdt=echo Loadng DT from mmc...; load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile}
            ftp__fdt=echo Loading DT from tftp...; tftp ${fdtaddr} ${fdtfile}
            load__image=if test $loadmode_kernel = tftp; then run ftp__zimage; fi; if test $loadmode_kernel = mmc; then run mmc__zimage; fi;
            load__fdt=if test $loadmode_devtree = tftp; then run ftp__fdt; fi; if test $loadmode_devtree = mmc; then run mmc__fdt; fi;
            
            
            uenvcmd=run load__image; run load__fdt; run setbootargs; bootz ${loadaddr} - ${fdtaddr}

             

            Cheers,

            Gilles

            .

  41. I am trying to build an SD card for the Beaglebone White with the 3.2 branch. Our application runs fine on this branch, we just need to make a small change to the u-boot code.

     

    I followed the recipe (a few times now!) but I get the following u-boot  error: ## Error: "loaduimage" not defined every time. Here is the full listing: http://pastebin.com/CjF9LYD3.

    Here is the output from printenv: http://pastebin.com/043p7ztj. Sure enough, loaduimage is not defined. What should it be and where do I define it?

    Here is the contents of the uEnv.txt: http://pastebin.com/iYhEBwXc

    fatls shows the following:

    U-Boot# fatls mmc 0:1
    104416 mlo
    365528 u-boot.img
    335 uenv.txt
    2714688 zimage
    337 uenv.txt~

    5 file(s), 0 dir(s)

    This is surely a dumb omission on my part but can you please help?

     

    Regards,

    James

     

     

     

     

     

    1. Hi James,

      In uEnv.txt rename loaduimage to loadzimage, I forgot to edit the uEnv.txt instructions after moving to v2013.10, in-which loaduimage was removed..

      Regards,

  42. Thanks Robert. Works fine!

  43. Hi Robert,

     

    First let me thank you for your active involvement. Your comments and answers have been so helpful, I'm sure I'm not the only one who feels this way so thank you.  Then allow me to pick your brain. I'm currently working with your version 3.8.13-bone28 trying to get a rotary encoder to work but it doesn't look like the driver source is compatible with DTB (?).

    Would you know anything about that particular driver? I think I got my dtb override right (despite the lack of examples out there) but judging by the error, it does sound like a driver issue. Would you have any suggestions? I'm attaching the override and the error I get.

     

    dts overlay
      fragment@0 {
        target = <&am33xx_pinmux>;
        __overlay__ {
    [...]
          ba_sdm50_enc_pins: pinmux_sdm50_enc_pins {
            pinctrl-single,pins = <
              0x040 0x2f  /* ROTARY_SIN: gpmc_a0.gpio1_16, INPUT | PULLDIS | MODE7 */
              0x044 0x2f  /* ROTARY_COS: gpmc_a1.gpio1_17, INPUT | PULLDIS | MODE7 */
            >;
          };
        }; /* overlay */
      }; /* fragment */
     
    [...]
      fragment@2 {
        target = <&ocp>;
        __overlay__ {
    
          /* avoid stupid warning */
          #address-cells = <1>;
          #size-cells = <1>;
    
          gpio_rotary {
            compatible = "rotary-encoder";
            pinctrl-names = "default";
            pinctrl-0 = <&ba_sdm50_enc_pins>;
    
            rotary@1 {
              gpios = <&gpio2 16 0x1>, <&gpio2 17 0x1>;
              linux,axis = <0>; /* REL_X */
              rotary-encoder,relative-axis;
            };
          };      
        }; /* overlay */
      }; /* fragment */

     

    Loading the overlay throws the following error

    dmesg load error
    [   61.911458] bone-capemgr bone_capemgr.8: part_number 'BIRDLAND-TEST', version 'N/A'
    [   61.920574] bone-capemgr bone_capemgr.8: slot #4: generic override
    [   61.927142] bone-capemgr bone_capemgr.8: bone: Using override eeprom data at slot 4
    [   61.935204] bone-capemgr bone_capemgr.8: slot #4: 'Override Board Name,00A0,Override Manuf,BIRDLAND-TEST'
    [   61.945504] bone-capemgr bone_capemgr.8: slot #4: Requesting part number/version based 'BIRDLAND-TEST-00A0.dtbo
    [   61.956135] bone-capemgr bone_capemgr.8: slot #4: Requesting firmware 'BIRDLAND-TEST-00A0.dtbo' for board-name 'Override Board Name', versi'
    [   61.972352] bone-capemgr bone_capemgr.8: slot #4: dtbo 'BIRDLAND-TEST-00A0.dtbo' loaded; converting to live tree
    [   61.983942] bone-capemgr bone_capemgr.8: slot #4: #3 overlays
    [   61.995827] input: gpio_keys.10 as /devices/ocp.3/gpio_keys.10/input/input1
    [   62.015860] bone-capemgr bone_capemgr.8: slot #4: Applied #3 overlays.
    [   62.069738] rotary-encoder gpio_rotary.11: unable to request GPIO -2
    [   62.079524] rotary-encoder: probe of gpio_rotary.11 failed with error -22
    
    

     

    Looking at the driver code suggests that it's trying to use GPIOs -2 and -22 (?)

    rotary_encoder.c
        err = gpio_request(pdata->gpio_a, DRV_NAME);
        if (err) {
                 dev_err(&pdev->dev, "unable to request GPIO %d\n",
                         pdata->gpio_a);
                 goto exit_unregister_input;
        } 
    
        err = gpio_request(pdata->gpio_b, DRV_NAME);
        if (err) {
                 dev_err(&pdev->dev, "unable to request GPIO %d\n",
                         pdata->gpio_b);
                 goto exit_unregister_input;
        } 

    Thanks!

    Gilles

    .

  44. I've just compiled kernel 3.8.13-bone32 for the Beaglebone because Alex Rau reported that kernel 3.8.13-bone26 was very close to meeting my real-time spidev requirements with some test code I'd posted to googlegroups.  Took longer than I'd hoped to find time to get back to this project.

    My question is, will a kernel compiled for the Beaglebone work on the BeagleboneBlack and vice-versa if I make the correct uboot/uEnv entries when I set up the SD cards?

    I ask, since as long as I was in the kernel building business today, I also built 3.12.5-bone10.6 for the BeagleboneBlack along with 3.12.5-arm7-x10 for the Pandaboard.

    Any of these boards that can meet the realtime spidev timing requirements of the test code I've posted would let this project move forward since I have all three boards on hand.

     

    1. yes, the same kernel (and microSD image) will work on both bone's.. It's only the default BeagleBone Black's u-boot in eMMC we have to worry about.

      Use the v3.13.x branch for the panda, v3.12.x is simply too broken.

      I doubt your going to see much improvements with your spidev case, your best bet is to use the Machinekit 3.8 xenomai branch.

      Regards,

      1. Great! That will save me some time.  I didn't see v3.13.x listed on the Panda Wiki,

        To get it, do I just change:

        git checkout origin/v3.12.x -b tmp
        to:
        git checkout origin/v3.13.x -b tmp
        after the cd armv7-multiplatform step?
        I was getting ready to make the SD cards, but I'll redo the Panda to 3.13.x if I've guessed correctly or you tell me how.
        (Edit)  Looks like I guessed correctly, and appear to have built 3.13.0-rc4-armv7-x4.2 for the Pandaboard.
  45. Everything seemed to build OK and I thought I'd followed the instructions correctly but my SD card boot is hanging at:

    [    2.411467] ThumbEE CPU extension supported.
    [    2.416075] Registering SWP/SWPB emulation handler
    [    2.423253] registered taskstats version 1
    [    2.483364] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
    [    2.489894] davinci_mdio 4a101000.mdio: detected phy mask fffffffe
    [    2.498256] libphy: 4a101000.mdio: probed
    [    2.502675] davinci_mdio 4a101000.mdio: phy[0]: device 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
    [    2.512952] Detected MACID = d4:94:a1:98:a8:df
    [    2.517884] cpsw 4a100000.ethernet: NAPI disabled
    [    2.526662] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
    [    2.546913] ALSA device list:
    [    2.550130]   No soundcards found.
    [    2.554839] Waiting for root device /dev/mmcblk0p2...

     

    Here is my uEnv.txt file, what have I missed?

    #optargs=

    mmcroot=/dev/mmcblk0p2 ro

    mmcrootfstype=ext4 rootwait fixrtc

     

    #To boot old v3.2.x based kernel enable: (BeagleBone only)

    #uenvcmd=run loadzimage; run mmc_classic_boot

     

    #To boot new v3.8.x/v3.12.x based device tree:

    uenvcmd=run loadzimage; run loadfdt; run mmcargs; bootz ${loadaddr} - ${fdtaddr}

     

    I'm trying to boot 3.8.13-bone32 on the Beagle Bone with Ubuntu 13.10 minimal rootfs.

     

     

    1. With a bit of trial and error I corrected my uEnv.txt file, for 3.8 it only needs:

      #To boot new v3.8.x/v3.12.x based device tree:

      uenvcmd=run loadzimage; run loadfdt; run mmcargs; bootz ${loadaddr} - ${fdtaddr}

       

      Logged in and networking works so I'll have to apt-get a lot of stuff as minimal rootfs isn't kidding, no gcc (sad)

      Did apt-get update ; apt-get upgrade and got 7 updates,   Now onward to getting spidev working and installing gcc and the libraries I need to build my test code.

      The bit with uEnv.txt made the installation instructions not end as well as the previous times.  Perhaps a bit of explanation in the Wiki that the top five lines apply to 3.2 versions and optargs is for Debian rootfs.  Maybe its obvious to y'all but it tripped me up.

       

      1. "minimal" do you run gcc on your network router? (wink)

        uEnv.txt is sup post to be obvious:

        First 3 lines are useful if you 'change' something..

        #optargs=
        #mmcroot=/dev/mmcblk0p2 ro
        #mmcrootfstype=ext4 rootwait fixrtc

        un-comment to boot 3.2:

        #To boot old v3.2.x based kernel enable: (BeagleBone only)
        #uenvcmd=run loadzimage; run mmc_classic_boot

        un-comment to boot 3.8/3.12

        #To boot new v3.8.x/v3.12.x based device tree:
        #uenvcmd=run loadzimage; run loadfdt; run mmcargs; bootz ${loadaddr} - ${fdtaddr}

        Which reminds me, with the new year, it's about time we said goodbye to the old 3.2 based kernel..

        Regards,

        1. I got gcc installed (apt-get install build-essential) and spidev to show up, none of the device tree stuff is anything but confusing at present, I used the BB-SPI0-01-00A0.dts to facilitate trying the Beaglebone Black without interfering with the HDMI stuff.   I was expecting /dev/spidev0.x but got /dev/spidev1.0 so obviously I'm not making head or tails of the device tree stuff, but recipe seemed to work to make /dev/spidev1.0 appear.

          I was unable to duplicate Alex Rau's good spidev timing after compiling  my test code, he said he used 3.8.13-bone26, but by the time I got around to try again last Friday we're building 3.8.13-bone32, regression?  he was mistaken in his report?  I'm missing some system optimization?  As before timing is essentially perfect if the test code calls to write a GPIO pin instead of the spidev write.

          I'm having a problem getting 3.13.0-rc4-armv7-x4.2 on the Pandaboard so I'll see you over there shortly.

  46. Hi there,

    Robert, you seem to be the guy to go to about Linux on BeagleBone. I want to join everyone in saying a huge "thanks" for all that you do.

    I have followed the instructions for the 3.8 branch with an Ubuntu filesystem. Everything seemed to work just fine, but when I boot the beagle bone (white) I never get a login prompt, despite getting lots of output and seemingly booting the kernel. I am connecting via the "screen" command. 

    Here is a pastebin of what I see when I press the reset button. This is consistent with what I see when using a prebuilt image, but in the prebuilt image a login prompt eventually shows up. That is not the case with this freshly built image. 

    http://pastebin.com/DBrfCYTW

    Any ideas?

    Thanks!

    Scott

    1. Hi Scott,

      It looks like you haven't setup the serial login terminal.

      BeagleBone#SerialLogin

      Double check that you typed ttyO0 (O=omap, not 0=zero) then the port zero.

      Regards,

      1. Hi Robert,

        Thanks for the quick feedback. I believe that I followed the instructions on the wiki for that section accurately. Here is my serial.conf:


         

        [brookes@shepherd-ROS-proj ~]$ cat /media/rootfs/etc/init/serial.conf 
        start on stopped rc RUNLEVEL=[2345]
        stop on runlevel [!2345]
         
        respawn
        exec /sbin/getty 115200 ttyO0

         

        Do you see an error? Thank you,

        Scott

        PS - not sure how to make the code blocks you use in your comments

  47. Hello Robert,

    I have compiled the kernel as per instructions given here & i chose to use ubuntu rootfs. I followed all steps of networking & serial login.

    After i put uSD card on BB, its user LEDs are blinking but  BB is not connecting to my windows PC. I cant see any "CircuitoBeaglebone" option in my VM ubuntu machine, though "FTDI Beaglebone" is visible.

    Please help.

    Best Regards,

    Pankaj

    1. Login thru the ftdi usb/serial interface.

      1. Hello Robert,

         

        But for that i will need extra hardware. is int so ?

        From FTDI to serial interface, like one giben in below link

         

        Best Regards,

        Pankaj

        1. The BeagleBone (not Black) has a built-in FTDI usb-serial adapter, just plug in a usb cable into the usb port next to the power plug.

          1. Hello Robert,

             

            I am able to connect now. It showed ttyUSB0 device & using screen tool i am able to connect to it. Since i used ubuntu rootfs i used the given usernam e& password and it was able to login with that.

            Thanks a lot Robert, its working fine now.

             

            Best Regards,

            Pankaj

  48. Hi, I just realized that there is a new rootfs available: debian-7.5-minimal-armhf-2014-07-07.tar.xz

    Robert, can u please explain in short what are the differences to the 2014-05-07 one?

    Is there a reason to change rootfs to the new one?

     

    Reagrds,

    Ben

    1. Just a snapshot refresh, no functional changes.

  49. Hello Rob,

    I have Ubuntu 14.04. 32 bit.

    When compiling u-boot, I get the following error"bad value (armv5) for -march= switch":

    b@station-1:~/Desktop/bb/u-boot$ make ARCH=arm CROSS_COMPILE=${CC}
      GEN     include/autoconf.mk.dep
    cc1: error: bad value (armv5) for -march= switch
      GEN     include/autoconf.mk
    cc1: error: bad value (armv5) for -march= switch
      CHK     include/config/uboot.release
      UPD     include/config/uboot.release
      CHK     include/generated/version_autogenerated.h
      UPD     include/generated/version_autogenerated.h
      CHK     include/generated/timestamp_autogenerated.h
      UPD     include/generated/timestamp_autogenerated.h
      HOSTCC  scripts/basic/fixdep
      CC      lib/asm-offsets.s
    lib/asm-offsets.c:1:0: error: bad value (armv5) for -march= switch
     /*
     ^
    make[1]: *** [lib/asm-offsets.s] Error 1
    make: *** [prepare0] Error 2
    Thank you!

     

     

     

     

    1. Hi,

      You get that error when you don't properly set CC as shown:

      BeagleBone#ARMCrossCompiler:GCC

      Regards,

      1. Fixed. Thank you!

  50. Is it possible to flash the image I've created to NAND? So far I can boot perfectly with Robert's instructions from the SDcard.

    1. It can be trivial, depending on what type of NAND. (eMMC/NAND/etc?)

      Regards,

      1. Sorry I was not clear Robert. I meant to the eMMC. I currently have Angstrom on the eMMC and Ubuntu on the SDCard.

         

          1. Hmm.. ok. I missed that step.

            Now I have uEnv.txt in my SDCard under boot/

            Do I just hold the boot(s2) button while powering up and hope that it flashes? It does not for me as yet... or I may have missed a step.

            I tried running "run loadall" at the u-boot problt, but get a not defined error.

            1. Everything on this wiki is manual, with the intent to show you "how to do it"... It's a script, boot up and run it..

              If you want automatic:

              http://beagleboard.org/latest-images

              Which is off-topic for this wiki..

              Regards,

              1. Sorry. I understand. It is copying now.

                The thing is on Firefox BeagleBone Black#eMMC goes to a different link and on Chrome is goes to the right one.

                I have Firefox 31 and I don;t see anything after serial login:

                http://imgur.com/OaN6R1u

                Must be a confluence bug. Thank you for your help again.

                1. Nope, just a user bug. (wink) There's two separate sections, depending on what board you have...

                  BeagleBone

                  BeagleBone Black

                  Regards,

  51. hi there,

    no offense, the time spent and the work you provided is undeniably huge, but comon

    just for instance:

    ------------------------------------------------
    Robert Nelson
    Hi Rajkumar,
    Please reread http://eewiki.net/display/linuxonarm/BeagleBone#BeagleBone-CopyingKernelandrelatedfiles the boot files (zImage/dtb's) need to be installed in the boot partition /media/boot/, not the boot directory on the rootfs partition /media/rootfs/boot/..
    sudo mkdir -p /media/boot/
    sudo mount /dev/sdX1 /media/boot/
    sudo cp -v ./linux-dev/deploy/X.*zImage /media/boot/zImage
    sudo mkdir -p /media/boot/dtbs/
    sudo tar xfv ./linux-dev/deploy/X-dtbs.tar.gz -C /media/boot/dtbs/
    sync
    sudo umount /media/boot
    ------------------------------------------------

    is the exact opposite of what has been explained in the tutorial.

    Would have appreciated to have it corrected.

    Even though the tutorial was not supposed to work, I still got the best result exactly following it, that is:

    uboot starting and the kernel saying the zImage is not found or not valid.

    Now I've been told the .dtb and the uImage have to be put into the boot partition and I dont even get

    uboot started now.

    still very few mentions about the uEnv file we dont have a clue of what we are supposed to put in this.

    How can you explain the original boot partition of the beaglebone is only made of a .dtb, a uImage and a uEnv

    only containing "optargs=run_hardware_tests quiet" ?

    how are we supposed to come up with these complex uEnv files as the ones discussed here?

    Im getting tired of these supposed advanced linux boards and their devicetree stupid thing.

    1. No need to rant, do you actually care to show what issue you actually having on bootup? (use pastebin.com)

      BTW, that message was written to Rajkumar on Feb 28, 2013. Things have changed since then, so the comments do NOT always match the "wiki/tutorial"

      Always follow the "wiki/tutorial", as those directions are always up to date.

      I'm confused about your uEnv.txt comment, as this guide only has one variable added to uEnv.txt:

      BeagleBone#Create/boot/uEnv.txt

      such that it will find the kernel image. 

      (unless you want to enable systemd, as that takes another kernel hint: BeagleBone#Debian/boot/uEnv.txt(enablesystemd) )

      Regards,

  52. yes I understood the hint about enabling systemd,

    so you mean I should stick to the uEnv made of

    sudo sh -c "echo 'uname_r=${kernel_version}' > /media/rootfs/boot/uEnv.txt"
    sudo sh -c "echo 'cmdline=quiet init=/lib/systemd/systemd' >> /media/rootfs/boot/uEnv.txt"
    and also to putting the uImage in the rootfs?
    Is the discussion I quoted deprecated?
    1. Yes, the discussion you quoted was long ago deprecated.

      I've rewritten the u-boot script, such that you ONLY have to pass it what kernel version you want to boot, via the uEnv.txt file. u-boot will search the microSD for all the boot files needed.  It'll also clearly complain if something is missing.

      uImage is also not needed.

      BTW, uImage usually only comes up in conversation, if your dealing with an old u-boot/bootloader in flash/emmc. Which means you are either using a beaglebone black. Which has a completely separate wiki (1) page, along with directions to work around old bootloadaders in flash/emmc (2).  Or you didn't build the u-boot/bootloader as specified (3):

      1: BeagleBone Black

      2: BeagleBone Black#DealingwitholdBootloaderineMMC

      3: BeagleBone#Bootloader:U-Boot

      Regards,

       

  53. Hello Robert,

        Thank you for the excellent wiki, I was able to build 3.8 and 3.15 kernels easily.  However, it seems that only the 3.8 patch set includes support for the cape manager and more specifically the Logibone FPGA cape.  Is support for that being dropped going forward?  I have not fully debugged all the differences, but the FPGA loader utility no longer works on 3.15.  Also I noticed the I2C bus enumeration changed (what was /dev/i2c1 became /dev/i2c2 in 3.15).

     

    Thank you,

    Justin

    1. I read the BeagleBone Black thread and basically got the answers.  Any news on moving the cape manager forward?

      Thanks,

      Justin

       

  54. hi guys,

    I successfully build the system following the this tutorial (great job!), but I do have one problem. I want to include D_CAN modules for CAN communication and I take care to configure the kernel correctly

    #

    # CAN Device Drivers

    #

    CONFIG_CAN_VCAN=y

    CONFIG_CAN_SLCAN=y

    CONFIG_CAN_DEV=y

    CONFIG_CAN_CALC_BITTIMING=y

    CONFIG_CAN_LEDS=y

    CONFIG_CAN_TI_HECC=y

    CONFIG_CAN_FLEXCAN=y

    CONFIG_CAN_GRCAN=y

    CONFIG_CAN_RCAR=y

    CONFIG_CAN_SJA1000=y

    CONFIG_CAN_SJA1000_ISA=m

    # CONFIG_CAN_SJA1000_PLATFORM is not set

    CONFIG_CAN_C_CAN=y

    CONFIG_CAN_C_CAN_PLATFORM=y

    CONFIG_CAN_CC770=y

    CONFIG_CAN_CC770_ISA=y

    CONFIG_CAN_CC770_PLATFORM=y

    but the CAN modules are not included in the build. Any idea why?

    Thanks,

    Atanasko