[beagleboard] wifi configuration on beaglebone black.

[Madhu K]

Hi All,

I was trying to configure wifi on beaglebone black board. But i am facing 
below problems.

I am using TP-LINK TL-WN823N adaptor.

Beaglebone black wifi setup steps :

1) Downloaded the stable kernel 4.4.2 from git.
2) Compiled the kernel and loaded new kernel to beaglebone black.
3) Downloaded the rlt8192eu ( TL-WN823N ) driver code from git.
4) Compiled the driver code for beaglebone black and inserted the module to 
new kernel.
5) Inserted TL-WN823N adapter to beaglebone black.

Problems :

1) I am getting below messages, i don't know what exactly that message 
indicates.

[  361.376724] RTL871X: Wrong rate section: (CCK,2T)
[  361.381816] RTL871X: Wrong rate section: (CCK,2T)



[  361.810547] RTL871X: duplicate tx power limit combination [band 
2.4G][regulation ETSI][bw 20M][rate section HT][rf path 2T][chnl 01]
[  361.823118] RTL871X: duplicate tx power limit combination [band 
2.4G][regulation MKK][bw 20M][rate section HT][rf path 2T][chnl 01]
[  361.835593] RTL871X: duplicate tx power limit combination [band 
2.4G][regulation FCC][bw 20M][rate section HT][rf path 2T][chnl 02]


2) I could see the wlan0 in ifconfig. but there no ip for wlano. I executed 
sudo ifup wlan0 command and i am getting below messages.


DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 3 (xid=0x1e59e38c)
[  840.120795] RTL871X: nolinked power save enter
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 6 (xid=0x1e59e38c)
[  846.819487] RTL871X: nolinked power save leave
DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 19 (xid=0x1e59e38c)
[  848.471030] RTL871X: nolinked power save enter
[  855.165440] RTL871X: nolinked power save leave
[  856.821011] RTL871X: nolinked power save enter


please help to resolve these issue.


Thanks and regards,

Madhu

-- 
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/a11e7499-f55b-429c-bf42-6a357744e807%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Pointers and dereferencing the data

[M Pitman]

I'm trying to read data collected from an ADC chip on one of the PRU's of
the Beaglebone Black and I'm having difficulty interpreting what I'm
seeing.  Using Derek Molloy's website as a guide, I use the commands

   unsigned int spiData[3];

   spiData[1] = readFileValue(MMAP1_LOC "addr");

to get the location to store the data.  The SPI code runs and then I spin
through a loop looking at the data.  However, I'm confused as to the proper
coding to display the data.

It seems to me that spiData[1] holds the address of the external memory and
so should be an integer pointer.  So I think I should just be able to
dereference that variable to get to the data.  However, I've tried several
methods with compiler errors such as

error: invalid type argument of type unary '*' (have 'int') or
warning: assignment makes integer from pointer without a cast

For example the following gives the unary error.

int p;
p = spiData[1];
   for (i=0; i < numberSamples; i++)
   {
  printf("Point: %d \t Data: %d\n", i++, (int *)*p);
  p = p + 2;
   }

If I replace (int *)*p with (int *)&p

the program compiles and runs but returns the same value for each reading.
However, running the program again gives a different value but still the
same value for each reading.  Obviously, I'm misunderstanding pointers

I really think I'm getting data placed at the value stored in spiData[1]
but I'm just not looking at it right.  Can anyone give me an example of how
I should be dereferencing that address to get to the data?

Thanks,

Mike Pitman

-- 
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/CAJ2u6KMmj1H2MB0nSnsKeq-9uGDBCopO8mROcgL5dZ%2Bw9ipDrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: which uboot source to compile (and how) for emmc/NAND

[David Woolford]

Hi Jeff,

Thanks for your reply. After I wrote that post I found the exact same link (
https://eewiki.net/display/linuxonarm/BeagleBone+Black) and the "obligatory
patches" are basically what I was missing for building the MLO and
u-boot.img files for the EMMC.

Sorry if I wasn't clear - my task is to write the contents of the EMMC from
scratch using only an Ethernet connection. I'm doing that using BOOTP/DHCP
and TFTP. It's working now.

Thanks,
Dave.

On Wed, 9 Aug 2017 at 02:20 Jeff Andich  wrote:

> I'm a newbie, so take this with a grain of salt or as comic relief for the
> experts on this website.
>
> I don't completely understand what you're trying to do, but it sounds like
> the kernel some how contains/flashes MLO/u-boot.img???
>
> But maybe you can generate SD Card which contains everything you need
> (e.g. MLO, u-boot.img, kernel, fs, uEnv.txt) and then uncomment the
> appropriate line within uEnv.txt to convert that into a flasher image, and
> subsequently flash the eMMC...
>
> Instructions for where to get EVERYTHING and transfer it to SD card for
> the BBB can be found here:
>
> https://eewiki.net/display/linuxonarm/BeagleBone+Black
>
> Once you download the u-boot source and apply all of the the obligatory
> patches for BBB, you will have a buildable u-boot/SPL tree.
>
> In lieu of generating a complete SD card image, it MAY BE possible to dd
> just the MLO/u-boot.img to the eMMC on the BBB, but I think you can only do
> this from a running FS on the BBB.
>
>
>
> On Tuesday, August 8, 2017 at 6:55:12 AM UTC-5, wolfwo...@gmail.com wrote:
>>
>> Hi,
>>
>> I'm trying to automate the process of flashing a bootable emmc (NAND) on
>> my beagle bone black. I've pin strapped the board to boot using bootp/dhcp
>> - the kernel that gets loaded by the u-boot.img (that was pulled in via
>> dhcp+tftp) uses an initramfs as the basis of writing the MLO, (a different)
>> u-boot.img and root file system (containing zImage and uEnv.txt) to
>> emmc/NAND. This all works and when I restart the beagle bone black it boots
>> as I expect. Hooray for automated emmc flashing.
>>
>> However my problem is that I can't seem to hand roll a version the the
>> MLO and u-boot.img that I flash to NAND. What I'm using right now are
>> copies I found of these two files in the debian images distributed here:
>> https://beagleboard.org/latest-images (These images tend to contain
>> filesystems with /opt/backup/uboot/MLO and /opt/back/uboot/u-boot.img files
>> existing). If I use these two boot loader files, and craft my
>> /boot/uEnv.txt just so (uuid needs to be specified), then I can boot a
>> couple of kernels/filesystems I have lying around successfully.
>>
>> But I can't seem to reproduce these two files (MLO and u-boot.img) for my
>> NAND from source. I've tried these git repos:
>>
>> git://git.denx.de/u-boot.git
>> git://git.ti.com/ti-u-boot/ti-u-boot.git
>>
>> and even the u-boot source that that ships with the SDK:
>>
>> ~/ti-processor-sdk-linux-am335x-evm-04.00.00.04/board-support/u-boot-2017.01+gitAUTOINC+9fd60700db-g9fd60700db/
>>
>> For each of those I'm running
>>
>> make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_evm am335x_evm_defconfig
>> && make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_evm
>>
>> And I've even tried a different config:
>>
>> make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_boneblack
>> am335x_boneblack_defconfig && make CROSS_COMPILE=arm-linux-gnueabihf-
>> O=am335x_boneblack
>>
>> This compilation process creates the MLO and u-boot.img files, but I can
>> never seem to successfully boot anything if I use them regardless of which
>> config I use.
>>
>> If it helps with clarity, I am trying out MLO and u-boot.img files by
>> booting from the SD card, copying over the new versions, and then running
>>
>> dd if=MLO of=/dev/mmcblk1 conv=notrunc bs=128k count=1 seek=1
>> dd if=u-boot.img of=/dev/mmcblk1 conv=notrunc bs=384k count=2 seek=1
>>
>> Note that I can always get back to the "bootable state" by writing the
>> backup boot loader files that come with debian distro instead: (the sd card
>> is running debian 8.7):
>>
>> dd if=/opt/backup/uboot/MLO of=/dev/mmcblk1 conv=notrunc bs=128k count=1
>> seek=1
>> dd if=/opt/backup/uboot/u-boot.img of=/dev/mmcblk1 conv=notrunc bs=384k
>> count=2 seek=1
>>
>>
>> How can I build MLO and u-boot.img files in order to successfully boot a
>> kernel and file system of my choosing on the emmc/NAND? Is there a page
>> somewhere? Any help would be appreciated.
>>
>

-- 
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/CAMp8jfrOwy7i4%2BOJM_djLWJ4iVBAF%3DiJucyS%3DaKd2cdDsZTcHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optou

[beagleboard] Re: which uboot source to compile (and how) for emmc/NAND

[Jeff Andich]

Good to hear..

This may come in handy when we're at the point of writing the eMMC in our
board..

Regards,

jeff


On Tue, Aug 8, 2017 at 6:50 PM David Woolford 
wrote:

> Hi Jeff,
>
> Thanks for your reply. After I wrote that post I found the exact same link
> (https://eewiki.net/display/linuxonarm/BeagleBone+Black) and the
> "obligatory patches" are basically what I was missing for building the MLO
> and u-boot.img files for the EMMC.
>
> Sorry if I wasn't clear - my task is to write the contents of the EMMC
> from scratch using only an Ethernet connection. I'm doing that using
> BOOTP/DHCP and TFTP. It's working now.
>
> Thanks,
> Dave.
>
> On Wed, 9 Aug 2017 at 02:20 Jeff Andich  wrote:
>
>> I'm a newbie, so take this with a grain of salt or as comic relief for
>> the experts on this website.
>>
>> I don't completely understand what you're trying to do, but it sounds
>> like the kernel some how contains/flashes MLO/u-boot.img???
>>
>> But maybe you can generate SD Card which contains everything you need
>> (e.g. MLO, u-boot.img, kernel, fs, uEnv.txt) and then uncomment the
>> appropriate line within uEnv.txt to convert that into a flasher image, and
>> subsequently flash the eMMC...
>>
>> Instructions for where to get EVERYTHING and transfer it to SD card for
>> the BBB can be found here:
>>
>> https://eewiki.net/display/linuxonarm/BeagleBone+Black
>>
>> Once you download the u-boot source and apply all of the the obligatory
>> patches for BBB, you will have a buildable u-boot/SPL tree.
>>
>> In lieu of generating a complete SD card image, it MAY BE possible to dd
>> just the MLO/u-boot.img to the eMMC on the BBB, but I think you can only do
>> this from a running FS on the BBB.
>>
>>
>>
>> On Tuesday, August 8, 2017 at 6:55:12 AM UTC-5, wolfwo...@gmail.com
>> wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to automate the process of flashing a bootable emmc (NAND) on
>>> my beagle bone black. I've pin strapped the board to boot using bootp/dhcp
>>> - the kernel that gets loaded by the u-boot.img (that was pulled in via
>>> dhcp+tftp) uses an initramfs as the basis of writing the MLO, (a different)
>>> u-boot.img and root file system (containing zImage and uEnv.txt) to
>>> emmc/NAND. This all works and when I restart the beagle bone black it boots
>>> as I expect. Hooray for automated emmc flashing.
>>>
>>> However my problem is that I can't seem to hand roll a version the the
>>> MLO and u-boot.img that I flash to NAND. What I'm using right now are
>>> copies I found of these two files in the debian images distributed here:
>>> https://beagleboard.org/latest-images (These images tend to contain
>>> filesystems with /opt/backup/uboot/MLO and /opt/back/uboot/u-boot.img files
>>> existing). If I use these two boot loader files, and craft my
>>> /boot/uEnv.txt just so (uuid needs to be specified), then I can boot a
>>> couple of kernels/filesystems I have lying around successfully.
>>>
>>> But I can't seem to reproduce these two files (MLO and u-boot.img) for
>>> my NAND from source. I've tried these git repos:
>>>
>>> git://git.denx.de/u-boot.git
>>> git://git.ti.com/ti-u-boot/ti-u-boot.git
>>>
>>> and even the u-boot source that that ships with the SDK:
>>>
>>> ~/ti-processor-sdk-linux-am335x-evm-04.00.00.04/board-support/u-boot-2017.01+gitAUTOINC+9fd60700db-g9fd60700db/
>>>
>>> For each of those I'm running
>>>
>>> make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_evm
>>> am335x_evm_defconfig && make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_evm
>>>
>>> And I've even tried a different config:
>>>
>>> make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_boneblack
>>> am335x_boneblack_defconfig && make CROSS_COMPILE=arm-linux-gnueabihf-
>>> O=am335x_boneblack
>>>
>>> This compilation process creates the MLO and u-boot.img files, but I can
>>> never seem to successfully boot anything if I use them regardless of which
>>> config I use.
>>>
>>> If it helps with clarity, I am trying out MLO and u-boot.img files by
>>> booting from the SD card, copying over the new versions, and then running
>>>
>>> dd if=MLO of=/dev/mmcblk1 conv=notrunc bs=128k count=1 seek=1
>>> dd if=u-boot.img of=/dev/mmcblk1 conv=notrunc bs=384k count=2 seek=1
>>>
>>> Note that I can always get back to the "bootable state" by writing the
>>> backup boot loader files that come with debian distro instead: (the sd card
>>> is running debian 8.7):
>>>
>>> dd if=/opt/backup/uboot/MLO of=/dev/mmcblk1 conv=notrunc bs=128k count=1
>>> seek=1
>>> dd if=/opt/backup/uboot/u-boot.img of=/dev/mmcblk1 conv=notrunc bs=384k
>>> count=2 seek=1
>>>
>>>
>>> How can I build MLO and u-boot.img files in order to successfully boot a
>>> kernel and file system of my choosing on the emmc/NAND? Is there a page
>>> somewhere? Any help would be appreciated.
>>>
>>

-- 
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 email

Re: [beagleboard] File writing from PRU

['Mark Lazarewicz' via BeagleBoard]

Been using emulators for 32 years in industry if you exclude debugging linux( 
printf is common) and look at bare metal or RTOS which many hard real time 
systems use you save time. IMO toggle gpio and printf is like erasing and 
programming eepeoms 30 years ago. Sure it works for applications but for low 
level bring up I won't work for a company that doesn't supply me a jtag. If 
your app uses the serial port your sol using printf. I recently worked at a 
company used an esp8260 Wi-Fi SoC project failed it took forever to reflash and 
once we added in the serial protocol printf was not possible. the lack of jtag 
killed the project. If your a student I get $90 of your own money may seem a 
lot but look at as an investment in your future every one uses jtag outside the 
linux community for RTOS and high end jtag like lauterbach used by ARM, TI etc 
etc cost thousands if dollars why do you think TI makes a cheap jtag and CCS 
support? Because for DSP ARM OMAP real world projects in successful products 
selling millions of units like the one I'm working on at work using omap138 
Greenhills RTOS on the ARM and sysbios on the 687x DSP of omap and btw we use 2 
PRUs this got to market quickly because of jtag. I will say this product is now 
debugged by loading binaries for DSP and ARM from a flash filesystem via 
telnet. T it took years to get that stable using you guessed it Greenhill sling 
shot jtag for ARM and CCS and jtag for ARM bootloader and DSP debug. I wasn't 
there when they debugged the PRUs its loaded from a c file by arm as is the DSP 
via shared DDR 
If you Google debugging the PRU with CCS you will find a tutorial for the bone 
PRU using CCS.Get the skills employers use to deliver products quickly I bet 
you never look back. I Probally have a dozen jtag for a dozen micros 
I buy them as a learning aid to hit the ground running on any new processor I 
use. These SOcs are way to complex and life is way to short to wiggle gpios.If 
you can't find the wiki I mentioned just ask 
Cheers
Sent from Yahoo Mail on Android 
 
  On Tue, Aug 8, 2017 at 5:07 PM, Clark Sann wrote:   Mark,

So what can I do with it if I get one? I’m programming the PRU in C, can I 
inspect variables and insert breakpoints?

Clark
> On Aug 8, 2017, at 4:56 PM, 'Mark Lazarewicz' via BeagleBoard 
>  wrote:
> 
> That sounds like a perfect justification to spend $90 on jtag

-- 
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/967BAFEF-EEB2-49CB-AB41-97A20CAF29AF%40icloud.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1694417349.2650157.1502232710966%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] File writing from PRU

[Clark Sann]

Mark,

So what can I do with it if I get one? I’m programming the PRU in C, can I 
inspect variables and insert breakpoints?

Clark
> On Aug 8, 2017, at 4:56 PM, 'Mark Lazarewicz' via BeagleBoard 
>  wrote:
> 
> That sounds like a perfect justification to spend $90 on jtag

-- 
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/967BAFEF-EEB2-49CB-AB41-97A20CAF29AF%40icloud.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] File writing from PRU

['Mark Lazarewicz' via BeagleBoard]

That sounds like a perfect justification to spend $90 on jtag

Sent from Yahoo Mail on Android 
 
  On Tue, Aug 8, 2017 at 3:35 PM, Clark Sann wrote:   
Thanks, Charles, for the great ideas. 

I definitely agree with you that debugging on the PRU is hard. I’ve been 
working on a problem on and off for weeks. I’ve solved it now but had decent 
debugging tools it would have only taken a few minutes. (Or if I knew C 
better!) It’s like trying to play tennis with a bag over my head.  Lucky for 
me, I don’t get paid for this stuff.

Today I got RPMsg working. I’m now using it to send commands to the PRU and to 
retrieve rudimentary diagnostic data. So I hope to pick up the pace a little 
bit. The PRU certainly has a steep learning curve!

I’ll also look into your suggestions. Thanks again!

Clark

> On Aug 8, 2017, at 11:08 AM, Charles Steinkuehler  
> wrote:
> 
> On 8/8/2017 10:11 AM, Clark Sann wrote:
>> 
>> But why did TI blather on and on about the printf_support switch and the 
>> high 
>> and low level IO drivers in the PRU C Compiler manual?
> 
> Because you can get printf working if you add a UART or other means to
> get data out of the system.
> 
>> What do you do to get diagnostic info while debugging PRU firmware?
> 
> My typical methods:
> 
> * "Twiddle" pru output pins at various points in the code.  Note that
> if you've got a good 'scope or logic analyzer (I'm typically using an
> Agilent MSO with 16 digital channels), you can shift out data values
> with a single pin, so it can be more useful than just "LED" style
> debugging.
> 
> * Dump data into a chunk of shared memory (typically one of the PRU
> data RAMs) and examine it from the ARM side.
> 
> * Use a debugger to single-step the PRU code.  I typically use the HAL
> based one provided with Machinekit but there are now several others
> available.
> 
> Regardless, debugging on the PRU is much harder than debugging code on
> the ARM side.
> 
> -- 
> Charles Steinkuehler
> char...@steinkuehler.net
> 
> -- 
> 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/hM0UojPprcY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/e5397db0-ee22-e884-a2d5-893936dea0df%40steinkuehler.net.
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0F280D4F-A9C9-4A8E-922A-DCCAC6034C1D%40icloud.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/1351920125.2597834.1502229364128%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] which uboot source to compile (and how) for emmc/NAND

['Mark Lazarewicz' via BeagleBoard]

AFAIK That SDK isn't Debian usually it's Arago and the sdk has a wiki 
describing building uboot but if your looking duplicate those .org binaries. If 
you search this group you should find a link Probally from Robert as to how to 
clone and build the correct stuff. Also check his eewiki he's got detailed 
instructions

Sent from Yahoo Mail on Android 
 
  On Tue, Aug 8, 2017 at 6:55 AM, 
wolfwoolf...@gmail.com wrote:   Hi,

I'm trying to automate the process of flashing a bootable emmc (NAND) on my 
beagle bone black. I've pin strapped the board to boot using bootp/dhcp - the 
kernel that gets loaded by the u-boot.img (that was pulled in via dhcp+tftp) 
uses an initramfs as the basis of writing the MLO, (a different) u-boot.img and 
root file system (containing zImage and uEnv.txt) to emmc/NAND. This all works 
and when I restart the beagle bone black it boots as I expect. Hooray for 
automated emmc flashing.

However my problem is that I can't seem to hand roll a version the the MLO and 
u-boot.img that I flash to NAND. What I'm using right now are copies I found of 
these two files in the debian images distributed here: 
https://beagleboard.org/latest-images (These images tend to contain filesystems 
with /opt/backup/uboot/MLO and /opt/back/uboot/u-boot.img files existing). If I 
use these two boot loader files, and craft my /boot/uEnv.txt just so (uuid 
needs to be specified), then I can boot a couple of kernels/filesystems I have 
lying around successfully.

But I can't seem to reproduce these two files (MLO and u-boot.img) for my NAND 
from source. I've tried these git repos:

git://git.denx.de/u-boot.git
git://git.ti.com/ti-u-boot/ti-u-boot.git

and even the u-boot source that that ships with the SDK:
~/ti-processor-sdk-linux-am335x-evm-04.00.00.04/board-support/u-boot-2017.01+gitAUTOINC+9fd60700db-g9fd60700db/

For each of those I'm running

make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_evm am335x_evm_defconfig && 
make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_evm

And I've even tried a different config:

make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_boneblack 
am335x_boneblack_defconfig && make CROSS_COMPILE=arm-linux-gnueabihf- 
O=am335x_boneblack

This compilation process creates the MLO and u-boot.img files, but I can never 
seem to successfully boot anything if I use them regardless of which config I 
use.

If it helps with clarity, I am trying out MLO and u-boot.img files by booting 
from the SD card, copying over the new versions, and then running

dd if=MLO of=/dev/mmcblk1 conv=notrunc bs=128k count=1 seek=1
dd if=u-boot.img of=/dev/mmcblk1 conv=notrunc bs=384k count=2 seek=1

Note that I can always get back to the "bootable state" by writing the backup 
boot loader files that come with debian distro instead: (the sd card is running 
debian 8.7):

dd if=/opt/backup/uboot/MLO of=/dev/mmcblk1 conv=notrunc bs=128k count=1 seek=1
dd if=/opt/backup/uboot/u-boot.img of=/dev/mmcblk1 conv=notrunc bs=384k count=2 
seek=1


How can I build MLO and u-boot.img files in order to successfully boot a kernel 
and file system of my choosing on the emmc/NAND? Is there a page somewhere? Any 
help would be appreciated.


-- 
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/ebe257da-d203-44b8-9b0b-8ca1bc49ca09%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/884409875.2580960.1502226983565%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] File writing from PRU

[Clark Sann]

Thanks, Charles, for the great ideas. 

I definitely agree with you that debugging on the PRU is hard. I’ve been 
working on a problem on and off for weeks. I’ve solved it now but had decent 
debugging tools it would have only taken a few minutes. (Or if I knew C 
better!) It’s like trying to play tennis with a bag over my head.  Lucky for 
me, I don’t get paid for this stuff.

Today I got RPMsg working. I’m now using it to send commands to the PRU and to 
retrieve rudimentary diagnostic data. So I hope to pick up the pace a little 
bit. The PRU certainly has a steep learning curve!

I’ll also look into your suggestions. Thanks again!

Clark

> On Aug 8, 2017, at 11:08 AM, Charles Steinkuehler  
> wrote:
> 
> On 8/8/2017 10:11 AM, Clark Sann wrote:
>> 
>> But why did TI blather on and on about the printf_support switch and the 
>> high 
>> and low level IO drivers in the PRU C Compiler manual?
> 
> Because you can get printf working if you add a UART or other means to
> get data out of the system.
> 
>> What do you do to get diagnostic info while debugging PRU firmware?
> 
> My typical methods:
> 
> * "Twiddle" pru output pins at various points in the code.  Note that
> if you've got a good 'scope or logic analyzer (I'm typically using an
> Agilent MSO with 16 digital channels), you can shift out data values
> with a single pin, so it can be more useful than just "LED" style
> debugging.
> 
> * Dump data into a chunk of shared memory (typically one of the PRU
> data RAMs) and examine it from the ARM side.
> 
> * Use a debugger to single-step the PRU code.  I typically use the HAL
> based one provided with Machinekit but there are now several others
> available.
> 
> Regardless, debugging on the PRU is much harder than debugging code on
> the ARM side.
> 
> -- 
> Charles Steinkuehler
> char...@steinkuehler.net
> 
> -- 
> 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/hM0UojPprcY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/e5397db0-ee22-e884-a2d5-893936dea0df%40steinkuehler.net.
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0F280D4F-A9C9-4A8E-922A-DCCAC6034C1D%40icloud.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Looking for "Java Tech Lead at Dallas, TX Need i94 and Passport number.

[Chaitanya Puvvada]

Hi,

Hope you are doing great,
My Self,* Chaitanya* from R2 Technologies. We have a requirement for "*Java
Tech Lead *at *Dallas, TX*. Please review the Job description below and if
you’d like to pursue this, please include a word copy of your latest resume
along with a daytime phone number and rate in your response. You can
also reach me at *470-242-7345 Ex-304*, Drop the suitable profiles on
*sudha...@r2techcorp.com*  and
chaitu.recruit...@gmail.com



*Position: Java Tech Lead *

*Location: Dallas, TX*

*Contract: Long Term*



*Must have Strong experience in*:

· Core Java, Hibernate, database Oracle, ORM framework – hibernate,
Core Spring, Java Design patterns (delegate, factory are used extensively),
Rally, Agile

· Swing UI – Preferred and will have to learn if no past experience

· Spring security Preferred and will have to learn if no past
experience

· Fitnesse preferred and will have to learn if no past experience







Thanks,

*Chaitanya*

*Technical Recruiter*

Disk:*470-242-7345 Ex-304*

*chaitu.recruit...@gmail.com *

Office: 248-522-7855 |Fax: (248) 479-5559
*R2 Technologies*

6515 Shiloh Rd, Unit 110, Alpharetta,GA 30005

-- 
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/CACteqcPW0ZS4bwMCaPLifJGJ_DpV_JqHsZeX2p%2BT%2BcWcA6SmpQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BB Blue boot status over serial?

[Ryan Van Rooyen]

Is there any way to view the BB Blue's boot status over a serial 
connection?  It looks like the BB Black had explicit pins you could connect 
a USB to TTL serial cable with to connect to the device.  Does anyone know 
if the BB Blue has the same pins and which pins those are?  I'm trying to 
diagnose a possible error during boot, is there any other ways to view boot 
status info/diagnose boot issues?

-Ryan

-- 
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/21ed999b-bf6f-45e3-b5de-60eaf00c26da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: which uboot source to compile (and how) for emmc/NAND

[Jeff Andich]

I'm a newbie, so take this with a grain of salt or as comic relief for the 
experts on this website.

I don't completely understand what you're trying to do, but it sounds like 
the kernel some how contains/flashes MLO/u-boot.img???

But maybe you can generate SD Card which contains everything you need (e.g. 
MLO, u-boot.img, kernel, fs, uEnv.txt) and then uncomment the appropriate 
line within uEnv.txt to convert that into a flasher image, and subsequently 
flash the eMMC...

Instructions for where to get EVERYTHING and transfer it to SD card for the 
BBB can be found here:

https://eewiki.net/display/linuxonarm/BeagleBone+Black

Once you download the u-boot source and apply all of the the obligatory 
patches for BBB, you will have a buildable u-boot/SPL tree.

In lieu of generating a complete SD card image, it MAY BE possible to dd 
just the MLO/u-boot.img to the eMMC on the BBB, but I think you can only do 
this from a running FS on the BBB.
 


On Tuesday, August 8, 2017 at 6:55:12 AM UTC-5, wolfwo...@gmail.com wrote:
>
> Hi,
>
> I'm trying to automate the process of flashing a bootable emmc (NAND) on 
> my beagle bone black. I've pin strapped the board to boot using bootp/dhcp 
> - the kernel that gets loaded by the u-boot.img (that was pulled in via 
> dhcp+tftp) uses an initramfs as the basis of writing the MLO, (a different) 
> u-boot.img and root file system (containing zImage and uEnv.txt) to 
> emmc/NAND. This all works and when I restart the beagle bone black it boots 
> as I expect. Hooray for automated emmc flashing.
>
> However my problem is that I can't seem to hand roll a version the the MLO 
> and u-boot.img that I flash to NAND. What I'm using right now are copies I 
> found of these two files in the debian images distributed here: 
> https://beagleboard.org/latest-images (These images tend to contain 
> filesystems with /opt/backup/uboot/MLO and /opt/back/uboot/u-boot.img files 
> existing). If I use these two boot loader files, and craft my 
> /boot/uEnv.txt just so (uuid needs to be specified), then I can boot a 
> couple of kernels/filesystems I have lying around successfully.
>
> But I can't seem to reproduce these two files (MLO and u-boot.img) for my 
> NAND from source. I've tried these git repos:
>
> git://git.denx.de/u-boot.git
> git://git.ti.com/ti-u-boot/ti-u-boot.git
>
> and even the u-boot source that that ships with the SDK:
>
> ~/ti-processor-sdk-linux-am335x-evm-04.00.00.04/board-support/u-boot-2017.01+gitAUTOINC+9fd60700db-g9fd60700db/
>
> For each of those I'm running
>
> make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_evm am335x_evm_defconfig 
> && make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_evm
>
> And I've even tried a different config:
>
> make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_boneblack 
> am335x_boneblack_defconfig && make CROSS_COMPILE=arm-linux-gnueabihf- 
> O=am335x_boneblack
>
> This compilation process creates the MLO and u-boot.img files, but I can 
> never seem to successfully boot anything if I use them regardless of which 
> config I use.
>
> If it helps with clarity, I am trying out MLO and u-boot.img files by 
> booting from the SD card, copying over the new versions, and then running
>
> dd if=MLO of=/dev/mmcblk1 conv=notrunc bs=128k count=1 seek=1
> dd if=u-boot.img of=/dev/mmcblk1 conv=notrunc bs=384k count=2 seek=1
>
> Note that I can always get back to the "bootable state" by writing the 
> backup boot loader files that come with debian distro instead: (the sd card 
> is running debian 8.7):
>
> dd if=/opt/backup/uboot/MLO of=/dev/mmcblk1 conv=notrunc bs=128k count=1 
> seek=1
> dd if=/opt/backup/uboot/u-boot.img of=/dev/mmcblk1 conv=notrunc bs=384k 
> count=2 seek=1
>
>
> How can I build MLO and u-boot.img files in order to successfully boot a 
> kernel and file system of my choosing on the emmc/NAND? Is there a page 
> somewhere? Any help would be appreciated.
>

-- 
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/bea657e2-1d31-4ce3-aef5-1506cc3de2e8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] File writing from PRU

[Charles Steinkuehler]

On 8/8/2017 10:11 AM, Clark Sann wrote:
> 
> But why did TI blather on and on about the printf_support switch and the high 
> and low level IO drivers in the PRU C Compiler manual?

Because you can get printf working if you add a UART or other means to
get data out of the system.

> What do you do to get diagnostic info while debugging PRU firmware?

My typical methods:

* "Twiddle" pru output pins at various points in the code.  Note that
if you've got a good 'scope or logic analyzer (I'm typically using an
Agilent MSO with 16 digital channels), you can shift out data values
with a single pin, so it can be more useful than just "LED" style
debugging.

* Dump data into a chunk of shared memory (typically one of the PRU
data RAMs) and examine it from the ARM side.

* Use a debugger to single-step the PRU code.  I typically use the HAL
based one provided with Machinekit but there are now several others
available.

Regardless, debugging on the PRU is much harder than debugging code on
the ARM side.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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/e5397db0-ee22-e884-a2d5-893936dea0df%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] File writing from PRU

[Clark Sann]

Thanks Charles. I agree that it seems to be impossible to write to the ARM 
file system. I wanted to do it to get better diagnostic information while I 
am debugging my PRU firmware. I'm finding that turning on outputs when I 
reach certain sections of firmware is growing tiresome. I might try 
enabling the UART and using it to send messages to me. 

But why did TI blather on and on about the printf_support switch and the 
high and low level IO drivers in the PRU C Compiler manual?

What do you do to get diagnostic info while debugging PRU firmware? 

I know of a few methods:

1. Turn an output on or off when a certain section of code is reached. (I 
do this but is is certainly primitive.)
2. Put a value in a register. Halt the PRU and inspect the registers. (I 
haven't tried this yet.)
3. Go into an infinite loop when a certain section of code is reached. 
(This sounds really weird but I think TI actually advised this as a 
potential debug method.)
4. Buy a JTAG and use CCS. (This is supposed to provide some type of 
breakpoint.)
5. Enable the PRU UART and send out diagnostic messages. (This seems 
promising.)
6. Use RPMsg to pass debug strings to the ARM. (This also seems promising.)

Clark

-- 
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/f0f2004d-f09e-4eb5-8601-606a78a50afe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Touch on LCD Chipsee (BBB-EXP-C) stopped respond

[Radovan Chovan]

Thanks for your answer, but what about *capacitive Chipsee *touchscreen 
behaviour?
I think the whole problem is related with multitouch, but I don't know how 
correctly set some touchscreen options in OS Debian.

Dňa utorok, 8. augusta 2017 15:20:02 UTC+2 Przemek Klosowski napísal(-a):
>
> It's possible that your palm deposits water or body oils and confuses the 
> resistive sensors. Can you try wiping the display with a paper 
> towel,perhaps sligtly moist with alcohol?
>
>

-- 
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/a6a867d2-35b0-4d43-831f-e68f532f88ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: OpenGL support for Beaglebone Black

[Przemek Klosowski]

On Mon, Aug 7, 2017 at 12:21 AM, sajeevan k  wrote:

> Hi all,
>
> Please provide help on using OpenGL with Beaglebone Black.
>

OpenGL has both hardware-supported and software implementations. If you're
planning to do something ambitious with your graphics, you need the
hardware drivers, which are proprietary and a little tricky (depend on
particular kernel version, etc). What are you trying to accomplish, what
did you try so far and what was the result of your attempts?

>
>
> Thanks & Regards,
> Sajeevan.K
>
> On Thursday, August 3, 2017 at 10:19:45 AM UTC+5:30, sajeevan k wrote:
>>
>>
>> Hi all,
>>
>> I have been using Linaro Tool chain and sysroot for cross compiling and
>> building my Qt applications for Beaglebone Black Rev C with debian image
>>
>> Cross Compile Tool chain used - 
>> gcc-linaro-4.9.4-2017.01-x86_64_arm-linux-gnueabihf
>>
>> Sysroot used - sysroot-eglibc-linaro-2017.01-arm-linux-gnueabihf.
>>
>> Does this arrangement support OpenGL?
>>
>> Is there any sysroot available for Beaglebone Black with installed OpenGL
>> ES packages ?
>>
>>
>> Thanks & Regards,
>> Sajeevan.K
>>
> --
> 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/658d1bf1-6d97-4d3d-a51c-840691301374%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgGwE-O_ZDB7sRwd%3Di--9pUNA7jz%2B0%3DPQXzTLystbrEY-g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Running bbb without emmc memory chip (physically, unsoldered)

[Przemek Klosowski]

are you aware that the eMMC chip is a ball-grid package? It's possible to
unsolder it, of course, with skill and hot-air repair station. I am not
sure if the boot sequence stops on failing to detect the eMMC presence ; I
suspect it's possible to force the SD boot using the usual keypresses that
work with eMMC present.

On Mon, Aug 7, 2017 at 4:03 PM,  wrote:

> Hello,
>
> Is there any way to physically extract the emmc memory chip and boot
> successfully the Angstrom linux distribution just/only from microSD card ?
>
> Do you have any advice for this problem ?
>
> Thank you 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/113c5509-d42a-477f-9d63-788a84bad3bf%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgFP3e541TC7aB9OZko5G1dqi3yR%2BQ3FVjO9pphe5TsshQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Touch on LCD Chipsee (BBB-EXP-C) stopped respond

[Przemek Klosowski]

It's possible that your palm deposits water or body oils and confuses the
resistive sensors. Can you try wiping the display with a paper
towel,perhaps sligtly moist with alcohol?

On Tue, Aug 8, 2017 at 5:04 AM, Radovan Chovan  wrote:

> So, now I have figured I can reproduce same problem with rezistive display
> from 4D Systems (BBB revC and Debian Wheezy(not Jessie)), when I touch
> display with my palm.
>
> But command
> sudo /etc/init.d/lightdm restart
>
> doesn't help at all. Display reboot with java application autostart lasted
> 20 seconds, but touch didn't still respond. When I touched this resistive
> display, I cannot still accomplish to start touch again after many tries
> with palm and finger touches.
>
> --
> 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/d8d8d1a8-5d77-4854-9f90-dc683212%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgFiB%3DCpv441TGCdMLqpuw%3D5SF%3DMdo0%3DgEysqxmnfjseBQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: What Are Some "Okay" Ways to Test If Specific Pins on the P8 and P9 Headers are Still Working?

[Graham]

Seth:
I don't think the software commands can see any closer to the pins than the 
I/O registers associated with the pins.
Physical or electrical damage to the pins, such as damaging the ESD diodes, 
or damaging an I/O transistor might not change the behavior at the I/O 
registers.
If you want to test or verify the pin hardware, I think some minimal 
external hardware needs to be involved.
--- Graham

==

On Monday, August 7, 2017 at 4:22:25 PM UTC-5, Mala Dies wrote:
>
> Hello Graham,
>
> Seth here. Okay, I will just check to see if they are working. I thought 
> the distro could detect our hardware and if it was in working order or not. 
> I know of the *i2cdetect *command to see if the hardware is available but 
> I thought there was a software to detect if the hardware still was working. 
>
> Seth
>
> P.S. Thank you for your input. I will check out the looping function for 
> output. I might just see if the multi-meter can read the respected volts 
> from the pins "I ruined." Thank you, again. 
>
> On Monday, August 7, 2017 at 12:58:39 PM UTC-5, Graham wrote:
>>
>> I don't know how to do a pure software solution.
>> If you want coverage of the BBB Hardware all the way to the pin, I would 
>> do a simple loop-back test, where the pins are connected in pairs, and you 
>> wiggle one pin as an output, and see if its paired pin can see it as an 
>> input.
>> Then reverse and wiggle the second pin, and see if the first sees it.
>> Very simple hardware. Just a bunch of pins shorted to each other.
>>
>> --- Graham
>>
>> ==
>>
>> On Monday, August 7, 2017 at 11:46:43 AM UTC-5, Mala Dies wrote:
>>>
>>> Hello,
>>>
>>> I am still looking around for test options for the Debian OS on our BBB. 
>>> Do you know how to test the P9 and P8 headers on our boards with software?
>>>
>>> Seth
>>>
>>> On Thursday, July 27, 2017 at 7:28:09 PM UTC-5, Mala Dies wrote:

 Hello,

 The other day is when I did some incorrect measurements and almost 
 burned down the "world." Anyway, I need some support. What are some 
 surefire ways I can test my GPIO pins in the Debian distro with our 
 commands?

 Seth

 P.S. I do not want to test them via hardware. I thought there might be 
 a way to test them with our BASH in Debian. If you know and are willing to 
 share, I would like to have you on board on this specific task. Thank you 
 again for the support. 

>>>

-- 
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/3f6fcfba-06a0-4c80-a067-121f6a596e18%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] which uboot source to compile (and how) for emmc/NAND

[wolfwoolford]

Hi,

I'm trying to automate the process of flashing a bootable emmc (NAND) on my 
beagle bone black. I've pin strapped the board to boot using bootp/dhcp - 
the kernel that gets loaded by the u-boot.img (that was pulled in via 
dhcp+tftp) uses an initramfs as the basis of writing the MLO, (a different) 
u-boot.img and root file system (containing zImage and uEnv.txt) to 
emmc/NAND. This all works and when I restart the beagle bone black it boots 
as I expect. Hooray for automated emmc flashing.

However my problem is that I can't seem to hand roll a version the the MLO 
and u-boot.img that I flash to NAND. What I'm using right now are copies I 
found of these two files in the debian images distributed here: 
https://beagleboard.org/latest-images (These images tend to contain 
filesystems with /opt/backup/uboot/MLO and /opt/back/uboot/u-boot.img files 
existing). If I use these two boot loader files, and craft my 
/boot/uEnv.txt just so (uuid needs to be specified), then I can boot a 
couple of kernels/filesystems I have lying around successfully.

But I can't seem to reproduce these two files (MLO and u-boot.img) for my 
NAND from source. I've tried these git repos:

git://git.denx.de/u-boot.git
git://git.ti.com/ti-u-boot/ti-u-boot.git

and even the u-boot source that that ships with the SDK:
~/ti-processor-sdk-linux-am335x-evm-04.00.00.04/board-support/u-boot-2017.01+gitAUTOINC+9fd60700db-g9fd60700db/

For each of those I'm running

make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_evm am335x_evm_defconfig 
&& make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_evm

And I've even tried a different config:

make CROSS_COMPILE=arm-linux-gnueabihf- O=am335x_boneblack 
am335x_boneblack_defconfig && make CROSS_COMPILE=arm-linux-gnueabihf- 
O=am335x_boneblack

This compilation process creates the MLO and u-boot.img files, but I can 
never seem to successfully boot anything if I use them regardless of which 
config I use.

If it helps with clarity, I am trying out MLO and u-boot.img files by 
booting from the SD card, copying over the new versions, and then running

dd if=MLO of=/dev/mmcblk1 conv=notrunc bs=128k count=1 seek=1
dd if=u-boot.img of=/dev/mmcblk1 conv=notrunc bs=384k count=2 seek=1

Note that I can always get back to the "bootable state" by writing the 
backup boot loader files that come with debian distro instead: (the sd card 
is running debian 8.7):

dd if=/opt/backup/uboot/MLO of=/dev/mmcblk1 conv=notrunc bs=128k count=1 
seek=1
dd if=/opt/backup/uboot/u-boot.img of=/dev/mmcblk1 conv=notrunc bs=384k 
count=2 seek=1


How can I build MLO and u-boot.img files in order to successfully boot a 
kernel and file system of my choosing on the emmc/NAND? Is there a page 
somewhere? Any help would be appreciated.

-- 
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/ebe257da-d203-44b8-9b0b-8ca1bc49ca09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] File writing from PRU

[Charles Steinkuehler]

On 8/7/2017 10:55 PM, Clark Sann wrote:
> I need some help from someone who has succeeded in getting the PRU to write 
> files onto the host's file system. I have tried two methods:
> 
> 1. Using open, fputs, fprintf, etc. This does not work for me. First of all, 
> unless I set the printf_support flag to minimal, even a simple program with 
> only 
> a single print statement uses more instruction memory than the BeagleBone PRU 
> has. Even if I set the flag to minimal, I do not find that any files have 
> been 
> written.
> 
> 2. Using the low level drivers described starting on page 124 of the PRUC 
> Compiler V21 User Guide. I also cannot get these functions to write a simple 
> file.
> 
> If anyone has succeeded in getting either of these methods to write a simple 
> string to a file, would you please consider posting some sample code?

You cannot write to anything like a file directly from the PRU.  The
best you could do is enable the PRU UART and craft a version of the C
library that would let you do printf() or similar to a console.

If you need to save data into a file, you will have to pass it from
the PRU to the ARM at which point you can do anything available via
Linux (print to console, write to file, send via Ethernet, etc).

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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/e57bbb0b-5c9b-0391-74eb-a33627da9da1%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Touch on LCD Chipsee (BBB-EXP-C) stopped respond

[Radovan Chovan]

So, now I have figured I can reproduce same problem with rezistive display 
from 4D Systems (BBB revC and Debian Wheezy(not Jessie)), when I touch 
display with my palm.

But command
sudo /etc/init.d/lightdm restart

doesn't help at all. Display reboot with java application autostart lasted 
20 seconds, but touch didn't still respond. When I touched this resistive 
display, I cannot still accomplish to start touch again after many tries 
with palm and finger touches.

-- 
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/d8d8d1a8-5d77-4854-9f90-dc683212%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Touch on LCD Chipsee (BBB-EXP-C) stopped respond

[Radovan Chovan]

Hi,
I have BeagleBoneBlack(revC) and this capacitive touchscreen from Chipsee: 
https://www.logicsupply.com/bbb-exp-c/.

When I tried check temperature of display (which is too high I think) with 
my palm,* I simulated stop of touch responding*. Then I tried touch on 
display with my fingers and palm randomly, but I had to touch display many 
times to accomplish responding of touch again.

*I attach some logs from /var/log.*

Some additional information from *Debian Jessie*:

uname -a
Linux beaglebone 4.4.62-ti-r103 #1 SMP Fri May 12 22:14:44 UTC 2017 armv7l 
GNU/Linux

xinput --list
? Virtual core pointerid=2[master pointer  (3)]
?   ? Virtual core XTEST pointer  id=4[slave  pointer  (2)]
?   ? EP0790M09   id=8[slave  pointer  (2)]
? Virtual core keyboard   id=3[master keyboard (2)]
? Virtual core XTEST keyboard id=5[slave  keyboard (3)]
? gpio_keys   id=6[slave  keyboard (3)]
? tps65217_pwr_butid=7[slave  keyboard (3)]



Problem is that our customer use JAVA application on Beagleaboard revC with 
Chipsee display which must work nonstop.

There are some possibilities of solutions, I hope:
1.) touchscreen driver fix
2.) detection of not touch responding in JAVA application and restart of 
display

With this command I can restart display:
sudo /etc/init.d/lightdm restart
But it lasts 40 seconds. Maybe there is some command for faster reset which 
can I run from JAVA application as Runtime.getRuntime().exec);


Note:
I have similar problem with resistive display from 4D Systems but I cannot 
reproduce issue with "touch not responding" so easily: 
https://groups.google.com/forum/#!msg/beagleboard/yBofgnpHd5I/J-NgrW9VAAAJ

-- 
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/05f0b6a3-9e8f-4f89-b626-9912036a4de0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[+0.00s] DEBUG: Logging to /var/log/lightdm/lightdm.log
[+0.00s] DEBUG: Starting Light Display Manager 1.10.3, UID=0 PID=21085
[+0.00s] DEBUG: Loading configuration dirs from 
/usr/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from 
/usr/share/lightdm/lightdm.conf.d/01_debian.conf
[+0.00s] DEBUG: Loading configuration dirs from 
/usr/local/share/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration dirs from /etc/xdg/lightdm/lightdm.conf.d
[+0.00s] DEBUG: Loading configuration from /etc/lightdm/lightdm.conf
[+0.00s] DEBUG: Using D-Bus name org.freedesktop.DisplayManager
[+0.00s] DEBUG: Registered seat module xlocal
[+0.00s] DEBUG: Registered seat module xremote
[+0.00s] DEBUG: Registered seat module unity
[+0.00s] DEBUG: Registered seat module surfaceflinger
[+0.04s] DEBUG: Adding default seat
[+0.04s] DEBUG: Seat: Starting
[+0.04s] DEBUG: Seat: Creating user session
[+0.05s] WARNING: Error getting user list from org.freedesktop.Accounts: 
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
org.freedesktop.Accounts was not provided by any .service files
[+0.06s] DEBUG: Loading user config from /etc/lightdm/users.conf
[+0.06s] DEBUG: User debian added
[+0.07s] DEBUG: Seat: Creating display server of type x
[+0.07s] DEBUG: Could not run plymouth --ping: Failed to execute child process 
"plymouth" (No such file or directory)
[+0.07s] DEBUG: Using VT 7
[+0.07s] DEBUG: Seat: Starting local X display on VT 7
[+0.07s] DEBUG: DisplayServer x-0: Logging to /var/log/lightdm/x-0.log
[+0.07s] DEBUG: DisplayServer x-0: Writing X server authority to 
/var/run/lightdm/root/:0
[+0.07s] DEBUG: DisplayServer x-0: Launching X Server
[+0.08s] DEBUG: Launching process 21093: /usr/bin/X :0 -seat seat0 -auth 
/var/run/lightdm/root/:0 -nolisten tcp vt7 -novtswitch
[+0.08s] DEBUG: DisplayServer x-0: Waiting for ready signal from X server :0
[+0.08s] DEBUG: Acquired bus name org.freedesktop.DisplayManager
[+0.08s] DEBUG: Registering seat with bus path 
/org/freedesktop/DisplayManager/Seat0
[+1.02s] DEBUG: Got signal 10 from process 21093
[+1.02s] DEBUG: DisplayServer x-0: Got signal from X server :0
[+1.02s] DEBUG: DisplayServer x-0: Connecting to XServer :0
[+1.04s] DEBUG: Seat: Display server ready, starting session authentication
[+1.04s] DEBUG: Session pid=21115: Started with service 'lightdm-autologin', 
username 'debian'
[+1.12s] DEBUG: Session pid=21115: Authentication complete with return value 0: 
Success
[+1.12s] DEBUG: Seat: Session authenticated, running command
[+1.12s] DEBUG: Registering session with bus path 
/org/freedesktop/DisplayManager/Session0
[+1.14s] DEBUG: Session pid=21115: Running command /etc/X11/Xsessi