[beagleboard] Re: [beagle-alpha] Beagle Entertainment System (BES) on framebuffer

[Andrew Henderson]

X11 is linked in because I apt-get the SDL 1.2 library, which has X11 as a 
package dependency. I don't actually use X11 for anything. If you were to 
build a bare-bones SDL 1.2 from source, you could remove the need to link 
in X11.


FYI, I have spoken with Ryan Gordon (one of the SDL maintainers) about a 
BeagleBone target in SDL 2.x. Raspberry Pi already has its own target, and 
I thought that having a BB target providing similar functionality would 
make things simple for everyone trying to get GLES, audio, input, etc. 
working on the platform. But, that discussion was maybe two years ago, 
when SGX support was in one kernel version and not in the next, HDMI audio 
was squirrelly, etc. Ryan left the door open for us to provide a patch for 
SDL 2.0 whenever we'd like, though, so it might be a good time to revisit 
that if the kernel and Debian filesystem are where they need to be to 
support such things.


Andrew


On Fri, 15 Sep 2017, Jason Kridner wrote:


Awesome, thanks.

It seems you are still linking in libX11. Is that right?


--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/alpine.DEB.2.20.1709151201030.31636%40gamehenge.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [beagle-alpha] Beagle Entertainment System (BES) on framebuffer

[Andrew Henderson]

BES is built without X, as it uses SGX OpenGL ES on the framebuffer. SDL 
1.2 initializes for ALSA audio, input via the framebuffer (i.e. keyboard

input) and Linux joystick devices, and video using full-screen 16 BPP with
the framebuffer target. I fill the framebuffer with all black pixels and
then ignore it (so no SDL_Flip() or SDL_UpdateRect() calls). The emulators 
render into SDL_Surfaces, and I take the pixel data of these surfaces, 
copy them into GLES textures, and then map those textures onto a pair of 
triangles covering the entire screen. This gives me scaling and bilinear 
filtering to any size display without requiring a software scaler.


Whenever I'm going to process the SDL event loop, I first check the 
BBB-specific inputs (PRU gamepads or GPIO inputs), generate the 
appropriate SDL_Events to represent input events, and then add those key 
events into the SDL event queue as key events. Then I do the SDL event 
loop and process key and joystick events as I normally would. This makes 
the hardware-specific inputs appear as keypresses to the emulators and
front-end GUI. The block of GPIOs I use for the 12 gamepad inputs (4 
d-pad, 8 buttons, 1 pause button) are the pins on the P8 header that 
aren't blocked by the LCD3 cape. If you want to change the GPIOs that are 
used, the GPIO numbers are stored in BES's SQL database.


As for your EGL error, I suspect it is a change in datatype definitions.
I've had a few people mention similar things regarding EGL. Don't install
the Mesa headers. Or rather, the Mesa OpenGL headers should be OK, but the
EGL ones will not be. Instead, point to the reference implementation
headers from Khronos:

https://www.khronos.org/registry/EGL/api/EGL/

An apt-get of the Mesa EGL headers will get headers intended to run on an
X11-based system. Look at the Khronos API reference for 
eglCreateWindowSurface():


https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglCreateWindowSurface.xhtml

The third parameter is of type NativeWindowType, which is intended to be a
"placeholder" for the proper datatype. Now look at the Mesa and Khronos
reference headers:

https://github.com/mesa3d/mesa/blob/master/include/EGL/egl.h
https://www.khronos.org/registry/EGL/api/EGL/egl.h

These two list the third parameter as having the type EGLNativeWindowType.
As the API changes, it must remain binary compatible with older versions
of the GLES libraries. The actual datatype of EGLNativeWindowType varies a
lot depending upon the particular platform you are working on, and the
Mesa and Khronos reference implementations differ in that regard:

https://github.com/mesa3d/mesa/blob/master/include/EGL/eglplatform.h
https://www.khronos.org/registry/EGL/api/EGL/eglplatform.h

So, use the Khronos EGL headers, not the ones from Mesa, and you should
get a clean build. Alternatively, you can force a cast on that parameter 
and it will probably work for you OK.


I've been meaning to get around to putting some fixes into BES and clean 
up its code in the next month or two, so I'll pull in any patches that you 
want to throw my way.


Andrew


On Fri, 15 Sep 2017, Jason Kridner wrote:


Andrew and all,
I'm looking to compile https://github.com/hendersa/bes for an Adafruit 1.8"
SPI LCD and GPIO buttons.

I'm trying to integrate on top of Debian Jessie or Stretch. I plan to make
the PRU updates to use remote-proc as that change looks pretty easy.

Do you compile BES without X11? I'm thinking that might be my issue, but I'm
not sure how the various EGL headers get selected in Debian. 

I'm getting the following error:
g++ -I. -Ines -Isqlite -c -O3 -fomit-frame-pointer -pedantic -Wall -W
-Wno-unused-parameter -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT
-DFRAMESKIP -DNO_FFMPEG -DFINAL_VERSION -DSDL -DNO_LINK -DC_CORE -DNO_ASM
-DZLIB -DHAVE_LIBPNG -DHAVE_MKSTEMP -DHAVE_STRINGS_H -DHAVE_SYS_IOCTL_H
-DHAVE_STDINT_H  eglSetup.cpp -o eglSetup.o
eglSetup.cpp: In function ‘int EGLInitialize()’:
eglSetup.cpp:123:64: error: invalid conversion from ‘EGLSurface {aka void*}’
to ‘EGLNativeWindowType {aka long unsigned int}’ [-fpermissive]
     surface = eglCreateWindowSurface(display, config, window, 0);
                                                                ^
Makefile:75: recipe for target 'eglSetup.o' failed
make: *** [eglSetup.o] Error 1

Here's what I have in my include file:
/usr/include/EGL/egl.h:EGLAPI EGLSurface EGLAPIENTRY eglCreateWindowSurface
(EGLDisplay dpy, EGLConfig config, EGLNativeWindowType win, const EGLint
*attrib_list);
/usr/include/EGL/egl.h:typedef void *EGLSurface;
/usr/include/EGL/eglplatform.h:typedef EGLNativeWindowType
 NativeWindowType;

I'm thinking I can just adjust the BES source to use (NativeWindow)X, where
X is my framebuffer,
but https://e2e.ti.com/support/embedded/linux/f/354/t/116795 points to
problems specifying any framebuffer other than 0. Is hacking on eglSetup.cpp
what I should be doing or will it be fruitless?

Regards,
Jason
--
https://beagleboard.org/about

--
Y

[beagleboard] Re: BBB android

[Andrew Henderson]

There are two parts to this: getting the i2c-tools source package into your 
Android source tree and telling the build process to include that package 
for your device. Since i2c-tools isn't in the XML manifest for A4B, you'll 
have to manually grab the i2c-tool source and put it in the correct place. 
You could also fork the XML manifest for A4B, add an entry for i2c-tools in 
there, and then point the repo tool to your forked manifest. Whichever way 
you do it, there is a copy of the i2c-tools source package here: 
https://github.com/hendersa/bbbandroid-external-i2c_tools

Assuming that you didn't fork the manifest XML and want to manually add it 
in, use repo to check out all of the A4B Android code like you normally 
would. Find the "external" directory in your Android source tree that hosts 
all of the external source code packages. Git clone the i2c-tools repo into 
that external directory. rename the "bbbandroid-external-i2c_tools" 
directory you just checked out to "i2c-tools".

Once you have the code in place in the "external" directory , you'll need 
to make sure that external source package is built for your device. Take a 
look at: 
https://github.com/csimmonds/a4b-beagleboneblack/blob/master/device.mk

After running repo and fetching all of the various source packages, this 
device.mk file will be living somewhere in your Android source tree. I 
forget its exact location where it ends up, but you can grep around and 
find it. Once you find it, add "i2c-tools" to the "PRODUCT_PACKAGES" list 
to include it in the build process. Take a look at the bottom of the 
BBBAndroid device.mk file to see an example: 
https://github.com/hendersa/bbbandroid-vendor-ti-beagleboneblack-aosp/blob/master/device.mk
 

Now build Android as you normally would, and i2c-tools will be in your 
system. This same process can be used to add in other external source 
packages into Android.

Andrew  

On Friday, September 1, 2017 at 9:57:06 AM UTC-4, sskc.k...@gmail.com wrote:
>
> The later android builds on Android4Beagle dont have i2c tools i presume. 
> How do we make a build with i2c tools?
>
>
> On Tuesday, 21 February 2017 21:33:35 UTC+5:30, Andrew Henderson wrote:
>>
>> The limiting factor in supporting Android on the BBB with newer kernels 
>> is support for SGX OpenGL ES. Newer Androids rely heavily on GLES for 
>> rendering. You can always fall back to PixelFlinger for software rendering, 
>> but a variety of apps will not work (or will work very slowly) when you use 
>> software rendering. For post 3.2 kernels, there are additional Android 
>> graphics libraries that are missing that you need for accelerated GLES. 
>> These libraries are proprietary and must be supplied by TI. Unfortunately, 
>> they are not supported any more, as support for the Android Graphics SDK 
>> has ended.   
>>
>> For non-GLES builds, I recommend that you look at Android4Beagle: 
>> http://www.2net.co.uk/android4beagle.html
>>
>> Andrew
>>
>> On Tuesday, February 14, 2017 at 1:01:40 PM UTC-5, Harshdeep Dhatt wrote:
>>>
>>> Is Android being actively supported on BBB? I found resources online 
>>> which said Android 4.4 was ported sometime back - 
>>> http://www.2net.co.uk/tutorial/android-4.4-beaglebone
>>>
>>> Does it make sense to support the latest Android versions on the BBB? is 
>>> there an audience for such a project? I know its not straightforward to 
>>> port android to latest bbb kernels. But i just want to know if there is 
>>> such a need. Then maybe the effort is worth the pain :)
>>>
>>> Thanks,
>>> Harshdeep
>>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/146f8202-2293-4b5f-a0c6-12f272c92219%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBB android

[Andrew Henderson]

The limiting factor in supporting Android on the BBB with newer kernels is 
support for SGX OpenGL ES. Newer Androids rely heavily on GLES for 
rendering. You can always fall back to PixelFlinger for software rendering, 
but a variety of apps will not work (or will work very slowly) when you use 
software rendering. For post 3.2 kernels, there are additional Android 
graphics libraries that are missing that you need for accelerated GLES. 
These libraries are proprietary and must be supplied by TI. Unfortunately, 
they are not supported any more, as support for the Android Graphics SDK 
has ended.   

For non-GLES builds, I recommend that you look at 
Android4Beagle: http://www.2net.co.uk/android4beagle.html

Andrew

On Tuesday, February 14, 2017 at 1:01:40 PM UTC-5, Harshdeep Dhatt wrote:
>
> Is Android being actively supported on BBB? I found resources online which 
> said Android 4.4 was ported sometime back - 
> http://www.2net.co.uk/tutorial/android-4.4-beaglebone
>
> Does it make sense to support the latest Android versions on the BBB? is 
> there an audience for such a project? I know its not straightforward to 
> port android to latest bbb kernels. But i just want to know if there is 
> such a need. Then maybe the effort is worth the pain :)
>
> Thanks,
> Harshdeep
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/417ee533-cf3d-4977-9233-28331f1514ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BES v0.8 does not recognize the USB Gamepad

[Andrew Henderson]

There are a number of reasons why you might be having trouble. Your 
original link to your gamepad pointed to your order, requiring that I enter 
your Aliexpress login information to view it. I pulled the gamepad product 
ID out of the URL and came to this product page: 
https://www.aliexpress.com/item/Retro-Super-for-Nintendo-SNES-USB-Controller-for-PC-for-MAC-Controllers-SEALED/32668671882.html

I see a lot of messages in your log about the USB OTG driver. Are you 
powering your BBB via a 5 volt, 2 amp power supply, or are you using the 
USB cable to power it? It looks like you are using the USB cable to power 
it, but you must use a power supply. Super low-cost USB devices like this 
may also be pretty buggy themselves, making them not work with the generic 
Linux USB HID gamepad driver.

Andrew
 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/17945290-5e9b-4f6b-8966-5ba2f837e191%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BES v0.8 does not recognize the USB Gamepad

[Andrew Henderson]

Hello there. I apologize for not responding sooner, as I have been very 
busy at work for the past few days and I have something like 600 mails in 
my inbox, waiting for a response.

The problem you are seeing is not because of your USB gamepad, but rather 
because you do not have the SNES gamepad interface circuitry attached. This 
causes there to be two "phantom" gamepads that BES sees as having every 
button pressed at once. This selects the first game on the GUI and then 
triggers the pause combo once in-game.

There is a simple hardware workaround for this issue: pull pins P9.12 and 
P9.14 high (3.3v). You can do this by connecting P9.12 to P9.4 and P9.14 to 
P9.3, as both P9.3 and P9.4 supply 3.3v. Like this: 
http://i.imgur.com/4C4Jrb1.jpg

Sorry for the inconvenience.

Andrew
 

On Wednesday, February 1, 2017 at 4:53:13 PM UTC-5, yol...@gmail.com wrote:
>
> Now, I have been trying to find out what it is happening with the BES 
> after flashing the v0.8 in a new uSD card.
>
> The main issue is with the USB controller 
> ,
>  
> let me explain what I have found.
>
> Just flashed the uSD, the BBB boots up perfectly, shows the @IP, and I can 
> connect through the web server. That is fine.
> Now, the steps I did were:
>
>1. Upload some ROMs to BBB. Meanwhile, I uploaded the ROMs, the screen 
>automatically change to 'PAUSE' screen. 
>2. I removed the USB gamepad (it neither work), and restart the BBB. 
>Here, there is no time to watch which ROMs are in the uSD, as screens 
>changes to 'PAUSE' automatically.
>3. Web server is out of business because of previous step, I can not 
>connect to it anymore.
>4. Checked in *Windows* the vendor ID and other parameters from the 
>USB gamepad. With 'joy.cpl' I can check the USB Gamepad is working fine.
>5. Format again the uSD, reflashes the BES v0.8, and without upload 
>any ROMs, modify the controller #1 buttons configuration with the one 
>obtain from 'joy.cpl'.
>6. Reboot with USB gamepad connected the BBB. Connect BBB through ssh, 
>check with 'dmesg' and 'lsusb' the USB devices. The USB gamepad is not 
>shown, it has not been detected.
>7. Unplug the USB gamepad, BBB and its ethernet still works.
>8. Plug again the USB gamepad, ethernet goes down, then nor ssh 
>neither the web browser works.
>
> Please, find attached a document with the outputs of the different 
> commands I tested, and also the VendorID information from Windows. Maybe, 
> you can figure out what it is happening.
>
> Does anyone knows how can I force the system to detect the USB gamepad? Is 
> it possible to add support for this USB gamepad?
>
> Thanks in advance.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/b1d590df-57c2-4a48-b30f-668c6b4b509a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

OK, this is starting to make more sense. 1920x1080 at 60 Hz is not a 
supported mode for the BBB. I've seen screen shearing on 1920x1080 at 24 Hz 
before with OpenGL ES on 3.14 with single buffering before. My suggestion 
is to use the "video=" parameter to set a supported resolution lower than 
1920x1080 and see how well that works for you. Here is a list of the 
supported modes: http://elinux.org/Beagleboard:BeagleBoneBlack_HDMI

Maybe try 1280x720-16@60, instead.

On Wednesday, March 18, 2015 at 7:02:29 AM UTC-4, Michael Gobbers wrote:
>
> For the video issue I tried changing the video parameter to 
> 1920x1080-16@60 the native resoltion of my display. However, when I did, I 
> did not see anything on the display.
>
> Here is a small video of the display so you get what I mean with flicker. 
> It seems that some video buffer isn't emptied or something as I'm seeing 
> old screens between the one that I should see
> https://youtu.be/me1_O4iaHB8
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

I have not yet tried FunctionFS under 3.14. The only reason it was in the 
3.8 kernel was to support ADB, so you can remove it if you wish. I am 
unfamiliar with that particular error.

On Wednesday, March 18, 2015 at 6:51:03 AM UTC-4, Michael Gobbers wrote:
>
> Hi Andrew,
>
> I retried the 3.14 kernel.
>
> I'm getting the following error:
>
>  WARNING: CPU: 0 PID: 110 at drivers/usb/gadget/f_fs.c:2595 
> ffs_ep0_write+0x44d/0x474()
>
> [  149.939235] Modules linked in:
>
> [  149.942448] CPU: 0 PID: 110 Comm: adbd Tainted: GW3.14.35+ 
> #6
>
> [  149.949616] [] (unwind_backtrace) from [] 
> (show_stack+0xb/0xc)
>
> [  149.957570] [] (show_stack) from [] 
> (dump_stack+0x4f/0x64)
>
> [  149.965181] [] (dump_stack) from [] 
> (warn_slowpath_common+0x4b/0x68)
>
> [  149.973686] [] (warn_slowpath_common) from [] 
> (warn_slowpath_null+0x11/0x14)
>
> [  149.982940] [] (warn_slowpath_null) from [] 
> (ffs_ep0_write+0x44d/0x474)
>
> [  149.991729] [] (ffs_ep0_write) from [] 
> (vfs_write+0x6d/0x130)
>
> [  149.999599] [] (vfs_write) from [] 
> (SyS_write+0x2d/0x64)
>
> [  150.006994] [] (SyS_write) from [] 
> (ret_fast_syscall+0x1/0x46)
>
> [  150.014950] ---[ end trace 3555ece349f08477 ]---
>
> [  151.039009] read descriptors
>
> [  151.042065] read strings
> I believe it has to do with the FunctionFS. What is it used for? Can I 
> disable it? I believe it is only used so that ADB would work right?
>
> To provide you with some extra info, I had to build the kernel with the 
> folowing modifications to the defconfig:
>
> I commented:
> # CONFIG_USB_G_NOKIA=m  //This led to an inconsistent state
>
> I included this:
> CONFIG_DMA_OMAP=y //This was a required dependency
>
> Cheers,
> Michael
>
>
>
> 2015-03-18 2:39 GMT+01:00 Andrew Henderson  >:
>
>> Are you using an LCD cape? I have seen flickering similar to what you 
>> described with the 3.8 kernel when I forced a video resolution via the 
>> "video=" kernel command line option (in uEnv.txt in the boot partition) for 
>> the LCD3/4/7 CircuitCo capes and the 4DCAPE-43T/70T capes from 4D Systems. 
>> For those display capes, the resolution is pulled from the device tree 
>> overlay for the cape automatically, so you should not specify a video 
>> resolution. If you are using HDMI, you may not be getting the proper EDID 
>> resolution information from your display. In that case, the TILCDC driver 
>> will default to 1024x768, which your display (if it is an HDMI display) may 
>> not properly support. Either way, I have seen that refresh problem when the 
>> logical resolution that the TILCDC driver expects mismatches the physical 
>> resolution of your display device.
>>
>> I have not seen that particular USB error before, but I also have not 
>> worked with the 3.10 kernel on the BBB. I've gone straight from 3.8 to 
>> 3.13/14.
>>
>> Andrew 
>>
>> On Tuesday, March 17, 2015 at 4:45:42 PM UTC-4, Michael Gobbers wrote:
>>>
>>> Hi Andrew,
>>>
>>> Thanks for the reply. Indeed Keith Conger supplied me with the patches. 
>>> I have gotten a bit further now as I'm getting the hand of configuring 
>>> and building the kernel for the beaglebone black. I'm now able to boot all 
>>> the way to the android home screen.
>>>
>>> However, I have major graphical glitches. It seems that the boot 
>>> animation is being displayed together with the home screen. Their also 
>>> seemed to be a lot of flickering on the screen. So there is something 
>>> seriously wrong there.
>>>
>>> The biggest issue for me that I came across was the fact that my usb 
>>> host port didn't seem to work. So no mouse available there.
>>> Today I tried the 3.10 kernel and there I do not have the graphical 
>>> glitches. However, again there is no host port available.
>>>
>>> from the ftdi output I did find the following while booting the kernel:
>>>
>>> [2.725494] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with 
>>> status -517
>>>
>>> [2.733755] platform musb-hdrc.0.auto: Driver musb-hdrc requests probe 
>>> deferral
>>>
>>> Have you ever come across this error?
>>>
>>
>
>
> -- 
> Michael Gobbers   <http://be.linkedin.com/in/michaelgobbers>
> +32477188592
>
>
> Desguinlei 6 - 2018 Antwerpen
>  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

Are you using an LCD cape? I have seen flickering similar to what you 
described with the 3.8 kernel when I forced a video resolution via the 
"video=" kernel command line option (in uEnv.txt in the boot partition) for 
the LCD3/4/7 CircuitCo capes and the 4DCAPE-43T/70T capes from 4D Systems. 
For those display capes, the resolution is pulled from the device tree 
overlay for the cape automatically, so you should not specify a video 
resolution. If you are using HDMI, you may not be getting the proper EDID 
resolution information from your display. In that case, the TILCDC driver 
will default to 1024x768, which your display (if it is an HDMI display) may 
not properly support. Either way, I have seen that refresh problem when the 
logical resolution that the TILCDC driver expects mismatches the physical 
resolution of your display device.

I have not seen that particular USB error before, but I also have not 
worked with the 3.10 kernel on the BBB. I've gone straight from 3.8 to 
3.13/14.

Andrew 

On Tuesday, March 17, 2015 at 4:45:42 PM UTC-4, Michael Gobbers wrote:
>
> Hi Andrew,
>
> Thanks for the reply. Indeed Keith Conger supplied me with the patches. 
> I have gotten a bit further now as I'm getting the hand of configuring and 
> building the kernel for the beaglebone black. I'm now able to boot all the 
> way to the android home screen.
>
> However, I have major graphical glitches. It seems that the boot animation 
> is being displayed together with the home screen. Their also seemed to be a 
> lot of flickering on the screen. So there is something seriously wrong 
> there.
>
> The biggest issue for me that I came across was the fact that my usb host 
> port didn't seem to work. So no mouse available there.
> Today I tried the 3.10 kernel and there I do not have the graphical 
> glitches. However, again there is no host port available.
>
> from the ftdi output I did find the following while booting the kernel:
>
> [2.725494] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with 
> status -517
>
> [2.733755] platform musb-hdrc.0.auto: Driver musb-hdrc requests probe 
> deferral
>
> Have you ever come across this error?
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

Hello Grayver.  Actually, USB cameras on the BBB are not something that I 
have any experience with. I do have support for V4L2 enabled in the kernel, 
and I have enabled USB camera support in the device/ti/BoardConfig.mk file 
for the Android build. But, I haven't given it a try to see how well it 
works. You may very well have the camera working, but without OpenGL ES to 
scale the captured video to the full screen size, it may not actually work 
in any standard camera app. If you have a USB camera that is known to work 
under Linux, you can give it a try and see how well it works out for you. 

My general rule is that if some device is supported under a Linux system 
with the 3.8 kernel on the BBB then it is supported under BBBAndroid with 
the 3.8 kernel. That doesn't mean that the Android apps will always play 
nice with your hardware, but the userspace interface to the device that is 
exposed by the kernel will be the same under Linux as it is under Android. 
 One of these days, I'm going to have to work with a USB camera under 
Android. But, until then, I can't give you any concrete recommendations. 
 Sorry. Your best bet is to check out what cameras people are using with 
OpenCV and then stick with one of those. If you need special modules loaded 
for a particular camera, you can place an "insmod" for the module or 
modules inside of the init.{ro.hardware}.rc file in the root file system of 
the BBBAndroid image.

Andrew

On Monday, March 16, 2015 at 1:50:21 PM UTC-4, grayv...@gmail.com wrote:
>
> Hi Andrew*,*
>
> I am trying to use the BBB for basic picture analysis with OpenCV over 
> Android OS.
>
> I was wondering, does this release support any basic usb cameras (are 
> there any drivers for known products)?
>
> So far i have found this 
> http://www.radiumboards.com/HD_Camera_Cape_for_BeagleBone_Black.php which 
> is a bit pricy.
>
> thank you very much,
>
> Grayver
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

Hello Michael. I believe that Keith Conger supplied you with the 3.18 
backport drivers for Bluetooth, right? I have Keith's patches sitting in my 
review queue, but I haven't yet created a branch with them. The problem 
that I'm running into is that the 3.8 kernel has the capemgr in it, but the 
later kernels do not. So, Bluetooth drivers in the newer kernels aren't 
readily available for BBBAndroid without a lot of screwing around. The 
drivers that you need are available in the 3.14 kernel, but the 3.14 kernel 
does not have support for dynamic loading of device tree overlays in it. 
Only 3.8 has this feature, which is why I am sticking with 3.8 for 
BBBAndroid. I want to make it easy for people to try different hardware 
configurations and easily prototype Android interfacing code, though some 
features requiring the drivers from newer kernels (like Bluetooth drivers) 
aren't available because of this. 

You could try just dropping the 3.14 kernel into the BBBAndroid build 
process as you are doing, but you must make sure that the device tree 
(.dtb) in the boot partition matches the kernel. The FTDI serial output 
will tell you of any issues with the bootloader and help you diagnose these 
sorts of problems. If all of the lights are on, you are having a problem 
very early in the boot process. My guess is that it is a mismatch of some 
sort among the bootloader, uEnv.txt file, the device tree .dtb, and the 
kernel. You probably haven't gotten far enough along in the build process 
to worry about having the correct kernel modules installed in the root file 
system, but that shouldn't be a problem if you are using my makefile.  My 
makefile installs the modules into place for you.

Also, make sure that you have the Android staging drivers (binder, 
anonymous shared memory, low memory killer, etc.) enabled in you kernel 
configuration for the 3.14 kernel. You were asked about all of those 
options when you built the kernel because you were using a kernel 
configuration file for the 3.8 kernel with your 3.14 kernel. There are a 
number of mismatches in the options between the two kernels, so the kernel 
Kconfig system was asking you to sort out the differences.

Andrew


On Wednesday, March 11, 2015 at 3:00:40 PM UTC-4, mgob...@orcasolutions.be 
wrote:
>
> Hi Andrew, 
>
> Thanks for the great job you've doing on the beagleboard. 
> For the project I'm currently working on I included bluetooth support to 
> the build. However, it seems that the le functionality isn't working 
> because it relies on some modules not available in the 3.8 kernel. 
>
> Some people pointed out the I should upgrade to kernel 3.14. However, I'm 
> kind of I'm the dark here and I don't really know what I'm doing wrong. 
>
> Would it be possible to point me in the right direction? 
>
> Currently I modidified the repo manifest to fetch the beaglebone 3.14 
> kernel and replace it with the original bbbkernel in the manifest. I ran 
> the make oldconfig on the kernel to merge the 3.4 config with the new 3.14 
> config. However, after running the build I tried to boot it on the BBB and 
> it failed to boot. The 4 userleds seem to stay lit. 
>
> After doing the make oldconfig I had to enter a lot of new options. I'm 
> not really sure what I was doing there... 
>
> Cheers, 
> Michael 
>
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

Hello Gianmaria. Sorry for the delay in getting back to you on this. The 
.img files for the various Android partitions are generated as part of the 
BBBAndroid build process.  But, the makefile installs the kernel, firmware, 
and modules into the file system after the .img files are generated. I stay 
away from installing Android into the eMMC because I don't want to limit 
the size of the partitions to fit within the 2GB/4GB eMMC. That is why I 
target the microSD card for the BBBAndroid build scripts. You can use the 
.img files that are generated during the BBBAndroid build process and use 
fastboot to place the images onto the eMMC (as Chris's instructions show in 
the link that you mentioned). But, you may have to shrink the size of the 
images because I include a few extra packages (such as the i2ctools) that 
aren't in the usual AOSP packages.  Because of this, my images are bigger 
than normal and may not fit onto a 4GB eMMC as-is.


On Monday, March 2, 2015 at 1:04:39 PM UTC-5, nvent...@gmail.com wrote:
>
>
> Hi Andrew,
> i found your git very usefull. Can you give me some information on how to 
> create .img files and boot android copletly from eMMC? Something like 
> 2net.co does here: 
>
> https://github.com/csimmonds/bbb-android-device-files/tree/kk4.4-fastboot
>
> Thank you in advance. 
>
> Regards,
> Gianmaria
>
> Il giorno giovedì 15 gennaio 2015 05:01:32 UTC+1, Andrew Henderson ha 
> scritto:
>>
>> I don't have the various cape .dtbo overlay files copied into the image 
>> (aside from those statically built into the am335x-boneblack.dtb file in 
>> the "dtbs" directory of the boot (first) partition.  To add any overlays to 
>> your system, copy the necessary .dtbo files into /system/vendor/firmware 
>> directory of the rootfs (second) partition.  You can automatically load the 
>> overlay on boot by adding the appropriate commands to the 
>> init.{ro.hardware}.rc file in the root directory of the rootfs partition. 
>>  Just look in that file for the "BBBAndroid" comments and read them to see 
>> how to do this.
>>
>> After the overlay loading command, you can add commands to chmod the 
>> permissions on the appropriate files in the /dev filesystem to relax the 
>> permissions on the UART tty files to allow apps to access them.  Just look 
>> in the init.{ro.hardware}.rc file for some examples (I chmod /dev/spidev* 
>> and the /dev/i2c* devices, for example). Ideally, you'd have a manager 
>> access such hardware resources on your behalf via the Android HAL.  But, 
>> for prototyping, it isn't a big deal to open these devices up and let apps 
>> talk to them directly via JNI.
>>
>> This is probably a good time to mention that I've recently put together a 
>> book which covers all the details involved in creating Android apps that 
>> talk directly to hardware.  It is "Android Hardware Interfacing with the 
>> BeagleBone Black" from Packt Publishing, and it is scheduled to go to print 
>> next month: 
>> https://www.packtpub.com/hardware-and-creative/android-hardware-interfacing-beaglebone-black
>>
>> So, if you're still fighting with the details a few weeks from now, there 
>> will actually be a reference book to help you out (using BBBAndroid, too!).
>>
>> On Tuesday, January 13, 2015 at 4:29:20 PM UTC-5, ti...@emailbx.com 
>> wrote:
>>>
>>> Thanks a lot for creating this.
>>> I have got this image and the BBB now is running using a 4DLcd 7". 
>>> For my experiments, i'm trying to use UART4 (as it's available in the 
>>> headers of the LCD) so i installed an apk for serial testing 
>>> http://code.google.com/p/android-serialport-api/ but when I try to send 
>>> some info  I get the error "You do not have read/write permission to the 
>>> serial port"
>>>
>>> I read that i have to enable muxing on the pins to enable uart4. How can 
>>> I do that in you image?
>>>
>>> Any info is appreciated.
>>>
>>> Thx
>>>
>>> On Saturday, November 15, 2014 at 3:25:58 PM UTC-6, Andrew Henderson 
>>> wrote:
>>>>
>>>> I have built a new microSD card image for BBBAndroid 
>>>> (bbbandroid_111514.img), and it is now available for download.  Just 
>>>> follow 
>>>> the link at bbbandroid.org to download it.
>>>>
>>>> In this build, USB ADB support is working just fine.  I've been able to 
>>>> connect with the BBB using both command-line ADB and ADB through the 
>>>> Eclipse ADT under both Windows and Lin

Re: [beagleboard] Re: BBBAndroid with USB Bluetooth Adapter Support

[Andrew Henderson]

I have the integration of Bluetooth into BBBAndroid in my work queue, and 
I'm getting to it, but it will still be a few days (at least).

On Wednesday, March 4, 2015 at 10:45:05 AM UTC-5, Michael Gobbers wrote:
>
> That would be great! I'm in kind of a hurry. At the moment I completer 
> step 2 of the steps you mentioned.
>
> Cheers,
> Michael
> On Mar 4, 2015 4:42 PM, "Keith Conger" > 
> wrote:
> >
> > Hi Michael,
> >
> > I've sent them to Andrew to review and hopefully include in bbbandroid.  
> If you're in a hurry I could email them to you.
> >
> > Keith
> >
> >
> > On Wednesday, March 4, 2015 at 8:26:23 AM UTC-7, 
> mgob...@orcasolutions.be wrote:
> >>
> >> Hi All,
> >>
> >> Hi All I'm trying to do the exact same thing here with bbbandroid. I 
> have an asus 4.0 dongle with the BCM20702A0 chipset. I'm not really 
> experienced when it comes to making my own kernels.
> >> I do understand what you are doing with these high level steps you laid 
> out here. However, I could use some help to actually execute them... I see 
> you are going to include them as patches? Is the patch already available? 
> Where can I find it? Thanks!
> >>
> >> Michael
> >>
> >> Op vrijdag 20 februari 2015 00:13:13 UTC+1 schreef Keith Conger:
> >>>
> >>>
> >>>
> >>> On Thursday, February 19, 2015 at 12:27:37 PM UTC-7, Andrew Henderson 
> wrote:
> >>>>
> >>>> On Thursday, February 19, 2015 at 1:50:43 PM UTC-5, Keith Conger 
> wrote:
> >>>>>
> >>>>> I've got bluetooth finally working.  Andrew, what would be the best 
> way to pass you the changes needed?
> >>>>
> >>>>
> >>>> Patches generated by git are fine.  If you know the major parts that 
> you patched, you can also cd into the appropriate directory and do a "git 
> status" to show you which files have changed and just mail me those files 
> (hendersa (at) icculus.org).  For subdirectories that are completely new 
> (like the Bluez added into external/), you can just tar up the directory 
> and send it to me.  My understanding is that you added in Bluez, modified 
> the build scripts to pull that external project in, patched bionic, and 
> changed the kernel config to build in Bluetooth.  Does that sound about 
> right? 
> >>>>
> >>>
> >>> Ok I'll start work on getting it over to you. Basically you are 
> correct. Here are the steps at a high level:
> >>>
> >>> * Add bluez repo to the manifest and told it to not pull bluedroid.
> >>> * Patched bionic, although I see bluez has a patched bionic in a repo 
> for 4.4, maybe I can just change the manifest.
> >>> * Built bluetooth kernel modules from backports, 3.8 is too old
> >>> * Added insmod commands to init.{ro.hardware}.rc "on boot" and added 
> "import init.bluetooth.rc"
> >>> * Commented out qemu=1 check for bluetooth.
> >>> * Had to manually move some libraries to /system/lib/hw/ from 
> /system/lib/
> >>>
> >>> Keith
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] "Android for the BeagleBone Black" book now available

[Andrew Henderson]

On Sunday, February 22, 2015 at 2:34:33 PM UTC-5, William Hermans wrote:
>
> Hey, Andrew,
>
> Good Job ! Question though. Do you and your co-author ( plus perhaps packt 
> ) plan on releasing an electronic version ? Old eyes prefer a medium that 
> can be easily magnified ( zoom ) for better reading experience . . .
>
 
You bet.  Because the title was shortened from "Android Hardware 
Interfacing with the BeagleBone Black" to "Android for the BeagleBone 
Black" at the last minute, Amazon is a little confused on the listing for 
the book.  The paperback is listed under the long name and the e-book is 
listed under the short one.  Here are the links:

Amazon 
paperback: 
http://www.amazon.com/Android-Hardware-Interfacing-BeagleBone-Black/dp/1784392162
Amazon Kindle 
eBook: 
http://www.amazon.com/Android-BeagleBone-Black-Andrew-Henderson-ebook/dp/B00TU3CXCQ
Packt 
Publishing: 
https://www.packtpub.com/hardware-and-creative/android-beaglebone-black

The Packt link will allow you to buy the e-book (PDF) or the e-book + 
paperback together direct from the publisher.

Andrew

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] "Android for the BeagleBone Black" book now available

[Andrew Henderson]

Hello all!  I am happy to announce that one of my colleagues, Aravind 
Prakash, and I have put together a book that gives some practical guidance 
on using Android on the BeagleBone Black platform. This book is "Android 
for the BeagleBone Black" from Packt Publishing (ISBN 978-1784392161), and 
it is now available on Amazon.  It covers a number of the details involved 
in installing Android on the BBB using the 3.8 Linux kernel and creating 
apps that interface with hardware connected to the BBB's P8/P9 connectors. 
There are step-by-step instructions on getting ADB over USB running, adding 
device tree overlays to your Android system, and setting up the system at 
boot via the Android init*.rc files.  There is also complete source code 
provided for sample apps that use JNI and AsyncTask background threads to 
talk with GPIO, I2C, and SPI hardware. We've selected some nice hardware 
components for the examples that will get you up-and-running without 
requiring you to have extensive hardware knowledge: 
http://i.imgur.com/bz4Fjeq.jpg

Packt has made a sample of the book available for free 
here: 
http://www.slideshare.net/Products123/android-for-the-beaglebone-black-sample-chapter

Back in 2013, I began experimenting with getting Android running on the 
BeagleBone Black with the 3.8 kernel so that I could quickly and easily 
interface capes and custom hardware with Android.  I made a few Android 
4.2.2 JellyBean images available and I received *thousands* of mails from 
hobbyists, engineers, and students asking all sorts of questions and 
sharing info about what they've discovered while using Android on the BBB. 
 The Android building process was a bit rough around the edges, so I tried 
to streamline the process as best as I could.  The result was the 
BBBAndroid project (bbbandroid.org), which allows you to build Android 
4.4.4 KitKat with the 3.8 kernel in only a handful of simple steps.  

I was surprised at all of the BBB projects that people have been using 
Android for!  A number of engineering firms and universities from all over 
the world have contacted me for advice about using the open hardware design 
of the BBB as an Android EVM or as a basis for new Android gizmos and 
research projects.  Having the 3.8 kernel available has allowed them to 
rapidly integrate and test hardware with their Android system prototypes, 
so I've heard about all sorts of tablets, car computers, portable media 
devices, smart toasters, etc. that people have been putting together with 
BBBs running Android.  Hopefully, this book will help give people those 
critical missing bits of information that they need to really dig in and 
start creating some nice Android-based projects.  Since the tutorials and 
documentation available for Android target the more "official" support for 
Android on the BBB with the 3.2 kernel, this book helps out those of you 
who want to use the BBB's cape manager to easily use commercially-available 
capes and quickly prototype new hardware and get it talking to Android apps.

Enjoy, and be sure to let me know what Android projects you're creating for 
the BBB!

Andrew

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beginning Operations on BBB, Android or Linux? Debugging and building Graphics applications

[Andrew Henderson]

On Thursday, February 19, 2015 at 5:02:45 PM UTC-5, Harvey White wrote: 
 

> I noticed that 4.2.2 doesn't even make the windows USB enumerator 
> beep... the 4.4.4 image I've tried, but several things seem not to 
> work, i.e. android comes up and says (remembering here:  core services 
> not running and wallpaper not running).  The mouse pointer seems to be 
> quite lagged, but I'm sending the HDMI output directly onto a monitor 
> right now.


Android uses OpenGL ES for its rendering, but the binary blob driver for 
the SGX GPU core on the BBB isn't supported under the 3.8 kernel.  This 
means all of the rendering to textures and then scaling the textures is 
done in software.  The larger the screen resolution that you use, the more 
sluggish the system will act.  The TILCDC driver in the kernel will 
initialize the framebuffer resolution at the highest resolution supported 
by your display.  Your HDMI/DVI display will report an EDID block to the 
kernel driver via your HDMI cable, and the EDID block contains a list of 
all modes the display supports. If your display doesn't report EDID 
information or your cable/converter blocks the EDID block, the resolution 
will default to 1024x768.  You can edit the uEnv.txt file in the boot 
partition of the microSD card to add a "video=" kernel command line option 
to limit the size of the resolution.  For example, "video=720x480@16" will 
limit you to 720x480, which will give you performance that is far more 
snappy than the performance at the higher 720/1080 resolutions.

Apparently with android studio, I don't need QT, since the drag and 
> drop GUI is built in, one of the attractive features of android (also 
> that I can run the application on a number of other things I have). 
>

Sorry about that.  I meant use Qt as the widget framework under Linux or 
just use Android (as in, the Android API framework and GUI).  You would not 
use Qt under Android. 

What compiler setup do you use for the Linux development?  It seems 
> that Android Studio is the hands down best choice for the development 
> of the java code...


I use a GCC toolchain natively on the BBB itself, Android SDK via Eclipse 
on the desktop, and the Android NDK for the native bits.  For hardware 
interfacing, I write a small C program under Linux on the BBB to actually 
perform ioctl() calls, flip bits in mmap()'s registers, etc.  Basically, 
all of the stuff that must happen on the actual hardware.  Once that works 
well, I make a clean interface to those functions and build it as a library 
on the BBB under Linux and make sure everything is OK.  That code is then 
moved over to my Windows system and built using the NDK.  It is usually 
little more than a file or two, so the Android.mk for it is trivial to set 
up.  I add the NDK-generated library into my project inside of Eclipse and 
then add in the appropriate JNI calls to access the native code.

For straight Linux development, it is GCC on the BBB and GCC in a Linux VM 
on my desktop.  I do much of the development on my desktop and then move 
the code to the BBB to shake out the x86/ARM 32/64 bit assumptions and get 
it working well on the BBB.  Then, I move it back to the desktop and see 
what I broke.  Do this a few times and you are in good shape.  #ifdef's 
will assist you in isolating the platform specific stuff so that you can 
have code that will build and run on both platforms.  I try to stick with 
the integer datatypes specified in  to explicitly specify data 
type sizes. 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBBAndroid with USB Bluetooth Adapter Support

[Andrew Henderson]

On Thursday, February 19, 2015 at 1:50:43 PM UTC-5, Keith Conger wrote:
>
> I've got bluetooth finally working.  Andrew, what would be the best way to 
> pass you the changes needed?
>

Patches generated by git are fine.  If you know the major parts that you 
patched, you can also cd into the appropriate directory and do a "git 
status" to show you which files have changed and just mail me those files 
(hendersa (at) icculus.org).  For subdirectories that are completely new 
(like the Bluez added into external/), you can just tar up the directory 
and send it to me.  My understanding is that you added in Bluez, modified 
the build scripts to pull that external project in, patched bionic, and 
changed the kernel config to build in Bluetooth.  Does that sound about 
right? 

Thanks again for all your help.
>

No problem at all.  Thanks for sticking this out and working through all 
this.  I'm sure others will appreciate the effort. 

Andrew

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beginning Operations on BBB, Android or Linux? Debugging and building Graphics applications

[Andrew Henderson]

On Tuesday, February 17, 2015 at 6:29:45 PM UTC-5, ma...@dragonworks.info 
wrote:
>
>
> I've considered the Debian Linux image as shipped.  Programming in C or 
> C++ is not a problem, and it looks as if it works well at accessing the I2C 
> devices. However, I've tried TI's Code Composer Studio, and find that the 
> examples don't compile properly because the paths are not valid in windows 
> 8.1 (apparently, lots of "file not found, fatal error", for the includes.  
> With multiple platforms and processors, CCS is not that friendly.  Nor is 
> using Android on CCS.  Not sure what graphics tools are available for 
> making a GUI program.
>

While everyone has their own method of development, I have had very good 
luck with developing C/C++ under a Linux VM on my desktop and natively on 
the BBB itself.  I'll get a code framework up and running on my Linux VM 
and then move the codebase over to the BBB to fine-tune it and add in the 
hardware interfacing bits as needed.  Some folks prefer to use a complete 
cross-compile environment on the desktop and then push the final 
binaries/libraries over to the BBB.
 

> Android Image.  I have the circuitco image, which boots, but does not 
> connect to the laptop over USB.  I can (probably) work thorugh the JNI 
> aspect if I need that to get to the I2C drivers working, but haven't yet.  
> Since Java has a built in GUI creator (drag and drop, I'm familiar with 
> Lazarus Pascal, Delphi, and Visual studio, although I don't like visual 
> studio at all), that solves the GUI problems.  Using Android studio, latest 
> version.
>

That is the 4.2.2 JellyBean image, correct?  The newer 4.4.4 KitKat image 
has ADB over USB support in it by default.  For hardware interfacing, I 
develop the C interfacing code natively under Linux on the BBB to test 
communication with the hardware.  Once it looks good, I move that code over 
to a platform with the NDK and build it as shared library for JNI use with 
an app. Include the built library into your app and use JNI to make the 
native calls. Keep in mind that you still need to properly mux the pins 
(via dynamic device tree overlays or static modifications to the base 
kernel device tree), and the hardware that you are talking to (usually via 
files in the /dev filesystem) must be accessible from your app.  Android 
locks down those permissions, so to make a device available at the app 
level without changing the Android HAL requires relaxing the device's 
permissions so that pretty much anyone can access it.

However, under android, even setting Developer options/usb debugging does 
> not even produce an undefined device on the direct USB cable connection to 
> the PC (windows 8.1).   Trying to edit the android usb configuration .ini 
> file (instructions at TI's android development platform) produces a file 
> that windows says has been tampered with, and refuses to install.  The 
> basic driver file (before modification) installs just fine.
>

BBBAndroid reports the BBB as a Google Nexus S (18D1:4E23).  If you don't 
have an ADB driver for this device already, it is included in the Universal 
ADB Driver: http://www.koushikdutta.com/post/universal-adb-driver  

SO:  Questions abound:
> 1) which application framework would be best to do what I need to do.  No 
> problem doing Java if needed, no problem with C, C++ if needed...
>

Check into Qt under Linux or Android.
 

> 2) Is there a specific problem with windows 8.1 and debugging (and 
> changing .ini files) that I don't know the solution to (hopefully yes)
>

No ADB support in that 4.2.2 image.  Switch to the 4.4.4 KitKat image (API 
19).
 

> 3) which platform is best at hardware access.  I need to be able to 
> read/write I2C with binary strings to be able to communicate to the 
> hardware and boards.  Those are already designed, so the protocol won't 
> change, and I2C specifies only the first one or two bytes anyway.
>

I think Linux is the easiest for developing this sort of thing.
 

> 4) I've read tons of web pages, and right now, I'd like to avoid Linux if 
> possible, but if necessary, then I guess I need to.  Right now I'm trying 
> to make it all work under windows 8.1 just to keep the development on the 
> same system. 
>

I think you should develop your hardware-interfacing bits under Linux and 
then decide which platform (Linux or Android) works best for your needs. 

Andrew 

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBBAndroid with USB Bluetooth Adapter Support

[Andrew Henderson]

Yes, there is a kernel command line option that is passed to the kernel in 
the uEnv.txt file that says so (qemu=1, I think?).  It has been a while, 
but I believe this is necessary to emulate the OpenGL ES calls. 
Otherwise, it all crashes constantly because there isn't OpenGL ES 
support.  You can try removing that option, though, and see how it works 
for you.  I originally added that in for the 4.2.2 JellyBean build from 
Rowboat, though we might get lucky and have it work without it from the 
4.4.4 KitKat build from AOSP.


Andrew

On Thu, 19 Feb 2015, Keith Conger wrote:


I've made a lot of progress with the help of the bluez team.  It looks like
my problem is that Android thinks its running in an emulator.
Using haltest from bluez everything works. haltest actually goes through
Android bluetooth HAL.

Andrew any idea on why it would think your kernel is for an emulator?

Thanks,
Keith

On Tuesday, February 17, 2015 at 5:24:07 PM UTC-7, Keith Conger wrote:
  Ok, apparently my problem may be because I'm running bluetoothd
  by hand and the socket isn't created.  
However I did get 111, connection refused.

Here is a complete logcat and my init files.

On Tuesday, February 17, 2015 at 3:52:32 PM UTC-7, Keith Conger wrote:
  Oh ok I see. I'll give it a try.

  Thanks,
  Keith

  On Tue, Feb 17, 2015 at 3:18 PM, Andrew Henderson
   wrote:
  > On Tue, 17 Feb 2015, Keith Conger wrote:
  >
  >> I did hand patch epoll_create1() into bionic.  The
  above was a logcat,
  >> how do I get the errno value?
  >
  >
  > Immediately after any failed POSIX call, the errno
  global variable (an
  > integer) is set.  Just include the errno.h header in the
  file making the
  > failed call to get access to the errno variable.  You
  can see how the logcat
  > message is being generated in that same file (usually
  via a system() call to
  > "logcat" or a C++ stream to LOG(INFO) or whatever.
  >
  > Andrew



  --
  Keith Conger
  keith DOT conger AT gmail DOT com
  http://thecongers.org

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the
Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/beagleboard/X4HYHv9cC-0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBBAndroid with USB Bluetooth Adapter Support

[Andrew Henderson]

On Tue, 17 Feb 2015, Keith Conger wrote:


I did hand patch epoll_create1() into bionic.  The above was a logcat,
how do I get the errno value?


Immediately after any failed POSIX call, the errno global variable (an 
integer) is set.  Just include the errno.h header in the file making the 
failed call to get access to the errno variable.  You can see how the 
logcat message is being generated in that same file (usually via a 
system() call to "logcat" or a C++ stream to LOG(INFO) or whatever.


Andrew

Re: [beagleboard] Re: BBBAndroid with USB Bluetooth Adapter Support

[Andrew Henderson]

On Tuesday, February 17, 2015 at 4:20:42 PM UTC-5, Keith Conger wrote:
 

> D/bluetoothd( 1072): 
> external/bluetooth/bluez/android/ipc.c:cmd_connect_cb() 
>
> E/bluetoothd( 1072): IPC: command socket connect failed
>
OK, this is the place to start.  A socket isn't being created properly. 
 That means that either the permissions aren't correct or the call used to 
create/interact with the socket is not supported.  The Bionic libc 
replacement does not implement a number of Linux kernel system calls 
because those system calls are not used under Android.  For example, shared 
memory or message queue syscalls aren't implemented because all IPC should 
be routed through Binder.  My guess is that you are running into something 
like this (section 1.2):

http://forum.xda-developers.com/showthread.php?t=2640723

The epoll_create1 syscall is not implemented by default in Bionic, so 
making an epoll_create1() call in Bionic results in an immediate failure. 
 Try dumping out logcat info at that error point with the errno value after 
the failed function call in cmd_connect_cb().  I bet that it is calling a 
Bionic function that doesn't generate the appropriate syscall to the kernel.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBBAndroid with USB Bluetooth Adapter Support

[Andrew Henderson]

Try configuring the kernel using the "menuconfig" target (like "make 
menuconfig" in the makefile).  I suspect that you are manually setting 
something in the .config and there are other settings that conflict with 
it.  Normally, these conflicts are managed via the Kconfig or menuconfig 
interface (i.e. it just takes options away from you or forces some items to 
be modules).  Make sure that the options that you are setting are actually 
all compatible with each other.  If all else fails, you can manually insmod 
modules in the init.{ro.hardware}.rc file inside of Android during boot.

On Tuesday, February 10, 2015 at 3:41:52 PM UTC-5, Keith Conger wrote:
>
> It built without errors.  I'm having trouble with the kernel though.  I 
> made sure kernel/.config and am335x_evm_android_defconfig both had 
> CONFIG_BT=y.  I re-ran make in the root of BBBAndroid. As soon as I 
> answered the questions about the USB gadget driver it reverted to CONFIG_BT=m 
> along with the other options I modified.  Any ideas Andrew?
>  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: BBBAndroid with USB Bluetooth Adapter Support

[Andrew Henderson]

If you get bluedroid working and it is a viable approach, let me know and 
I'll add it into the manifest as an external repo for BBBAndroid.  Right 
now, I don't have the cgroups set up properly for audio, so I'm not sure 
how well audio support is working via HDMI or audio cape.  Bluetooth is a 
question mark right now, but the other pieces work OK.  I've used the 
Adafruit DS1307 RTC breakout board via I2C to set the system clock during 
the kernel boot process, so that will be transparent to Android.

If you take a look at the top-level makefile, you'll see these lines:

kernel_not_configured := $(wildcard kernel/.config)

ifeq ($(TARGET_PRODUCT), beagleboneblack)
CLEAN_RULE = kernel_clean clean
rowboat: kernel_build
endif

kernel_build: droid
ifeq ($(strip $(kernel_not_configured)),)
$(MAKE) -C kernel ARCH=arm am335x_evm_android_defconfig
endif

That "am335x_evm_android_defconfig" is getting selected because the script 
isn't finding your kernel/.config file.  I guess this isn't working 
properly for you for some reason?  Anyway, you can remove that defconfig 
from that line or backup/modify that defconfig in kernel/arch/arm/configs.

I have been at SU for so long now that I have a mailbox in the EECS 
department and potential PhD students are brought by my office to ask 
questions during their campus visits.  My usual advice to them is to dress 
warm and invest in a high-quality snow shovel.

On Tuesday, February 10, 2015 at 5:45:49 PM UTC, Keith Conger wrote:
>
> Hi Andrew,
>
> Thanks for replying.
>
> I have read that.  I'm currently compiling BBBAndroid with Android-x86's 
> bluedroid which appears to have USB BT support.
>
>
> http://git.android-x86.org/?p=platform/external/bluetooth/bluedroid.git;a=summary
>
> I'd like to use rfcomm and audio, rfcomm is more important though.  I'm 
> open to other hardware suggestions too.  
>
> My requirements for my little pet project are:
>
> Android 
> Resistive touch screen
> Bluetooth
> USB Host
> RTC
> Audio out
>
> BTW I see your attending SU.  Great school, I attended a few courses there 
> and just moved away from the area.
>
> Thanks again,
> Keith
>
> -- 
> Keith Conger
> keith DOT conger AT gmail DOT com
> http://thecongers.org
>  

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid with USB Bluetooth Adapter Support

[Andrew Henderson]

Well, Bluetooth being recognized by the kernel and Bluetooth being 
accessible via the API are two very different animals.  Enabling the 
Bluetooth stack in the kernel, as well as the device drivers, is the first 
step.  Once that portion is done, your Bluetooth device must be registered 
within the Android HAL to access it from the API.  If you take a look in 
the BBBAndroid source tree in 
hardware/libhardware/include/hardware/bluetooth.h, you can see the 
interface functions used to bridge the API to a Bluetooth device.  I have 
not checked into whether you can bypass all of this by using a USB 
Bluetooth device, though.  For example, if you are using a Bluetooth 
keyboard with a USB/Bluetooth dongle plugged into the BBB, will the BBB see 
it as a Bluetooth device or a USB keyboard?  If you can leverage the USB 
drivers and have the Bluetooth functionality of your device be "invisible" 
to Android, then you're in luck.  But, if you want to use the full 
Bluetooth API to manage your device, BBBAndroid is missing the portion of 
the HAL needed to make that happen.

What is the nature of the Bluetooth device that you are using? 

On Thursday, February 5, 2015 at 1:39:48 PM UTC-5, Keith Conger wrote:
>
> Has anyone managed to enable USB Bluetooth Adapter Support in BBBAndroid. 
>  I've read the Android > 4.2 can support USB bluetooth if built correctly.
>
> This is what I've tried so far:
>
> I set the following in "device/ti/beagleboneblack/BoardConfig.mk"
> BOARD_HAVE_BLUETOOTH := true
>
> And the following in "kernel/.config"
> CONFIG_BT=y
> CONFIG_BT_RFCOMM=y
> CONFIG_BT_RFCOMM_TTY=y
> CONFIG_BT_BNEP=y
> CONFIG_BT_BNEP_MC_FILTER=y
> CONFIG_BT_BNEP_PROTO_FILTER=y
> CONFIG_BT_HIDP=y
>
> #
> # Bluetooth device drivers
> #
> CONFIG_BT_HCIBTUSB=y
> CONFIG_BT_HCIBTSDIO=y
> CONFIG_BT_HCIUART=y
> CONFIG_BT_HCIUART_H4=y
> CONFIG_BT_HCIUART_BCSP=y
> CONFIG_BT_HCIUART_ATH3K=y
> CONFIG_BT_HCIUART_LL=y
> CONFIG_BT_HCIUART_3WIRE=y
> CONFIG_BT_HCIBCM203X=y
> CONFIG_BT_HCIBPA10X=y
> CONFIG_BT_HCIBFUSB=y
> CONFIG_BT_HCIVHCI=y
> CONFIG_BT_MRVL=y
> CONFIG_BT_MRVL_SDIO=y
> CONFIG_BT_ATH3K=y
> CONFIG_BT_WILINK=y
>
> However after I build a new image, most of the above are reverted to ‘m’ 
> from ’y’.
>
> Created a file called “/system/etc/permissions/beagleboardblack.xml” that 
> contains:
>
> 
> 
> 
>
> I'm new to the Android OS build environment, so I'm not sure if I missing 
> something.  I need Bluetooth for the project I'm working on.  So I'm open 
> to any options even if it means different hardware all together.
>
> Thanks in advance
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

I don't have the various cape .dtbo overlay files copied into the image 
(aside from those statically built into the am335x-boneblack.dtb file in 
the "dtbs" directory of the boot (first) partition.  To add any overlays to 
your system, copy the necessary .dtbo files into /system/vendor/firmware 
directory of the rootfs (second) partition.  You can automatically load the 
overlay on boot by adding the appropriate commands to the 
init.{ro.hardware}.rc file in the root directory of the rootfs partition. 
 Just look in that file for the "BBBAndroid" comments and read them to see 
how to do this.

After the overlay loading command, you can add commands to chmod the 
permissions on the appropriate files in the /dev filesystem to relax the 
permissions on the UART tty files to allow apps to access them.  Just look 
in the init.{ro.hardware}.rc file for some examples (I chmod /dev/spidev* 
and the /dev/i2c* devices, for example). Ideally, you'd have a manager 
access such hardware resources on your behalf via the Android HAL.  But, 
for prototyping, it isn't a big deal to open these devices up and let apps 
talk to them directly via JNI.

This is probably a good time to mention that I've recently put together a 
book which covers all the details involved in creating Android apps that 
talk directly to hardware.  It is "Android Hardware Interfacing with the 
BeagleBone Black" from Packt Publishing, and it is scheduled to go to print 
next 
month: 
https://www.packtpub.com/hardware-and-creative/android-hardware-interfacing-beaglebone-black

So, if you're still fighting with the details a few weeks from now, there 
will actually be a reference book to help you out (using BBBAndroid, too!).

On Tuesday, January 13, 2015 at 4:29:20 PM UTC-5, ti...@emailbx.com wrote:
>
> Thanks a lot for creating this.
> I have got this image and the BBB now is running using a 4DLcd 7". 
> For my experiments, i'm trying to use UART4 (as it's available in the 
> headers of the LCD) so i installed an apk for serial testing 
> http://code.google.com/p/android-serialport-api/ but when I try to send 
> some info  I get the error "You do not have read/write permission to the 
> serial port"
>
> I read that i have to enable muxing on the pins to enable uart4. How can I 
> do that in you image?
>
> Any info is appreciated.
>
> Thx
>
> On Saturday, November 15, 2014 at 3:25:58 PM UTC-6, Andrew Henderson wrote:
>>
>> I have built a new microSD card image for BBBAndroid 
>> (bbbandroid_111514.img), and it is now available for download.  Just follow 
>> the link at bbbandroid.org to download it.
>>
>> In this build, USB ADB support is working just fine.  I've been able to 
>> connect with the BBB using both command-line ADB and ADB through the 
>> Eclipse ADT under both Windows and Linux.  You can push/pull files, 
>> install/reinstall apps, get logcat output, shell, etc. using the USB cable 
>> that came with your BBB board.  If you want a root shell on Android, the 
>> ADB shell is the way to go.
>>
>> I changed the USB ID to 18D1:4E23 for the BBB device when BBBAndroid is 
>> being used.  These are the same USB vendor and device IDs as a Google Nexus 
>> S.  The reason that I changed this is to make life much easier for the 
>> Windows users.  Each phone vendor provides their own drivers for USB ADB, 
>> and it was difficult for the Windows users to get the drivers set up 
>> properly.  This should make things much easier for them.  Linux users never 
>> had a problem with it, since their USB ADB worked right out of the box.
>>
>> I also shrunk the image to 7.6 GB to accommodate everyone that was having 
>> difficulty writing the 8 GB image to their microSD cards that were actually 
>> a little bit smaller than 8 GB.
>>
>> Andrew
>>
>>
>> On Sunday, September 28, 2014 11:14:24 AM UTC-4, Andrew Henderson wrote:
>>>
>>> Hello all. I have released a new port of Android for the BBB.  This 
>>> version uses AOSP 4.4.4 (KitKat) and the 3.8 Linux kernel. I have made 
>>> build instructions and a pre-made image available at 
>>> http://www.bbbandroid.org.  I use a combination of AOSP repos and 
>>> Rowboat build scripts, and I have a few custom repos for the kernel, 
>>> bootloader, and additional "external" tools (such as i2c-tools).  You can 
>>> view the repo manifest XML file for the project here:
>>>
>>>
>>> https://github.com/hendersa/bbbandroid-manifest/blob/master/bbbandroid-aosp-4.4.4_r1-3.8.xml
>>>
>>> Because this Android image uses the 3.8 kernel, you should be able to 
>>> just plug in your capes and go w

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

1. Your repo command for fetching the AOSP code is hanging up, which can be 
caused by a few different things.  Review the "Source sync issues" section 
of https://source.android.com/source/known-issues.html.  Also, ensure that 
you are using the latest version of git.  This does not mean that you 
apt-get git, this means that you check the version that you have, see if 
that is the latest version available from source, and the download the 
latest git source and get it built and running on your system.

2. The guide that you linked outlines the process for building KitKat 4.4.4 
with a 3.2 Linux kernel.  This is quite a different kernel than the 3.8 
kernel provided in BBBAndroid. 3.8 uses DRM and supports the BBB's capemgr, 
which is a very different approach than 3.2 uses.  If you need a guide to 
build KitKat with a 3.8 kernel, follow the guide on the bbbandroid.org 
website: http://bbbandroid.sourceforge.net/build.html.  If you are using a 
3.2 kernel with your Android, I can't help you troubleshoot drivers and 
such because I don't work with the older kernel versions.  The nice folks 
at https://code.google.com/p/rowboat/ are a better resource for 
troubleshooting 3.2 kernel issues.

3. What is the display? Who is the manufacturer? Can you provide a link to 
it?  How does the display connect to the BBB (cape, HDMI connector, other)? 
 What version of the kernel does the manufacturer supply drivers for? Does 
the manufacturer supply a device tree node for the display?  Did the 
display work with the BBBAndroid image, but without the touchscreen?  I 
have no idea what your display is and how it works, so I can't help you get 
it working.

Andrew

On Saturday, January 3, 2015 11:50:53 AM UTC-5, ido...@gmail.com wrote:
>
> Hi Andrew,
> Maybe you can help me,I'm trying to use beaglebone black with a custom 
> touch screen, so i tough that Android O.S would do the job in the best way. 
> I've downloaded the prebuild Android 4.4.4 image but it didn't support the 
> touch of the screen.
> I Contact the company who made the screen and they told me i have to 
> insert their driver into the Android kernel inorder it will support the 
> touch in the screen.
> So I've follow the link in http://2net.co.uk/ and got to the guide  
> https://github.com/csimmonds/bbb-android-device-files/tree/kk4.4-sdcard
> and has they guid I'm willing to download the AOSP first and then the 
> specific bbb device files, but after few days of trying to download the 
> AOSP files (and in between increasing again & again my virtual machine) i 
> got this last screen which I'm pretty frustrated about because I cant 
> understand if the download is already over or not. and as I understand 
> redownload means to start over the download again.
> I'll be glad if someone could help me what do I do with the next screen? 
> and do I even going the right way with the above steps?
>
> Thnks,
> Ido
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

Using the HDMI cable to connect the BBB to your DVI/HDMI display should 
work without an issue.  You do not need HDMI audio to use the Android 
image.  I have used it without an issue with the various LCD capes without 
audio, for example.  Using the ethernet LAN connection and USB mouse are 
also supported.

I will need more information before I am able to help you.

Can you supply a complete FTDI output from bootloader boot through to about 
60 seconds?  The reason that I ask for this is because I need to see where 
the video resolution is being set in the TILCDC framebuffer driver.  While 
there are a number of failed services in the logcat output that you 
provided in your other post, I need to see the results of the kernel 
booting output first before I can move on to helping you troubleshoot any 
user space issues.  The logcat output shows that you are well into the boot 
process of user space.  If anything is failing in kernel space, I need to 
know that first.

Are you not seeing anything on your display?  One of the most common 
problems is the EDID block not being sent from your monitor to the BBB. 
 When this happens, the TILCDC kernel driver will default to a resolution 
of 1024x768 (which may not be supported by your monitor).  This results in 
a blank screen.  My first guess is that this is your problem (especially if 
you see it for both the old and new Android images).

Are you stuck at the screen with the "Android" animation on it?  You should 
not be, from what I can see of your logcat output.

On Friday, December 19, 2014 3:33:01 AM UTC-5, kiran...@gmail.com wrote:
>
> Hi andrew! i tried you images (old and new) for beagle bone black. But i 
> am not getting booted into it.
>
> Is it required to connect Display, LAN, and USB mouse. 
> If I use HDMI CABLE (sony erricsion) to connect my PC monitor, will it 
> drive.
>
> the FTDI output:
> [6.038794] g_ffs: read descriptors
> [6.042738] g_ffs: read strings
> [6.060551]  gadget: g_ffs ready
> [6.064563] musb-hdrc musb-hdrc.0.auto: MUSB HDRC host driver
> [6.072874] musb-hdrc musb-hdrc.0.auto: new USB bus registered, 
> assigned bus number 2
> [6.081893] usb usb2: New USB device found, idVendor=1d6b, 
> idProduct=0002
> [6.089055] usb usb2: New USB device strings: Mfr=3, Product=2, 
> SerialNumber=1
> [6.096608] usb usb2: Product: MUSB HDRC host driver
> [6.101795] usb usb2: Manufacturer: Linux 3.8.13+ musb-hcd
> [6.107524] usb usb2: SerialNumber: musb-hdrc.0.auto
> [6.114174] hub 2-0:1.0: USB hub found
> [6.118361] hub 2-0:1.0: 1 port detected
> shell@beagleboneblack:/ $ [6.293332] CAUTION: musb: Babble Interrupt 
> Occurred
> [6.391168] CAUTION: musb: Babble Interrupt Occurred
> [   27.787048] warning: `zygote' uses 32-bit capabilities (legacy support 
> in use)
> [   43.804027] healthd: battery l=0 v=0 t=0.0 h=1 st=1 chg=
> [   46.763599] net eth0: initializing cpsw version 1.12 (0)
> [   46.772805] net eth0: phy found : id is : 0x7c0f1
> [   46.789857] libphy: PHY 4a101000.mdio:01 not found
> [   46.794916] net eth0: phy 4a101000.mdio:01 not found on slave 1
> [   46.817629] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> [   68.388050] init: sys_prop: permission denied uid:1003 
>  name:service.bootanim.exit
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

Adding additional packages to your Android build is independent of the 
kernel that you use.  So, whether you use a 3.2, 3.8, 3.14+ kernel on your 
BBB with Android, it is still the same.  After you clone the Android source 
repos and you have the complete Android source on your machine, look inside 
the "device" directory of the Android source and locate the directory for 
your device.  In my Android builds, this is the device/ti/beagleboneblack 
directory.  Open the device.mk file in this directory and look at it.  A 
variety of packages will be added to your device-specific build using lines 
like this:

PRODUCT_PACKAGES += \
librs_jni \
com.android.future.usb.accessory

You just need to add the following at the end of your file, but before any 
$(call ...) lines at the end of the file:

PRODUCT_PACKAGES += dropbear

Now that you've added the dropbear package to the build, you need to add 
the source code for dropbear.  All of the extra external packages like 
dropbear are in the "external" directory of the Android source tree.  If 
you don't have an "external/dropbear" directory there, you can fetch the 
dropbear git repo from AOSP.  When the dropbear package has been added and 
you've modified device.mk to include the dropbear package, run your lunch 
command again and rebuild the system.  It will now include the dropbear 
binaries.  Make sure that an Android.mk file exists in your 
external/dropbear directory, since this is the makefile used by the Android 
build system to build each Android component.  If you don't have an 
Android.mk file, you downloaded dropbear from somewhere on the internet, 
rather than pulling it from AOSP.

You'll need to create your SSL keys, copy all of the dropbear files over to 
your Android system, and modify the init.rc file to launch the dropbear 
daemon at the appropriate time.  Just google a bit and you'll see many 
people that are installing dropbear to their rooted Android systems.  I am 
not going to walk you through these steps because it varies from Android 
system to system and there are plenty of examples out there to help you.

Andrew


On Wednesday, November 19, 2014 1:43:25 AM UTC-5, lik...@gmail.com wrote:
>
> Hi Andrew.
>
> Could you please tell me how can i add dropbear support for android 4.4 
> running on linux 3.2 kernel.
>
> Looking for a quick response from your end..
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

I have built a new microSD card image for BBBAndroid 
(bbbandroid_111514.img), and it is now available for download.  Just follow 
the link at bbbandroid.org to download it.

In this build, USB ADB support is working just fine.  I've been able to 
connect with the BBB using both command-line ADB and ADB through the 
Eclipse ADT under both Windows and Linux.  You can push/pull files, 
install/reinstall apps, get logcat output, shell, etc. using the USB cable 
that came with your BBB board.  If you want a root shell on Android, the 
ADB shell is the way to go.

I changed the USB ID to 18D1:4E23 for the BBB device when BBBAndroid is 
being used.  These are the same USB vendor and device IDs as a Google Nexus 
S.  The reason that I changed this is to make life much easier for the 
Windows users.  Each phone vendor provides their own drivers for USB ADB, 
and it was difficult for the Windows users to get the drivers set up 
properly.  This should make things much easier for them.  Linux users never 
had a problem with it, since their USB ADB worked right out of the box.

I also shrunk the image to 7.6 GB to accommodate everyone that was having 
difficulty writing the 8 GB image to their microSD cards that were actually 
a little bit smaller than 8 GB.

Andrew


On Sunday, September 28, 2014 11:14:24 AM UTC-4, Andrew Henderson wrote:
>
> Hello all. I have released a new port of Android for the BBB.  This 
> version uses AOSP 4.4.4 (KitKat) and the 3.8 Linux kernel. I have made 
> build instructions and a pre-made image available at 
> http://www.bbbandroid.org.  I use a combination of AOSP repos and Rowboat 
> build scripts, and I have a few custom repos for the kernel, bootloader, 
> and additional "external" tools (such as i2c-tools).  You can view the repo 
> manifest XML file for the project here:
>
>
> https://github.com/hendersa/bbbandroid-manifest/blob/master/bbbandroid-aosp-4.4.4_r1-3.8.xml
>
> Because this Android image uses the 3.8 kernel, you should be able to just 
> plug in your capes and go without any hassle:
>
> Built-in HDMI cape:
> http://i.imgur.com/q4AZQ95.jpg
>
> 4D Systems LCD capes:
> 4DCAPE-43T: http://i.imgur.com/6qHmgqX.jpg
> 4DCAPE-70T: http://i.imgur.com/UZLG7Or.jpg
>
> CircuitCo LCD capes:
> LCD3: http://i.imgur.com/LC7SrBB.jpg 
> LCD4: http://i.imgur.com/1xBQ8R6.jpg
> LCD7: http://i.imgur.com/vxoqROE.jpg
>
> Andrew
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Audio from HDMI connected Beagleboard Black

[Andrew Henderson]

Please review this: http://elinux.org/Beagleboard:BeagleBoneBlack_HDMI

Only the two CEA modes listed in that resolution list support audio.  If 
your display is not at one of those two resolutions, there will not be any 
audio.  The 720x480 video mode was supported in the 3.8 kernel and also had 
audio, but this mode is no longer supported.  If no EDID block is received 
by the BBB from your display, the Linux kernel defaults to 1024x768, which 
is a non-CEA mode (which won't have audio). 

On Thursday, November 13, 2014 11:46:15 AM UTC-5, anil kumar wrote:
>
> Recently i bought Beagle Bone Black, with which i connected my HDMI TV to 
> BBB.. I am unable to get any audio from the connections i made.. do we get 
> any audio from BBB after making the above connections? Or we require extra 
> hardware to get the audio? Please help me out.. thank you
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Cross-compiling SDL 1.2 for BBB.

[Andrew Henderson]

I build SDL1.2 natively on the BBB for BeagleSNES.  I use the framebuffer 
for video, ALSA audio, and the joystick subsystem without any issue.  I 
have not tried the X11 video target because I have only worked with the 
framebuffer, but there isn't a reason why it would not work just as well.

There is currently no framebuffer target in 2.0.  I have added a 
rudimentary BeagleBone Black video target to my 2.0 codebase as I continue 
to work on getting the kinks worked out of the SGX-based OpenGL ES on the 
framebuffer with the 3.17 kernel.  With the features of the BBB still in 
flux, I would stick with 1.2 for your development for now.

Disable as much of SDL as you can via the configure script when you build 
natively.  I don't remember having to enable swap to build SDL, though I 
definitely have to enable it to build BeagleSNES natively.  I had to pull 
in a few dev packages to get the headers that I needed to build SDL, but it 
has been so long since I have done it that I don't remember which ones.

Andrew

On Sunday, November 2, 2014 5:04:59 PM UTC-5, abald...@gmail.com wrote:
>
> Hi,
>
> I've been trying to setup my cross-compile tool chain for programming on 
> the BBB through a Linux Mint box with Eclipse running in VMPlayer. So far 
> I've been able to configure almost all the needed components properly to 
> cross-compile and deploy using g++-4.8-arm-linux-gnueabihf (for some reason 
> the non 'hf' version doesn't work-- I admit I am still trying to 
> differentiate between the various flavors of arm out there that are 
> represented by the compilers).
>
> However, I can't seem to quite get/find a cross-complied version of the 
> SDL lib (I know SDL2) doesn't work on the BBB.
>
> I found this  page with 
> some instructions, but it doesn't seem to work quite right for me either. 
> Further, I know there is a version of SDL 1.2 that can be apt-get from the 
> BBB itself-- but of course this doesn't help when wanting to try to 
> cross-compile rather than compile directly on the BBB.
>
> Lastly, though I've been able to find some rather easy/straight forward 
> instructions 
> for the Raspberry Pi 
> , I can't 
> seem to find anything comparable for the Debian version of BB.
>
> Does anyone happen to have any recommendations or suggestions?
>
> Thanks-
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Unable to deploy Android image on beaglebone black

[Andrew Henderson]

You can certainly write the Android image to the eMMC, though I have not 
set up the scripts to perform the partitioning and writing.  You'll also be 
limited to the 4GB of the newest BBB's eMMC.  Because the AOSP KitKat 
includes more software than JellyBean does, I don't think you'll be able to 
fit it onto the 2GB eMMC of earlier BBB revisions without removing some 
packages.  I follow the Rowboat project's partitioning scheme, which is a 
bit different than the default partitioning scheme of AOSP.  I combine the 
rootfs and system partitions into one, for example.  My suggestion would be 
to take a look at Chris Simmonds's fine tutorial to install KitKat to the 
eMMC and then change the kernel and bootloader to the ones from my image 
(with a modified uEnv.txt for eMMC booting and disabling SGX).  Take a look 
at his readme here to see how to get things set 
up: https://github.com/csimmonds/bbb-android-device-files/tree/kk4.4-fastboot

I have not looked into the details of writing Android to the eMMC because I 
try to package my Android images for ease of prototyping.  This means that 
you should be able to have multiple copies of Android on various microSD 
cards and be able to swap them quickly and easily to try different things. 
 It also means that you can always mount the microSD card on a desktop 
Linux system to make any modifications that you want without fighting to 
get into the eMMC to make your changes.  So, I don't have any plans to add 
writing to the eMMC in the immediate future.

Andrew

On Thursday, October 30, 2014 2:47:46 AM UTC-4, Prasad Marathe wrote:
>
> Hello,
>
> Thanks for your immediate response. I follow the steps mentioned by you 
> and try to deploy latest image on sd card. Now i am able to boot Android 
> 4.4 Kitkat on my Beagelbone black through Micro SD card. I follow the steps 
> mentioned in http://elinux.org/Beagleboard:Android but unable to deploy 
> image from micro sd card to eMMC. Could you help me to solve this issue?
> Is there any other way to deploy android image on eMMC?
>
> Kindly reply as early as possible. Awaiting for your response.
>
>
> On Tue, Oct 21, 2014 at 8:57 PM, Andrew Henderson  > wrote:
>
>> There is a newer version of Android available.  The version referenced on 
>> the elinux.org page is JellyBean 4.2.2, and the newer one is KitKat 
>> 4.4.4.  You can get the newer one at bbbandroid.org.
>>
>> The easiest way to troubleshoot this sort of thing is to use an FTDI 
>> cable to monitor the BBB during boot.  This will allow you to capture the 
>> debug output from the bootloader and the kernel.  Since you are using 
>> Windows XP, you won't be able to natively mount the partitions of your 
>> microSD card and look at them to ensure that you wrote the image properly.  
>> You could try using an application like Linux Reader to see the partitions 
>> on your Win32 machine: http://www.diskinternals.com/linux-reader.
>>
>> You need to verify two things: 
>>
>> 1. Did you write the image properly to the microSD card?  There can be a 
>> few causes for this, including not decompressing the image prior to writing 
>> and getting a bad write to the microSD card.  If you can see the four 
>> partitions (one VFAT, three EXT4), then you probably wrote the image OK.
>>
>> 2. Is the bootloader at least getting into kernel boot?  You'll need to 
>> see the FTDI output to determine this.
>>
>> Andrew
>>  
>>
>> On Tuesday, October 21, 2014 5:03:56 AM UTC-4, Prasad Marathe wrote:
>>>
>>>
>>> Hello,
>>>
>>> I am trying to deploy Android image on beaglebone black as mentioned in 
>>> http://elinux.org/Beagleboard:Android this URL. But after following the 
>>> steps mentioned, User LED's are not blinking. So i am not able to deploy 
>>> the image on beaglebone black. kindly help to sort this issue.
>>> I am using following tools for deployment:
>>>
>>> Host machine - 32 bit Windows XP service pack 3
>>> Beaglebone black - rev 00A5 S/N 2014BBBK0661 running BoneScript 0.2.4 at 
>>> 192.168.7.2
>>> OS on eMMC - Debian
>>> Supply - 5V 2A Adapter
>>> SD card used for Android image deployment - 8GB class 4 SanDisk Micro SD 
>>> card
>>>
>>  -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/beagleboard/_74iD6epCPo/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 

[beagleboard] Re: Memory Mapped Access to /dev/mem GPIO2 fails, GPIO1 OK

[Andrew Henderson]

I have found that accessing GPIOs via mmap() of /dev/mem works without 
accessing additional control register settings if you export one GPIO pin 
in each bank so that the GPIO kernel driver "unlocks" each bank and wakes 
it up.  GPIO1 is awake by default, but you can get the other GPIO0, GPIO2, 
and GPIO3 working via the following commands:

echo 5 > /sys/class/gpio/export
echo 65 > /sys/class/gpio/export
echo 105 > /sys/class/gpio/export

I do the same with Android in the init.{ro.hardware}.rc file:

write /sys/class/gpio/export 5
write /sys/class/gpio/export 65
write /sys/class/gpio/export 105

As for running those commands under Linux, I usually place the commands to 
export the pins into a shell script that also launches the application that 
uses the GPIOs.  Since you have to be root to mmap() the pages with GPIO 
control registers, you can run the shell script via sudo and have the 
script export the pins and then launch your binary.  You could also place 
the commands in the /etc/rc.local startup script or the like, if you want.

Andrew

On Wednesday, October 29, 2014 1:49:16 PM UTC-4, Nic Cyn wrote:
>
> Success!!! Thank you very much! - this works. I really appreciate your 
> advice. I absolutely would not have got this sorted without it.
>
> I am going to write up a summary and post it on this thread so that 
> anybody else that runs into this issue can find it. However I do have a 
> couple more questions - if you (or anybody) have the time to provide any 
> insights you might have.
>
>
>- The CM_PER_GPIO1_CLKCTRL at 0x44e0[0xac] for Bank GPIO1 is 
>already set, yet the equivalents for GPIO2 and GPIO3 are not. Any idea how 
>CM_PER_GPIO1_CLKCTRL got set?
>- Are there any Device Tree settings that you know of that can set the 
>CLKCTRLs for GPIO2 and GPIO3 at boot up?
>- There is no CM_PER_GPIO0_CLKCTRL for the GPIO0 bank. I gather GPIO0 
>is something of a special case due to the wakeup capabilities it contains. 
>Is the GPIO0 bank always enabled? Any thoughts on why GPIO0 is not there?
>- Your example OR'ed with 0x40002 - presumably to place it in standby 
>- rather than fully active. I am curious - under what circumstances would 
>you want to put a CLKCTRL in standby mode?
>- Do you have any idea why /dev/mem would fail to access GPIO3 if the 
>CLKCTRL was not set and yet SYSFS can read the GPIO states on GPIO3? 
>Obviously SYSFS is a device driver and does not need to hit /dev/mem but 
>even so it appears the CLKCTRL is used to transfer the state off the 
>physical pin and into the GPIO bank so why would SYSFS work if the clock 
> is 
>disabled. 
>- You must have run into this issue yourself. How on earth did you 
>figure out that it was the CLKCTRL registers? The reason I ask I I would 
>like to know how to diagnose this sort of thing myself and it all seems 
>such a mystery at the moment.
>
>
> Once again many thanks.
>
>
>
> On Tuesday, 28 October 2014 21:28:19 UTC, bris...@yahoo.com.au wrote:
>>
>> This is out of a program I use - 
>> Enter code here...
>> uint32_t *clock_gpio3;
>> clock_gpio3 = (uint32_t *) mmap(NULL, 0x1000, PROT_READ | PROT_WRITE, 
>> MAP_SHARED, fd, 0x44E0);
>> clock_gpio3[0x2d] |= 0x40002; // 2d is b4 divide by 4 because it is a 
>> byte offset
>>
>>
>>
>>
>>
>>
>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

Yes, that is the expected output.  You're through most of the boot process 
if zygote is started.  Therefore, you aren't experiencing bootloader or 
kernel problems.

Can you describe the problem that you are seeing in more detail?  Do you 
see anything on the screen at all?  You should see the "Android" animation 
screen while the system is starting up.  If you aren't seeing anything at 
all on the screen, then you might be having HDMI issues (like a bad cable 
that isn't reporting EDID information fro your display to the BBB). Look 
back through your FTDI log and look for any messages regarding tilcdc.  If 
you see something like this:

[3.680634] tilcdc 4830e000.lcdc: found TDA19988
[3.686131] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[3.693072] [drm] No driver support for vblank timestamp query.
[3.699640] tilcdc 4830e000.lcdc: No connectors reported connected with 
modes
[3.707162] [drm] Cannot find any crtc or sizes - going 1024x768
[3.722056] Console: switching to colour frame buffer device 128x48
[3.733792] tilcdc 4830e000.lcdc: fb0:  frame buffer device

... then you are experiencing a cable problem.

If you can see the "Android" animation screen and that screen never exits, 
then let me know and we can troubleshoot from there.  But this:

[   44.074598] init: sys_prop: permission denied uid:1003  
name:service.bootanim.exit

... tells me that your animation screen finished and that the system booted 
up properly.

Andrew


On Tuesday, October 21, 2014 12:48:59 AM UTC-4, lik...@gmail.com wrote:
>
> Hi Andrew,
>
> Thanks for the reply.
>
> The only log for zygote that i can see in my FTDI output is: 
>
> [   23.539523] warning: `zygote' uses 32-bit capabilities (legacy support 
> in use)
>
> Then some other logs like:
>
> [   44.074598] init: sys_prop: permission denied uid:1003  
> name:service.bootanim.exit
>
> Is this the expected output??
>
> On Tuesday, 21 October 2014 06:49:52 UTC+5:30, Andrew Henderson wrote:
>>
>> I don't see any errors that are out of the ordinary in your FTDI output. 
>>  How long did you wait before giving up?  If there is a failure on the 
>> first boot, you should see some sort of failure beyond that in the log. 
>>  You can also run logcat from the FTDI shell to get some more details.  If 
>> you see that zygote is started in your log, you're well on your way.  It 
>> takes several minutes on the first boot before the top level screen comes 
>> up.  Until then, you just see the "Android" animation on the screen.
>>
>> The FTDI shell belong to the "shell" user and group, not root.  If you'd 
>> like to use root, plug in your USB cable and use ADB to shell in to the 
>> system.
>>
>> Andrew
>>
>>
>> On Monday, October 20, 2014 3:26:22 AM UTC-4, lik...@gmail.com wrote:
>>>
>>>
>>> Hi Andrew,
>>>
>>> Thanks very much for the great work.
>>>
>>> Now i am trying to port AOSP 4.4.4 (KitKat) for the BBB by using your 
>>> repo manifest XML file. I built the U-boot, Kernel Successfully and also 
>>> created the Filesystem.  But the problem is after putting all the built 
>>> images into the microSD card, while booting i am getting some errors. i 
>>> think it is not booting upto the android level, as it is getting stuck 
>>> somewhere else. please take a look at the errors: 
>>>
>>> [2.847248]   #0: TI BeagleBone Black
>>> [3.559459] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data 
>>> mode. Opts: (null)
>>> [3.568018] VFS: Mounted root (ext4 filesystem) on device 179:2.
>>> [3.575446] devtmpfs: mounted
>>> [3.578863] Freeing init memory: 244K
>>> [4.602721] init (1): /proc/1/oom_adj is deprecated, please use 
>>> /proc/1/oom_score_adj instead.
>>> [4.705862] init: /dev/hw_random not found
>>> [4.710863] init: cannot open '/initlogo.rle'
>>> [4.823625] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data 
>>> mode. Opts: nomblk_io_submit,errors=panic
>>> [4.862816] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
>>> [4.886477] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
>>> [4.893231] init: /dev/hw_random not found
>>> [4.923083] init: cannot find '/system/bin/sgx/rc.pvr', disabling 
>>> 'pvr'
>>> [4.934643] init: cannot find '/system/bin/rild', disabling 
>>> 'ril-daemon'
>>> [4.948132] healthd: wakealarm_init: timerfd_create failed
>>> [4.958423] healthd: No charger sup

[beagleboard] Re: Unable to deploy Android image on beaglebone black

[Andrew Henderson]

There is a newer version of Android available.  The version referenced on 
the elinux.org page is JellyBean 4.2.2, and the newer one is KitKat 4.4.4. 
 You can get the newer one at bbbandroid.org.

The easiest way to troubleshoot this sort of thing is to use an FTDI cable 
to monitor the BBB during boot.  This will allow you to capture the debug 
output from the bootloader and the kernel.  Since you are using Windows XP, 
you won't be able to natively mount the partitions of your microSD card and 
look at them to ensure that you wrote the image properly.  You could try 
using an application like Linux Reader to see the partitions on your Win32 
machine: http://www.diskinternals.com/linux-reader.

You need to verify two things: 

1. Did you write the image properly to the microSD card?  There can be a 
few causes for this, including not decompressing the image prior to writing 
and getting a bad write to the microSD card.  If you can see the four 
partitions (one VFAT, three EXT4), then you probably wrote the image OK.

2. Is the bootloader at least getting into kernel boot?  You'll need to see 
the FTDI output to determine this.

Andrew
 

On Tuesday, October 21, 2014 5:03:56 AM UTC-4, Prasad Marathe wrote:
>
>
> Hello,
>
> I am trying to deploy Android image on beaglebone black as mentioned in 
> http://elinux.org/Beagleboard:Android this URL. But after following the 
> steps mentioned, User LED's are not blinking. So i am not able to deploy 
> the image on beaglebone black. kindly help to sort this issue.
> I am using following tools for deployment:
>
> Host machine - 32 bit Windows XP service pack 3
> Beaglebone black - rev 00A5 S/N 2014BBBK0661 running BoneScript 0.2.4 at 
> 192.168.7.2
> OS on eMMC - Debian
> Supply - 5V 2A Adapter
> SD card used for Android image deployment - 8GB class 4 SanDisk Micro SD 
> card
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

I don't see any errors that are out of the ordinary in your FTDI output. 
 How long did you wait before giving up?  If there is a failure on the 
first boot, you should see some sort of failure beyond that in the log. 
 You can also run logcat from the FTDI shell to get some more details.  If 
you see that zygote is started in your log, you're well on your way.  It 
takes several minutes on the first boot before the top level screen comes 
up.  Until then, you just see the "Android" animation on the screen.

The FTDI shell belong to the "shell" user and group, not root.  If you'd 
like to use root, plug in your USB cable and use ADB to shell in to the 
system.

Andrew


On Monday, October 20, 2014 3:26:22 AM UTC-4, lik...@gmail.com wrote:
>
>
> Hi Andrew,
>
> Thanks very much for the great work.
>
> Now i am trying to port AOSP 4.4.4 (KitKat) for the BBB by using your repo 
> manifest XML file. I built the U-boot, Kernel Successfully and also created 
> the Filesystem.  But the problem is after putting all the built images into 
> the microSD card, while booting i am getting some errors. i think it is not 
> booting upto the android level, as it is getting stuck somewhere else. 
> please take a look at the errors: 
>
> [2.847248]   #0: TI BeagleBone Black
> [3.559459] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data 
> mode. Opts: (null)
> [3.568018] VFS: Mounted root (ext4 filesystem) on device 179:2.
> [3.575446] devtmpfs: mounted
> [3.578863] Freeing init memory: 244K
> [4.602721] init (1): /proc/1/oom_adj is deprecated, please use 
> /proc/1/oom_score_adj instead.
> [4.705862] init: /dev/hw_random not found
> [4.710863] init: cannot open '/initlogo.rle'
> [4.823625] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data 
> mode. Opts: nomblk_io_submit,errors=panic
> [4.862816] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
> [4.886477] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
> [4.893231] init: /dev/hw_random not found
> [4.923083] init: cannot find '/system/bin/sgx/rc.pvr', disabling 'pvr'
> [4.934643] init: cannot find '/system/bin/rild', disabling 'ril-daemon'
> [4.948132] healthd: wakealarm_init: timerfd_create failed
> [4.958423] healthd: No charger supplies found
> [4.967361] init: cannot find '/system/etc/install-recovery.sh', 
> disabling 'flash_recovery'
> [4.979856] healthd: BatteryStatusPath not found
> [4.989605] healthd: BatteryHealthPath not found
> [4.998759] init: property 'sys.powerctl' doesn't exist while expanding 
> '${sys.powerctl}'
> [5.012524] healthd: BatteryPresentPath not found
> [5.018248] healthd: BatteryCapacityPath not found
> [5.023926] init: powerctl: cannot expand '${sys.powerctl}'
> [5.030486] healthd: BatteryVoltagePath not found
> [5.035933] init: property 'sys.sysctl.extra_free_kbytes' doesn't exist 
> while expanding '${sys.sysctl.extra_free_kbytes}'
> [5.047582] healthd: BatteryTemperaturePath not found
> [5.053002] healthd: BatteryTechnologyPath not found
> [5.058308] init: cannot expand '${sys.sysctl.extra_free_kbytes}' while 
> writing to '/proc/sys/vm/extra_free_kbytes'
> [5.069792] binder: 91:91 transaction failed 29189, size 0-0
> [5.076145] init: property 'sys.sysctl.tcp_def_init_rwnd' doesn't exist 
> while expanding '${sys.sysctl.tcp_def_init_rwnd}'
> [5.088106] init: cannot expand '${sys.sysctl.tcp_def_init_rwnd}' while 
> writing to '/proc/sys/net/ipv4/tcp_default_init_rwnd'
> *shell@beagleboneblack:/ $*
>
> I am expecting *root@android* over here, whereas i am getting 
> *shell@beagleboneblack* in this case
>
> Could you please help me out on this. Expecting a quick response from your 
> end..
>
>
> After 
> On Sunday, 28 September 2014 20:44:24 UTC+5:30, Andrew Henderson wrote:
>>
>> Hello all. I have released a new port of Android for the BBB.  This 
>> version uses AOSP 4.4.4 (KitKat) and the 3.8 Linux kernel. I have made 
>> build instructions and a pre-made image available at 
>> http://www.bbbandroid.org.  I use a combination of AOSP repos and 
>> Rowboat build scripts, and I have a few custom repos for the kernel, 
>> bootloader, and additional "external" tools (such as i2c-tools).  You can 
>> view the repo manifest XML file for the project here:
>>
>>
>> https://github.com/hendersa/bbbandroid-manifest/blob/master/bbbandroid-aosp-4.4.4_r1-3.8.xml
>>
>> Because this Android image uses the 3.8 kernel, you

[beagleboard] Re: BBB standard Angstrom: how to launch the X desktop and are there any emulators for console/computer?

[Andrew Henderson]

Hello Karl.  There are several emulators that run OK, but could run much 
faster with some tuning.  Basically, any of the SDL-based ones that can use 
a framebuffer target will probably work OK.  I've found that you need to 
hack on them a bit to get decent performance, though.  I think that you are 
out of luck on the N64 for now, since we're still sorting out some details 
on capes for the 3.14/3.17 kernels that have SGX support for OpenGL ES and 
EGL support.  The N64 would run too slowly using software rendering, but it 
might run semi-acceptably with an accelerated OpenGL ES.

Here is my BeagleSNES emulator system for SNES 
titles: https://www.youtube.com/watch?v=f8IbhJ7xH6g
I am also taking performance measurements on a few other platforms and 
doing some tuning: https://www.youtube.com/watch?v=5kjJrflm5mU

I would not worry about using X.  Instead, look at emulators that can run 
on the framebuffer.

Andrew

On Monday, October 6, 2014 4:10:49 AM UTC-4, Karl Longen wrote:
>
> I was able after 3 attempts to find a way to have the X server to run.
>
> Looks like the Angstrom build start as soon as you put the card in the 
> BBB; and at the same time it is flashing the internal memory. This threw me 
> off track, since the restore on the internal memory was not completed, and 
> this caused the OS to boot incomplete.
>
> Now I am just trying to figure out if there are emulators for the BBB, in 
> particular for Amiga, Nintendo 64 and Sega Genesis.
>
> Thanks.
>
>
> On Saturday, October 4, 2014 1:05:15 AM UTC-7, Karl Longen wrote:
>>
>> I wiped my internal memory for the BBB, to try 
>> Debian(BBB-eMMC-flasher-debian-7.5-2014-05-14-2gb), but I discovered that 
>> Debian was made to run on 2 GB, but on the Rev C, which has 4 GB of 
>> memory...My BBB was basically running with 120 MB free, which is unusable.
>>
>> So I decided to put back the 2 GB Angstrom version on it. But I see that 
>> at boot I get no desktop...how do I install the desktop on Angstrom distro? 
>> (I have the BBB-eMMC-flasher-2013.09.04.img).
>>
>> Also, is there any emulator for the BBB? I would like to have few roms to 
>> play old classics, especially for Amiga, Genesis and Super Nintendo. I know 
>> about Linux version for various emulator (I use Ubuntu on virtual machine), 
>> but I don't see version either for Angstrom nor ARM/BBB.
>>
>> I even tried the ubuntu release, running on SD card; which has a desktop 
>> pre-configured, but it is quite slow and also has no emulator whatsoever.
>>
>> Any help would really make my day, I've been banging my head for the past 
>> 10 hours to make it happen.
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

One thing that I should note is that if you use ADB to push files over to 
the BBB, you must be sure that the permissions of the file that you pushed 
are set correctly after the transfer.  If you are pushing the 
init.generic*.rc files over, you must do something like:

$ adb shell
root@beagleboneblack:/ # chmod 750 init.genericam33xx\(flatteneddevicetr.rc

If the permissions are too "permissive", the "import" command in init.rc 
will refuse to include the init.generic*.rc file because it is a security 
risk.  If the init.generic*.rc file isn't included, then ADB won't start, 
and you are effectively prevented from using ADB at that point.  You'll 
have to mount the EXT4 partition under Linux to fix the permissions.  Be 
careful!

Andrew

On Sunday, October 12, 2014 9:50:55 PM UTC-4, Andrew Henderson wrote:
>
> The "rootfs" filesystem (the / filesystem) is set to read-only once you 
> reach the post-fs phase of boot.  This is why you can't ADB push to it.  
> I've been on the fence as to whether I should remount this as read-write, 
> and I suppose that I probably should.  Since I'm trying to open up this 
> Android a bit to make it easier for people to experiment with, it is 
> reasonable to do so.  It also allows the Windows people who can't easily 
> mount EXT4 to make changes to their Android system via ADB.
>
> Look at your init.genericam33xx(flatteneddevicetr.rc file at around line 
> 36:
>
> # we will remap this as /storage/sdcard0 with the sdcard fuse tool
> mkdir /data/media 0770 media_rw media_rw
> chown media_rw media_rw /data/media
>
> # Set indication (checked by vold) that we have finished this action
> setprop vold.post_fs_data_done 1
>
> Right before that "# Set indication ..." line, add these two lines:
>
> # BBBAndroid: Remount the rootfs as rw for ADB push of files to /
> mount rootfs rootfs / rw remount
>
> This will remount / as read-write.  The original remount to read-only 
> occurs in init.rc, but you generally don't want to change the standard .rc 
> files, so I override all of the defaults in the platform-specific .rc 
> files.  I just pushed this change up to the repo: 
> https://github.com/hendersa/bbbandroid-vendor-ti-beagleboneblack-aosp
>
> I have not checked into the nav bar issue, but I know that I have seen it 
> in some resolutions and not in others.  Maybe try a different resolution?  
> I'll see it at 720x480, for example, when using HDMI.  But I won't see it 
> at the much higher resolutions (1920x1080, I think).  
>
> Andrew
>
>
> On Monday, October 13, 2014 1:13:44 AM UTC, Lei Wang wrote:
>>
>> Hi Andrew,
>>
>> I rebuild the BBBAndroid and created my own image. The ADB USB does work 
>> after I replaced those (3) files you attached earlier. It is a very good 
>> news. 
>> But I did find out that I couldn't push file thru the ADB push. I tried 
>> both the eclipse ADT and command line. Neither works. I've got some 
>> information like,
>>
>> E:\Program Files\Android\android-sdk\platform-tools>adb push 
>> "init.genericam33xx
>> (flatteneddevicetr.rc" /init.genericam33xx(flatteneddevicetr.rc
>> failed to copy 'init.genericam33xx(flatteneddevicetr.rc' to 
>> '/init.genericam33xx
>> (flatteneddevicetr.rc': Read-only file system
>>
>> Another minor issue is that the navigation bar is not shown in the 
>> interface. I double checked the images you attached. I couldn't find 
>> navigation bar either. I had same issue with TI's stock image (Kernel 3.2 
>> based). I added a line to the  
>> init.am335xevm.rc: "setprop lcd.landscape true", which fixed the problem (
>> https://gitorious.org/rowboat/vendor-ti-am335xevm/commit/53391ade1b440e94c73db59444bf72529ce9ff32).
>>  
>> I did the same to the init.generic*.rc file. However it didn't work this 
>> time. I wonder if you know how to bring the navigation bar back.
>>
>>
>>
>> Thanks a lot!
>>
>> Lei
>>
>>
>> On Sunday, October 12, 2014 1:03:54 PM UTC-4, Andrew Henderson wrote:
>>>
>>> I'll have to make the next pre-made image a little smaller than the full 
>>> capacity of my microSD cards because so many of the manufacturers are being 
>>> very liberal on exactly how many bytes they consider 8GB to be...
>>>
>>> I have a Realtek RTL8188CUS USB wifi dongle sitting here (an Edimax 
>>> EW-7811 of some sort, I believe), so I'll check into getting it set up for 
>>> you when I have a few minutes.  The kernel modules are actually already 
&g

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

The "rootfs" filesystem (the / filesystem) is set to read-only once you 
reach the post-fs phase of boot.  This is why you can't ADB push to it.  
I've been on the fence as to whether I should remount this as read-write, 
and I suppose that I probably should.  Since I'm trying to open up this 
Android a bit to make it easier for people to experiment with, it is 
reasonable to do so.  It also allows the Windows people who can't easily 
mount EXT4 to make changes to their Android system via ADB.

Look at your init.genericam33xx(flatteneddevicetr.rc file at around line 36:

# we will remap this as /storage/sdcard0 with the sdcard fuse tool
mkdir /data/media 0770 media_rw media_rw
chown media_rw media_rw /data/media

# Set indication (checked by vold) that we have finished this action
setprop vold.post_fs_data_done 1

Right before that "# Set indication ..." line, add these two lines:

# BBBAndroid: Remount the rootfs as rw for ADB push of files to /
mount rootfs rootfs / rw remount

This will remount / as read-write.  The original remount to read-only 
occurs in init.rc, but you generally don't want to change the standard .rc 
files, so I override all of the defaults in the platform-specific .rc 
files.  I just pushed this change up to the repo: 
https://github.com/hendersa/bbbandroid-vendor-ti-beagleboneblack-aosp

I have not checked into the nav bar issue, but I know that I have seen it 
in some resolutions and not in others.  Maybe try a different resolution?  
I'll see it at 720x480, for example, when using HDMI.  But I won't see it 
at the much higher resolutions (1920x1080, I think).  

Andrew


On Monday, October 13, 2014 1:13:44 AM UTC, Lei Wang wrote:
>
> Hi Andrew,
>
> I rebuild the BBBAndroid and created my own image. The ADB USB does work 
> after I replaced those (3) files you attached earlier. It is a very good 
> news. 
> But I did find out that I couldn't push file thru the ADB push. I tried 
> both the eclipse ADT and command line. Neither works. I've got some 
> information like,
>
> E:\Program Files\Android\android-sdk\platform-tools>adb push 
> "init.genericam33xx
> (flatteneddevicetr.rc" /init.genericam33xx(flatteneddevicetr.rc
> failed to copy 'init.genericam33xx(flatteneddevicetr.rc' to 
> '/init.genericam33xx
> (flatteneddevicetr.rc': Read-only file system
>
> Another minor issue is that the navigation bar is not shown in the 
> interface. I double checked the images you attached. I couldn't find 
> navigation bar either. I had same issue with TI's stock image (Kernel 3.2 
> based). I added a line to the  
> init.am335xevm.rc: "setprop lcd.landscape true", which fixed the problem (
> https://gitorious.org/rowboat/vendor-ti-am335xevm/commit/53391ade1b440e94c73db59444bf72529ce9ff32).
>  
> I did the same to the init.generic*.rc file. However it didn't work this 
> time. I wonder if you know how to bring the navigation bar back.
>
>
>
> Thanks a lot!
>
> Lei
>
>
> On Sunday, October 12, 2014 1:03:54 PM UTC-4, Andrew Henderson wrote:
>>
>> I'll have to make the next pre-made image a little smaller than the full 
>> capacity of my microSD cards because so many of the manufacturers are being 
>> very liberal on exactly how many bytes they consider 8GB to be...
>>
>> I have a Realtek RTL8188CUS USB wifi dongle sitting here (an Edimax 
>> EW-7811 of some sort, I believe), so I'll check into getting it set up for 
>> you when I have a few minutes.  The kernel modules are actually already 
>> sitting in the image, so you should be able to insmod them from within the 
>> init.{ro.hardware}.rc file.
>>
>> Andrew
>>
>> On Sunday, October 12, 2014 12:45:54 PM UTC-4, Altaf wrote:
>>>
>>> Hello, 
>>> Great work appreciate. 
>>> It would be awesome if you can add USB WiFi Support for Atheros AR9271  
>>> or Realtek RTL8188CUS Based Device
>>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

I'll have to make the next pre-made image a little smaller than the full 
capacity of my microSD cards because so many of the manufacturers are being 
very liberal on exactly how many bytes they consider 8GB to be...

I have a Realtek RTL8188CUS USB wifi dongle sitting here (an Edimax EW-7811 
of some sort, I believe), so I'll check into getting it set up for you when 
I have a few minutes.  The kernel modules are actually already sitting in 
the image, so you should be able to insmod them from within the 
init.{ro.hardware}.rc file.

Andrew

On Sunday, October 12, 2014 12:45:54 PM UTC-4, Altaf wrote:
>
> Hello, 
> Great work appreciate. 
> It would be awesome if you can add USB WiFi Support for Atheros AR9271  
> or Realtek RTL8188CUS Based Device
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

Right now, I don't have any plans to flash the eMMC.  BBBAndroid is 
currently intended to be a prototyping platform, so I'd prefer to make the 
entire OS easily removable in case you need to mount it on a different 
machine and fix any changes that you made to .rc, .dtbo, or .ko files in 
the rootfs file system.  SGX support is planned, as soon as the 3.14/3.17 
kernels move a little further along.  I plan on moving all of my projects 
to the newer kernels once all of the features that I need are there.

On Friday, October 10, 2014 12:10:18 AM UTC-4, Adam Singer wrote:
>
> Wow great job Andrew! Just ran with this image with ease. Is there 
> anything built in that can be used to flash to eMMC? Any plans to integrate 
> with the SGX drivers for better graphics drivers?
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Access GPIO/SPI etc. on Expansion Header

[Andrew Henderson]

To be fair, using spidev to set up SPI and then bitbanging it from 
userspace is, at best, a very unorthodox approach.  It just happened to be 
suited to the particular problem that I trying to solve.  I can completely 
understand how such an approach would be viewed with some distaste by 
experienced kernel developers as it is far from the a standard approach to 
the problem.  And they really aren't wrong.  It isn't the correct way to 
develop a generalized solution.  I was just curious as to whether anyone 
else had attempted it and what their results were like.  

The particular project that required my SPI tinkering finished quite a 
while ago and it worked like a charm, so I'll just chalk it up as a 
learning experience and leave it at that.  The BBB, kernel code, etc. are 
all there for you to play around with.  Try crazy stuff out and have fun 
with it.  Some will work out OK and some won't, but you won't know until 
you give it a shot.

On Thursday, October 9, 2014 2:54:05 PM UTC-4, William Hermans wrote:
>
> *Well, I have gotten it working before using mmap() calls because I had a 
>> very specific need for it for a proprietary project that I can't share the 
>> code for, but I was informed (in no uncertain terms) that using mmap() for 
>> SPI comms in user space is a bad idea and that I am not a smart person:*
>>
>
> Isnt it funny how when you *may* ask these people who responded to you 
> post they would not offer any assistance. But as soon as you put up working 
> code for something that works for you, Suddenly everyone is offering their 
> "help"
>
> Personally, I can see several flaws with using mmap in any situation. But 
> if it works for you, and works well. I say to hell with what anyone else 
> says. So long as it's abstracted, and no one else has to maintain it.
>
> I keep seeing the same text from the same person "how very unlinix like of 
> you" or some such garbage. Sorry, I can not disagree more. First of all, 
> mmap was created for a reason. This reason has nothing to do with critiques 
> on user implementation while using it. Secondly, Linux is about freedom, 
> not one individuals "dictatorship" or misconception of what Linux should be.
>
> Also, I've seen some implementations many of the commentators of the post 
> you linked to and . . . yeah let us just say that some of the stuff I have 
> seen is far from perfect. So many of them do not have a leg to stand on 
> when it comes to criticizing someone else's implementation.
>
> Andrew, anyway you're probably smart enough to not need my encouragement, 
> but I'd encourage you to keep using mmap, while thinking of alternate 
> methods of achieving the same end goal. While again thinking which method 
> might be better and why. Software development is great for constantly 
> keeping our minds busy while learning new techniques, and technologies. 
> There is always something new to learn, and no one amongst us started off 
> by knowing *everything*.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Access GPIO/SPI etc. on Expansion Header

[Andrew Henderson]

Well, I have gotten it working before using mmap() calls because I had a 
very specific need for it for a proprietary project that I can't share the 
code for, but I was informed (in no uncertain terms) that using mmap() for 
SPI comms in user space is a bad idea and that I am not a smart person:

https://plus.google.com/109402916922772242647/posts/YUpRgyD1HME

Offhand, I'm guessing that you're loading a device tree overlay for SPI 
that specifies the driver "spidev" to be in control of the SPI channels. 
 You're probably hitting the registers correctly in user space, but the 
spidev driver is having the power management in the kernel shut down SPI 
because the spidev driver hasn't sent a message within the last 2 seconds. 
 In the kernel source, the drivers/spi/spi-omap2-mcspi.c file has the 
function omap2_mcspi_probe().  This function sets up some power management 
at the end:

pm_runtime_use_autosuspend(&pdev->dev);
pm_runtime_set_autosuspend_delay(&pdev->dev, SPI_AUTOSUSPEND_TIMEOUT);
pm_runtime_enable(&pdev->dev);

As for an example of doing the transfer, you'll want to mimic the code in 
the omap2_mcspi_txrx_pio() function in that same file.  Ignore the 
OMAP2_MCSPI_CHCONF_TURBO paths, as you won't be hitting any of those. 
 You'll also need to completely avoid mentioning the spidev in the overlay 
(only mux the pins) and set all the registers up yourself.  Or, you can 
shut off the power management in the SPI driver (comment out the 
pm_runtime_enable() call), set up SPI via ioctls() to /dev/spidev from 
userspace, and then bitbang the registers via mmap().  Either way, 
mmap()-ing SPI is possible, but you REALLY need to make sure that there 
isn't another way to do what you need to do.

In short, you should not be doing it this way.  But, if you really want to 
experiment and learn about the spidev driver in the process, go for it.

Andrew

On Wednesday, October 8, 2014 3:14:28 PM UTC-4, Patrick Sheridan wrote:
>
> Hi Andrew,
>
> I know this is an old forum, but I've been stuck trying approach 2, using 
> an mmap to /dev/mem to control the SPI device.  Do you know of any working 
> examples?
>
> Specifically, I'm trying to write to SPI0[MCSPI_TX0] with SPI0.D0 
> configured for output without using a FIFO, but I typically get nothing--no 
> error, but no SPI CLK action either.  The CH0STAT register is showing TX to 
> be full, but I don't know why the system does not initiate the transfer.
>
> Any example configuration code you have would be greatly appreciated.
>
> Thanks,
> Patrick
>
> On Tuesday, October 15, 2013 9:58:54 PM UTC-4, Andrew Henderson wrote:
>>
>> For SPI, mux the pins in the device tree to enable the SPI0 and or SPI1 
>> interfaces, then reference the Linux kernel documentation:
>>
>> https://www.kernel.org/doc/Documentation/spi
>> https://github.com/piranha32/IOoo/blob/master/src/SPI.cpp
>>
>> I suspect that the "spidev_test.c" file in the kernel or the SPI.cpp is 
>> what you are interested in, though the "spidev" file is the documentation 
>> on how all each of the pieces work.
>>
>> For GPIO, there are a few places to look:
>>
>> http://www.youtube.com/watch?v=wui_wU1AeQc
>> https://github.com/piranha32/IOoo/blob/master/src/BeagleGoo.cpp
>> http://www.armhf.com/index.php/using-beaglebone-black-gpios/
>>
>> PWM has been discussed here on the forums:
>>
>>
>> https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/wjbOVE6ItNg
>>
>> When controlling any of the "built-in" features of the BBB, there are 
>> generally one of three approaches that you can take:
>>
>> 1. You can use a kernel device driver to speak directly to the control 
>> registers and then control the driver via an ioctl() call on the exposed 
>> /dev/* device file(s) for the driver.
>> 2. You can mmap() /dev/mem into your process's memory space and change 
>> those registers directly.  For bare-metal programming, you would talk 
>> directly to the memory-mapped registers this way (but without the mmap()).
>> 3. You can "echo" into and "cat" out of the files in the file system that 
>> export out device functionality.  For example /sys/device/*, 
>> /sys/class/gpio/*, etc.
>>
>> If you have a more specific question as to what exactly you want to do, 
>> I'm sure someone here can point you to an appropriate discussion on it that 
>> has already happened in the BeagleBoard group. A lot of this material has 
>> been discussed quite a bit.  But, to answer your original question, I have 
>> not heard of a single library that does everything.  But, there are 

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

I accidentally attached an incorrect .rc file with some additional testing 
material in it.  I'm attaching the proper one now.

On Tuesday, October 7, 2014 1:10:50 AM UTC, Andrew Henderson wrote:
>
> I have not made a new premade image with USB ADB, but I have it working.  
> In your current BBBAndroid image, replace your uEnv.txt (/boot partition) 
> with the one I have attached.  Replace your two init.genericam33xx*.rc 
> files (/rootfs partition) with the two I have attached.  In addition to 
> getting USB ADB up and running, the main .rc file also changes some 
> permissions to make them more relaxed.  Now, i2c-tools work without 
> superuser privileges and it "wakes up" all four GPIO banks in case you need 
> to mmap() the GPIO registers.
>
> If you watch the FTDI output from the BBB (when the USB is plugged in at 
> boot), you'll see something like the following:
>
> [5.784087] CAUTION: musb: Babble Interrupt Occurred
> [5.854604] CAUTION: musb: Babble Interrupt Occurred
> [6.048723] CAUTION: musb: Babble Interrupt Occurred
> [6.119724] CAUTION: musb: Babble Interrupt Occurred
> [6.341756]  gadget: high-speed config #1: FunctionFS
>
> On your dev system side, use ADB to list the devices:
>
> $ adb devices
> List of devices attached
> BBBANDROID  device
>
> $ adb logcat
> ...
> D/AlarmScheduler(  917): No events found starting within 1 week.
> I/ActivityManager(  592): Waited long enough for: ServiceRecord{a5fb0900 
> u0 com.android.calendar/.alerts.InitAlarmsService}
> D/InitAlarmsService(  917): Clearing and rescheduling alarms.
> D/ConnectivityService(  592): Sampling interval elapsed, updating 
> statistics ..
> D/ConnectivityService(  592): Done.
> D/ConnectivityService(  592): Setting timer for 720seconds
>
>
> On Sunday, October 5, 2014 5:24:27 PM UTC, Andrew Henderson wrote:
>>
>> USB ADB is currently being worked on.  The image I provided builds in 
>> FunctionFS support, but I have not yet made the modifications to the .rc 
>> files to point ADB to FunctionFS.  I'm currently working on a few 
>> modifications to the .rc files to make the image a bit more "BBB friendly" 
>> for those interested in using it for Android hardware interfacing practice.
>>
>> On Sunday, October 5, 2014 12:31:33 PM UTC-4, Lei Wang wrote:
>>>
>>> May I ask if ADB over USB is supported in this release? Thanks very 
>>> much! -lei
>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


init.genericam33xx(flatteneddevicetr.rc
Description: Binary data

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

I have not made a new premade image with USB ADB, but I have it working.  
In your current BBBAndroid image, replace your uEnv.txt (/boot partition) 
with the one I have attached.  Replace your two init.genericam33xx*.rc 
files (/rootfs partition) with the two I have attached.  In addition to 
getting USB ADB up and running, the main .rc file also changes some 
permissions to make them more relaxed.  Now, i2c-tools work without 
superuser privileges and it "wakes up" all four GPIO banks in case you need 
to mmap() the GPIO registers.

If you watch the FTDI output from the BBB (when the USB is plugged in at 
boot), you'll see something like the following:

[5.784087] CAUTION: musb: Babble Interrupt Occurred
[5.854604] CAUTION: musb: Babble Interrupt Occurred
[6.048723] CAUTION: musb: Babble Interrupt Occurred
[6.119724] CAUTION: musb: Babble Interrupt Occurred
[6.341756]  gadget: high-speed config #1: FunctionFS

On your dev system side, use ADB to list the devices:

$ adb devices
List of devices attached
BBBANDROID  device

$ adb logcat
...
D/AlarmScheduler(  917): No events found starting within 1 week.
I/ActivityManager(  592): Waited long enough for: ServiceRecord{a5fb0900 u0 
com.android.calendar/.alerts.InitAlarmsService}
D/InitAlarmsService(  917): Clearing and rescheduling alarms.
D/ConnectivityService(  592): Sampling interval elapsed, updating 
statistics ..
D/ConnectivityService(  592): Done.
D/ConnectivityService(  592): Setting timer for 720seconds


On Sunday, October 5, 2014 5:24:27 PM UTC, Andrew Henderson wrote:
>
> USB ADB is currently being worked on.  The image I provided builds in 
> FunctionFS support, but I have not yet made the modifications to the .rc 
> files to point ADB to FunctionFS.  I'm currently working on a few 
> modifications to the .rc files to make the image a bit more "BBB friendly" 
> for those interested in using it for Android hardware interfacing practice.
>
> On Sunday, October 5, 2014 12:31:33 PM UTC-4, Lei Wang wrote:
>>
>> May I ask if ADB over USB is supported in this release? Thanks very much! 
>> -lei
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
kernel_file=zImage

console=ttyO0,115200n8
#video_res=video=720x480-16@60
mmcroot=/dev/mmcblk0p2 rw
mmcrootfstype=ext4 rootwait fixrtc
 
loadkernel=load mmc ${mmcdev}:${mmcpart} 0x8020 ${kernel_file}
loadfdt=load mmc ${mmcdev}:${mmcpart} 0x815f /dtbs/${fdtfile}
 
boot_ftd=run loadkernel; run loadfdt

mmcargs=setenv bootargs consoleblank=0 androidboot.console=ttyO0 mem=512M 
acpi=noirq vt.global_cursor_default=0 mpurate=1000 ${video_res} qemu=1 
console=${console} root=${mmcroot} rootfstype=${mmcrootfstype} init=/init 
ip=off g_ffs.idVendor=0x18d1 g_ffs.idProduct=0x4e26 
g_ffs.iSerialNumber=BBBANDROID

uenvcmd=run boot_ftd; run mmcargs; bootz 0x8020 - 0x815f



init.genericam33xx(flatteneddevicetr.rc
Description: Binary data


init.genericam33xx(flatteneddevicetr.usb.rc
Description: Binary data

[beagleboard] Re: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

USB ADB is currently being worked on.  The image I provided builds in 
FunctionFS support, but I have not yet made the modifications to the .rc 
files to point ADB to FunctionFS.  I'm currently working on a few 
modifications to the .rc files to make the image a bit more "BBB friendly" 
for those interested in using it for Android hardware interfacing practice.

On Sunday, October 5, 2014 12:31:33 PM UTC-4, Lei Wang wrote:
>
> May I ask if ADB over USB is supported in this release? Thanks very much! 
> -lei

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglenes doesnot boot

[Andrew Henderson]

If you are converting to DVI, then you are probably using a computer 
monitor without audio.  BeagleSNES forces its resolution to 720x480, which 
is a CEA video mode that support both audio and video for HDMI televisions 
(480i).  A standard computer monitor will typically not support this mode, 
meaning that your BeagleSNES system may be booting properly but you just 
can't see anything on the screen.  You can try making a backup copy of the 
uEnv.txt file in the /boot partition and then removing the 
"video=720x480@60-16" option from the kernel command line.  The kernel will 
default to the highest resolution available for your monitor, but 
BeagleSNES will still assume only a 720x480 display.

BeagleSNES is really only intended for use with HDMI televisions or the 
LCD3 cape, but you can usually coax it into working with a computer monitor 
(though you lose out on the audio unless you plug in a USB audio device and 
use that).

Andrew


On Sunday, September 28, 2014 11:11:29 AM UTC-4, marcus silva wrote:
>
> Thanks a lot all the answers. I will read the documentation and do all the 
> tests and return tomorrow. I used HDMI DVI cabel. I used the same step and 
> software to create SD card as BBB advised.
> Em 28/09/2014 11:59, "Andrew Henderson" > 
> escreveu:
>
>> What did the output from your FTDI cable show you?  Did you look at the 
>> documentation (http://beaglesnes.sourceforge.net/BeagleSNES_Guide.pdf)? 
>> If so, what did you try from the "troubleshooting" section (section 4.1, 
>> pages 23 and 24)? Are you using an HDMI display with audio or only video 
>> (like a computer monitor)?  Did you decompress the image prior to writing 
>> it to the microSD card (section 2.3, pages 10 and 11)?  What software did 
>> you use to write the image to the microSD card? dd? Or something else? Can 
>> you see any partitions on the microSD card when you mount it on a Linux PC? 
>>  
>>
>> On Saturday, September 27, 2014 9:33:21 AM UTC-4, marcus silva wrote:
>>>
>>> Hi. My beaglebone black does not work. It just doesnot boot. Any one 
>>> have the same issue?
>>> BBB i think os rev b and beaglenes .06.
>>>
>>  -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel

[Andrew Henderson]

Hello all. I have released a new port of Android for the BBB.  This version 
uses AOSP 4.4.4 (KitKat) and the 3.8 Linux kernel. I have made build 
instructions and a pre-made image available at http://www.bbbandroid.org. 
 I use a combination of AOSP repos and Rowboat build scripts, and I have a 
few custom repos for the kernel, bootloader, and additional "external" 
tools (such as i2c-tools).  You can view the repo manifest XML file for the 
project here:

https://github.com/hendersa/bbbandroid-manifest/blob/master/bbbandroid-aosp-4.4.4_r1-3.8.xml

Because this Android image uses the 3.8 kernel, you should be able to just 
plug in your capes and go without any hassle:

Built-in HDMI cape:
http://i.imgur.com/q4AZQ95.jpg

4D Systems LCD capes:
4DCAPE-43T: http://i.imgur.com/6qHmgqX.jpg
4DCAPE-70T: http://i.imgur.com/UZLG7Or.jpg

CircuitCo LCD capes:
LCD3: http://i.imgur.com/LC7SrBB.jpg 
LCD4: http://i.imgur.com/1xBQ8R6.jpg
LCD7: http://i.imgur.com/vxoqROE.jpg

Andrew

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglenes doesnot boot

[Andrew Henderson]

What did the output from your FTDI cable show you?  Did you look at the 
documentation (http://beaglesnes.sourceforge.net/BeagleSNES_Guide.pdf)? If 
so, what did you try from the "troubleshooting" section (section 4.1, pages 
23 and 24)? Are you using an HDMI display with audio or only video (like a 
computer monitor)?  Did you decompress the image prior to writing it to the 
microSD card (section 2.3, pages 10 and 11)?  What software did you use to 
write the image to the microSD card? dd? Or something else? Can you see any 
partitions on the microSD card when you mount it on a Linux PC?  

On Saturday, September 27, 2014 9:33:21 AM UTC-4, marcus silva wrote:
>
> Hi. My beaglebone black does not work. It just doesnot boot. Any one have 
> the same issue?
> BBB i think os rev b and beaglenes .06.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Android running on BBB with Linux 3.8

[Andrew Henderson]

Since I answered this over on the 4DSystems forums, I figured that I should 
link it here for everyone's reference:

http://forum.4dsystems.com.au/forum/forum-aa/4d-systems-hardware/beaglebone-display-modules-and-capes/40743-screen-resolution-and-key-mapping-4dcape-43-beaglebone-black-android-kernel-3-8

Andrew

On Saturday, September 13, 2014 10:21:40 AM UTC-4, Mahendra Gunawardena 
wrote:
>
> I have installed Andrew's Android build on a BBB with a 4D 4.3 display. 
> Most of it is working well. 
>
> Has anyone succeeded getting keys mapped to Home, Menu, Back and Search?
>
> Thanks
>
> Mahen
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: [beagle-alpha] Re: debian testing: 2014-08-19

[Andrew Henderson]

On Wed, 20 Aug 2014, Robert Nelson wrote:


btw, what's your guys thoughts on the simplified dts file, here is the
black:  Simple enough for end users to enable/disable things for their
custom capes?


One thing that I am curious about is the workflow for building the 
.dtb being used by the end user using this universal cape design.  Will 
the boot .dtb be built at kernel compile time only? Or are there plans for 
the arch/arm/boot/am33*.dts* and associated files to be built 
independently of the kernel to allow for modifications of the boot .dtb 
without requiring a kernel rebuild?


If it is built only at kernel build time, is it possible to use #define 
preprocessor logic to selectively enable pieces of the universal cape 
.dts* files via menuconfig (and avoid end-users having to edit the .dts* 
files themselves)?


Also, is HDMI audio not included in the RCN 3.14 kernel?  I was just 
looking through the current 3.14 BB kernel on github and saw the McASP 
pins and compatibility for the am33xx audio driver in the .dts files, but 
the RCN kernel only has McASP mappings for the audio cape.  For the 
universal cape, will the HDMI audio functionality be rolled into the 
include file for the nxp-hdmi cape?  I figure that the two kernel trees 
will converge together to include all functionality eventually, but I am 
curious how HDMI audio will be handled for the universal cape design.  Two 
HDMI cape includes (one with audio, one without)?  Or one for HDMI video 
and one for HDMI audio?  It seems like the second one would be better to 
avoid trouble with people accidentally enabling both, since it turns a 
mutual exclusion setup into an additive one...


Andrew

--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglexm

[Andrew Henderson]

Gerald, what is the support lifetime from CircuitCo for the BBxM? I've 
always been happy with mine, and it is has been a great little board.  What 
have the orders been like for the original BeagleBoard since the BBxM came 
out?  Have you built any of the original BeagleBoards within the past few 
years? I've always been curious about how many people are interested in the 
older boards as reference platforms versus newcomers to the community that 
stick to only the newer platforms.

Andrew


On Tuesday, July 8, 2014 1:42:57 PM UTC-4, Gerald wrote:
>
> We no longer make the xM on a regular basis. We do not sell that many at 
> all these days. We rely on distributors placing orders and stocking them. 
> We then have to schedule them in a couple of times per year.
>
> How many boards are you looking for?
>
> Gerald
>
>
>
> On Tue, Jul 8, 2014 at 11:36 AM, Tony Solorzano  > wrote:
>
>>  Hello,
>>
>> I can't find any other way to contact your company about this issue… I 
>> currently have a open order with Digikey and have been buying these from 
>> them. I placed my order and they came back with this response.
>>
>>  
>>
>> Please see below Delivery information.
>>
>>  
>>
>> *Part:*  296-25798-ND
>>
>> *Salesorder:*  40062172
>>
>>  
>>
>> *Est Delivery:* 
>> SUPPRESSED   
>>   
>>  
>>
>> *DIR Results:* DELIVERY INFORMATION IS NOT AVAILABLE FOR THIS DEVICE DUE 
>> TO CAPACITY AND PRODUCTION CONSTRAINTS. CIRCUITCO PRODUCT IS MADE TO ORDER 
>> AND THE FACTORY IS DOING ITS BEST TO KEEP UP WITH PRODUCTION DEMAND. NO 
>> APPROXIMATE DELIVERY DATE IS AVAILABLE.
>>
>>  
>>
>>  
>>
>> I have never come across something like this. I can't be left in limbo 
>> about a delivery date, as everyone has due dates to commit. 
>>
>>  
>>
>> Thanks,
>>
>> Tony Solorzano
>>
>> SAE Materials
>>
>> 408-492-1784 x 305
>>   
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BeagleSNES v0.6 released

[Andrew Henderson]

Hello all. Version 0.6 of BeagleSNES (http://www.beaglesnes.org) has been 
released.  BeagleSNES is a complete software solution that turns your 
BeagleBone Black or BeagleBoard-xM into a Super Nintendo system:

https://www.youtube.com/watch?v=f8IbhJ7xH6g

Each release, in addition to the source code and documentation, includes a 
4GB microSD card image that can be used as-is to get you up and running as 
quickly as possible.  The documentation walks you through the process of 
writing the image to your microSD card, adding SNES ROMs to your BeagleSNES 
system, and mapping the controls of your gamepads to those of the SNES 
controllers.

Documentation: http://beaglesnes.sourceforge.net/BeagleSNES_Guide.pdf
Release: http://sourceforge.net/projects/beaglesnes/files/v0.6%20Release/

The release notes for the new version are below.  Enjoy!

Andrew

---

BeagleSNES Changelog Version 0.6 Release - 03 July 2014 General: - Updated 
the documentation. Application: - Added GPIO input support (BBB targets). - 
Added a splash screen to keep the user distracted while a background thread 
loads the GUI assets. - Added support for the pause menu with snapshot 
load/save. - Added gamepad and GPIO configuration support to the XML-based 
games.xml file. - Cleaned up the emulator shutdown code so that a game can 
be cleanly exited and control will return to the front-end GUI. - Changed 
from sync()-ing the filesystem to fsync()-ing specific files when saving 
snapshots, screenshots, saved games, etc. - Fixed hi-res blitters that were 
smashing the stack on some games (Donkey Kong Country, Secret of Mana, 
Seiken Densetsu 3). - Added a shrinking blitter to make the hi-res blitters 
work with a 320x240 display. - Reenabled support for loading compressed 
ROMs (.zip, .gz). - Added Expat libraries into the configure script. - 
Cleaned up the XML parser a bit more to eliminate closing tag errors where 
there weren’t actually errors. - Added more aggressive optimization flags 
to the compile options to squeeze out a few more FPS. File System: - Added 
entries for eth1 to /etc/network/interfaces for users having difficulty 
getting the BBB ethernet to initialize and pick up an IP via DHCP. - Placed 
a device tree overlay for the CircuitCo Audio Cape (RevB) (BB-BONE-AUDI-02) 
in /lib/firmware in case anyone wants to try using it with the BBB.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: XML library in Beaglebone Black

[Andrew Henderson]

What XML library are you using?  I built and deployed Expat 
(http://expat.sourceforge.net/) without having to do anything special, 
though I was using an older Ubuntu on a microSD card, rather than the 
default Angstrom/Debian.  Of course, the newer Debian eMMC image would 
allow you to apt-get the Python dependencies you need, or even Expat 
directly. 

Andrew


On Wednesday, June 25, 2014 2:49:21 AM UTC-4, anandva...@gmail.com wrote:
>
> Hello,
>
> I am using beaglebone black with the default kernel present in it.
> I need a XML library to be ported on the board. The problem I am getting 
> is there are dependencies like python etc. while compiling the xml library.
> Can anyone please in sorting this out? Is there any easy way to install 
> xml library?
> Suggestions please!
>
> Regards,
> Anand Vaidya
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: change startup logo BBB debian

[Andrew Henderson]

You must recompile the kernel to change the image.  The image is compiled 
directly into the kernel.

Andrew


On Wednesday, June 25, 2014 1:51:45 AM UTC-4, janszyma...@gmail.com wrote:
>
> Hi,
>
> I see the similar post here 
> https://groups.google.com/forum/embed/?place=forum/beagleboard&showsearch=true&showpopout=true&showtabs=true&hideforumtitle=true&parenturl=http%3A%2F%2Fwww.beagleboard.org%2FCommunity%2FForums#!searchin/beagleboard/custom$20startup$20screen/beagleboard/10pnGDSH_FQ/cFXBPWXb_8kJ
>  
> , but my question is:
> How to change the startup logo on BBB with Debian without recompiling the 
> whole image?
> I want to replace the Beagleboard.org + pequin with something else.
>
> Jan
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Android running on BBB with Linux 3.8

[Andrew Henderson]

Hello Polash.  I received your mail to me this morning on this topic.  Keep 
in mind that I have about four to five people mailing me data sheets EVERY 
MORNING asking me how to get this or that working with the BBB, so I'm 
going to give you the quick overview and post it here so perhaps others can 
find it.

1. Get your LCD working under Linux, rather than Android.  The kernel in 
Android is the Linux kernel with a few extra Android features in it. You'll 
have more tools under Linux for querying the system, loading/unloading 
device tree overlays, etc. than you will under Android, and it makes it a 
lot easier.  If you get your display working under Linux, then start 
working with Android.

2. Use a Linux image with the 3.8 kernel to do your development.  This will 
allow you to boot and then dynamically load your overlay later, which will 
make your life easier during development.

3. Use the TILCDC driver in the kernel.  This is a generic-ish LCD driver 
that has a lot of flexibility.  The driver is controlled by a device tree 
fragment that describes behavior specific to the controller chip for your 
LCD.  For an example that is similar to your LCD, please examine the 
firmware/capes/BB-BONE-LCD4-01-00A1.dts file in the 3.8 kernel source tree 
to see a working example of the LCD interfacing for a similar LCD.  This 
file works for both the CircuitCo LCD4 and the 4D Systems 4DCAPE-43T cape 
boards.  You use the device tree to map control lines for your LCD 
controller to specific BBB pins, define your PWM duty cycles for backlight 
brightness, and any clocks rates, inverted signals, etc.

4. Once you get your display working, if you are permanently attaching this 
display to the BBB, statically build your overlay fragment into the 
kernel's device tree.

5. Disable the HDMI and HDMIN built-in capes so that they don't claim the 
LCD pins during development.  You'll be doing your interaction with the 
system over the network or, even better, via the FTDI serial interface.

6. Your display is not a cape without an eeprom to identify the cape to the 
I2C capebus.  This is not actually required if you are hard-coding the 
device tree nodes into the device tree.  Making your display into a full 
cape enables the capemgr to dynamically discover the cape and load the 
appropriate device tree overlay at boot.  But, if you are manually loading 
the overlay on the command line, you're fine.

This is a VERY brief look at the process.  Please keep in mind that I spend 
a few hours answering mail on the BBB each day and I just can't hold your 
hand to walk you through the process of developing your product.  Good luck!

Andrew


On Wednesday, June 4, 2014 1:35:11 AM UTC-4, p3f...@gmail.com wrote:
>
> I followed the steps recommended in the link 
> http://icculus.org/~hendersa/android/ .The BBB is booting through HDMI 
> properly. My requirement is to boot on a new LCD SH480272T-006-I13Q with 
> the datasheet link as 
> http://www.google.co.in/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCMQFjAA&url=http%3A%2F%2Fwww.cec-mc.ru%2Fpdf%2FSPF-PH480272T-006-I13Q_002[2].pdf&ei=z66OU9q1I8aokAXDi4DYDQ&usg=AFQjCNFxB5up6lYg3ohs5YGn2vuaGpWPCg&bvm=bv.68235269,d.dGI
> How do I manipulate the EEPROM pins to work for my LCD in the firmware.(if 
> that is required...I dont know!).
> Suggestions Requested Please!!!
>
>
> Regards
> Polash
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Sound output - Ubuntu on BBxm

[Andrew Henderson]

I remember having problems with the audio on the BBxM using Ubuntu around 
February of last year.  Turns out the trouble was this:

https://bugs.launchpad.net/ubuntu/+bug/651302

I believe that I added a few lines to the /etc/rc.local script to make the 
appropriate alsamixer commands on each boot.  But, the audio does actually 
work just fine once you turn it on via alsamixer:

https://www.youtube.com/watch?v=enscdpjscz0

Andrew
 

On Friday, February 28, 2014 12:18:20 PM UTC-5, gmsmith...@gmail.com wrote:
>
> Hi all,
>
> I am running a Ubuntu 12.04LTS on BBxm for some time now and am very 
> pleased with it. It does, however, lacked the sound output feature. Did 
> this got fixed in later version like Ubuntu 13 images?
>
> Thanks in advance.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Change start up logo in debian for beaglebone

[Andrew Henderson]

I build custom splash screens into my kernel for my projects.  Here is the 
information that you need:

1. The framebuffer penguin logo in the corner represents the number of 
processors detected.  One penguin logo means one processor.  That is the 
original intended purpose of the logo.  This same technique will work with 
other Linux platforms, but you'll see multiple splash screens on multicore 
platforms.

2. The logo can be stored in 4-bit (16 color) or pseudo 8-bit (224 color) 
formats.

3. The logo for the 224-color image is stored in the kernel source at 
drivers/video/logo/logo_linux_clut224.ppm

4. The logo is positioned in the upper-left corner.  Replacing that logo 
with another logo still results in the new logo being positioned in the 
upper-left corner.

5. The logo can have a max width of 1280 pixels.  If it is wider than that, 
nothing will show up.

To create a .ppm suitable as a splash, I start with a 256-color PNG. Once I 
have one that I like, I convert it using the following command:

$ pngtopnm [IMAGE.PNG] | ppmquant -fs 223 | pnmtoplainpnm > 
[KERNEL_ROOT]/drivers/video/logo/logo_linux_clut224.ppm

Make sure that you backup the original penguin logo (original 
logo_linux_clut224.ppm file), as this command will replace it with your new 
one.

Once you have the new .ppm file in place within the kernel tree, rebuild 
the kernel.  The logo image is compiled into the kernel itself.  Copy your 
new kernel into place on the boot partition of your microSD, point the 
uEnv.txt to it if you have a new name for your kernel, and away you go.

Andrew


On Monday, May 19, 2014 5:13:59 PM UTC-4, Mirko Fucci wrote:
>
>
> Hi everyone,
>
> i wonder if is possible to change startup logo in beaglebone black: it's 
> the penguin on the top left part of the screen. 
>
> Alternatively is possible to remove the logo?
>
> Thanks everyone !!
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Android running on BBB with Linux 3.8

[Andrew Henderson]

It appears that one of your partitions is not properly mounting, hence the 
failure of all of the daemons to start.  The launch scripts are trying to 
start everything, but since the files aren't there, nothing is going to be 
able to start.  Are you using a microSD card bigger than 4GB?  This might 
be of some help to 
you: 
https://groups.google.com/forum/?fromgroups=#!category-topic/beagleboard/android/kx43JkGPDkA

Andrew

On Wednesday, April 23, 2014 11:40:46 AM UTC-4, jeremy geslin wrote:
>
>
> Thanks a lot for this great job !
>
> I was able to flash the compiled image on SD card and to boot my BBB on 
> android without too much trouble (I only faced display resolution issue 
> with my DVI display).
> But now I'm fighting to replicate the same from the compilation stage. I 
> followed step by step your instructions (
> http://icculus.org/~hendersa/android/), by the way really well described 
> since I'm far away to be an expert in this area, and I succeed to build the 
> image and fashed it on SD card.
> Unfortunately, the android boot doesn't complete. On the display, I first 
> get the Linux icon (penguin) in the top left side, then "ANDROID" text 
> appears endlessly. I never reach the step when android icon is displayed.
>
> Here is what I observe on the debug port (last part):
>
> [2.510219] mmc1: BKOPS_EN bit is not set
> [2.517157] mmc1: new high speed MMC card at address 0001
> [2.523620] mmcblk1: mmc1:0001 MMC02G 1.78 GiB
> [2.528784] mmcblk1boot0: mmc1:0001 MMC02G partition 1 1.00 MiB
> [2.535639] mmcblk1boot1: mmc1:0001 MMC02G partition 2 1.00 MiB
> [2.544012]  mmcblk1: p1 p2
> [2.549817]  mmcblk1boot1: unknown partition table
> [2.557000]  mmcblk1boot0: unknown partition table
> [2.589896] tilcdc 4830e000.fb: found TDA19988
> [2.595354] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [2.602322] [drm] No driver support for vblank timestamp query.
> [2.701590] Console: switching to colour frame buffer device 160x64
> [2.728743] tilcdc 4830e000.fb: fb0:  frame buffer device
> [2.734413] tilcdc 4830e000.fb: registered panic notifier
> [2.740104] [drm] Initialized tilcdc 1.0.0 20121205 on minor 0
> [2.795760] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6
> [2.802176] davinci_mdio 4a101000.mdio: detected phy mask fffe
> [2.809819] libphy: 4a101000.mdio: probed
> [2.814090] davinci_mdio 4a101000.mdio: phy[0]: device 
> 4a101000.mdio:00, driver SMSC LAN8710/LAN8720
> [2.823943] Detected MACID = 90:59:af:49:d2:c1
> [2.828598] cpsw 4a10.ethernet: NAPI disabled
> [2.835754] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 
> 00:00:01 UTC (946684801)
> [2.897265] tilcdc 4830e000.fb: timeout waiting for framedone
> [2.915299] ALSA device list:
> [2.918443]   #0: TI BeagleBone Black
> [5.700344] EXT4-fs (mmcblk0p2): recovery complete
> [5.712806] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data 
> mode. Opts: (null)
> [5.721334] VFS: Mounted root (ext4 filesystem) on device 179:2.
> [5.730288] devtmpfs: mounted
> [5.733724] Freeing init memory: 236K
> [5.771806] init (1): /proc/1/oom_adj is deprecated, please use 
> /proc/1/oom_score_adj instead.
> [5.896375] init: cannot open '/initlogo.rle'
> [9.427979] EXT4-fs (mmcblk0p3): recovery complete
> [   10.102043] EXT4-fs (mmcblk0p3): mounted filesystem with ordered data 
> mode. Opts: nomblk_io_submit,errors=panic
> [   10.149532] init: cannot find '/system/bin/vold', disabling 'vold'
> [   10.157261] init: cannot find '/system/bin/sgx/rc.pvr', disabling 'pvr'
> [   10.164888] init: cannot find '/system/bin/netd', disabling 'netd'
> [   10.172136] init: cannot find '/system/bin/debuggerd', disabling 
> 'debuggerd'
> [   10.180494] init: cannot find '/system/bin/surfaceflinger', disabling 
> 'surfaceflinger'
> [   10.189167] init: cannot find '/system/bin/app_process', disabling 
> 'zygote'
> [   10.197073] init: cannot find '/system/bin/drmserver', disabling 'drm'
> [   10.204255] init: cannot find '/system/bin/mediaserver', disabling 
> 'media'
> [   10.211996] init: cannot find '/system/bin/installd', disabling 
> 'installd'
> [   10.225883] init: cannot find '/system/etc/install-recovery.sh', 
> disabling 'flash_recovery'
> [   10.234762] init: cannot find '/system/bin/keystore', disabling 
> 'keystore'
> [   10.298698] init: untracked pid 92 exited
> /system/bin/sh: /system/etc/mkshrc[8]: id: not found
> @android:/ # 
>
> It sounds to me that I'm missing something during the compilation but what 
> ???
>
> Any support would be more than welcome !
>
> Jeremy.
>
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit htt

[beagleboard] Re: Device Tree in android

[Andrew Henderson]

1. In that Android image, device tree overlay files are copied into the 
/system/vendor/firmware directory of the root file system.

2. To disable HDMI, you must disable both the HDMI (video and audio) and 
HDMIN (video only) capes:

capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

3. The overlay fragments of the "default" capes (LCD3/4/7, HDMI, eMMC, 
etc.) are compiled into the kernel itself.  They do not need to be copied 
into /system/vendor/firmware.  Only your own custom .dtbo files need to be 
copied into the firmware diretory.  If the LCD7 cape is plugged into the 
BBB at boot, it will be detected via the capebus manager in the kernel and 
the LCD7 cape's overlay will be automatically enabled.  The only thing that 
you will need to do to use the LCD7 cape is to remove the "video=" option 
from the kernel command line arguments in the uEnv.txt file and have the 
LCD7 cape plugged in at boot.  The resolution will be pulled automatically 
from the cape overlay, so you don't specify it on the kernel command line.

Cape overlays have a priority to their loading order on the cape bus.  In 
your case, the LCD capes have a higher priority than that of the HDMI.  If 
you plug in the LCD7 cape and turn the BBB on, the LCD7 cape gets control 
of the LCDC pins.  The HDMI and HDMIN capes will then fail to load because 
they both request the use of the LCDC pins, so HDMI is disabled 
automatically when the LCD7 cape is in use.

Echo-ing the name of a device tree overlay into the bone_capemgr does work 
for loading overlays, but only for custom .dtbo files that you copy into 
/system/vendor/firmware (rather than /lib/firmware under Linux).   

Andrew

On Monday, April 21, 2014 7:06:22 PM UTC-4, Samer Shatta wrote:
>
> Hi
> i am using android 3.8 (andrew henderson build)
> i have some questions on how to act with device tree over it :
>
> 1- where to find the available device trees ?
> in angstrom the .dts & .dtbo files are exist in /lib/firmware
> but in android i didn't find any folder that contain the dts or dtbo files 
> , so where can i find them ?
>
> 2- how to disable hdmi ?
> i try to append the following line to uENV.txt
>
> capemgr.disable_partno=BB-BONELT-HDMI
>
> but it dosen't work .
>
> 3- i want to enable lcd 7 cape manually how can i do that ?
> in angstrom i do that by the following echo command :
>
> echo BB-BONE-LCD7-01 > /sys/devices/bone_capemgr.8/slots
>
> but in android it also doesn't work .
>
> please help .
>
> Thanks
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Availability - how come nobody has any BeagleBone Black to sell?

[Andrew Henderson]

Adafruit has BBBs in stock right now.  I just received the notification 
mail on it.  It is first come, first serve, so go get one!

http://www.adafruit.com/products/1278

Andrew

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: How to increase appearance time of penguin logo..?

[Andrew Henderson]

Typically, your init process will be a shell script of some sort that sets 
up your environment (launches daemons, mounts partitions, etc.) and then 
launches your app.  There are several "slim" environments (SLiM login 
manager, Slim for PHP5, Slim templates for Ruby, etc.), so I'm not sure 
which one you are referring to. If you need an X server, launch it from the 
shell script you have as your init process and then launch your app from 
with the init process shell script or as some start-up script in your X 
environment.  As long as the init process shell script launches all of the 
pieces that you need to get everything working, and the shell script never 
terminates, you'll be fine.

Andrew

On Saturday, February 1, 2014 12:13:12 AM UTC-5, Kishor Dhanawade wrote:
>
> Hello Andrew sir,
>My applixcation is GUI application and it requires 
> desktop environment (slim in my case). Is it possible to execute GUI 
> appllication as init process.And I have already removed non required 
> deamons and services.I got success in reducing about 4-5 second. thank you 
> for your help.
>
>
>
>
> On Thu, Jan 30, 2014 at 2:44 AM, Andrew Henderson 
> 
> > wrote:
>
>> Hello Kishor.  I suggest that you read about the "fbcondecor" kernel 
>> patch to learn about how to keep a boot splashscreen up beyond that of the 
>> Tux penguin logo that you have now.
>>
>> Much of the time period where the logo is not on the screen is due to 
>> filesystem checks and daemons starting.  You should make your application 
>> become the "init" process for your system and manually start whatever 
>> daemons you need.  That will probably cut your boot time in half, at least. 
>>  I trimmed down my system and got the boot to about 20 seconds, but when I 
>> made my app the init process the boot went down to about 8 seconds when the 
>> app started and fully usable in about 10 seconds.
>>
>> Andrew
>>
>>
>> On Saturday, January 25, 2014 7:15:25 AM UTC-5, Kishor Dhanawade wrote:
>>>
>>> Hii,
>>>  I am using a Beaglebone black board for my application with 
>>> ubuntu-12.04(armhf)-3.8.13 kernel. My application is executing after 20 
>>> seconds from power on. For this much of time I want to keep the linux 
>>> logo(penguin logo) appearing on screen before my application starts. Right 
>>> now it is appearing for 2 seconds after that blank screen for 18 seconds. 
>>> What modification should I do to achieve 2 seconds to 20  seconds??   
>>> Thanking you.
>>>
>>> Regards,
>>> Kishor
>>>
>>  -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/beagleboard/04U3ssflXoM/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> beagleboard...@googlegroups.com .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Re: Can't get BeagleSNES to work on BBB

[Andrew Henderson]

Glad that you found the Android image useful!  If you have the chance, can 
you plug in each of those gamepads that you have, run "lsusb", and send me 
the results?  I suspect that they will report as different gamepads, even 
though the branding is the same.  I'd eventually like to have an sqlite 
database that has USB ID strings and button mappings in it so that 
BeagleSNES will automatically configure your controller if it is one listed 
in its database.  But, if your two gamepads both report exactly the same 
and still have different button mappings, that means the database approach 
might not work.

The 3.12/3.13 kernels have much better USB support, so USB gamepads should 
work far better (especially when hotplugging).  But, they aren't quite 
there yet.  When they are, I'll move both the BBB and BB-xM over to those 
kernels.

Andrew

On Tuesday, January 28, 2014 11:17:09 PM UTC-5, Scott Paul wrote:
>
> I'll keep an eye out for the update.  In the meantime, I bought a second, 
> different controller and everything works now.  Connecting the controller 
> has been a little spotty compared to the other one that the start and 
> select buttons don't work on, but it works.  I cycled the power a couple 
> times, plugged and unplugged it and it eventually worked.  Once it did work 
> it seemed more consistently connected after a power cycle.  The other 
> remote didn't have that issue.  Oh well.  It works.
>
> I've only tried a few games quickly, but I like it.  For anyone else 
> ordering through Amazon...
>
> This is where I ordered the one that worked: 
> http://www.amazon.com/gp/product/B0058FN036/ref=oh_details_o02_s00_i00?ie=UTF8&psc=1
> Sold by *Hitgaming Video Games 
> <http://www.amazon.com/gp/help/seller/at-a-glance.html?ie=UTF8&isAmazonFulfilled=1&seller=A3O4XUIPWQ2IWK>*
>
> This is where I ordered the one that caused me problems: 
> http://www.amazon.com/gp/product/B0034ZOAO0/ref=oh_details_o03_s00_i00?ie=UTF8&psc=1
> Sold by *Hitgaming Video Games 
> <http://www.amazon.com/gp/help/seller/at-a-glance.html?ie=UTF8&isAmazonFulfilled=1&seller=A3O4XUIPWQ2IWK>*
>
> Good luck getting the right one :)
>
> Anyways, thanks Andrew.  I also got the Android 4.2.2 running on the BBB. 
>  Good work on that too!  That also worked after I tried imaging the disk 
> from the Ubuntu machine.
>
>
> On Sunday, January 26, 2014 4:02:54 PM UTC-5, Andrew Henderson wrote:
>>
>> Yes.  The front-end GUI does not look at that configuration file for 
>> button mapping.  That is the configuration file for the SNES9X emulator. 
>>  Part of my work for v0.5 is to pull button mappings from that file.  v0.5 
>> should give you the following:
>>
>> - An additional VFAT partition that houses the config files, ROMs, and 
>> images.  This way, you can pop the microSD card into your non-Linux PC and 
>> add ROMs, edit files, etc.
>> - XML for the games.cfg.  This is using the Expat XML parsing library. 
>>  This will eliminate most of the common problems, I hope, like the config 
>> file having to be just-so or DOS end-of-line characters messing things up, 
>> etc.
>> - Key mapping from the SNES9X emulator's config file so that you can do a 
>> custom key mappings.
>>
>> I am a PhD student, and I've been working on a papers over the past few 
>> months, so I haven't been working on BeagleSNES development as much as I 
>> would like.  I'm still working on it, though, and I'll be getting a release 
>> out as soon as I can.  Trust me, I don't want to answer mail after mail for 
>> support when I can release a new version that addresses these issues 
>> directly!
>>
>> Andrew
>>  
>>
>> On Sunday, January 26, 2014 3:13:18 PM UTC-5, Scott Paul wrote:
>>>
>>> Hi Andrew.  Is there a short explanation for why I can't quickly edit 
>>> the "*snes9x.conf.BBB*" file and change the lines 
>>>
>>>
>>> *J00:B8 = Joypad1 SelectJ00:B9 = Joypad1 Start*
>>>
>>> to something like 
>>>
>>>
>>> *J00:B6 = Joypad1 SelectJ00:B7 = Joypad1 Start*
>>>
>>> to effectively test different button mappings? I tried editing them and 
>>> popping the card back in the BBB but it doesn't seem to do anything.  Does 
>>> modifying that conf file require a rebuild to take effect?  
>>>
>>> When do you hope to release the v0.5?
>>>
>>>
>>> On Friday, January 3, 2014 9:22:19 AM UTC-5, Andrew Henderson wrote:
>>>>
>>>> Hey Scott.  I have been away for the holidays and won't be back

[beagleboard] Re: How to increase appearance time of penguin logo..?

[Andrew Henderson]

Hello Kishor.  I suggest that you read about the "fbcondecor" kernel patch 
to learn about how to keep a boot splashscreen up beyond that of the Tux 
penguin logo that you have now.

Much of the time period where the logo is not on the screen is due to 
filesystem checks and daemons starting.  You should make your application 
become the "init" process for your system and manually start whatever 
daemons you need.  That will probably cut your boot time in half, at least. 
 I trimmed down my system and got the boot to about 20 seconds, but when I 
made my app the init process the boot went down to about 8 seconds when the 
app started and fully usable in about 10 seconds.

Andrew


On Saturday, January 25, 2014 7:15:25 AM UTC-5, Kishor Dhanawade wrote:
>
> Hii,
>  I am using a Beaglebone black board for my application with 
> ubuntu-12.04(armhf)-3.8.13 kernel. My application is executing after 20 
> seconds from power on. For this much of time I want to keep the linux 
> logo(penguin logo) appearing on screen before my application starts. Right 
> now it is appearing for 2 seconds after that blank screen for 18 seconds. 
> What modification should I do to achieve 2 seconds to 20  seconds??   
> Thanking you.
>
> Regards,
> Kishor
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Re: Can't get BeagleSNES to work on BBB

[Andrew Henderson]

Yes.  The front-end GUI does not look at that configuration file for button 
mapping.  That is the configuration file for the SNES9X emulator.  Part of 
my work for v0.5 is to pull button mappings from that file.  v0.5 should 
give you the following:

- An additional VFAT partition that houses the config files, ROMs, and 
images.  This way, you can pop the microSD card into your non-Linux PC and 
add ROMs, edit files, etc.
- XML for the games.cfg.  This is using the Expat XML parsing library. 
 This will eliminate most of the common problems, I hope, like the config 
file having to be just-so or DOS end-of-line characters messing things up, 
etc.
- Key mapping from the SNES9X emulator's config file so that you can do a 
custom key mappings.

I am a PhD student, and I've been working on a papers over the past few 
months, so I haven't been working on BeagleSNES development as much as I 
would like.  I'm still working on it, though, and I'll be getting a release 
out as soon as I can.  Trust me, I don't want to answer mail after mail for 
support when I can release a new version that addresses these issues 
directly!

Andrew
 

On Sunday, January 26, 2014 3:13:18 PM UTC-5, Scott Paul wrote:
>
> Hi Andrew.  Is there a short explanation for why I can't quickly edit the "
> *snes9x.conf.BBB*" file and change the lines 
>
>
> *J00:B8 = Joypad1 SelectJ00:B9 = Joypad1 Start*
>
> to something like 
>
>
> *J00:B6 = Joypad1 SelectJ00:B7 = Joypad1 Start*
>
> to effectively test different button mappings? I tried editing them and 
> popping the card back in the BBB but it doesn't seem to do anything.  Does 
> modifying that conf file require a rebuild to take effect?  
>
> When do you hope to release the v0.5?
>
>
> On Friday, January 3, 2014 9:22:19 AM UTC-5, Andrew Henderson wrote:
>>
>> Hey Scott.  I have been away for the holidays and won't be back to my 
>> office with my equipment until the start of next week.  You have everything 
>> set up correctly, it seems.  The games.cfg looks OK, in any case.  The 
>> problem is that the button numbers for the start and select are hardcoded 
>> in the front-end GUI.  I have a better button mapping scheme on my dev list 
>> for v0.5 of BeagleSNES, but I can't work on it and get another release out 
>> until I am able to get back to my equipment.  The short answer is that you 
>> will require a code change and recompile to get it working for your 
>> particular controller.
>>
>> I have a big laundry list of things that I have been working on that I 
>> want to get out for v0.5, and a few of the items have been delaying me in 
>> getting the release out.  I may just have to bite the bullet and expedite 
>> the more urgent items because a large number of people have received new 
>> BBBs for the holidays and have been filling my inbox with all sorts of 
>> issues regarding gamepads and button mappings.
>>
>> Good work on getting everything working as well as you have so far.  I 
>> should write a book on how to develop the BBB into a standalone appliance 
>> based on all of the feedback and reports that I have received from everyone 
>> over the last six months...
>>
>> Andrew
>>
>>
>> On Wednesday, January 1, 2014 6:23:41 PM UTC-5, Scott Paul wrote:
>>>
>>> So close...
>>>
>>> I had an old PC sitting around collecting dust so I formatted that to 
>>> Ubuntu 12.04.  I re-did everything from that machine.  Before I started, 
>>> when I plugged in the SD card that I had setup from the Win7 machine into 
>>> the Ubuntu machine it seemed to mount the two partitions fine ... but it 
>>> also gave me a pop-up error message about not wanting to mount the drive 
>>> for some reason ... even though I could see both parts.  Anyways, it did 
>>> this each time I mounted the card.  After I reformatted the card with the 
>>> beaglesnes image that message has no longer come up.  I have mounted the 
>>> card several more times too.  
>>>
>>> At first it did not work.  Then I took it out of its Adafruit 
>>> case<http://www.adafruit.com/products/1555?gclid=CNGJv-2J3rsCFVLxOgodcRsAeA>and
>>>  tried.  Then it would boot up, give me music, and let me scroll through 
>>> the placeholder's in the default config.  I am certain I tried this before 
>>> but it did not matter.  I quickly realized that the molding on the cable 
>>> needed to be cut down.  If I had read adafruit's page closer, I might have 
>>> caught that note.  Not happy about that, but it worked.  I think that I had 
>>> both a cable problem and a Wind

Re: [beagleboard] Angstrom Abandoned for BBB? Rumor + a Rant

[Andrew Henderson]

I'll just step in here a moment to say something.  The BBB's software has 
rough edges.  It is improving all of the time.  Many people are tinkering 
away behind the scenes, trying out different things, finding the rough 
edges, talking about them, etc.  I understand the frustration of anyone 
that wants a working base to start from when creating their own projects. 
 I receive a great deal of mail from many beginnings that are running into 
all sorts of issues, and I am either able to help them with their project 
quickly or get them pointed towards the right place to talk about it.  And 
it isn't just me doing this sort of thing.  The community has a variety of 
people that are all tinkering with their own projects and are helping 
others along the way.  We just don't have a "formal" person to hold 
accountable when things don't work.

I know that this isn't ideal, and I completely understand where you are 
coming from.  But, I guess that I just accept it for what it is, sigh, and 
say "I guess I'm going to have to figure out some workaround for this silly 
thing".  Most people lack the experience to just dig in and fix things, and 
that's OK.  The kernel for the BBB is quite a patchwork of, well... 
patches.  It's a mess, really, especially in the 3.8 kernel.  Little pieces 
work here and there, things break and get fixed, etc.  I think that you're 
really going to see everything "working and working well" around the time 
that the 3.13 kernel becomes the standard one for BBB.  3.12 is looking 
good, anyway, though it still is missing a few bits here and there.

I remember when the BeagleBoard-xM changed from the 2.6 kernel and it 
couldn't be clocked at 1 GHz anymore because the support wasn't in the 
kernel.  People complained.  Oh boy, did they complain.  There were 
statements like "this is false advertising" and "they said it could do 1 
GHz and they LIED", etc.  But really, this is just the name of the game 
when it comes to these hobbyist boards.

I am sorry that you are frustrated with the current state of the BBB's 
kernel and OS choices, but it is always changing (and usually improving). 
 In the meantime, the more experienced hobbyists will keep ironing out the 
kinks as best as we can, documenting what we find, and really putting a lot 
of sweat and tears into beating the BBB into what we want it to be. 
 Personally, I do what I do because I am trying to provide good reference 
platforms (BeagleSNES as a standalone appliance, Android with the 3.8 
kernel for tablet prototypers, etc.) that other people can learn from or 
use as a base for their own projects.  Sometimes, I fix a minor thing and 
pass it along to everyone else.  Other times, I just do some investigation, 
figure out what isn't quite right, and then pass that along to people like 
Robert that are fiddling away on their own interests.

It is what it is.  It isn't ideal and polished, but then again, some people 
like me find that kind of interesting.  I know it isn't for everyone, 
though.

Andrew
  

On Wednesday, January 1, 2014 10:05:09 PM UTC-5, Terry Storm wrote:
>
> What is funny is that it still seems to be expected that everyone who buys 
> a BBB should be required to have the capability to make it work correctly. 
> Your argument is valid but still only for a small proportion of buyers. 
> Think of all the people out there who have brought a BBB to maybe be a step 
> up from their Arduino. They have never used linux etc, its a hell of a 
> learning curve.
>
> It find it hard to believe that it should be expected that everyone who 
> buys a BBB should have had at least (say) 5 years of linux experience 
> before they even consider buying one. This is targeted at a wide range of 
> users, which includes hobbyists who have never touch embedded development 
> boards before. The price of the BBB is irrelevant. What is relevant is 
> there are a ton of people stuck, and a bunch of experienced linux people 
> who are capable of fixing issues and making the BBB work as they require, 
> slagging of everyone else who is not capable and saying they shouldn't have 
> purchased in the first place. Or that all these inexperienced users should 
> harden up and take a concrete pill and figure it out themselves.
>
> Ridiculous.
>
> Swap places and see how far you get.
>
> Making GPIO do things, writing basic application code etc, basically 
> turning a BBB into a glorified Arduino, no problem for most people and that 
> is something that can easily be learnt. Rewriting kernels and drivers so 
> supplied hardware even works, this is a problem for most people. Bringing 
> up a discussion to talk about this, how this constitutes as whining or 
> complaining, I don't know.
>
> This topic has gone way off topic anyway.
>
> End of the day we have great hardware, no one is complaining about that. 
> End of the day we have crap supporting software and now it seems no 
> official (paid) developers, and issues relating to kernels which most use

[beagleboard] Re: BeagleSNES with non-Tomee controller?

[Andrew Henderson]

I don't have that particular controller, so I can't tell you whether it 
works or not.  As long as there isn't a specific kernel driver for that 
control (meaning it will work with the generic USB joystick driver already 
in BeagleSNES), you'll get joystick events from the gamepad.  But, that 
might not be all that useful to you if the buttons aren't properly mapped. 
 BeagleSNES v0.5 will have a better button mapping mechanism, since the 
button mapping is hard-coded in the source for the Tomee on the front-end 
GUI. Give it a try if you have the controller handy and mail me directly 
(hendersa (at) icculus.org) with the results and I'll add it into my notes.

Andrew

On Thursday, January 2, 2014 5:20:55 PM UTC-5, Aidoboy wrote:
>
> Anyone here know anything about using Gtron controllers with BeagleSNES? 
> The guide says there is only official support for Tomee, I was wondering if 
> there was any unofficial for Gtron, as I don't have the knowledge to create 
> the mapping myself.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Re: Can't get BeagleSNES to work on BBB

[Andrew Henderson]

Hey Scott.  I have been away for the holidays and won't be back to my 
office with my equipment until the start of next week.  You have everything 
set up correctly, it seems.  The games.cfg looks OK, in any case.  The 
problem is that the button numbers for the start and select are hardcoded 
in the front-end GUI.  I have a better button mapping scheme on my dev list 
for v0.5 of BeagleSNES, but I can't work on it and get another release out 
until I am able to get back to my equipment.  The short answer is that you 
will require a code change and recompile to get it working for your 
particular controller.

I have a big laundry list of things that I have been working on that I want 
to get out for v0.5, and a few of the items have been delaying me in 
getting the release out.  I may just have to bite the bullet and expedite 
the more urgent items because a large number of people have received new 
BBBs for the holidays and have been filling my inbox with all sorts of 
issues regarding gamepads and button mappings.

Good work on getting everything working as well as you have so far.  I 
should write a book on how to develop the BBB into a standalone appliance 
based on all of the feedback and reports that I have received from everyone 
over the last six months...

Andrew


On Wednesday, January 1, 2014 6:23:41 PM UTC-5, Scott Paul wrote:
>
> So close...
>
> I had an old PC sitting around collecting dust so I formatted that to 
> Ubuntu 12.04.  I re-did everything from that machine.  Before I started, 
> when I plugged in the SD card that I had setup from the Win7 machine into 
> the Ubuntu machine it seemed to mount the two partitions fine ... but it 
> also gave me a pop-up error message about not wanting to mount the drive 
> for some reason ... even though I could see both parts.  Anyways, it did 
> this each time I mounted the card.  After I reformatted the card with the 
> beaglesnes image that message has no longer come up.  I have mounted the 
> card several more times too.  
>
> At first it did not work.  Then I took it out of its Adafruit 
> caseand
>  tried.  Then it would boot up, give me music, and let me scroll through 
> the placeholder's in the default config.  I am certain I tried this before 
> but it did not matter.  I quickly realized that the molding on the cable 
> needed to be cut down.  If I had read adafruit's page closer, I might have 
> caught that note.  Not happy about that, but it worked.  I think that I had 
> both a cable problem and a Windows problem, but maybe it was only a 
> cable/case problem and I didn't do something else write the time I tried 
> that with the Win7 SD card setup.
>
> I have been at it for a while today, but the problem now is that it will 
> not select the games I've added in the menu.  I have tested the controller 
> on the Ubuntu machine and can see the start and select buttons do 
> register.  I have been doing everything in the Ubuntu machine.  The 
> pictures are showing up, the text descriptions are updated.  At first I had 
> 5 games listed so I tried adding 5 more.  Each time the menu list updated 
> as expected, but pressing start or select doesn't do anything.  The roms 
> are all in the rootfs/home/ubuntu/beaglesnes/rom folder.  They are all 
> .smc.  I even removed spaces and tried shortening the .smc file names.
>
> I'm only using one controller.  I can't really think of much else to try 
> right now.  Again, I welcome any support.  I attached my games.cfg file if 
> that helps
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Re: 3.12-rc4: kernel testing time...

[Andrew Henderson]

I just tried checking out the 3.12 branch to build it and see where it is 
at.  I noticed that the old dummy nxp audio driver in 
gpu/drm/i2c/tda998x_audio_drv.c is no longer there.  Is the plan to use the 
OMAP HDMI driver to just set up a simple I2S signal via McASP0?  Or will 
some other CODEC be used?  I was placing the audio cape info into the 
shared tree to see if I could coax it into working when I noticed that the 
old driver had disappeared...

Andrew

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Re: BB black screen and Android

[Andrew Henderson]

Which Android image are you using?  I have spoken with 4D in the past, and 
they have verified that my 3.8-based Android image works with that cape. 
 The cape reports itself as the CircuitCo LCD4, I believe.  Make sure that 
your uEnv.txt does not explicitly list a "video=" argument on the kernel 
command line options.

Andrew

On Friday, November 22, 2013 5:11:34 AM UTC-5, Pierre Ficheux wrote:
>
> Hi all,
>
> I've bought a LCD screen for my BB black:
>
> http://www.logicsupply.com/components/touchscreen-displays/4dcape-43t/
>
> It works fine with Linux but Android display is still on HDMI output. 
>
> Any idea ??
>
> regards
>
> Pierre
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Re: Enabling the UART / SPI / I2C on the Beagle Bone Black for Android

[Andrew Henderson]

Well, I can't speak for the official TI releases, but I can provide you 
with instructions for my Android build based off of the 3.8 kernel.

Configuring the pin muxing, as well as associating kernel drivers to 
particular muxed pins, are performed by device tree overlays in the 3.8 
kernel. This means that you can use the kernel command-line options for 
capemgr.enable_partno to load overlays that are part of the kernel proper. 
 For example, you can add the following kernel command line option to the 
uEnv.txt to enable SPI0:

capemgr.enable_partno=BB-SPI0

... or enable UART1:

capemgr.enable_partno=BB-UART1

... or enable I2C1:

capemgr.enable_partno=BB-I2C1

... or the alternate pinmux for I2C1:

capemgr.enable_partno=BB-I2C1A1

... and so on and so forth.  To enable multiple cape overlays, just 
separate them with a comma:

capemgr.enable_partno=BB-SPI0,BB-UART1

If you want to enable an overlay that conflicts with the HDMI, you'll have 
to disable either the audio portion of the HDMI cape (HDMIN) or the entire 
cape using capemgr.disable_partno:

capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN  (disable both)
capemgr.disable_partno=BB-BONELT-HDMIN  (disable audio)

If you have a custom overlay that is not one that you have built into your 
kernel (capes in the firmware/capes directory of your Linux kernel source 
tree), you'll have to install it in the /system/vendor/firmware directory 
in the root of your Android filesystem.  I believe that /system/vendor is 
there, but you'll have to create the "firmware" directory in it.  This is 
analogous to copying your custom overlay into /lib/firmware on a Linux 
system.  Just compile your overlay into a .dtbo file with dtc and then copy 
it into that directory.  Loading the overlay is done by echo'ing the name 
of the overlay into the slot manager (just like on Linux):

echo MY_CAPE_NAME > /sys/devices/bone_capemgr.8/slots

You can do this over the FTDI cable via the root shell, or you can add the 
command to the bottom of your init.rc to do it automatically upon system 
start.  The number for your capemgr might be different (bone_capemgr.9, for 
example).  On Linux I echo into cone_capemgr.*, but I believe that is a 
bash-specific thing and you'll have to list the explicit file when you do 
it via the Android system shell.  

I've had students that I've worked with turn on several UARTs for 
communications, turn on SPI, etc. for their projects.  Of course, unless 
you have a HAL set up to provide access to the device drivers exposed via 
the /dev filesystem, you'll need to use native code to talk to the exposed 
devices in /dev and then act as the interface to your Java apps via JNI.

Andrew


On Monday, November 18, 2013 11:28:02 AM UTC-5, nikhil...@gmail.com wrote:
>
> How can I enable the UART / SPI / I2C on the Beagle Bone Black for 
> Android...please help me 
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Re: Can't get BeagleSNES to work on BBB

[Andrew Henderson]

If your system is working OK (you boot off the BeagleSNES microSD card and 
you have the BBB plugged into an HDMI TV), you will briefly see a 
BeagleSNES splash screen in the kernel before coming up in the main game 
selection menu.  Boot takes about 10-12 seconds.  Once you hit the menu, 
the background music will begin playing.  Zip forward to 0:40 to see it in 
action here:

https://www.youtube.com/watch?v=igJ4qADrSwo

If the gamepad is not plugged in, the lower left corner of the game 
selection menu will say "PLEASE CONNECT PLAYER 1 GAMEPAD".  The system will 
still start up just fine without one plugged in, though.  Once you plug a 
gamepad in, the lower left corner will change to "+ to select game". 

BeagleSNES has two modes for starting up.  The first is the default "fast 
boot" setup, which uses BeagleSNES as the init process for the system.  In 
this mode, many of the service daemons aren't started to shorten boot 
time.  Because of this, networking will not work.  the other mode is 
"development" mode.  It takes about 20 seconds to boot, rather than 10, but 
it gives you networking and all the other daemons that you're used to 
having in a full desktop system.  So, you'll never have network 
connectivity with BeagleSNES unless you switch from "fast boot" to 
"development".  This is done by commenting out one line and commenting 
another one in in the uEnv.txt file in the /boot partition.  The BeagleSNES 
manual .pdf has instructions to get you through the process.

But, it sounds like you might have some fundamentals to take care of, 
first.  Are you using a 5VDC 2A power supply?  You won't get very far by 
powering the system via USB because pushing the AM3359 at a full 1 GHz 
draws too much power.  You'll need to use a power supply.  When connecting 
to the system using PuTTY, are you connecting over the network, or via an 
FTDI debug cable?  The FTDI cable will tell you exactly what is going on, 
and it is a must because you'll see output from the boot process from the 
bootloader starting through to a login prompt.  This debug output is 
probably your best bet in having me help diagnose your problem, since there 
are a lot of variables we can eliminate by looking at the output.

Aside from that, if you have no microSD card in your system, and you 
connect your BBB to your HDMI TV (while the BBB is off), and then you turn 
on the BBB, do you see the Angstrom installed on the BBB's eMMC running on 
your TV?  If not, did you see Angstrom boot on the TV before you flashed 
the eMMC to update it?  You might just have to retry the eMMC flash (and 
maybe re-download and/or rewrite the microSD card you use to flash the 
eMMC). 

I have not held down the boot button when booting from BeagleSNES before, 
so I'm not familiar with what will happen if you do.  You do not need to 
hold the button down, since I have set up the uEnv.txt and bootloader for 
the BeagleSNES image so that it will be picked up by the bootloader 
installed in the eMMC (with the Angstrom image).  My Android image that you 
tried is set up the same way... both BeagleSNES and the Android image are 
designed to just "burn and go".

Anyway, if you don't have the power supply and FTDI cable, definitely pick 
those up.  If you have the FTDI cable, send me a log of your system booting 
at hendersa (at) icculus.org and I'll look it over to see if I find 
anything odd. Glad you like the documentation!  It turns out that the time 
taken to write good docs pays for itself many times over in reduced support 
mails!  

Andrew   


On Wednesday, November 13, 2013 9:30:56 PM UTC-5, Scott Paul wrote:
>
> Hi Andrew, thanks for responding.  
>
> 1. Yep, about 800mb, got the full image.
> 2. Yep, on my 32bit Win 7 system using 7-zip to extract.
> 3. With the imaged card in the BBB, nothing mounts, at all.  I get lights 
> dancing, but nothing.
> 4. I tried with and without the boot button down, multiple times.
>
> I felt like I was being safe about setting this thing up too.  I have an 
> anti-static mat at my bench and everything.  It is new and this is one of 
> the first things I'm trying with it.
>
> I just tried to run android and that did not work either 
> (BBB_JB_Android_3_8_13.img).  Now I'm wondering if the board is busted. 
>  The steps seem very easy and clear to me.  Something just isn't working. 
>  I'd rather not spend another $45 to find out its software or my setup.
>
> If I have the image written to the card, plug it in the BBB, and try 
> booting it with the default setup, what will the screen look like on the TV?
> What will happen if I boot without the controller attached?
> Will booting work with and without the boot button held down at power up?
> When should I be letting go of the boot button at startup?
>
> Thanks again for taking anytime to address my questions.  Very good job ( 
> the write up is great ).
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribe

[beagleboard] Re: Can't get BeagleSNES to work on BBB

[Andrew Henderson]

Hello Scott.  Here are some of the usual problems that I see when people 
contact me about BeagleSNES:

1. Did you download the beaglesnes_full.img.bz2 file?  Sometimes, people 
download one of the other files, which provides a portion of the system or 
the source code, rather than the executable image.
2. Did you decompress the BeagleSNES image before you wrote it to the 
microSD card?  I have had reports from people using my Android image that 
if you write the image without decompressing it, you get similar behavior 
to what you are reporting.
3. The root filesystem in the image is EXT4, which won't mount under 
Windows 7.  If you don't have a Linux system to mount the microSD card 
under, you'll need to either copy the ROMs over to the BBB via the network 
or copy them onto the /boot partition (which mounts under Windows) and then 
copy them from the /boot partition into the proper place once you get 
BeagleSNES booted.
4. Are you holding down the boot button to force the system to boot off the 
microSD card?  You DO NOT have to do this.  I wrote the uEnv.txt in the 
BeagleSNES /boot partition to specify the microSD card device as the boot 
device, so you can just pop in the microSD card and it will boot.

A 4 GB microSD card is fine, since I made the image about 3.6 GB in size to 
account for slightly smaller microSD cards that advertise themselves as 4 
GB.

Your first step is to get the system booted.  Then you can add some ROMs. 
 If you have written the image properly, it should boot to the game 
selection GUI with the placeholder entries in the menu.  If you aren't 
seeing anything over the FTDI cable with PuTTY when you boot, you probably 
are writing the still-compressed image to the microSD card.

Andrew


On Friday, November 8, 2013 6:27:00 PM UTC-5, Scott Paul wrote:
>
> Hello, first time using a BBB, and I've hit a wall.  I'm good with Arduino 
> toys and before switching back to Windows 7 I used multiple Ubuntu machines 
> for about 3 years.  So some of this BBB stuff isn't too far fetched for me.
>
> I bought the board from Adafruit about 2 weeks ago now for the soul 
> purpose of getting BeagleSNES to work on it.  From what I can tell, the SD 
> card isn't getting written correctly or the Beagle can't read it as it 
> should.
>
> I followed the getting started for BBB.  I was able to plug it in and see 
> it and then use Putty to log in as root.  I also downloaded the latest 
> software for it, imaged that onto an SD card and the update went fine, 
> although it took about 65 minutes.  Much longer than the "caution, may take 
> 45 minutes" warning suggested.  After plugging it back into my Windows 7 
> machine it looks fine, so the update seems to have worked, so my SD card 
> burning ability is fine, and the BBB can read the card.
>
> So I download the full BBB image, write that to a card, plug it into the 
> BBB, plug in the miniUSB cable to Windows, and all I get is a unique blink 
> pattern for about the first 10 seconds on power up.  After that, its just 
> the heartbeat pattern.  Windows never sees any partition, so I can't copy 
> my roms to it.  Basically it looks frozen somewhere.  I checked the MD5 
> hash whatever code and it is a match for the file from Sourceforge.  I try 
> just plugging everything into the TV anyways (2 different TV's) and there 
> is nothing.  I follow the instructions closely and repeat, nothing.  I 
> deviate a little and try resetting or holding the boot button longer, 
> nothing. Just a heartbeat and no screen or sound action.
>
> Then I go back and reburn the image to another 4Gb card, nothing on 
> Windows or at the TV.  I redownload the zipped image, rewrite both cards, 
> nothing.
>
> In summary, a whole lotta nothing :)  It seems like all the pieces have 
> proven they work somehow, except the actual BeagleSNES image, which I 
> downloaded twice and re-wrote to multiple cards, multiple times.  
>
> Now I am downloading Android and going to burn that to another card to see 
> if that will work.  If that works for me, then what?  Is BeagleSNES working 
> with the latest of everything?  I assume it is or I would be able to find 
> more problems in searching this forum, but I didn't.
>
> Should I try to do a complete format of the microSD card before writing 
> the image to it?  I don't think that should matter.
> Should I try getting an 8Gb card? I saw on some write ups that 4Gb is 
> close and might not always work for other images.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Re: Access GPIO/SPI etc. on Expansion Header

[Andrew Henderson]

For SPI, mux the pins in the device tree to enable the SPI0 and or SPI1 
interfaces, then reference the Linux kernel documentation:

https://www.kernel.org/doc/Documentation/spi
https://github.com/piranha32/IOoo/blob/master/src/SPI.cpp

I suspect that the "spidev_test.c" file in the kernel or the SPI.cpp is 
what you are interested in, though the "spidev" file is the documentation 
on how all each of the pieces work.

For GPIO, there are a few places to look:

http://www.youtube.com/watch?v=wui_wU1AeQc
https://github.com/piranha32/IOoo/blob/master/src/BeagleGoo.cpp
http://www.armhf.com/index.php/using-beaglebone-black-gpios/

PWM has been discussed here on the forums:

https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/wjbOVE6ItNg

When controlling any of the "built-in" features of the BBB, there are 
generally one of three approaches that you can take:

1. You can use a kernel device driver to speak directly to the control 
registers and then control the driver via an ioctl() call on the exposed 
/dev/* device file(s) for the driver.
2. You can mmap() /dev/mem into your process's memory space and change 
those registers directly.  For bare-metal programming, you would talk 
directly to the memory-mapped registers this way (but without the mmap()).
3. You can "echo" into and "cat" out of the files in the file system that 
export out device functionality.  For example /sys/device/*, 
/sys/class/gpio/*, etc.

If you have a more specific question as to what exactly you want to do, I'm 
sure someone here can point you to an appropriate discussion on it that has 
already happened in the BeagleBoard group. A lot of this material has been 
discussed quite a bit.  But, to answer your original question, I have not 
heard of a single library that does everything.  But, there are a lot of 
examples of each piece that you can certainly stick together to make one.

Andrew


On Monday, October 14, 2013 8:15:44 AM UTC-4, Satz Klauer wrote:
>
> Hi,
>
> with its (freely programmable) expansion connector BeagleBoard Black seems 
> to be a perfect thingy for embedded applications. Since I did not find 
> anything suitable (only a Python library or some JavaScript-based things 
> which all seem to be way to slow for my usage):
>
> Is there a (realtime-capable) library available that gives the possibility 
> to access the expansion header and utilitise it's SPIs, digital IOs and PWM 
> outputs? With "library" of course every piece of code is meant whatever is 
> out there (so it can be kernel driver based for existing Linux variants, 
> bare-metal code, whatever...)
>
> Thanks!
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.