Re: [beagleboard] 4.1 repo

[Micka]

Robert,

The Kernel side *dts change is :

clk_mcasp0_fixed: clk_mcasp0_fixed {
  #clock-cells = <0>;
  compatible = "fixed-clock";
  clock-frequency = <24576000>;
};

clk_mcasp0: clk_mcasp0 {
  #clock-cells = <0>;
  compatible = "gpio-gate-clock";
  clocks = <_mcasp0_fixed>;
  enable-gpios = < 27 GPIO_ACTIVE_HIGH>; /* BeagleBone
Black Clk enable on GPIO1_27 */
};



is it ?

Le mar. 8 mars 2016 à 15:46, Robert Nelson  a
écrit :

> On Tue, Mar 8, 2016 at 12:21 AM,   wrote:
> > Everyone,
> >
> > I'm a noob and trying to get the BBB Audio Cape Rev B working.  Is there
> an
> > update at all coming from BB on this?
>
>
> https://github.com/beagleboard/bb.org-overlays/commit/419c160cb30f40230edea0460a9776eed1f7779f
>
> I have a kernel side *dts change i need todo to..
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> 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.
>

-- 
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: QNX on beaglebone black

[Karl Karpfen]

This is a bit off-topic, but: what is the state of QNX at the moment? Last 
time I have seen it, it came with a very poor X-Server interface which 
caused strange crashes. And it was not possible to compile and use a 
platform-independent GUI-toolkit like wxWidgets with QNX. Has this changes 
meanwhile or is QNX still a closed universe where all the necessary 
standards do not work?



Am Mittwoch, 9. März 2016 00:27:29 UTC+1 schrieb acheesehead:
>
> I just downloaded and built the latest 'experimental' QNX 6.6 BSP for BBB. 
> Got the same errors. Turns out that the permissions of files in 
> install/sbin and install/bin needed to change. Once I changed their 
> permissions, all goes well. The build script does not mount the SD card or 
> the eMMC, so that must be done manually.
>
> On Tuesday, March 1, 2016 at 3:00:18 PM UTC-7, Steven Hartmann wrote:
>>
>> I hope there is someone here successfully using QNX on the BBB.  I am 
>> currently doing a QNX evaluation and am having trouble with the BBB BSP.  I 
>> am using the BSP_ti-am335x-beaglebone_br-660_be-660_SVN797070_JBN574.zip 
>> BSP.  The package comes with a pre-built image, which boots up fine.  I 
>> have been able to do a few test programs with it, but now I need to modify 
>> the BSP to change which features are used.  The first step in doing this 
>> was to just recompile the BSP to make sure I can recreate the precompiled 
>> version.  The build goes fine and creates an image.  I can boot off the 
>> image, but it gives a lot of errors:
>>
>> U-Boot#  fatload mmc 0 8100 ifs-ti-am335x-beaglebone.bin
>> reading ifs-ti-am335x-beaglebone.bin
>> 5794620 bytes read in 657 ms (8.4 MiB/s)
>> U-Boot# go 8100
>> ## Starting application at 0x8100 ...
>>
>> __Board ID__
>> header:  ee3355aa
>> name:A335BNLT
>> 
>> BeagleBone Black detected
>>
>> VFPv3: fpsid=410330c3
>> coproc_attach(10): attach fe08a3fc (fe08ad24)
>> coproc_attach(11): attach fe08a3fc (fe08ad24)
>> Welcome to QNX Neutrino 6.6.0 on the Texas Instruments AM335x BeagleBone 
>> (ARMv7 Cortex-A8 core) - Board
>> Unable to start "devc-seromap" (2)
>> Unable to access "/dev/ser1" (2)
>> Unable to access "/dev/ser1" (2)
>> Starting MMC/SD driver...
>> Unable to start "devb-sdmmc-j5_generic" (2)
>> Unable to start "devb-sdmmc-j5_generic" (2)
>> starting I2C driver...
>> Unable to start "i2c-omap35xx-j5" (2)
>> Unable to access "/dev/i2c0" (2)
>> starting WDT reset utility...
>> Unable to start "dm814x-wdtkick" (2)
>> starting Board ID driver...
>> Unable to start "am335x-boardid" (2)
>> Unable to access "/dev/bdid" (2)
>> Setting OS Clock from on-board RTC
>> Unable to start "rtc" (2)
>> Sat Jan 01 00:00:15 GMT 2000
>> Starting USB OTG Host driver...
>> Starting SPI driver...
>> Unable to start "spi-master" (2)
>> Starting network driver...
>> starting leds driver...
>> Unable to start "am335x-leds" (2)
>> Unable to access "/dev/leds" (2)
>> Setting environment variables...
>> done.
>> Starting Screen Graphics...
>> done.
>> Starting HDMI Audio driver...
>> Unable to access /dev/snd/pcmC0D1p
>> ksh: No controlling tty (open /dev/tty: No such device or address)
>> ksh: warning: won't have full job control
>>
>>
>> All of the software that reports "unable to start" does not have execute 
>> permissions.  When I tried to add execute permissions by hand, it said the 
>> file did not exist.
>>
>> My build host is linux mint.
>>
>> 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] bbb Internal ADC configuration settings?

[William Hermans]

>
> *Also another conceptual question, can you explain what exactly is
> in_voltage0_raw and iio:device0? I know it's not a folder, and I interact
> with it by using cat. So is it just like a text file or something?*


in_voltage0_raw == one shot mode.

/dev/iio:device0 == continuous mode.

continuous mode is only really useful if you need more than 3-4 thousand
samples a second. Otherwise one shot mode will possibly work just fine. It
really how much you're trying to do all at once.

On Tue, Mar 8, 2016 at 10:51 PM, Audrey  wrote:

> Thanks for the reply John. Could you perhaps explain how to modify the
> oversample, open delay time, and sample time in greater detail in the
> BB-ADC overlay? I do not see these variables in the dto in github (
> https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-ADC-00A0.dts).
> Also, what value can/should I change them to?
>
> So just to clarify, reading from
> /sys/bus/iio/devices/iio:device0/in_voltage0_raw reads attributes using
> sysfs, while reading from /dev/iio:device0 reads the values using IIO? Also
> another conceptual question, can you explain what exactly is
> in_voltage0_raw and iio:device0? I know it's not a folder, and I interact
> with it by using cat. So is it just like a text file or something?
>
> Thanks.
>
> On Sunday, March 6, 2016 at 2:15:17 PM UTC-5, john3909 wrote:
>>
>> That is because you are doing this wrong. Reading attributes via sysfs is
>> slow and not meant for this purpose. With IIO, you enable a scan element
>> (echo 1 > in_voltage0_en) and then you enable the buffer (echo 1 >
>> buffer/enable)and then you read the values from /dev/iio:device0. In the
>> BB-ADC overlay, you can modify the scan update time by modifying the
>> Oversample (default is 16x), Open Delay time (default is 0x98) and sample
>> time (default is 1). Now the IIO ADC driver captures samples using
>> interrupts which isn’t ideal, but it will capture samples at a much higher
>> rate than can be read from sysfs. If you want to capture at full speed, the
>> driver needs to be updated to use DMA.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Mar 6, 2016, at 12:19 AM, Audrey  wrote:
>>
>> Where can I find it (and set it)?
>>
>> I'm right now trying to collect voltage readings using beaglebone's
>> internal adc using a bash script and a while loop. Right now the data
>> collection is clocking at around 33 microseconds, but I know that the
>> internal adc should be able to collect data as fast as 5 microseconds. What
>> should I do to make that happen? Is the problem with making while loops
>> move faster, or is it about setting the adc configurations?
>>
>> This is my bash script:
>>
>> #!/bin/bash
>>
>> #echo cape-bone-iio > /sys/devices/bone_capemgr.*/slots
>>
>> t0=$(date +%s%6N)
>>
>> while true; do
>>t1=$(date +%s%6N)
>>rawVal=$(cat /sys/bus/iio/devices/iio:device0/in_voltage0_raw)
>>voltage=$(bc -l <<< $rawVal/4095*1.8)
>>time=$(expr $t1 - $t0)
>>echo $time $voltage
>> done
>>
>>
>> --
>> 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.
>

-- 
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] bbb Internal ADC configuration settings?

[Audrey]

Thanks for the reply John. Could you perhaps explain how to modify the 
oversample, open delay time, and sample time in greater detail in the 
BB-ADC overlay? I do not see these variables in the dto in github 
(https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/BB-ADC-00A0.dts).
 
Also, what value can/should I change them to?

So just to clarify, reading from 
/sys/bus/iio/devices/iio:device0/in_voltage0_raw reads attributes using 
sysfs, while reading from /dev/iio:device0 reads the values using IIO? Also 
another conceptual question, can you explain what exactly is 
in_voltage0_raw and iio:device0? I know it's not a folder, and I interact 
with it by using cat. So is it just like a text file or something?

Thanks.

On Sunday, March 6, 2016 at 2:15:17 PM UTC-5, john3909 wrote:
>
> That is because you are doing this wrong. Reading attributes via sysfs is 
> slow and not meant for this purpose. With IIO, you enable a scan element 
> (echo 1 > in_voltage0_en) and then you enable the buffer (echo 1 > 
> buffer/enable)and then you read the values from /dev/iio:device0. In the 
> BB-ADC overlay, you can modify the scan update time by modifying the 
> Oversample (default is 16x), Open Delay time (default is 0x98) and sample 
> time (default is 1). Now the IIO ADC driver captures samples using 
> interrupts which isn’t ideal, but it will capture samples at a much higher 
> rate than can be read from sysfs. If you want to capture at full speed, the 
> driver needs to be updated to use DMA. 
>
> Regards,
> John
>
>
>
>
> On Mar 6, 2016, at 12:19 AM, Audrey  wrote:
>
> Where can I find it (and set it)?
>
> I'm right now trying to collect voltage readings using beaglebone's 
> internal adc using a bash script and a while loop. Right now the data 
> collection is clocking at around 33 microseconds, but I know that the 
> internal adc should be able to collect data as fast as 5 microseconds. What 
> should I do to make that happen? Is the problem with making while loops 
> move faster, or is it about setting the adc configurations?
>
> This is my bash script:
>
> #!/bin/bash
>
> #echo cape-bone-iio > /sys/devices/bone_capemgr.*/slots
>
> t0=$(date +%s%6N)
>
> while true; do
>t1=$(date +%s%6N)
>rawVal=$(cat /sys/bus/iio/devices/iio:device0/in_voltage0_raw)
>voltage=$(bc -l <<< $rawVal/4095*1.8)
>time=$(expr $t1 - $t0)
>echo $time $voltage
> done
>
>
> -- 
> 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.

Re: [beagleboard] Using Connman for WiFi AP/tether...

[Brian Anderson]

> > So one has to wonder if it would be wise to eliminate 
> > /etc/network/interfaces (or at least have everthing commented out with 
> > warnings) to help prevent the often occurring confusion when Connman 
> > overrides definitions in /etc/network/interfaces.  And, of course, 
> > /etc/network/interfaces is supposed to be "legacy". 
>
> I think we will just blank it out, then users can add there own tweaks.. 
>

With a big fat warning about connman overriding certain settings!
 

>
> I think i figured out how to get the usb0 to start at 192.168.7.2 
>
> https://paste.debian.net/413402/


Err, couldn't figure out from the pastebin.  Looked at your repo, and it 
appears you are trying to have some control over what the starting IP 
address that DHCP will hand out for tethering?  If so, I don't think you 
can necessarily assume that the USB gadget will be the first thing needing 
an address can you? What if one tethers WiFi then USB?  What if there is an 
address conflict with the localhost or USB host?  I'm assuming that connman 
deals with these use cases when allocating a new IP address via its 
internal DHCP.  And you still won't get the "static" address you desire.


>
> (so much stuff is hard-coded for 192.168.7.2) 
>

Ya, and therein lies the problem it seems.  Maybe it would be best to bite 
the bullet here and go for .local discovery?  OTOH, not sure if 
mDNS hostname discovery works on a Windoze machine?


ba

-- 
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] Waiting for root device

[Robert Nelson]

On Tue, Mar 8, 2016 at 7:57 PM,   wrote:
> I'm trying to boot the 4.4.3 kernel from
> https://github.com/beagleboard/linux/tree/4.4 on a beaglebone white and the
> kernel stops the boot after 'Waiting for root device'

Here's that git checkout on a beaglebone black:

https://paste.debian.net/413462/

I'll test it out on a white tomorrow..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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] Waiting for root device

[William Hermans]

Additionally, are you sure you have 3 partitions on your MMC device ?
Typically on modern RCN releases there is only one.

On Tue, Mar 8, 2016 at 8:18 PM, William Hermans  wrote:

> So here is a silly question. Are you sure /dev/mmcblk0p3 even exists ?
> because mmcblk0 on the beaglebone black would be the eMMC . . .
>
> On Tue, Mar 8, 2016 at 6:57 PM,  wrote:
>
>> I'm trying to boot the 4.4.3 kernel from
>> https://github.com/beagleboard/linux/tree/4.4 on a beaglebone white and
>> the kernel stops the boot after 'Waiting for root device'
>>
>> The MMC* and REGULATOR* options are enabled:
>> CONFIG_MMC=y
>> CONFIG_MMC_BLOCK=y
>> CONFIG_MMC_BLOCK_MINORS=16
>> CONFIG_MMC_BLOCK_BOUNCE=y
>> CONFIG_MMC_OMAP=y
>> CONFIG_MMC_OMAP_HS=y
>> CONFIG_REGULATOR=y
>> CONFIG_REGULATOR_FIXED_VOLTAGE=y
>> CONFIG_REGULATOR_USERSPACE_CONSUMER=y
>> CONFIG_REGULATOR_ACT8865=m
>> CONFIG_REGULATOR_ANATOP=y
>> CONFIG_REGULATOR_AS3722=y
>> CONFIG_REGULATOR_AXP20X=y
>> CONFIG_REGULATOR_DA9052=y
>> CONFIG_REGULATOR_DA9063=y
>> CONFIG_REGULATOR_FAN53555=m
>> CONFIG_REGULATOR_GPIO=y
>> CONFIG_REGULATOR_MC13XXX_CORE=m
>> CONFIG_REGULATOR_MC13783=m
>> CONFIG_REGULATOR_MC13892=m
>> CONFIG_REGULATOR_MT6311=y
>> CONFIG_REGULATOR_PALMAS=y
>> CONFIG_REGULATOR_PBIAS=y
>> CONFIG_REGULATOR_PFUZE100=y
>> CONFIG_REGULATOR_PWM=y
>> CONFIG_REGULATOR_S2MPA01=m
>> CONFIG_REGULATOR_S2MPS11=m
>> CONFIG_REGULATOR_S5M8767=m
>> CONFIG_REGULATOR_TI_ABB=y
>> CONFIG_REGULATOR_TPS65023=y
>> CONFIG_REGULATOR_TPS6507X=y
>> CONFIG_REGULATOR_TPS65217=y
>> CONFIG_REGULATOR_TPS65218=y
>> CONFIG_REGULATOR_TPS65910=y
>> CONFIG_REGULATOR_TWL4030=y
>> CONFIG_REGULATOR_VEXPRESS=m
>>
>> The config is generated from bb.org_defconfig.
>>
>> The full boot log is:
>> ## Booting kernel from Legacy Image at 8200 ...
>>Image Name:   Linux-4.4.3+
>>Image Type:   ARM Linux Kernel Image (no loading done) (uncompressed)
>>Data Size:8112968 Bytes = 7.7 MiB
>>Load Address: fff2
>>Entry Point:  fff2
>>Verifying Checksum ... OK
>> ## Flattened Device Tree blob at 8800
>>Booting using the fdt blob at 0x8800
>>XIP Kernel Image (no loading done) ... OK
>>Using Device Tree in place at 8800, end 88010cb3
>>
>> Starting kernel ...
>>
>> [0.00] Booting Linux on physical CPU 0x0
>> [0.00] Initializing cgroup subsys cpuset
>> [0.00] Initializing cgroup subsys cpu
>> [0.00] Initializing cgroup subsys cpuacct
>> [0.00] Linux version 4.4.3+ () (gcc version 4.9.x-google 20150123
>> (prerelease) (4.9.2_cos_gg_21201ea_4.9.2-r116) ) #30 Tue Mar 8 17:27:58 PST
>> 2016
>> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
>> cr=10c5387d
>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>> instruction cache
>> [0.00] Machine model: TI AM335x BeagleBone
>> [0.00] cma: Reserved 24 MiB at 0x8e80
>> [0.00] Memory policy: Data cache writeback
>> [0.00] CPU: All CPU(s) started in SVC mode.
>> [0.00] AM335X ES1.0 (sgx neon )
>> [0.00] Built 1 zonelists in Zone order, mobility grouping on.
>> Total pages: 64960
>> [0.00] Kernel command line: console=ttyO0,115200n8 loglevel=7
>> init=/sbin/init cros_legacy cros_debug oops=panic panic=-1 noinitrd
>> vt.global_cursor_default=0
>> capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4,BB-UART5,bone-servo-gpios,bone-servo-spi1
>> root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait
>> [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
>> [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072
>> bytes)
>> [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536
>> bytes)
>> [0.00] Memory: 218028K/262144K available (10677K kernel code,
>> 836K rwdata, 3704K rodata, 592K init, 857K bss, 19540K reserved, 24576K
>> cma-reserved, 0K highmem)
>> [0.00] Virtual kernel memory layout:
>> [0.00] vector  : 0x - 0x1000   (   4 kB)
>> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
>> [0.00] vmalloc : 0xd080 - 0xff80   ( 752 MB)
>> [0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
>> [0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>> [0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
>> [0.00]   .text : 0xc0008000 - 0xc0e1370c   (14382 kB)
>> [0.00]   .init : 0xc0e14000 - 0xc0ea8000   ( 592 kB)
>> [0.00]   .data : 0xc0ea8000 - 0xc0f791c8   ( 837 kB)
>> [0.00].bss : 0xc0f7d000 - 0xc1053514   ( 858 kB)
>> [0.00] NR_IRQS:16 nr_irqs:16 16
>> [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128
>> interrupts
>> [0.00] OMAP clockevent source: timer2 at 2400 Hz
>> [0.21] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps
>> every 89478484971ns
>> [0.50] clocksource: timer1: mask: 

Re: [beagleboard] Waiting for root device

[William Hermans]

So here is a silly question. Are you sure /dev/mmcblk0p3 even exists ?
because mmcblk0 on the beaglebone black would be the eMMC . . .

On Tue, Mar 8, 2016 at 6:57 PM,  wrote:

> I'm trying to boot the 4.4.3 kernel from
> https://github.com/beagleboard/linux/tree/4.4 on a beaglebone white and
> the kernel stops the boot after 'Waiting for root device'
>
> The MMC* and REGULATOR* options are enabled:
> CONFIG_MMC=y
> CONFIG_MMC_BLOCK=y
> CONFIG_MMC_BLOCK_MINORS=16
> CONFIG_MMC_BLOCK_BOUNCE=y
> CONFIG_MMC_OMAP=y
> CONFIG_MMC_OMAP_HS=y
> CONFIG_REGULATOR=y
> CONFIG_REGULATOR_FIXED_VOLTAGE=y
> CONFIG_REGULATOR_USERSPACE_CONSUMER=y
> CONFIG_REGULATOR_ACT8865=m
> CONFIG_REGULATOR_ANATOP=y
> CONFIG_REGULATOR_AS3722=y
> CONFIG_REGULATOR_AXP20X=y
> CONFIG_REGULATOR_DA9052=y
> CONFIG_REGULATOR_DA9063=y
> CONFIG_REGULATOR_FAN53555=m
> CONFIG_REGULATOR_GPIO=y
> CONFIG_REGULATOR_MC13XXX_CORE=m
> CONFIG_REGULATOR_MC13783=m
> CONFIG_REGULATOR_MC13892=m
> CONFIG_REGULATOR_MT6311=y
> CONFIG_REGULATOR_PALMAS=y
> CONFIG_REGULATOR_PBIAS=y
> CONFIG_REGULATOR_PFUZE100=y
> CONFIG_REGULATOR_PWM=y
> CONFIG_REGULATOR_S2MPA01=m
> CONFIG_REGULATOR_S2MPS11=m
> CONFIG_REGULATOR_S5M8767=m
> CONFIG_REGULATOR_TI_ABB=y
> CONFIG_REGULATOR_TPS65023=y
> CONFIG_REGULATOR_TPS6507X=y
> CONFIG_REGULATOR_TPS65217=y
> CONFIG_REGULATOR_TPS65218=y
> CONFIG_REGULATOR_TPS65910=y
> CONFIG_REGULATOR_TWL4030=y
> CONFIG_REGULATOR_VEXPRESS=m
>
> The config is generated from bb.org_defconfig.
>
> The full boot log is:
> ## Booting kernel from Legacy Image at 8200 ...
>Image Name:   Linux-4.4.3+
>Image Type:   ARM Linux Kernel Image (no loading done) (uncompressed)
>Data Size:8112968 Bytes = 7.7 MiB
>Load Address: fff2
>Entry Point:  fff2
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 8800
>Booting using the fdt blob at 0x8800
>XIP Kernel Image (no loading done) ... OK
>Using Device Tree in place at 8800, end 88010cb3
>
> Starting kernel ...
>
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Initializing cgroup subsys cpuset
> [0.00] Initializing cgroup subsys cpu
> [0.00] Initializing cgroup subsys cpuacct
> [0.00] Linux version 4.4.3+ () (gcc version 4.9.x-google 20150123
> (prerelease) (4.9.2_cos_gg_21201ea_4.9.2-r116) ) #30 Tue Mar 8 17:27:58 PST
> 2016
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7),
> cr=10c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [0.00] Machine model: TI AM335x BeagleBone
> [0.00] cma: Reserved 24 MiB at 0x8e80
> [0.00] Memory policy: Data cache writeback
> [0.00] CPU: All CPU(s) started in SVC mode.
> [0.00] AM335X ES1.0 (sgx neon )
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.
> Total pages: 64960
> [0.00] Kernel command line: console=ttyO0,115200n8 loglevel=7
> init=/sbin/init cros_legacy cros_debug oops=panic panic=-1 noinitrd
> vt.global_cursor_default=0
> capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4,BB-UART5,bone-servo-gpios,bone-servo-spi1
> root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait
> [0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
> [0.00] Dentry cache hash table entries: 32768 (order: 5, 131072
> bytes)
> [0.00] Inode-cache hash table entries: 16384 (order: 4, 65536
> bytes)
> [0.00] Memory: 218028K/262144K available (10677K kernel code, 836K
> rwdata, 3704K rodata, 592K init, 857K bss, 19540K reserved, 24576K
> cma-reserved, 0K highmem)
> [0.00] Virtual kernel memory layout:
> [0.00] vector  : 0x - 0x1000   (   4 kB)
> [0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
> [0.00] vmalloc : 0xd080 - 0xff80   ( 752 MB)
> [0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
> [0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
> [0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
> [0.00]   .text : 0xc0008000 - 0xc0e1370c   (14382 kB)
> [0.00]   .init : 0xc0e14000 - 0xc0ea8000   ( 592 kB)
> [0.00]   .data : 0xc0ea8000 - 0xc0f791c8   ( 837 kB)
> [0.00].bss : 0xc0f7d000 - 0xc1053514   ( 858 kB)
> [0.00] NR_IRQS:16 nr_irqs:16 16
> [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128
> interrupts
> [0.00] OMAP clockevent source: timer2 at 2400 Hz
> [0.21] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
> 89478484971ns
> [0.50] clocksource: timer1: mask: 0x max_cycles:
> 0x, max_idle_ns: 79635851949 ns
> [0.68] OMAP clocksource: timer1 at 2400 Hz
> [0.000470] Console: colour dummy device 80x30
> [0.000515] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
> [0.000525] This ensures that you still see kernel messages. 

Re: [beagleboard] Re: tilcdc FIFO underflow

[William Hermans]

That's not what I've been taught over the last 20 years. In C variable[0]
is essentially a pointer to the start of variable. Which if you want to get
technical is not the "adddress of" variable. Regardless  should
give the starting address of variable. So at minimum [0] is a bit
superfluous which makes the code harder to read through . . . and is
something I'd never do personally.

Is that nick picky enough ? ;)

Also to nickpick even more. memset() expects type unsigned character, and
uint8_t *, and unsigned char * are not really equivalent . . . which is a
source of even more errors ;) *This* I've had personal hands on with ;)

On Tue, Mar 8, 2016 at 7:07 PM,  wrote:

> *Because it's not calling malloc() over and over...*
>>>
>>
>> Yeap, you're right it's calling memset() every loop. Not sure why I was
>> thinking it was calling malloc() every loop. But the point is, it does not
>> matter what is being called in the loop. any system / API call in the loop,
>> without some form of a sleep() will eat up a lot of CPU cycles. Again, as
>> much as the system will allow it to, which is usually in the mid to high
>> 90%'s . . .
>>
>
> Yes it's definitely not nice to call memset() in such a tight loop, but
> the program is just for demonstration purposes. As mentioned at least one
> gstreamer 1.6 audio decoder plugins will call memset() consecutively fast
> enough to cause issues with the lcdc dma. And thus screen flicker.
>
>
> So,  <- beginning of an array, equivalent to variable[0], but
>> what is [0] ? A multi dimensional array ? that's not what was
>> defined . . . to be 100% honest I'm not sure what it does, but the first
>> thing that comes to mind is "undefined behavior".
>>
> I won't go into details, but "" is not the same as "variable[0]".
> (You might be able construct some special/silly case tho where the content
> of variable[0] is equivalent to ).
>
> And "[0]" is equivalent to "variable". The latter might have been
> more readable in the context of the code, but both version are valid C.
> Basically you are getting the address of the first element of the memory
> block, which is the starting address of the memory block itself, which is
> what memset expects.
>
>
>> On Tue, Mar 8, 2016 at 5:39 PM,  wrote:
>>
>>> I'm surprised that code would compile at all without a compiler error.
 As [0] probably is not what you think it is.

>>> I see no issue here. Can you elaborate?
>>>
>>>
 Also, for the record, infinitely allocating an arbitrary amount of
 dynamic memory, in a loop, without any kind of a pause is going to eat up
 an incredible amount of CPU cycles. As in that code will very likely use as
 close to 100% CPU as the system will allow it. Which again, is no wonder
 you're "flickering" . . .

>>> The code is not allocating anything in a loop.
>>>
>>>
 You lucky your program does not randomly crash for using malloc() on
 the same dynamic memory over, and over, without using free(), or instead
 using realloc() . . .

>>> Because it's not calling malloc() over and over...
>>>
>>>
>>> The issue here is that if you run memset() in a tight loop (which at
>>> least one gstreamer1.6 audio decoder plugins does), it seems to clog up the
>>> data bus enough for the DMA to fail.
>>>
>>>
>>>
 On Tue, Mar 8, 2016 at 10:16 AM, Radek Dostál  wrote:

> Hi Michael,
>
> we had very similar issue, which we encountered when updating to
> gstreamer 1.6. Using git bisect we were able to find a root cause and
> prepare simple test program, which reliably reproduces the issue:
>
> #include 
> #include 
> #include 
>
> int main(int argc, char **argv)
> {
> int size;
> uint8_t *memblock;
>
> if (argc < 2)
> return -1;
>
> size = atoi(argv[1]);
>
> memblock = malloc(size);
>
> while (1)
> {
> memset([0], 0, size);
> }
>
> free(memblock);
>
> return 0;
> }
>
> starting this program will cause crazy flickering, ...
>
> We were able to reproduce the issue with
>
> 1) debian originally provided on beaglebone using memtest utility for
> carlos. Kernel version was:
>
> Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) (gcc
> version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015
>
> 2) latest version of debian from beaglebone website Kernel version
> was:
>
> Linux version 4.1.15-ti-rt-r43 (root@a4-imx6q-wandboard-2gb) (gcc
> version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT RT Thu Jan 21 20:13:58 
> UTC
> 2016
>
> so it seems to be existing for ages.
>
> Did you in the mean time managed to find a solution for your problem?
>
> Thanks,
> Radek
>
> On Monday, 

Re: [beagleboard] Re: tilcdc FIFO underflow

[pietrmar]

>
> *Because it's not calling malloc() over and over...*
>>
>
> Yeap, you're right it's calling memset() every loop. Not sure why I was 
> thinking it was calling malloc() every loop. But the point is, it does not 
> matter what is being called in the loop. any system / API call in the loop, 
> without some form of a sleep() will eat up a lot of CPU cycles. Again, as 
> much as the system will allow it to, which is usually in the mid to high 
> 90%'s . . .
>

Yes it's definitely not nice to call memset() in such a tight loop, but the 
program is just for demonstration purposes. As mentioned at least one 
gstreamer 1.6 audio decoder plugins will call memset() consecutively fast 
enough to cause issues with the lcdc dma. And thus screen flicker.
 

So,  <- beginning of an array, equivalent to variable[0], but what 
> is [0] ? A multi dimensional array ? that's not what was defined 
> . . . to be 100% honest I'm not sure what it does, but the first thing that 
> comes to mind is "undefined behavior".
>
I won't go into details, but "" is not the same as "variable[0]". 
(You might be able construct some special/silly case tho where the content 
of variable[0] is equivalent to ).

And "[0]" is equivalent to "variable". The latter might have been 
more readable in the context of the code, but both version are valid C. 
Basically you are getting the address of the first element of the memory 
block, which is the starting address of the memory block itself, which is 
what memset expects.


> On Tue, Mar 8, 2016 at 5:39 PM,  wrote:
>
>> I'm surprised that code would compile at all without a compiler error. As 
>>> [0] probably is not what you think it is. 
>>>
>> I see no issue here. Can you elaborate?
>>  
>>
>>> Also, for the record, infinitely allocating an arbitrary amount of 
>>> dynamic memory, in a loop, without any kind of a pause is going to eat up 
>>> an incredible amount of CPU cycles. As in that code will very likely use as 
>>> close to 100% CPU as the system will allow it. Which again, is no wonder 
>>> you're "flickering" . . .
>>>
>> The code is not allocating anything in a loop.
>>  
>>
>>> You lucky your program does not randomly crash for using malloc() on the 
>>> same dynamic memory over, and over, without using free(), or instead using 
>>> realloc() . . .
>>>
>> Because it's not calling malloc() over and over...
>>
>>
>> The issue here is that if you run memset() in a tight loop (which at 
>> least one gstreamer1.6 audio decoder plugins does), it seems to clog up the 
>> data bus enough for the DMA to fail.
>>
>>  
>>
>>> On Tue, Mar 8, 2016 at 10:16 AM, Radek Dostál  wrote:
>>>
 Hi Michael,

 we had very similar issue, which we encountered when updating to 
 gstreamer 1.6. Using git bisect we were able to find a root cause and 
 prepare simple test program, which reliably reproduces the issue:

 #include 
 #include 
 #include 

 int main(int argc, char **argv)
 {
 int size;
 uint8_t *memblock;

 if (argc < 2)
 return -1;

 size = atoi(argv[1]);

 memblock = malloc(size);

 while (1)
 {
 memset([0], 0, size);
 }

 free(memblock);

 return 0;
 }

 starting this program will cause crazy flickering, ...

 We were able to reproduce the issue with

 1) debian originally provided on beaglebone using memtest utility for 
 carlos. Kernel version was: 

 Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) (gcc version 
 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015 

 2) latest version of debian from beaglebone website Kernel version was: 

 Linux version 4.1.15-ti-rt-r43 (root@a4-imx6q-wandboard-2gb) (gcc 
 version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT RT Thu Jan 21 20:13:58 
 UTC 
 2016 

 so it seems to be existing for ages.

 Did you in the mean time managed to find a solution for your problem?

 Thanks,
 Radek

 On Monday, February 8, 2016 at 1:18:50 PM UTC+1, Michael Liesenberg 
 wrote:
>
> Hi there,
>
>
> i was able to get my 10.1 custom Display to work with the RGB Pins on 
> the beaglebone black.
>
> I am using the latest Debian Jessie image from beagleboard.org and 
> the X11 Desktop has the right colors and the right size.
>
> So i assume that the Timings from my display are correct.
>
>
> panel {
>
> status = "okay";
>
> compatible = "ti,tilcdc,panel";
>
> pinctrl-names = "default";
>
> pinctrl-0 = <_lcd_lcd_pins>;
>
> panel-info {
>

[beagleboard] Waiting for root device

[printesoi]

I'm trying to boot the 4.4.3 kernel 
from https://github.com/beagleboard/linux/tree/4.4 on a beaglebone white 
and the kernel stops the boot after 'Waiting for root device'

The MMC* and REGULATOR* options are enabled:
CONFIG_MMC=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=16
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_MMC_OMAP=y
CONFIG_MMC_OMAP_HS=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_USERSPACE_CONSUMER=y
CONFIG_REGULATOR_ACT8865=m
CONFIG_REGULATOR_ANATOP=y
CONFIG_REGULATOR_AS3722=y
CONFIG_REGULATOR_AXP20X=y
CONFIG_REGULATOR_DA9052=y
CONFIG_REGULATOR_DA9063=y
CONFIG_REGULATOR_FAN53555=m
CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_MC13XXX_CORE=m
CONFIG_REGULATOR_MC13783=m
CONFIG_REGULATOR_MC13892=m
CONFIG_REGULATOR_MT6311=y
CONFIG_REGULATOR_PALMAS=y
CONFIG_REGULATOR_PBIAS=y
CONFIG_REGULATOR_PFUZE100=y
CONFIG_REGULATOR_PWM=y
CONFIG_REGULATOR_S2MPA01=m
CONFIG_REGULATOR_S2MPS11=m
CONFIG_REGULATOR_S5M8767=m
CONFIG_REGULATOR_TI_ABB=y
CONFIG_REGULATOR_TPS65023=y
CONFIG_REGULATOR_TPS6507X=y
CONFIG_REGULATOR_TPS65217=y
CONFIG_REGULATOR_TPS65218=y
CONFIG_REGULATOR_TPS65910=y
CONFIG_REGULATOR_TWL4030=y
CONFIG_REGULATOR_VEXPRESS=m

The config is generated from bb.org_defconfig.

The full boot log is:
## Booting kernel from Legacy Image at 8200 ...
   Image Name:   Linux-4.4.3+
   Image Type:   ARM Linux Kernel Image (no loading done) (uncompressed)
   Data Size:8112968 Bytes = 7.7 MiB
   Load Address: fff2
   Entry Point:  fff2
   Verifying Checksum ... OK
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   XIP Kernel Image (no loading done) ... OK
   Using Device Tree in place at 8800, end 88010cb3

Starting kernel ...

[0.00] Booting Linux on physical CPU 0x0
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys cpuacct
[0.00] Linux version 4.4.3+ () (gcc version 4.9.x-google 20150123 
(prerelease) (4.9.2_cos_gg_21201ea_4.9.2-r116) ) #30 Tue Mar 8 17:27:58 PST 
2016
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
cr=10c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine model: TI AM335x BeagleBone
[0.00] cma: Reserved 24 MiB at 0x8e80
[0.00] Memory policy: Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES1.0 (sgx neon )
[0.00] Built 1 zonelists in Zone order, mobility grouping on. 
 Total pages: 64960
[0.00] Kernel command line: console=ttyO0,115200n8 loglevel=7 
init=/sbin/init cros_legacy cros_debug oops=panic panic=-1 noinitrd 
vt.global_cursor_default=0 
capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4,BB-UART5,bone-servo-gpios,bone-servo-spi1
 
root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 
bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] Memory: 218028K/262144K available (10677K kernel code, 836K 
rwdata, 3704K rodata, 592K init, 857K bss, 19540K reserved, 24576K 
cma-reserved, 0K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xd080 - 0xff80   ( 752 MB)
[0.00] lowmem  : 0xc000 - 0xd000   ( 256 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc0e1370c   (14382 kB)
[0.00]   .init : 0xc0e14000 - 0xc0ea8000   ( 592 kB)
[0.00]   .data : 0xc0ea8000 - 0xc0f791c8   ( 837 kB)
[0.00].bss : 0xc0f7d000 - 0xc1053514   ( 858 kB)
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 
interrupts
[0.00] OMAP clockevent source: timer2 at 2400 Hz
[0.21] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 
89478484971ns
[0.50] clocksource: timer1: mask: 0x max_cycles: 
0x, max_idle_ns: 79635851949 ns
[0.68] OMAP clocksource: timer1 at 2400 Hz
[0.000470] Console: colour dummy device 80x30
[0.000515] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
[0.000525] This ensures that you still see kernel messages. Please
[0.000534] update your kernel commandline.
[0.000559] Calibrating delay loop... 548.86 BogoMIPS (lpj=2744320)
[0.048563] pid_max: default: 32768 minimum: 301
[0.048750] Security Framework initialized
[0.048769] Yama: becoming mindful.
[0.048821] AppArmor: AppArmor disabled by boot time parameter
[0.049088] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[  

Re: [beagleboard] Re: tilcdc FIFO underflow

[William Hermans]

I would also like to point out that the free() after the loop ( end of
program ) is not necessary. Modern Linux versions deal with this
automatically. I do not suppose it'll hurt, but figured I'd point that out.

On Tue, Mar 8, 2016 at 6:23 PM, William Hermans  wrote:

> *Because it's not calling malloc() over and over...*
>>
>
> Yeap, you're right it's calling memset() every loop. Not sure why I was
> thinking it was calling malloc() every loop. But the point is, it does not
> matter what is being called in the loop. any system / API call in the loop,
> without some form of a sleep() will eat up a lot of CPU cycles. Again, as
> much as the system will allow it to, which is usually in the mid to high
> 90%'s . . .
>
> I'm surprised that code would compile at all without a compiler error. As
>> [0] probably is not what you think it is.
>>
> I see no issue here. Can you elaborate?
>
> So,  <- beginning of an array, equivalent to variable[0], but
> what is [0] ? A multi dimensional array ? that's not what was
> defined . . . to be 100% honest I'm not sure what it does, but the first
> thing that comes to mind is "undefined behavior".
>
>
> On Tue, Mar 8, 2016 at 5:39 PM,  wrote:
>
>> I'm surprised that code would compile at all without a compiler error. As
>>> [0] probably is not what you think it is.
>>>
>> I see no issue here. Can you elaborate?
>>
>>
>>> Also, for the record, infinitely allocating an arbitrary amount of
>>> dynamic memory, in a loop, without any kind of a pause is going to eat up
>>> an incredible amount of CPU cycles. As in that code will very likely use as
>>> close to 100% CPU as the system will allow it. Which again, is no wonder
>>> you're "flickering" . . .
>>>
>> The code is not allocating anything in a loop.
>>
>>
>>> You lucky your program does not randomly crash for using malloc() on the
>>> same dynamic memory over, and over, without using free(), or instead using
>>> realloc() . . .
>>>
>> Because it's not calling malloc() over and over...
>>
>>
>> The issue here is that if you run memset() in a tight loop (which at
>> least one gstreamer1.6 audio decoder plugins does), it seems to clog up the
>> data bus enough for the DMA to fail.
>>
>>
>>
>>> On Tue, Mar 8, 2016 at 10:16 AM, Radek Dostál  wrote:
>>>
 Hi Michael,

 we had very similar issue, which we encountered when updating to
 gstreamer 1.6. Using git bisect we were able to find a root cause and
 prepare simple test program, which reliably reproduces the issue:

 #include 
 #include 
 #include 

 int main(int argc, char **argv)
 {
 int size;
 uint8_t *memblock;

 if (argc < 2)
 return -1;

 size = atoi(argv[1]);

 memblock = malloc(size);

 while (1)
 {
 memset([0], 0, size);
 }

 free(memblock);

 return 0;
 }

 starting this program will cause crazy flickering, ...

 We were able to reproduce the issue with

 1) debian originally provided on beaglebone using memtest utility for
 carlos. Kernel version was:

 Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) (gcc version
 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015

 2) latest version of debian from beaglebone website Kernel version was:

 Linux version 4.1.15-ti-rt-r43 (root@a4-imx6q-wandboard-2gb) (gcc
 version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT RT Thu Jan 21 20:13:58 UTC
 2016

 so it seems to be existing for ages.

 Did you in the mean time managed to find a solution for your problem?

 Thanks,
 Radek

 On Monday, February 8, 2016 at 1:18:50 PM UTC+1, Michael Liesenberg
 wrote:
>
> Hi there,
>
>
> i was able to get my 10.1 custom Display to work with the RGB Pins on
> the beaglebone black.
>
> I am using the latest Debian Jessie image from beagleboard.org and
> the X11 Desktop has the right colors and the right size.
>
> So i assume that the Timings from my display are correct.
>
>
> panel {
>
> status = "okay";
>
> compatible = "ti,tilcdc,panel";
>
> pinctrl-names = "default";
>
> pinctrl-0 = <_lcd_lcd_pins>;
>
> panel-info {
>
> ac-bias   = <255>;
>
> ac-bias-intrpt= <0>;
>
> dma-burst-sz  = <16>;
>
> bpp   = <32>;
>
> fdd 

Re: [beagleboard] Re: tilcdc FIFO underflow

[William Hermans]

>
> *Because it's not calling malloc() over and over...*
>

Yeap, you're right it's calling memset() every loop. Not sure why I was
thinking it was calling malloc() every loop. But the point is, it does not
matter what is being called in the loop. any system / API call in the loop,
without some form of a sleep() will eat up a lot of CPU cycles. Again, as
much as the system will allow it to, which is usually in the mid to high
90%'s . . .

I'm surprised that code would compile at all without a compiler error. As
> [0] probably is not what you think it is.
>
I see no issue here. Can you elaborate?

So,  <- beginning of an array, equivalent to variable[0], but what
is [0] ? A multi dimensional array ? that's not what was defined .
. . to be 100% honest I'm not sure what it does, but the first thing that
comes to mind is "undefined behavior".


On Tue, Mar 8, 2016 at 5:39 PM,  wrote:

> I'm surprised that code would compile at all without a compiler error. As
>> [0] probably is not what you think it is.
>>
> I see no issue here. Can you elaborate?
>
>
>> Also, for the record, infinitely allocating an arbitrary amount of
>> dynamic memory, in a loop, without any kind of a pause is going to eat up
>> an incredible amount of CPU cycles. As in that code will very likely use as
>> close to 100% CPU as the system will allow it. Which again, is no wonder
>> you're "flickering" . . .
>>
> The code is not allocating anything in a loop.
>
>
>> You lucky your program does not randomly crash for using malloc() on the
>> same dynamic memory over, and over, without using free(), or instead using
>> realloc() . . .
>>
> Because it's not calling malloc() over and over...
>
>
> The issue here is that if you run memset() in a tight loop (which at least
> one gstreamer1.6 audio decoder plugins does), it seems to clog up the data
> bus enough for the DMA to fail.
>
>
>
>> On Tue, Mar 8, 2016 at 10:16 AM, Radek Dostál  wrote:
>>
>>> Hi Michael,
>>>
>>> we had very similar issue, which we encountered when updating to
>>> gstreamer 1.6. Using git bisect we were able to find a root cause and
>>> prepare simple test program, which reliably reproduces the issue:
>>>
>>> #include 
>>> #include 
>>> #include 
>>>
>>> int main(int argc, char **argv)
>>> {
>>> int size;
>>> uint8_t *memblock;
>>>
>>> if (argc < 2)
>>> return -1;
>>>
>>> size = atoi(argv[1]);
>>>
>>> memblock = malloc(size);
>>>
>>> while (1)
>>> {
>>> memset([0], 0, size);
>>> }
>>>
>>> free(memblock);
>>>
>>> return 0;
>>> }
>>>
>>> starting this program will cause crazy flickering, ...
>>>
>>> We were able to reproduce the issue with
>>>
>>> 1) debian originally provided on beaglebone using memtest utility for
>>> carlos. Kernel version was:
>>>
>>> Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) (gcc version
>>> 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015
>>>
>>> 2) latest version of debian from beaglebone website Kernel version was:
>>>
>>> Linux version 4.1.15-ti-rt-r43 (root@a4-imx6q-wandboard-2gb) (gcc
>>> version 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT RT Thu Jan 21 20:13:58 UTC
>>> 2016
>>>
>>> so it seems to be existing for ages.
>>>
>>> Did you in the mean time managed to find a solution for your problem?
>>>
>>> Thanks,
>>> Radek
>>>
>>> On Monday, February 8, 2016 at 1:18:50 PM UTC+1, Michael Liesenberg
>>> wrote:

 Hi there,


 i was able to get my 10.1 custom Display to work with the RGB Pins on
 the beaglebone black.

 I am using the latest Debian Jessie image from beagleboard.org and the
 X11 Desktop has the right colors and the right size.

 So i assume that the Timings from my display are correct.


 panel {

 status = "okay";

 compatible = "ti,tilcdc,panel";

 pinctrl-names = "default";

 pinctrl-0 = <_lcd_lcd_pins>;

 panel-info {

 ac-bias   = <255>;

 ac-bias-intrpt= <0>;

 dma-burst-sz  = <16>;

 bpp   = <32>;

 fdd   = <0x80>;

 tft-alt-mode  = <0>;

 stn-565-mode  = <0>;

 mono-8bit-mode= <0>;

 sync-edge = <0>;

 sync-ctrl = <1>;

 

Re: [beagleboard] Re: tilcdc FIFO underflow

[pietrmar]

>
> I'm surprised that code would compile at all without a compiler error. As 
> [0] probably is not what you think it is. 
>
I see no issue here. Can you elaborate?
 

> Also, for the record, infinitely allocating an arbitrary amount of dynamic 
> memory, in a loop, without any kind of a pause is going to eat up an 
> incredible amount of CPU cycles. As in that code will very likely use as 
> close to 100% CPU as the system will allow it. Which again, is no wonder 
> you're "flickering" . . .
>
The code is not allocating anything in a loop.
 

> You lucky your program does not randomly crash for using malloc() on the 
> same dynamic memory over, and over, without using free(), or instead using 
> realloc() . . .
>
Because it's not calling malloc() over and over...


The issue here is that if you run memset() in a tight loop (which at least 
one gstreamer1.6 audio decoder plugins does), it seems to clog up the data 
bus enough for the DMA to fail.

 

> On Tue, Mar 8, 2016 at 10:16 AM, Radek Dostál  > wrote:
>
>> Hi Michael,
>>
>> we had very similar issue, which we encountered when updating to 
>> gstreamer 1.6. Using git bisect we were able to find a root cause and 
>> prepare simple test program, which reliably reproduces the issue:
>>
>> #include 
>> #include 
>> #include 
>>
>> int main(int argc, char **argv)
>> {
>> int size;
>> uint8_t *memblock;
>>
>> if (argc < 2)
>> return -1;
>>
>> size = atoi(argv[1]);
>>
>> memblock = malloc(size);
>>
>> while (1)
>> {
>> memset([0], 0, size);
>> }
>>
>> free(memblock);
>>
>> return 0;
>> }
>>
>> starting this program will cause crazy flickering, ...
>>
>> We were able to reproduce the issue with
>>
>> 1) debian originally provided on beaglebone using memtest utility for 
>> carlos. Kernel version was: 
>>
>> Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) (gcc version 
>> 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015 
>>
>> 2) latest version of debian from beaglebone website Kernel version was: 
>>
>> Linux version 4.1.15-ti-rt-r43 (root@a4-imx6q-wandboard-2gb) (gcc version 
>> 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT RT Thu Jan 21 20:13:58 UTC 2016 
>>
>> so it seems to be existing for ages.
>>
>> Did you in the mean time managed to find a solution for your problem?
>>
>> Thanks,
>> Radek
>>
>> On Monday, February 8, 2016 at 1:18:50 PM UTC+1, Michael Liesenberg wrote:
>>>
>>> Hi there,
>>>
>>>
>>> i was able to get my 10.1 custom Display to work with the RGB Pins on 
>>> the beaglebone black.
>>>
>>> I am using the latest Debian Jessie image from beagleboard.org and the 
>>> X11 Desktop has the right colors and the right size.
>>>
>>> So i assume that the Timings from my display are correct.
>>>
>>>
>>> panel {
>>>
>>> status = "okay";
>>>
>>> compatible = "ti,tilcdc,panel";
>>>
>>> pinctrl-names = "default";
>>>
>>> pinctrl-0 = <_lcd_lcd_pins>;
>>>
>>> panel-info {
>>>
>>> ac-bias   = <255>;
>>>
>>> ac-bias-intrpt= <0>;
>>>
>>> dma-burst-sz  = <16>;
>>>
>>> bpp   = <32>;
>>>
>>> fdd   = <0x80>;
>>>
>>> tft-alt-mode  = <0>;
>>>
>>> stn-565-mode  = <0>;
>>>
>>> mono-8bit-mode= <0>;
>>>
>>> sync-edge = <0>;
>>>
>>> sync-ctrl = <1>;
>>>
>>> raster-order  = <0>;
>>>
>>> fifo-th   = <0>;
>>>
>>> };
>>>
>>> display-timings {
>>>
>>> native-mode = <>;
>>>
>>> timing0: 1280x800 {
>>>
>>> clock-frequency = 
>>> <7000>;
>>>
>>> hactive = <1280>;
>>>
>>> vactive = <800>;
>>>
>>> hfront-porch = <80>;
>>>
>>> hback-porch = <60>;
>>>
>>> hsync-len = <20>;
>>>
>>> vback-porch = <12>;
>>>
>>> vfront-porch = <8>;
>>>
>>> vsync-len = <3>;
>>>

Re: [beagleboard] Using Connman for WiFi AP/tether...

[William Hermans]

Also, I'm glad you all are working on getting this working. Truly. But is
it or does it really have to be all this work, and all this difficult to
get this sort of thing working ? Me, I really *really* hate, yes hate, with
a passion -> connman. So of course im sitting on the sidelines here
thinking this should be doable with using connman. But again, of course,
I've no hands on yet to date.

On Tue, Mar 8, 2016 at 6:05 PM, William Hermans  wrote:

> *(so much stuff is hard-coded for 192.168.7.2)*
>>
>
> So, again. I'm wondering why you all *need* to have dhcp on this interface
> at all ? I mean with all the hassles I'm hearing about on the forums here,
> it would be easier to teach people how to set the interface manually to
> *7.1 on the host side. Then of course . . . *7.2 on the beaglebone. I've
> been doing this pretty much since day one, give or take a week or two shake
> down early on . . .and yeah have had no problems. Definately not the
> problems I'm seeing crop up on the forums here all the time . . .
>
> On Tue, Mar 8, 2016 at 4:25 PM, Robert Nelson 
> wrote:
>
>> > Ya.  I have a couple of BBGs and didn't read the fine print close
>> enough to
>> > see that there is no barrel jack.
>> > So, I have an Andice Labs Power Cape at the ready and/or build my own
>> power
>> > supply as power over USB is obviously such a non-starter for real work.
>>
>> I have that same power cape, just need to assemble it..
>>
>> >
>> > Excellent!
>> >
>> > So one has to wonder if it would be wise to eliminate
>> > /etc/network/interfaces (or at least have everthing commented out with
>> > warnings) to help prevent the often occurring confusion when Connman
>> > overrides definitions in /etc/network/interfaces.  And, of course,
>> > /etc/network/interfaces is supposed to be "legacy".
>>
>> I think we will just blank it out, then users can add there own tweaks..
>>
>> I think i figured out how to get the usb0 to start at 192.168.7.2
>>
>> https://paste.debian.net/413402/
>>
>> (so much stuff is hard-coded for 192.168.7.2)
>>
>> > When this is sorted, it would be cool to work towards an "on-boarding"
>> > solution (possibly using something like AllJoyn OnBoarding Service) to
>> > provision credentials on boards with on board wifi...sorta like what
>> JasonK
>> > was pining about.
>>
>> I'd be up for anything unified.. ;)
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
>> --
>> 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.
>>
>
>

-- 
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] Using Connman for WiFi AP/tether...

[William Hermans]

>
> *(so much stuff is hard-coded for 192.168.7.2)*
>

So, again. I'm wondering why you all *need* to have dhcp on this interface
at all ? I mean with all the hassles I'm hearing about on the forums here,
it would be easier to teach people how to set the interface manually to
*7.1 on the host side. Then of course . . . *7.2 on the beaglebone. I've
been doing this pretty much since day one, give or take a week or two shake
down early on . . .and yeah have had no problems. Definately not the
problems I'm seeing crop up on the forums here all the time . . .

On Tue, Mar 8, 2016 at 4:25 PM, Robert Nelson 
wrote:

> > Ya.  I have a couple of BBGs and didn't read the fine print close enough
> to
> > see that there is no barrel jack.
> > So, I have an Andice Labs Power Cape at the ready and/or build my own
> power
> > supply as power over USB is obviously such a non-starter for real work.
>
> I have that same power cape, just need to assemble it..
>
> >
> > Excellent!
> >
> > So one has to wonder if it would be wise to eliminate
> > /etc/network/interfaces (or at least have everthing commented out with
> > warnings) to help prevent the often occurring confusion when Connman
> > overrides definitions in /etc/network/interfaces.  And, of course,
> > /etc/network/interfaces is supposed to be "legacy".
>
> I think we will just blank it out, then users can add there own tweaks..
>
> I think i figured out how to get the usb0 to start at 192.168.7.2
>
> https://paste.debian.net/413402/
>
> (so much stuff is hard-coded for 192.168.7.2)
>
> > When this is sorted, it would be cool to work towards an "on-boarding"
> > solution (possibly using something like AllJoyn OnBoarding Service) to
> > provision credentials on boards with on board wifi...sorta like what
> JasonK
> > was pining about.
>
> I'd be up for anything unified.. ;)
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
> --
> 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.
>

-- 
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: QNX on beaglebone black

[acheesehead]

I just downloaded and built the latest 'experimental' QNX 6.6 BSP for BBB. 
Got the same errors. Turns out that the permissions of files in 
install/sbin and install/bin needed to change. Once I changed their 
permissions, all goes well. The build script does not mount the SD card or 
the eMMC, so that must be done manually.

On Tuesday, March 1, 2016 at 3:00:18 PM UTC-7, Steven Hartmann wrote:
>
> I hope there is someone here successfully using QNX on the BBB.  I am 
> currently doing a QNX evaluation and am having trouble with the BBB BSP.  I 
> am using the BSP_ti-am335x-beaglebone_br-660_be-660_SVN797070_JBN574.zip 
> BSP.  The package comes with a pre-built image, which boots up fine.  I 
> have been able to do a few test programs with it, but now I need to modify 
> the BSP to change which features are used.  The first step in doing this 
> was to just recompile the BSP to make sure I can recreate the precompiled 
> version.  The build goes fine and creates an image.  I can boot off the 
> image, but it gives a lot of errors:
>
> U-Boot#  fatload mmc 0 8100 ifs-ti-am335x-beaglebone.bin
> reading ifs-ti-am335x-beaglebone.bin
> 5794620 bytes read in 657 ms (8.4 MiB/s)
> U-Boot# go 8100
> ## Starting application at 0x8100 ...
>
> __Board ID__
> header:  ee3355aa
> name:A335BNLT
> 
> BeagleBone Black detected
>
> VFPv3: fpsid=410330c3
> coproc_attach(10): attach fe08a3fc (fe08ad24)
> coproc_attach(11): attach fe08a3fc (fe08ad24)
> Welcome to QNX Neutrino 6.6.0 on the Texas Instruments AM335x BeagleBone 
> (ARMv7 Cortex-A8 core) - Board
> Unable to start "devc-seromap" (2)
> Unable to access "/dev/ser1" (2)
> Unable to access "/dev/ser1" (2)
> Starting MMC/SD driver...
> Unable to start "devb-sdmmc-j5_generic" (2)
> Unable to start "devb-sdmmc-j5_generic" (2)
> starting I2C driver...
> Unable to start "i2c-omap35xx-j5" (2)
> Unable to access "/dev/i2c0" (2)
> starting WDT reset utility...
> Unable to start "dm814x-wdtkick" (2)
> starting Board ID driver...
> Unable to start "am335x-boardid" (2)
> Unable to access "/dev/bdid" (2)
> Setting OS Clock from on-board RTC
> Unable to start "rtc" (2)
> Sat Jan 01 00:00:15 GMT 2000
> Starting USB OTG Host driver...
> Starting SPI driver...
> Unable to start "spi-master" (2)
> Starting network driver...
> starting leds driver...
> Unable to start "am335x-leds" (2)
> Unable to access "/dev/leds" (2)
> Setting environment variables...
> done.
> Starting Screen Graphics...
> done.
> Starting HDMI Audio driver...
> Unable to access /dev/snd/pcmC0D1p
> ksh: No controlling tty (open /dev/tty: No such device or address)
> ksh: warning: won't have full job control
>
>
> All of the software that reports "unable to start" does not have execute 
> permissions.  When I tried to add execute permissions by hand, it said the 
> file did not exist.
>
> My build host is linux mint.
>
> 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] Using Connman for WiFi AP/tether...

[Robert Nelson]

> Ya.  I have a couple of BBGs and didn't read the fine print close enough to
> see that there is no barrel jack.
> So, I have an Andice Labs Power Cape at the ready and/or build my own power
> supply as power over USB is obviously such a non-starter for real work.

I have that same power cape, just need to assemble it..

>
> Excellent!
>
> So one has to wonder if it would be wise to eliminate
> /etc/network/interfaces (or at least have everthing commented out with
> warnings) to help prevent the often occurring confusion when Connman
> overrides definitions in /etc/network/interfaces.  And, of course,
> /etc/network/interfaces is supposed to be "legacy".

I think we will just blank it out, then users can add there own tweaks..

I think i figured out how to get the usb0 to start at 192.168.7.2

https://paste.debian.net/413402/

(so much stuff is hard-coded for 192.168.7.2)

> When this is sorted, it would be cool to work towards an "on-boarding"
> solution (possibly using something like AllJoyn OnBoarding Service) to
> provision credentials on boards with on board wifi...sorta like what JasonK
> was pining about.

I'd be up for anything unified.. ;)

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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] Using Connman for WiFi AP/tether...

[Brian Anderson]

On Tuesday, March 8, 2016 at 2:01:36 PM UTC-8, RobertCNelson wrote:
>
> PS, i'm also switched to 'git' on the build: 
>
>
> https://github.com/rcn-ee/repos/commit/dd480e6dac1317eac1cc15b2a60740e7ba53128e
>  
>
> It's currently building, so i'll retest in a bit.. 
>
> > Did you unplug/replug the USB cable from the desktop?  When first 
> enabling 
> > this with the cable plugged in, it seems to require a re-plug to get 
> DHCP to 
> > issue an IP.  But I suppose your dhclient request from the desktop side 
> > should have triggered this. 
>
> That's actually going to be a problem. On the BeagleBone Green, power 
> comes thru usb0...  (and i've run out of BeagleBone Black's at 
> work...) 
>

Ya.  I have a couple of BBGs and didn't read the fine print close enough to 
see that there is no barrel jack.
So, I have an Andice Labs Power Cape at the ready and/or build my own power 
supply as power over USB is obviously such a non-starter for real work.

 

>
> I've tried, restarting connman.service, that didn't help... We might 
> have to fake a hotplug event? 
>

Sounds like the right thing, but I haven't done that before. I suppose a 
hotplug event on boot iff a usb cable is plugged in?
 

>
> >> (systemd: 215 debian jessie) 
> >> 
> >> dnsmasq/create_ap removed 
> >> 
> >> $(dirname $0)/autoconfigure_usb0.sh disabled... 
> >> 
> >> bone: 
> >> 
> >> usb0  Link encap:Ethernet  HWaddr ec:24:b8:d2:06:a0 
> >>   inet6 addr: fe80::ee24:b8ff:fed2:6a0/64 Scope:Link 
> >>   UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1 
> >>   RX packets:6 errors:0 dropped:0 overruns:0 frame:0 
> >>   TX packets:20 errors:0 dropped:0 overruns:0 carrier:0 
> >>   collisions:0 txqueuelen:1000 
> >>   RX bytes:1968 (1.9 KiB)  TX bytes:6180 (6.0 KiB) 
> > 
> > 
> > Do you see a tether interface (ip addr)?  Attached log has output from 
> ip on 
> > bone.  And of course, if you have rebooted, you need to enable the 
> tether 
> > again unless you have setup things for persistent tethering...some 
> connman 
> > config parameter. 
>
> Nope, no tether, and i've enabled: 
>
> PersistentTetheringMode=true 
>
> err.. 
>
> that seems like it was it!! 
>
> mkdir /etc/connman/ 
> mv /etc/connman.conf /etc/connman/main.conf 
>
> reboot... 
>
> Mar 08 21:57:44 beaglebone connmand[307]: usb0 {RX} 0 packets 0 bytes 
> Mar 08 21:57:44 beaglebone connmand[307]: usb0 {TX} 3 packets 390 bytes 
> Mar 08 21:57:44 beaglebone connmand[307]: usb0 {newlink} index 3 
> address EC:24:B8:D2:06:A0 mtu 1500 
> Mar 08 21:57:44 beaglebone connmand[307]: usb0 {newlink} index 3 
> operstate 6  
> Mar 08 21:57:45 beaglebone connmand[307]: usb0 {RX} 0 packets 0 bytes 
> Mar 08 21:57:45 beaglebone connmand[307]: usb0 {TX} 3 packets 390 bytes 
> Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3 
> address EC:24:B8:D2:06:A0 mtu 1500 
> Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3 
> operstate 6  
> Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3 
> address EC:24:B8:D2:06:A0 mtu 1500 
> Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3 
> operstate 6  
> Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3 
> address EC:24:B8:D2:06:A0 mtu 1500 
> Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3 
> operstate 6  
> Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3 
> address EC:24:B8:D2:06:A0 mtu 1500 
> Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3 
> operstate 6  
> Mar 08 21:57:45 beaglebone kernel: device usb0 entered promiscuous mode 
> Mar 08 21:57:45 beaglebone kernel: tether: port 1(usb0) entered forwarding 
> state 
> Mar 08 21:57:45 beaglebone kernel: tether: port 1(usb0) entered forwarding 
> state 
>
> bone: 
>
> tetherLink encap:Ethernet  HWaddr ec:24:b8:d2:06:a0 
>   inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0 
>   inet6 addr: fe80::38b0:4eff:feb4:9211/64 Scope:Link 
>   UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1 
>   RX packets:684 errors:0 dropped:0 overruns:0 frame:0 
>   TX packets:360 errors:0 dropped:0 overruns:0 carrier:0 
>   collisions:0 txqueuelen:0 
>   RX bytes:66369 (64.8 KiB)  TX bytes:38011 (37.1 KiB) 
>
> usb0  Link encap:Ethernet  HWaddr ec:24:b8:d2:06:a0 
>   inet6 addr: fe80::ee24:b8ff:fed2:6a0/64 Scope:Link 
>   UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1 
>   RX packets:684 errors:0 dropped:0 overruns:0 frame:0 
>   TX packets:380 errors:0 dropped:0 overruns:0 carrier:0 
>   collisions:0 txqueuelen:1000 
>   RX bytes:66369 (64.8 KiB)  TX bytes:60067 (58.6 KiB) 
>
> desktop: 
>
> enxec24b8d206af: flags=4163  mtu 1500 
> inet 192.168.0.2  netmask 255.255.255.0  broadcast 192.168.0.255 
> inet6 fe80::ee24:b8ff:fed2:6af  prefixlen 64  scopeid 0x20 

[beagleboard] A problem about module driver compiling

[Mian Tang]

Hi,

I'm working on ADC driver development. Basically, it's a module driver that 
I can use insmod to install. My platform is BeagleBone black and the kernel 
version is 3.8.13-bone72.

I encountered a strange problem. I added a new function, and in this 
function I added printk for message printing. But after compiling it, it 
cannot be installed correctly. I also called modinfo to check its info 
below:

root@beaglebone:~#insmod ad1299.ko
Error: could not insert module ad1299.ko: Invalid module format

root@beaglebone:~# modinfo ad1299.ko
filename:   /root/ad1299.ko
modinfo: ../libkmod/libkmod-elf.c:207: elf_get_mem: Assertion `offset < 
elf->size' failed.
Aborted
root@beaglebone:~#

Is there anyone who can tell me why is this happened? 

Any suggestions are appreciated.

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] A problem of module driver compiling

[Mian Tang]

Hi,

I'm working on Beaglebone Black 3.8.13-bone72, and developing ADC driver. 
Actually it's a module driver. It worked before and I can use insmod to 
install driver. But today, I added a new function in my driver with printk 
for printing, and then compiled it. The driver cannot be installed any 
more. When I use modinfo to see its info, it diplays below:

root@beaglebone:~# modinfo ad1299.ko
filename:   /root/ad1299.ko
modinfo: ../libkmod/libkmod-elf.c:207: elf_get_mem: Assertion `offset < 
elf->size' failed.
Aborted
root@beaglebone:~#

-- 
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: tilcdc FIFO underflow

[William Hermans]

>
> *starting this program will cause crazy flickering, ...*
>

I'm surprised that code is not causing more of a problem than just
"flickering" - Whatever that means. In fact, I'm surprised that code would
compile at all without a compiler error. As [0] probably is not
what you think it is.

Also, for the record, infinitely allocating an arbitrary amount of dynamic
memory, in a loop, without any kind of a pause is going to eat up an
incredible amount of CPU cycles. As in that code will very likely use as
close to 100% CPU as the system will allow it. Which again, is no wonder
you're "flickering" . . .

You lucky your program does not randomly crash for using malloc() on the
same dynamic memory over, and over, without using free(), or instead using
realloc() . . .

On Tue, Mar 8, 2016 at 10:16 AM, Radek Dostál  wrote:

> Hi Michael,
>
> we had very similar issue, which we encountered when updating to gstreamer
> 1.6. Using git bisect we were able to find a root cause and prepare simple
> test program, which reliably reproduces the issue:
>
> #include 
> #include 
> #include 
>
> int main(int argc, char **argv)
> {
> int size;
> uint8_t *memblock;
>
> if (argc < 2)
> return -1;
>
> size = atoi(argv[1]);
>
> memblock = malloc(size);
>
> while (1)
> {
> memset([0], 0, size);
> }
>
> free(memblock);
>
> return 0;
> }
>
> starting this program will cause crazy flickering, ...
>
> We were able to reproduce the issue with
>
> 1) debian originally provided on beaglebone using memtest utility for
> carlos. Kernel version was:
>
> Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) (gcc version
> 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015
>
> 2) latest version of debian from beaglebone website Kernel version was:
>
> Linux version 4.1.15-ti-rt-r43 (root@a4-imx6q-wandboard-2gb) (gcc version
> 4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT RT Thu Jan 21 20:13:58 UTC 2016
>
> so it seems to be existing for ages.
>
> Did you in the mean time managed to find a solution for your problem?
>
> Thanks,
> Radek
>
> On Monday, February 8, 2016 at 1:18:50 PM UTC+1, Michael Liesenberg wrote:
>>
>> Hi there,
>>
>>
>> i was able to get my 10.1 custom Display to work with the RGB Pins on the
>> beaglebone black.
>>
>> I am using the latest Debian Jessie image from beagleboard.org and the
>> X11 Desktop has the right colors and the right size.
>>
>> So i assume that the Timings from my display are correct.
>>
>>
>> panel {
>>
>> status = "okay";
>>
>> compatible = "ti,tilcdc,panel";
>>
>> pinctrl-names = "default";
>>
>> pinctrl-0 = <_lcd_lcd_pins>;
>>
>> panel-info {
>>
>> ac-bias   = <255>;
>>
>> ac-bias-intrpt= <0>;
>>
>> dma-burst-sz  = <16>;
>>
>> bpp   = <32>;
>>
>> fdd   = <0x80>;
>>
>> tft-alt-mode  = <0>;
>>
>> stn-565-mode  = <0>;
>>
>> mono-8bit-mode= <0>;
>>
>> sync-edge = <0>;
>>
>> sync-ctrl = <1>;
>>
>> raster-order  = <0>;
>>
>> fifo-th   = <0>;
>>
>> };
>>
>> display-timings {
>>
>> native-mode = <>;
>>
>> timing0: 1280x800 {
>>
>> clock-frequency =
>> <7000>;
>>
>> hactive = <1280>;
>>
>> vactive = <800>;
>>
>> hfront-porch = <80>;
>>
>> hback-porch = <60>;
>>
>> hsync-len = <20>;
>>
>> vback-porch = <12>;
>>
>> vfront-porch = <8>;
>>
>> vsync-len = <3>;
>>
>> hsync-active = <0>;
>>
>> vsync-active  = <0>;
>>
>> };
>>
>> };
>>
>> };
>>
>>
>> But when i play a video or when i have many frames on the 

Re: [beagleboard] Re: C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

[William Hermans]

By the way, don't worry about mmap(). It's an C/C++ API call meant interact
directly with a systems memory. e.g. you can poke / prod any memory
location for good, and even bad purposes. Usually using mmap() in this
manner is frowned on, as it can be insecure, or can lead to system
instability if one does not know what they're doing. Essentially, you
bypass the kernel completely when doing this, and is one reason why it can
be so fast.

On Tue, Mar 8, 2016 at 3:09 PM, William Hermans  wrote:

> Well, one shot mode is good for close to 6k reads / second *if* one needs
> / wants to. Well, realistically, because of CPU usage. I'd probably limit
> oneshot mode to around 3-4k samples a second. Once a second is definitely
> no problem.
>
> http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/
>
> The example code is C, but perhaps you can use it to write an interface
> for C#.
>
> On Tue, Mar 8, 2016 at 1:38 PM, 'PatM001' via BeagleBoard <
> beagleboard@googlegroups.com> wrote:
>
>> Wow, didn't mean to start a war!
>>
>> Libpruio looks great but as mentioned, no C# version. I'll have a look at
>> that utility mentioned above for converting to other languages.
>>
>> I don't know anything about mmap, I'll have to google that.
>>
>> As it is the app I'm working on only needs to read the ADCs once per
>> second and the low passes are working so well I just take the average of 10
>> samples in a row (something like 16ms for three ADC 10x each). Even once
>> per second is overkill (the process change is quite slow - like 5-30
>> minutes from one extreme to the other).
>>
>> Anyway, faster sampling was so that I could make a rudimentary
>> oscilloscope for playing around with low pass filter configurations. Just
>> using the default BB-ADC overlay I get some 800+ samples per second (which
>> I'm sure a lot are probably reading the same value multiple times) and it
>> does give me all the info I need for tuning up the input filters.
>>
>>
>> On Thursday, March 3, 2016 at 10:25:52 PM UTC-8, TJF wrote:
>>
>>> Hi John!
>>>
>>> Thanks for that link. Another issue first:
>>>
>>> We're poluting this thread by interesting, but off-topic stuff. I hope
>>> you don't mind that I switch our discussion to the new thread and
>>> answer there
>>> 
>>> .
>>>
>>> BR
>>>
>> --
>> 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.
>>
>
>

-- 
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: Debian img 8.3 lxqt boot indefinitely on some BBB

['PatM001' via BeagleBoard]

Just a blind shot in the dark but what are you powering the boards with? 
LCDs take a fair bit of power and you could just be on the ragged edge with 
some boards able to work with slightly less voltage before the watchdog 
reboots it.

4D recommends a minimum 2A@5VDC so if you're just connecting to your PC USB 
port or using a smaller power supply that could be the problem.

On Monday, March 7, 2016 at 4:09:29 AM UTC-8, mpso...@gmail.com wrote:

> Hello,
> After installing the bone-debian-8.3-;xqt-4gb-armhf-2016-01-24-4gb.img on 
> a SD card, I'm able to boot this image on some BBB.
> But on some other BBB, the boot process start with some text on the 
> display (4DCAPE-70T) and suddently reboot, and this indefinitely...
> What can be the problem please, in particular, what is the cause that the 
> BBB reboot indefinitely?
>
>

-- 
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: C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

[William Hermans]

Well, one shot mode is good for close to 6k reads / second *if* one needs /
wants to. Well, realistically, because of CPU usage. I'd probably limit
oneshot mode to around 3-4k samples a second. Once a second is definitely
no problem.

http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/

The example code is C, but perhaps you can use it to write an interface for
C#.

On Tue, Mar 8, 2016 at 1:38 PM, 'PatM001' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Wow, didn't mean to start a war!
>
> Libpruio looks great but as mentioned, no C# version. I'll have a look at
> that utility mentioned above for converting to other languages.
>
> I don't know anything about mmap, I'll have to google that.
>
> As it is the app I'm working on only needs to read the ADCs once per
> second and the low passes are working so well I just take the average of 10
> samples in a row (something like 16ms for three ADC 10x each). Even once
> per second is overkill (the process change is quite slow - like 5-30
> minutes from one extreme to the other).
>
> Anyway, faster sampling was so that I could make a rudimentary
> oscilloscope for playing around with low pass filter configurations. Just
> using the default BB-ADC overlay I get some 800+ samples per second (which
> I'm sure a lot are probably reading the same value multiple times) and it
> does give me all the info I need for tuning up the input filters.
>
>
> On Thursday, March 3, 2016 at 10:25:52 PM UTC-8, TJF wrote:
>
>> Hi John!
>>
>> Thanks for that link. Another issue first:
>>
>> We're poluting this thread by interesting, but off-topic stuff. I hope
>> you don't mind that I switch our discussion to the new thread and answer
>> there
>> 
>> .
>>
>> BR
>>
> --
> 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.
>

-- 
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] Using Connman for WiFi AP/tether...

[Robert Nelson]

PS, i'm also switched to 'git' on the build:

https://github.com/rcn-ee/repos/commit/dd480e6dac1317eac1cc15b2a60740e7ba53128e

It's currently building, so i'll retest in a bit..

> Did you unplug/replug the USB cable from the desktop?  When first enabling
> this with the cable plugged in, it seems to require a re-plug to get DHCP to
> issue an IP.  But I suppose your dhclient request from the desktop side
> should have triggered this.

That's actually going to be a problem. On the BeagleBone Green, power
comes thru usb0...  (and i've run out of BeagleBone Black's at
work...)

I've tried, restarting connman.service, that didn't help... We might
have to fake a hotplug event?

>> (systemd: 215 debian jessie)
>>
>> dnsmasq/create_ap removed
>>
>> $(dirname $0)/autoconfigure_usb0.sh disabled...
>>
>> bone:
>>
>> usb0  Link encap:Ethernet  HWaddr ec:24:b8:d2:06:a0
>>   inet6 addr: fe80::ee24:b8ff:fed2:6a0/64 Scope:Link
>>   UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1
>>   RX packets:6 errors:0 dropped:0 overruns:0 frame:0
>>   TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
>>   collisions:0 txqueuelen:1000
>>   RX bytes:1968 (1.9 KiB)  TX bytes:6180 (6.0 KiB)
>
>
> Do you see a tether interface (ip addr)?  Attached log has output from ip on
> bone.  And of course, if you have rebooted, you need to enable the tether
> again unless you have setup things for persistent tethering...some connman
> config parameter.

Nope, no tether, and i've enabled:

PersistentTetheringMode=true

err..

that seems like it was it!!

mkdir /etc/connman/
mv /etc/connman.conf /etc/connman/main.conf

reboot...

Mar 08 21:57:44 beaglebone connmand[307]: usb0 {RX} 0 packets 0 bytes
Mar 08 21:57:44 beaglebone connmand[307]: usb0 {TX} 3 packets 390 bytes
Mar 08 21:57:44 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:44 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6 
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {RX} 0 packets 0 bytes
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {TX} 3 packets 390 bytes
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6 
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6 
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6 
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 21:57:45 beaglebone connmand[307]: usb0 {newlink} index 3
operstate 6 
Mar 08 21:57:45 beaglebone kernel: device usb0 entered promiscuous mode
Mar 08 21:57:45 beaglebone kernel: tether: port 1(usb0) entered forwarding state
Mar 08 21:57:45 beaglebone kernel: tether: port 1(usb0) entered forwarding state

bone:

tetherLink encap:Ethernet  HWaddr ec:24:b8:d2:06:a0
  inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
  inet6 addr: fe80::38b0:4eff:feb4:9211/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1
  RX packets:684 errors:0 dropped:0 overruns:0 frame:0
  TX packets:360 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:66369 (64.8 KiB)  TX bytes:38011 (37.1 KiB)

usb0  Link encap:Ethernet  HWaddr ec:24:b8:d2:06:a0
  inet6 addr: fe80::ee24:b8ff:fed2:6a0/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1
  RX packets:684 errors:0 dropped:0 overruns:0 frame:0
  TX packets:380 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:66369 (64.8 KiB)  TX bytes:60067 (58.6 KiB)

desktop:

enxec24b8d206af: flags=4163  mtu 1500
inet 192.168.0.2  netmask 255.255.255.0  broadcast 192.168.0.255
inet6 fe80::ee24:b8ff:fed2:6af  prefixlen 64  scopeid 0x20
ether ec:24:b8:d2:06:af  txqueuelen 1000  (Ethernet)
RX packets 180  bytes 24507 (23.9 KiB)
RX errors 3  dropped 0  overruns 0  frame 3
TX packets 183  bytes 24716 (24.1 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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] Using Connman for WiFi AP/tether...

[Brian Anderson]

>
>> sudo dhclient enxec24b8d206af not getting an ip... 
>>
>
> Didn't have to do that.  Well, maybe that would have negated the need to 
> re-plug the cable.  I have an IP on the host side:
>
>
OK, I rebooted the Bone and enabled the tether from the Bone.  IP didn't 
show up on laptop.  dhclient on the laptop hung (well, maybe it would 
timeout but I was impatient).  Re-plugging the cable got me a shiny new IP 
on the laptop (eth1).  Laptop is running Linux Mint and Network Manager.

ba 

-- 
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] Using Connman for WiFi AP/tether...

[Brian Anderson]

 

>
>
> Humm, not getting an ip over usb0 yet, (connman with 9e96310) 
>

Did you unplug/replug the USB cable from the desktop?  When first enabling 
this with the cable plugged in, it seems to require a re-plug to get DHCP 
to issue an IP.  But I suppose your dhclient request from the desktop side 
should have triggered this.
 

> (systemd: 215 debian jessie) 
>
> dnsmasq/create_ap removed 
>
> $(dirname $0)/autoconfigure_usb0.sh disabled... 
>
> bone: 
>
> usb0  Link encap:Ethernet  HWaddr ec:24:b8:d2:06:a0 
>   inet6 addr: fe80::ee24:b8ff:fed2:6a0/64 Scope:Link 
>   UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1 
>   RX packets:6 errors:0 dropped:0 overruns:0 frame:0 
>   TX packets:20 errors:0 dropped:0 overruns:0 carrier:0 
>   collisions:0 txqueuelen:1000 
>   RX bytes:1968 (1.9 KiB)  TX bytes:6180 (6.0 KiB) 
>

Do you see a tether interface (ip addr)?  Attached log has output from ip 
on bone.  And of course, if you have rebooted, you need to enable the 
tether again unless you have setup things for persistent tethering...some 
connman config parameter.
 

>
> root@beaglebone:~# journalctl | grep conn | grep usb0 
> Mar 08 20:22:54 beaglebone connmand[322]: usb0 {create} index 3 type 1 
>  
> Mar 08 20:22:54 beaglebone connmand[322]: usb0 {update} flags 4098  
> Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3 
> address EC:24:B8:D2:06:A0 mtu 1500 
> Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3 
> operstate 2  
> Mar 08 20:22:54 beaglebone connmand[322]: Adding interface usb0 [ gadget ] 
> Mar 08 20:22:54 beaglebone connmand[322]: usb0 {update} flags 102467 
>  
> Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3 
> address EC:24:B8:D2:06:A0 mtu 1500 
> Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3 
> operstate 6  
> Mar 08 20:22:54 beaglebone connmand[322]: usb0 {add} route fe80:: gw 
> :: scope 0  
>
> Hmmm.  That's it?  I have _lots_ more output (see attached file).

Note also, that I have a wired connection on eth0 as well as a powered hub 
with a TP-Link and BT dongle attached.  Not that the TP-Link and BT dongle 
matter.  But I am wondering about eth0.
 

>
> root@beaglebone:~# cat /var/lib/connman/settings 
> [global] 
> OfflineMode=false 
>
> [Wired] 
> Enable=true 
> Tethering=false 
>
> [Gadget] 
> Enable=true 
> Tethering=true 
>
>
Pretty much same as mine.

FWIW, I also have /etc/connman/main.conf:

# Place this file in /etc/connman/main.conf

[General]

# Don't manage mesh point interfaces of the form "mpx"...
NetworkInterfaceBlacklist=mp

# Ordered list of preferred technologies to connect to.
PreferredTechnologies=ethernet,wifi
 

> Desktop: 
>
>
> enxec24b8d206af: flags=4163  mtu 1500 
> ether ec:24:b8:d2:06:af  txqueuelen 1000  (Ethernet) 
> RX packets 20  bytes 5020 (4.9 KiB) 
> RX errors 0  dropped 0  overruns 0  frame 0 
> TX packets 7  bytes 2702 (2.6 KiB) 
> TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 
>
> sudo dhclient enxec24b8d206af not getting an ip... 
>

Didn't have to do that.  Well, maybe that would have negated the need to 
re-plug the cable.  I have an IP on the host side:

brian_anderson@htc-thinkpad1 ~ $ ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: eth0:  mtu 1500 qdisc pfifo_fast 
state DOWN group default qlen 1000
link/ether 54:ee:75:31:34:94 brd ff:ff:ff:ff:ff:ff
inet6 fe80::56ee:75ff:fe31:3494/64 scope link 
   valid_lft forever preferred_lft forever
4: wlan0:  mtu 1500 qdisc mq state DOWN 
group default qlen 1000
link/ether e8:b1:fc:46:1d:ba brd ff:ff:ff:ff:ff:ff
inet6 fe80::eab1:fcff:fe46:1dba/64 scope link 
   valid_lft forever preferred_lft forever
39: eth1:  mtu 1500 qdisc pfifo_fast state 
UNKNOWN group default qlen 1000
link/ether d0:5f:b8:fd:1e:d6 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.2/24 brd 192.168.0.255 scope global eth1
   valid_lft forever preferred_lft forever
inet6 fe80::d25f:b8ff:fefd:1ed6/64 scope link 
   valid_lft forever preferred_lft forever
 

I attached a log.txt file with a bunch of details.

ba

-- 
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.
Bone
===

debian@htc-bbb4:~/Data/projects/connman$ cat 

[beagleboard] Help with Brushless Esc.

[Nicklas Johansson]

Hello!

so i have just got my hands on a BBB and i want to try out my quad-copter 
motors, and it seems like i just cant get it to spin!

the following code is what i use to run, and with no luck i am no 
completely stuck to why it wont spin.
[code]
var b = require('bonescript');
var motor = "P8_13";
var state = 0;

b.pinMode("USR3", 'out');
b.pinMode("USR2", 'out');
b.pinMode("USR1", 'out');
b.pinMode("USR0", 'out');
b.pinMode(motor, 'out');

b.digitalWrite("USR3", 0);
b.digitalWrite("USR2", 0);
b.digitalWrite("USR1", 0);
b.digitalWrite("USR0", 0);

startMotorSpeed = function()
{ 
  b.analogWrite(motor, 0.6, 488 );
};
mainTimer = setInterval(startMotorSpeed, 2 );

stopTimer = function() {
clearInterval(mainTimer);
  b.digitalWrite("USR3", 1);
b.digitalWrite("USR2", 1);
b.digitalWrite("USR1", 1);
b.digitalWrite("USR0", 1);
console.log( "done spining!" );
};

setTimeout(stopTimer, 2000);
[/code]

So anyhelp here would be awesome!
the esc im using is a RHD brushless esc simonk 12a.

-- 
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: C#: Checking when ADC is ready - or- speeding up sample rate? (kernel 4.1 debian)

['PatM001' via BeagleBoard]

Wow, didn't mean to start a war!

Libpruio looks great but as mentioned, no C# version. I'll have a look at 
that utility mentioned above for converting to other languages.

I don't know anything about mmap, I'll have to google that.

As it is the app I'm working on only needs to read the ADCs once per second 
and the low passes are working so well I just take the average of 10 
samples in a row (something like 16ms for three ADC 10x each). Even once 
per second is overkill (the process change is quite slow - like 5-30 
minutes from one extreme to the other).

Anyway, faster sampling was so that I could make a rudimentary oscilloscope 
for playing around with low pass filter configurations. Just using the 
default BB-ADC overlay I get some 800+ samples per second (which I'm sure a 
lot are probably reading the same value multiple times) and it does give me 
all the info I need for tuning up the input filters.

On Thursday, March 3, 2016 at 10:25:52 PM UTC-8, TJF wrote:

> Hi John!
>
> Thanks for that link. Another issue first:
>
> We're poluting this thread by interesting, but off-topic stuff. I hope you 
> don't mind that I switch our discussion to the new thread and answer there 
> 
> .
>
> BR
>

-- 
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] Using Connman for WiFi AP/tether...

[Robert Nelson]

On Tue, Mar 8, 2016 at 1:26 PM, Robert Nelson  wrote:
> Hi Job Brian!
>
> On Tue, Mar 8, 2016 at 12:59 PM, Brian Anderson  wrote:
>> I wanted to document some steps that I took to get Connman working for
>> setting up a WiFI AP.  Connman terminology for this is "tethering".  All of
>> this was done on a recent (Feb2016) Debian Jessie distro with the 4.1.x TI
>> kernel.
>>
>> 1.  There is an issue with the systemd connman.service unit file.  Connman
>> needs to be able to dynamically load kernel modules in order for tethering
>> to work.  The systemd unit file lacks the CAP_SYS_MODULE capability in the
>> CapabilityBoundingSet property.  The proper setting should be:
>>
>> CapabilityBoundingSet=CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE
>> CAP_NET_RAW CAP_SYS_TIME CAP_SYS_MODULE
>>
>> I first attempted to add a systemd drop-in to merge this into the distros
>> connman.service, but alas, also ran into systemd issue 1221
>> (https://github.com/systemd/systemd/issues/1221).  Apparently this systemd
>> issue was fixed after release 226.  Currently, RCN Debian images run systemd
>> 215.  So, you will have to directly modify
>> /lib/systemd/system/connman.service to correct this capability deficiency.
>>
>> I have posted a bug report to the Connman mail list, and a patch has been
>> committed to Connman mainline to fix this missing capability (commit
>> 9e96310).
>
> I'll add that commit to our connman patchset..
>
>>
>> 2.  Stop and disable dnsmasq service.  dnsmasq is being used for DHCP on the
>> usb gadget.  dnsmasq apparently conflicts with Connman's internal DHCP.
>>
>> 3.  I renamed /etc/dnsmasq.d/usb0-dhcp to /etc/dnsmasq.d/usb0-dhcp~ to
>> disable boot time setup being performed by
>> /opt/scripts/boot/autoconfigure_usb0.sh
>>
>> 4.  I renamed /etc/network/interfaces to /etc/network/interfaces.org to
>> avoid any conflicts and confusion between Connman and legacy ifup/ifdown and
>> test that Connman can truely deal with all network setup without having to
>> resort to any legacy tools.
>>
>> After these fixes, I can now successfully setup a WiFI AP using
>> `connmanctl`.  Traffic on the AP will have internet traffic routed to the
>> ethernet interface.  Client STAs connected to the AP will have DHCP
>> allocated IP addresses (typically on the 192.168.0.1/24 network).
>>
>> connmanctl enable wifi
>> connmanctl tether wifi on  
>>
>> Note that I can also setup a usb gadget tether using similar `connmanctl`
>> commands:
>>
>> connmanctl enable gadget
>> connmanctl tether gadget on
>>
>> A client connected to the usb gadget will also have a DHCP allocated IP
>> address (again typically on the 192.168.0.1/24 network).  You may need to
>> re-plug the USB cable in order to have an IP address allocated after you
>> turn on the tether.
>>
>> So, all of this avoids the `create_ap` hackery and the necessity to run
>> dnsmasq for the usb ethernet gadget.  Unfortunately, I see no way to use
>> this method to allocate a static IP address on the usb gadget.  Reading the
>> Connman mail list, I doubt defining a static IP for the usb gadget would
>> ever be supported as in general there is no way to guarantee that wouldn't
>> be a conflict with the static IP...or at least that's the way I read the
>> discussion.  But, the BBB _does_ show up via mDNS on the client (in this
>> case, my Linux laptop).  Both the BBB web site and the "workstation" show up
>> via Avahi Discovery browser.  And I can ssh to the BBB via .local.
>> So, maybe we don't necessarily need a static IP to supporting "connecting"
>> to the BBB from usb clients?
>
> Sweet i like it!
>
> As long as "hostname.local" works i don't mind losing 192.168.7.2


Humm, not getting an ip over usb0 yet, (connman with 9e96310)
(systemd: 215 debian jessie)

dnsmasq/create_ap removed

$(dirname $0)/autoconfigure_usb0.sh disabled...

bone:

usb0  Link encap:Ethernet  HWaddr ec:24:b8:d2:06:a0
  inet6 addr: fe80::ee24:b8ff:fed2:6a0/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST DYNAMIC  MTU:1500  Metric:1
  RX packets:6 errors:0 dropped:0 overruns:0 frame:0
  TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:1968 (1.9 KiB)  TX bytes:6180 (6.0 KiB)

root@beaglebone:~# journalctl | grep conn | grep usb0
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {create} index 3 type 1 
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {update} flags 4098 
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3
operstate 2 
Mar 08 20:22:54 beaglebone connmand[322]: Adding interface usb0 [ gadget ]
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {update} flags 102467

Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} index 3
address EC:24:B8:D2:06:A0 mtu 1500
Mar 08 20:22:54 beaglebone connmand[322]: usb0 {newlink} 

[beagleboard] i2c driver for bmp280 pressure/temperature sensor

[AV8TOR]

I have an Element 14 BB Black.

I have the sensor connected up for i2c (as opposed to spi). 
It works OK when I flash the eMMC 
with bone-debian-8.3-lxqt-4gb-armhf-2016-01-24-4gb.img. Meaning that I can 
find the temperature and pressure files provided in the driver.
The problem there is with that particular image... SSH over USB does not 
work. As a workaround I have to use serial which isn't as nice as a SSH 
shell.

So I flash the eMMC with bone-debian-8.2-osd3358-2015-12-07-2gb.img. SSH 
over USB works great, but I can't seem to load any drivers for the bmp280. 
 in fact, when I CD to /sys/bus/i2c/drivers I do not see the bmp280 listed 
there. And the cat command as listed below fails with "file not found". 

For reference the commands I'm using are: 
#add the driver

echo bmp280 0x77 > /sys/class/i2c-adapter/i2c-2/new_device


#Verify that the driver loaded.

dmesg | grep bmp

[  552.045158] i2c i2c-2: new_device: Instantiated device bmp280 at 0x77


Get the pressure reading:

cat /sys/bus/i2c/drivers/bmp280/2-0077/iio\:device0/in_pressure_input

on the debian 8.2 flashed image as referenced above.

root@beaglebone:/sys/bus/i2c# i2cdetect -r 2   
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will probe file /dev/i2c-2 using read byte commands.
I will probe address range 0x03-0x77.
Continue? [Y/n] Y
 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- 77



Can someone please help me to understand what it is I'm doing wrong? I just 
want to be able to SSH into the board over USB as well as load up the 
driver and get readings from the sensor. 


Thanks in advance,

Mike


-- 
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] Using Connman for WiFi AP/tether...

[Robert Nelson]

Hi Job Brian!

On Tue, Mar 8, 2016 at 12:59 PM, Brian Anderson  wrote:
> I wanted to document some steps that I took to get Connman working for
> setting up a WiFI AP.  Connman terminology for this is "tethering".  All of
> this was done on a recent (Feb2016) Debian Jessie distro with the 4.1.x TI
> kernel.
>
> 1.  There is an issue with the systemd connman.service unit file.  Connman
> needs to be able to dynamically load kernel modules in order for tethering
> to work.  The systemd unit file lacks the CAP_SYS_MODULE capability in the
> CapabilityBoundingSet property.  The proper setting should be:
>
> CapabilityBoundingSet=CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE
> CAP_NET_RAW CAP_SYS_TIME CAP_SYS_MODULE
>
> I first attempted to add a systemd drop-in to merge this into the distros
> connman.service, but alas, also ran into systemd issue 1221
> (https://github.com/systemd/systemd/issues/1221).  Apparently this systemd
> issue was fixed after release 226.  Currently, RCN Debian images run systemd
> 215.  So, you will have to directly modify
> /lib/systemd/system/connman.service to correct this capability deficiency.
>
> I have posted a bug report to the Connman mail list, and a patch has been
> committed to Connman mainline to fix this missing capability (commit
> 9e96310).

I'll add that commit to our connman patchset..

>
> 2.  Stop and disable dnsmasq service.  dnsmasq is being used for DHCP on the
> usb gadget.  dnsmasq apparently conflicts with Connman's internal DHCP.
>
> 3.  I renamed /etc/dnsmasq.d/usb0-dhcp to /etc/dnsmasq.d/usb0-dhcp~ to
> disable boot time setup being performed by
> /opt/scripts/boot/autoconfigure_usb0.sh
>
> 4.  I renamed /etc/network/interfaces to /etc/network/interfaces.org to
> avoid any conflicts and confusion between Connman and legacy ifup/ifdown and
> test that Connman can truely deal with all network setup without having to
> resort to any legacy tools.
>
> After these fixes, I can now successfully setup a WiFI AP using
> `connmanctl`.  Traffic on the AP will have internet traffic routed to the
> ethernet interface.  Client STAs connected to the AP will have DHCP
> allocated IP addresses (typically on the 192.168.0.1/24 network).
>
> connmanctl enable wifi
> connmanctl tether wifi on  
>
> Note that I can also setup a usb gadget tether using similar `connmanctl`
> commands:
>
> connmanctl enable gadget
> connmanctl tether gadget on
>
> A client connected to the usb gadget will also have a DHCP allocated IP
> address (again typically on the 192.168.0.1/24 network).  You may need to
> re-plug the USB cable in order to have an IP address allocated after you
> turn on the tether.
>
> So, all of this avoids the `create_ap` hackery and the necessity to run
> dnsmasq for the usb ethernet gadget.  Unfortunately, I see no way to use
> this method to allocate a static IP address on the usb gadget.  Reading the
> Connman mail list, I doubt defining a static IP for the usb gadget would
> ever be supported as in general there is no way to guarantee that wouldn't
> be a conflict with the static IP...or at least that's the way I read the
> discussion.  But, the BBB _does_ show up via mDNS on the client (in this
> case, my Linux laptop).  Both the BBB web site and the "workstation" show up
> via Avahi Discovery browser.  And I can ssh to the BBB via .local.
> So, maybe we don't necessarily need a static IP to supporting "connecting"
> to the BBB from usb clients?

Sweet i like it!

As long as "hostname.local" works i don't mind losing 192.168.7.2

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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] cmst (connman gui) fails to start on jessie (8.3)

[Jon Peterson]

this is a fairly recent install of Jessie, apt-get update/upgrade, and a 
few packages like tightvncserver, gksu, ntp, autocutsel, tightvncserver, 
leafpad, ... and I didn't ask explicitly for connman or cmst to be 
installed.

running from xterm "cmst" puts up a dialog box about installing a new icon 
definition file and then select "save".
there are two message on xterm:
Qt: XKEYBOARD extension not present on the X server.
The X11 connection broke (error 4). Did the X11 server die?
there is no system tray icon.

When I read the package details:
QT GUI for Connman with system tray icon

Graphical user interface to control the connman daemon. The connman daemon 
must be started as you normally would, this program just interfaces with 
that daemon. You can see what technologies and services connman has found, 
and for wifi services an agent is registered to assist in obtaining the 
information from you necessary to logon to the wifi service. 


I don't get a GUI window presented.


The Start/Internet/Connman UI Setup puts up the same dialog box as above, 
and then, after "save" does nothing.


I guess the question I have as a new user, is do I even need connman and 
cmst or can I remove them both and mange the network setup manually? Am I 
missing something, because trying to learn connman looks like a lot of 
learning curve for not much gain...


ps I am finding Jessie a lot harder to get going on than Wheezy. there are 
so many changes it's almost like starting over again.


-- 
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] Using Connman for WiFi AP/tether...

[Brian Anderson]

I wanted to document some steps that I took to get Connman working for 
setting up a WiFI AP.  Connman terminology for this is "tethering".  All of 
this was done on a recent (Feb2016) Debian Jessie distro with the 4.1.x TI 
kernel.

1.  There is an issue with the systemd connman.service unit file.  Connman 
needs to be able to dynamically load kernel modules in order for tethering 
to work.  The systemd unit file lacks the CAP_SYS_MODULE capability in the 
CapabilityBoundingSet property.  The proper setting should be:

CapabilityBoundingSet=CAP_KILL CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
CAP_NET_RAW CAP_SYS_TIME CAP_SYS_MODULE

I first attempted to add a systemd drop-in to merge this into the distros 
connman.service, but alas, also ran into systemd issue 1221 
(https://github.com/systemd/systemd/issues/1221).  Apparently this systemd 
issue was fixed after release 226.  Currently, RCN Debian images run 
systemd 215.  So, you will have to directly modify 
/lib/systemd/system/connman.service to correct this capability deficiency.

I have posted a bug report to the Connman mail list, and a patch has been 
committed to Connman mainline to fix this missing capability (commit 
9e96310).

2.  Stop and disable dnsmasq service.  dnsmasq is being used for DHCP on 
the usb gadget.  dnsmasq apparently conflicts with Connman's internal DHCP.

3.  I renamed /etc/dnsmasq.d/usb0-dhcp to /etc/dnsmasq.d/usb0-dhcp~ to 
disable boot time setup being performed by 
/opt/scripts/boot/autoconfigure_usb0.sh

4.  I renamed /etc/network/interfaces to /etc/network/interfaces.org to 
avoid any conflicts and confusion between Connman and legacy ifup/ifdown 
and test that Connman can truely deal with all network setup without having 
to resort to any legacy tools.

After these fixes, I can now successfully setup a WiFI AP using 
`connmanctl`.  Traffic on the AP will have internet traffic routed to the 
ethernet interface.  Client STAs connected to the AP will have DHCP 
allocated IP addresses (typically on the 192.168.0.1/24 network).

connmanctl enable wifi
connmanctl tether wifi on  

Note that I can also setup a usb gadget tether using similar `connmanctl` 
commands:

connmanctl enable gadget
connmanctl tether gadget on

A client connected to the usb gadget will also have a DHCP allocated IP 
address (again typically on the 192.168.0.1/24 network).  You may need to 
re-plug the USB cable in order to have an IP address allocated after you 
turn on the tether.

So, all of this avoids the `create_ap` hackery and the necessity to run 
dnsmasq for the usb ethernet gadget.  Unfortunately, I see no way to use 
this method to allocate a static IP address on the usb gadget.  Reading the 
Connman mail list, I doubt defining a static IP for the usb gadget would 
ever be supported as in general there is no way to guarantee that wouldn't 
be a conflict with the static IP...or at least that's the way I read the 
discussion.  But, the BBB _does_ show up via mDNS on the client (in this 
case, my Linux laptop).  Both the BBB web site and the "workstation" show 
up via Avahi Discovery browser.  And I can ssh to the BBB via 
.local.  So, maybe we don't necessarily need a static IP to 
supporting "connecting" to the BBB from usb clients?

This all seems to be encouraging as a possible path to addressing the 
"requirements" that JasonK enumerated in this thread: 
https://groups.google.com/forum/#!category-topic/beagleboard/v4_A2x1I5gs

ba

-- 
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: tilcdc FIFO underflow

[Radek Dostál]

Hi Michael,

we had very similar issue, which we encountered when updating to gstreamer 
1.6. Using git bisect we were able to find a root cause and prepare simple 
test program, which reliably reproduces the issue:

#include 
#include 
#include 

int main(int argc, char **argv)
{
int size;
uint8_t *memblock;

if (argc < 2)
return -1;

size = atoi(argv[1]);

memblock = malloc(size);

while (1)
{
memset([0], 0, size);
}

free(memblock);

return 0;
}

starting this program will cause crazy flickering, ...

We were able to reproduce the issue with

1) debian originally provided on beaglebone using memtest utility for 
carlos. Kernel version was: 

Linux version 3.8.13-bone70 (root@a5-imx6q-wandboard-2gb) (gcc version 
4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri Jan 23 02:15:42 UTC 2015 

2) latest version of debian from beaglebone website Kernel version was: 

Linux version 4.1.15-ti-rt-r43 (root@a4-imx6q-wandboard-2gb) (gcc version 
4.9.2 (Debian 4.9.2-10) ) #1 SMP PREEMPT RT Thu Jan 21 20:13:58 UTC 2016 

so it seems to be existing for ages.

Did you in the mean time managed to find a solution for your problem?

Thanks,
Radek

On Monday, February 8, 2016 at 1:18:50 PM UTC+1, Michael Liesenberg wrote:
>
> Hi there,
>
>
> i was able to get my 10.1 custom Display to work with the RGB Pins on the 
> beaglebone black.
>
> I am using the latest Debian Jessie image from beagleboard.org and the 
> X11 Desktop has the right colors and the right size.
>
> So i assume that the Timings from my display are correct.
>
>
> panel {
>
> status = "okay";
>
> compatible = "ti,tilcdc,panel";
>
> pinctrl-names = "default";
>
> pinctrl-0 = <_lcd_lcd_pins>;
>
> panel-info {
>
> ac-bias   = <255>;
>
> ac-bias-intrpt= <0>;
>
> dma-burst-sz  = <16>;
>
> bpp   = <32>;
>
> fdd   = <0x80>;
>
> tft-alt-mode  = <0>;
>
> stn-565-mode  = <0>;
>
> mono-8bit-mode= <0>;
>
> sync-edge = <0>;
>
> sync-ctrl = <1>;
>
> raster-order  = <0>;
>
> fifo-th   = <0>;
>
> };
>
> display-timings {
>
> native-mode = <>;
>
> timing0: 1280x800 {
>
> clock-frequency = 
> <7000>;
>
> hactive = <1280>;
>
> vactive = <800>;
>
> hfront-porch = <80>;
>
> hback-porch = <60>;
>
> hsync-len = <20>;
>
> vback-porch = <12>;
>
> vfront-porch = <8>;
>
> vsync-len = <3>;
>
> hsync-active = <0>;
>
> vsync-active  = <0>;
>
> };
>
> };
>
> };
>
>
> But when i play a video or when i have many frames on the display i get 
> some screen flickers.
>
>
> On the log via UART i see the following:
>
>
> 1- When booting up: of_graph_get_next_endpoint(): no port node found in 
> /ocp/lcdc@4830e000
>
> 2- When video or many frames are displayed:
>
>  tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x0020): FIFO underflow
>
>  tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x0004): Sync lost
>
>
> Any idea?
>
>
> Is the DDR flash rate to slow? Or the DMA buffer not big enougth?
>
>
>

-- 
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: LCD touch screen is not saved after reboot

[Bremenpl]

  
  
Do you know where is this file saved?

W dniu 2016-03-08 o 16:28, Radovan
  Chovan pisze:


  Hi,
I have this values from "Calibrate Touchscreen" application on
Debian found in "Start menu". When I finished this calibration
test, then command window appeared and there were these values.

  
  -- 
  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/nQPsVPl-S5o/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.


-- 
Bremenpl
  




-- 
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: LCD touch screen is not saved after reboot

[Radovan Chovan]

Hi,
I have this values from "Calibrate Touchscreen" application on Debian found 
in "Start menu". When I finished this calibration test, then command window 
appeared and there were these values.

-- 
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] 4.1 repo

[Robert Nelson]

On Tue, Mar 8, 2016 at 12:21 AM,   wrote:
> Everyone,
>
> I'm a noob and trying to get the BBB Audio Cape Rev B working.  Is there an
> update at all coming from BB on this?

https://github.com/beagleboard/bb.org-overlays/commit/419c160cb30f40230edea0460a9776eed1f7779f

I have a kernel side *dts change i need todo to..

Regards,

-- 
Robert Nelson
https://rcn-ee.com/

-- 
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] Unable to connect to wireless network usin Netgear n1500 on beaglebone Rev c

[romajain07]

After completing the steps of removing the hashes from reqd places i changed 
the security(wpa-psk) and the ssid and rebooted it but still the netgear usb 
dongle doesnt show up any wireless connection. It so happens that the usb hub 
to which the dongle is connected (usb hub connectd to mouse and keyboard also) 
switches off in between many a times.Is it a software or hardware related 
isssue?

-- 
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] 4.1 repo

[burnsj]

Everyone,

I'm a noob and trying to get the BBB Audio Cape Rev B working.  Is there an 
update at all coming from BB on this?

On Tuesday, January 12, 2016 at 7:53:27 PM UTC-6, RobertCNelson wrote:
>
>
>
> On Tue, Jan 12, 2016 at 5:57 PM, Bruce Glazier  > wrote:
>
>> Thanks Robert, glad it could get resolved.
>>
>
> It's still a hack,  we need to find a way to call edma subsystem and 
> re-enable those channels for the overlay situation..
>
> Right now it'll burn a little more power.. So users looking to save every 
> little mA, will need to disable the un-used options in that included *.dtsi
>
> Regards,
>
>
> -- 
> Robert Nelson
> https://rcn-ee.com/
>

-- 
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: Touchscreen 4DCape-70T driver update on Debian (3.8.13)

[burnsj]

Radovan,

I used the 4D Cape 70T and 4DCape 70T II's and they had conflicts with the 
BBB Audio Cape Rev B.  I actually called 4DS in Australia asking them to 
remove the conflict.  The interrupt conflict I have is the GPIO used by the 
up down left right button, which I didn't need.  If I could remove that 
myself, I would!  Very frustrating.

On Tuesday, March 1, 2016 at 8:29:03 AM UTC-6, Radovan Chovan wrote:
>
> Hi,
> how can I update  4DCape-70T touchscreen driver for BeagleBone Black  on 
> Debian (3.8.13)?
> I tried update /lib/firmware/BB-BONE-LCD7-01-00A3.dtbo (from 15th May 
> 2014) via "dtc" with this source (
> https://github.com/beagleboard/linux/blob/3.8/firmware/capes/BB-BONE-LCD7-01-00A3.dts
>  
> ) but I think nothing was changed.
> Is BBB using this touchscreen driver at all? I think touchscreen is still 
> using some native "ti_tsc" driver.
>
> (for info: topic with my main problem: 
> http://forum.4dsystems.com.au/forum/forum-aa/4d-systems-hardware/beaglebone-display-modules-and-capes/50818-bbb-4dcape-70t-|-finger-touch-left-mouse-click-stopped-working
> )
>

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