[beagleboard] UART4 read in pthread not working

[Regina Choi]

Hi, 

I have programmed (in C) UART4 read in thread with blocking read, the code 
as below: I confirmed that the UART receive port does have data through 
oscilloscope, but somehow there is no data in read( ), the return count 
always zero ?  

The strange thing is if minicom is open on the Uart4, then the read( ) in 
receive thread started to run as normal.  However, the regular file write 
become weird.  The string won't be able to be written into file ?! 

Btw, my BBB version is 3.8.13-bone47


#include
#include// required for fopen, exit()
#include
#include
//#include
#include
#include
#include "readerComm.h"


pthread_t uartRxT , uartTxT;
int file, file2;

int main (int argc, char* argv[])
{
int count;
 
pthread_attr_t attr;
void *status;
FILE *fdata;


if(argc != 2)
{

printf("Invalid number of arguments, exiting!");
return -2;

}

if((file = open("/dev/ttyO4", O_RDWR | O_NOCTTY | O_NDELAY ))< 0)
{
perror("UART: Failed to open the file");
return -1;
}

fcntl(file, F_SETFL, 0); // blocking read
struct termios options; //oriopt
tcgetattr(file, &options);
options.c_cflag = B9600 | CS8 | CREAD | CLOCAL;
options.c_iflag = IGNPAR | ICRNL;

options.c_iflag &= ~IGNBRK;
options.c_iflag &= ~(IXON | IXOFF | IXANY); // shut off xon/xoff ctrl

options.c_cc[VMIN]  = 2;// Non Canonical input mode (as we didnt 
set ICANON for c_lflag)
options.c_cc[VTIME] = 10;// 1 sec timeout


tcflush(file, TCIFLUSH);

tcsetattr(file, TCSANOW, &options);


unsigned char cmd[] = {0x11, 0x00, 0x32};//"Tx From Beaglebone ";

if ((count = write(file, (char*)cmd, 3))<0){
  perror("Failed to write to the output\n");
  return -1;
 }else{
 printf("Byte sent: %d \n", count);
 }

fdata = fopen("capture.dat", "w");
if (fdata == NULL) {
printf("I couldn't open capture.dat for writing.\n");
exit(0);
}

// save in file ( cannot print to file ??)
fprintf(fdata, "%s", "test");
perror("UART: Test comment");


pthread_attr_init(&attr);
pthread_attr_setdetachstate(&
attr, PTHREAD_CREATE_JOINABLE);

// Create UArt Tx thread
if(pthread_create(&uartTxT, &attr, &uartTxWait, NULL)){
perror("GPIO: Failed to create the tx thread");

return -1;
}

// Create Uart Rx thread
if(pthread_create(&uartRxT, &attr, &uartRxWait, NULL)){
perror("GPIO: Failed to create the rx thread");

return -1;
}

pthread_attr_destroy(&attr);
pthread_join(uartRxT,&status);
pthread_join(uartTxT,&status);

close(file);// close first file descriptor

// capture.dat file close
fclose(fdata);

return 0;

}

// UART RX thread
void* uartRxWait(void *param){

unsigned char receive[100];
int count, n;
fd_set input;
struct timeval timeout;

//initialize input set
FD_ZERO(&input);
FD_SET(file, &input);

timeout.tv_sec=0;
timeout.tv_usec=0;

while(1){
   
if ((count = read(file, (void *)receive, 100))<0)
{
perror("Failed to read from input \n");
printf("count = %d\n", count);
}else{

if(receive[2]==0x32){
printf("Header received \n"); 
}
printf("Byte received [%d] \n", count);
printf("Value of Pi = 0x%.2x\n", receive[0]);

  }
 
}

pthread_exit(0);
}


void* uartTxWait(void *param){

usleep(100);
pthread_exit(0);
}

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

Re: [beagleboard] How to decide min_free_kbytes size for BBB based custom board embedded Linux board

[Ankur Tank]

Thank you for reply Mr. Nelson,

Were there any patches or fixes your remember for 3.12 kernel ?
We will move to 4.1 kernel but its in pipeline and current boards which we 
are shipping should work with 3.12.
Considering that do you have any suggestions for us to fix this issue ?

While testing I also observed that after mentioned error I saw following 
error in the partition from where board was booting.

[ 194.912834] EXT4-fs error (device mmcblk0p15): ext4_journal_check_start:56
: Detected aborted journal
[ 194.922558] EXT4-fs (mmcblk0p15): Remounting filesystem read-only

This error was recovered after rebooting board. However I think we must 
handle this case.
I thinking of running e2fsck and reboot the board when error is received 
during mounting partition.
But what if this errors not recovered at all ?
do you suggest on that?

Regards,
Ankur

On Tuesday, 19 July 2016 22:38:25 UTC+5:30, RobertCNelson wrote:
>
>
>
> On Tue, Jul 19, 2016 at 11:11 AM, Ankur Tank  > wrote:
>
>>
>> We are using BeagleBoneBlack based custom Linux board.  
>> It has 256MB of RAM and 4GB of eMMC.   
>> Currently RFS size of the project is 163MB. While RFS partition size is 
>> 500MB.  
>> For testing, we added 20 number of big files(10MB size) and started 
>> firmware upgrade process.  
>>
>> During the firmware Upgrade process we see following error when roofs is 
>> being written,
>>
>> We could solve it by changing 
>> /proc/sys/vm/min_free_kbytes
>>
>> from *2005* to *4096*.
>>
>> *But now my doubt is what should be the ideal value for that, what 
>> factors we should consider while calculating it. From the kernel 
>> documentation I don't get that information, *
>> *but I could understand one thing that is this value can not be too low 
>> or too high or else system will break.*
>>
>> Any suggestion/pointer ?
>>
>> [ 6676.674219] mmcqd/1: page allocation failure: order:1, mode:
>> 0x200020
>> [ 6676.674256] CPU: 0 PID: 612 Comm: mmcqd/1 Tainted: P   O 
>> 3.12.10-005-ts-armv7l #2
>> [ 6676.674321] [] (unwind_backtrace+0x0/0xf4) from [<
>> c0011130>] (show_stack+0x10/0x14)
>> [ 6676.674355] [] (show_stack+0x10/0x14) from [] 
>> (warn_alloc_failed+0xe0/0x118)
>> [ 6676.674383] [] (warn_alloc_failed+0xe0/0x118) from [<
>> c008a3ac>] (__alloc_pages_nodemask+0x74c/0x8f8)
>> [ 6676.674413] [] (__alloc_pages_nodemask+0x74c/0x8f8) from 
>> [] (cache_alloc_refill+0x328/0x620)
>> [ 6676.674436] [] (cache_alloc_refill+0x328/0x620) from [<
>> c00b3224>] (__kmalloc+0xa0/0xe8)
>> [ 6676.674471] [] (__kmalloc+0xa0/0xe8) from [] (
>> edma_prep_slave_sg+0x84/0x388)
>> [ 6676.674505] [] (edma_prep_slave_sg+0x84/0x388) from [<
>> c02ec0a0>] (omap_hsmmc_request+0x414/0x508)
>> [ 6676.674544] [] (omap_hsmmc_request+0x414/0x508) from [<
>> c02d6748>] (mmc_start_request+0xc4/0xe0)
>> [ 6676.674568] [] (mmc_start_request+0xc4/0xe0) from [<
>> c02d7530>] (mmc_start_req+0x2d8/0x38c)
>> [ 6676.674589] [] (mmc_start_req+0x2d8/0x38c) from [<
>> c02e4818>] (mmc_blk_issue_rw_rq+0xb4/0x9d8)
>> [ 6676.674611] [] (mmc_blk_issue_rw_rq+0xb4/0x9d8) from [<
>> c02e52e0>] (mmc_blk_issue_rq+0x1a4/0x468)
>> [ 6676.674631] [] (mmc_blk_issue_rq+0x1a4/0x468) from [<
>> c02e5c68>] (mmc_queue_thread+0x88/0x118)
>> [ 6676.674657] [] (mmc_queue_thread+0x88/0x118) from [<
>> c004d8b8>] (kthread+0xb4/0xb8)
>> [ 6676.674681] [] (kthread+0xb4/0xb8) from [] (
>> ret_from_fork+0x14/0x3c)
>>
>
> This actually smells very much like the random mmc issues we saw on 
> "3.8.x" based images... mmc wasn't really fixed/solid till the 3.14.x 
> timeline...  Not sure how much of that was back-ported to 3.12.10...
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fa3de366-e38b-4f0a-a8c5-16ed05f30b9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to decide min_free_kbytes size for BBB based custom board embedded Linux board

[William Hermans]

>
> Thank you for reply Willian Hermans,
> I already referred links you provided below and that's the reason I turned
> to the forums to understand If I a doing anything wrong.
> OR What is the right approach.
>

Ok, it has been my experience that it is best to let Linux handle such
things as it sees fit. Granted this is the first time I've actually seen,
or heard of this. Which tells me that again, this is something best left to
Linux to work out.

I did years ago attempt to manually manage something similar ( in relation
to GbE and frame sizes etc ) in an attempt to get better performance from
my network adapters . . . and it did not end well. As I ended up making
things much worse than what Linux was doing automatically. This option
looks very similar in that you can easily end up making things much worse
than they already are.

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

[beagleboard] Re: Bagle bone boot is stopped at starting kernel

[Ratan]

 Hi James ,

Thanks for the links , at last I am able to go ahead from startin Kernel .

Issue was the dtb address .

After this I am getting stuck at below .

[6.109739] init: Error while reading from descriptor: Bad file 
descriptor
[6.117091] init: Error while reading from descriptor: Bad file 
descriptor
[6.125627] init: plymouth-ready (startup) main process (119) terminated 
with sta7
[6.134105] init: plymouth-upstart-bridge main process (120) terminated 
with stat1
[6.142219] init: plymouth-upstart-bridge main process ended, respawning
[6.152647] init: hwclock main process (123) terminated with status 127
[6.289465] init: ureadahead main process (124) terminated with status 5
[6.298215] init: plymouth-upstart-bridge main process (129) terminated 
with stat1
[6.306361] init: plymouth-upstart-bridge main process ended, respawning
[6.314406] init: plymouth main process (131) terminated with status 71
[6.406667] init: mountall main process (136) terminated with status 127



Full Log is as below .





U-Boot# setenv ipaddr 192.168.1.5;setenv serverip 192.168.1.8;tftpboot 
0x8FFEE000 am0
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.1.8; our IP address is 192.168.1.5
Filename 'am335x-boneblack.dtb'.
Load address: 0x8ffee000
Loading: T #
 10.7 KiB/s
done
Bytes transferred = 60627 (ecd3 hex)
link up on port 0, speed 100, full duplex
Using cpsw device
TFTP from server 192.168.1.8; our IP address is 192.168.1.5
Filename 'uImage-BBB'.
Load address: 0x80007fc0
Loading: T T 
#
 #
 #
 #
 #
 #
 #
 #
 #
 227.5 KiB/s
done
Bytes transferred = 7810336 (772d20 hex)
## Booting kernel from Legacy Image at 80007fc0 ...
   Image Name:   Linux-4.1.24+
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:7810272 Bytes = 7.4 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 8ffee000
   Booting using the fdt blob at 0x8ffee000
   XIP Kernel Image ... OK
OK
   Using Device Tree in place at 8ffee000, end 8cd2

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.1.24+ (root@ratan-VirtualBox) (gcc version 
4.7.3 (Ubu6
[0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
cr=50c5387d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cae
[0.00] Machine model: TI AM335x BeagleBone Black
[0.00] cma: Reserved 24 MiB at 0x9e00
[0.00] Memory policy: Data cache writeback
[0.00] CPU: All CPU(s) started in SVC mode.
[0.00] AM335X ES2.0 (sgx neon )
[0.00] PERCPU: Embedded 13 pages/cpu @df90e000 s24128 r8192 d20928 
u53248
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  
Total pages: 8
[0.00] Kernel command line: console=ttyO0,115200n8 
root=/dev/mmcblk0p2 ro rot
[0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
[0.00] Dentry cache hash table entries: 65536 (order: 7, 524288 
bytes)
[0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 
bytes)
[0.00] Memory: 478624K/522240K available (7033K kernel code, 936K 
rwdata, 37)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xffc0 - 0xfff0   (3072 kB)
[0.00] vmalloc : 0xe080 - 0xff00   ( 488 MB)
[0.00] lowmem  : 0xc000 - 0xe000   ( 512 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf80 - 0xbfe0   (   6 MB)
[0.00]   .text : 0xc0008000 - 0xc0a9572c   (10806 kB)
[0.00]   .init : 0xc0a96000 - 0xc0b1c000   ( 536 kB)
[0.00]   .data : 0xc0b1c000 - 0xc0c0630c   ( 937 kB)
[0.00].bss : 0xc0c09000 - 0xc0cf7ba0   ( 955 kB)
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[0.00] Preemptible hierarchical RCU implementation.
[0.00]  RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1.
[0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[0.00] NR_IRQS:16 nr_ir

Re: [beagleboard] How to decide min_free_kbytes size for BBB based custom board embedded Linux board

[Ankur Tank]

Thank you for reply Willian Hermans,
I already referred links you provided below and that's the reason I turned 
to the forums to understand If I a doing anything wrong.
OR What is the right approach.

On Tuesday, 19 July 2016 22:29:20 UTC+5:30, William Hermans wrote:
>
> I'm not sure why you feel compelled to even bother playing with this. In 
> 20-21 years of using Linux I've never had to set this manually. But . . .
>
>
> https://www.google.com/search?q=%2Fproc%2Fsys%2Fvm%2Fmin_free_kbytes&ie=utf-8 
>  
> >
>
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-tunables.html
>  
> >
>
> Be cautious when setting this parameter, as both too-low and too-high 
>> values can be damaging and break your system. 
>> Setting *min_free_kbytes* too low prevents the system from reclaiming 
>> memory. This can result in system hangs and OOM-killing multiple processes. 
>> However, setting this parameter to a value that is too high (5-10% of 
>> total system memory) will cause your system to become out-of-memory 
>> immediately. Linux is designed to use all available RAM to cache file 
>> system data. Setting a high *min_free_kbytes* value results in the 
>> system spending too much time reclaiming memory. 
>>
>
>
>
> On Tue, Jul 19, 2016 at 9:11 AM, Ankur Tank  > wrote:
>
>>
>> We are using BeagleBoneBlack based custom Linux board.  
>> It has 256MB of RAM and 4GB of eMMC.   
>> Currently RFS size of the project is 163MB. While RFS partition size is 
>> 500MB.  
>> For testing, we added 20 number of big files(10MB size) and started 
>> firmware upgrade process.  
>>
>> During the firmware Upgrade process we see following error when roofs is 
>> being written,
>>
>> We could solve it by changing 
>> /proc/sys/vm/min_free_kbytes
>>
>> from *2005* to *4096*.
>>
>> *But now my doubt is what should be the ideal value for that, what 
>> factors we should consider while calculating it. From the kernel 
>> documentation I don't get that information, *
>> *but I could understand one thing that is this value can not be too low 
>> or too high or else system will break.*
>>
>> Any suggestion/pointer ?
>>
>> [ 6676.674219] mmcqd/1: page allocation failure: order:1, mode:
>> 0x200020
>> [ 6676.674256] CPU: 0 PID: 612 Comm: mmcqd/1 Tainted: P   O 
>> 3.12.10-005-ts-armv7l #2
>> [ 6676.674321] [] (unwind_backtrace+0x0/0xf4) from [<
>> c0011130>] (show_stack+0x10/0x14)
>> [ 6676.674355] [] (show_stack+0x10/0x14) from [] 
>> (warn_alloc_failed+0xe0/0x118)
>> [ 6676.674383] [] (warn_alloc_failed+0xe0/0x118) from [<
>> c008a3ac>] (__alloc_pages_nodemask+0x74c/0x8f8)
>> [ 6676.674413] [] (__alloc_pages_nodemask+0x74c/0x8f8) from 
>> [] (cache_alloc_refill+0x328/0x620)
>> [ 6676.674436] [] (cache_alloc_refill+0x328/0x620) from [<
>> c00b3224>] (__kmalloc+0xa0/0xe8)
>> [ 6676.674471] [] (__kmalloc+0xa0/0xe8) from [] (
>> edma_prep_slave_sg+0x84/0x388)
>> [ 6676.674505] [] (edma_prep_slave_sg+0x84/0x388) from [<
>> c02ec0a0>] (omap_hsmmc_request+0x414/0x508)
>> [ 6676.674544] [] (omap_hsmmc_request+0x414/0x508) from [<
>> c02d6748>] (mmc_start_request+0xc4/0xe0)
>> [ 6676.674568] [] (mmc_start_request+0xc4/0xe0) from [<
>> c02d7530>] (mmc_start_req+0x2d8/0x38c)
>> [ 6676.674589] [] (mmc_start_req+0x2d8/0x38c) from [<
>> c02e4818>] (mmc_blk_issue_rw_rq+0xb4/0x9d8)
>> [ 6676.674611] [] (mmc_blk_issue_rw_rq+0xb4/0x9d8) from [<
>> c02e52e0>] (mmc_blk_issue_rq+0x1a4/0x468)
>> [ 6676.674631] [] (mmc_blk_issue_rq+0x1a4/0x468) from [<
>> c02e5c68>] (mmc_queue_thread+0x88/0x118)
>> [ 6676.674657] [] (mmc_queue_thread+0x88/0x118) from [<
>> c004d8b8>] (kthread+0xb4/0xb8)
>> [ 6676.674681] [] (kthread+0xb4/0xb8) from [] (
>> ret_from_fork+0x14/0x3c)
>> [ 6676.674691] Mem-info:
>> [ 6676.674700] Normal per-cpu:
>> [ 6676.674711] CPU0: hi:   90, btch:  15 usd:  79
>> [ 6676.674739] active_anon:4889 inactive_anon:13 isolated_anon:0
>> [ 6676.674739]  active_file:8082 inactive_file:43196 isolated_file:0
>> [ 6676.674739]  unevictable:422 dirty:2 writeback:1152 unstable:0
>> [ 6676.674739]  free:3286 slab_reclaimable:1090 slab_unreclaimable:
>> 915
>> [ 6676.674739]  mapped:1593 shmem:39 pagetables:181 bounce:0
>> [ 6676.674739]  free_cma:1982
>> [ 6676.674800] Normal free:13144kB min:2004kB low:2504kB high:3004kB 
>> active_anon:19556kB inactive_anon:52kB active_file:32328kB inactive_file:
>> 172784kB unevictable:o
>> [ 6676.674813] lowmem_reserve[]: 0 0 0
>> [ 6676.674831] Normal: 2584*4kB (UMC) 217*8kB (C) 57*16kB (C) 5*32kB 
>> (C) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB = 
>> 13144kB
>> [ 6676.674885] 51661 total pagecache pages
>> [ 6676.674900] 0 pages in swap cache
>> [ 6676.674910] Swap cache stats: add 0, delete 0, find 0/0
>> [ 6676.674918] Free swap  = 0kB
>> [ 6676.674925] Total swap = 0kB
>> [ 6676.67

[beagleboard] Re: How to recovery after disable eMMC in uEnv.txt

[qiu . weibin]

Hi 
I got the same problem. Have you solved it?

On Sunday, July 19, 2015 at 7:33:38 PM UTC+8, huey...@gmail.com wrote:
>
> I uncorrectly disable eMMC in my Beaglebone Black Rev. C by following 
> steps:
>
> 1. Mount the FAT partition:
>
>$ mount /dev/mmcblk0p1  /mnt/card
>
> 2. Edit the uEnv.txt on the mounted partition:
>
>$ nano /mnt/card/uEnv.txt
>
> 3. Enable following line in uEnv.txt
>
> 
> optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
>
> Then I can not boot again, following message show on screen:
>
> [0.741541] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' 
> failed
>
> then I boot into 
>
> Busybox v1.20.2 (Debian 1:1.20.0-7) built-in shell (ash)
> Enter 'help' for a list of built-in commands.
>
> /bin/sh: can't access tty; job control turned off
> (initramfs)
>
> Since there is no /dev/mmcblk0p1 now, I can not mount it and edit uEnv.txt 
> again.
>
> Then how can I recovery my eMMC from this point?
>
>

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

[beagleboard] Re: How to use PRU constants table?

[dinuxbg]

Hi Karl,

These constants allow the C compiler to produce more efficient code. Of 
course you can also use them in assembly programs by explicitly using 
lbco/sbco instructions.

Let me give you an example how pru-gcc uses the constant table. Consider 
this C code snippet:
# define MYREG   ( * (volatile uint32_t *)(0x4802A000 + 0x24))
MYREG = 42;


Normally pru-gcc would output the following:
ldi r14, %lo(1208131620)
ldi r14.w2, %hi_rlz(1208131620)
ldi r15, 42
sbbor15, r14, 0, 4

But you can tell the compiler that this address base is special (btw, 
already defined for you in ):
#pragma ctable_entry 2 0x4802a000
Then the compiler can produce a much shorter instruction sequence:
ldi r14, 42
sbcor14, 2, 36, 4

TI's compiler uses a different syntax for the constants declarations, but 
essentially does the same optimization.

Regards,
Dimitar

On Friday, July 15, 2016 at 11:41:06 AM UTC+3, Karl Karpfen wrote:
>
> Hi,
>
> the AM335x TRM specifies a constants table for PRU which can be used for 
> easier access of memory addresses. As an example: for I2C1 registers which 
> originally use base-address 0x4802A000 a constant 2 is defined.
>
> What I do not understand: how can one use these constants? How does the 
> mapping from a constant to a base-address work where I have to add an 
> offset in order to access desired registers?
>
> Or is this an assembler-thingy only which can't be used out of 
> PRU-C-Software?
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/720f7e7d-d6ee-4498-851f-8cb5a2fa5087%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Building drivers without source on BBB

[Raul Piper]

No It did not work.I just replaced the name of my module in your
example Makefile .Did you follow any pre-steps before this?
Rp

On Tue, Jul 19, 2016 at 9:55 PM, ZeekHuge  wrote:
> Hi Raul Piper,
>
> You should probably not worry about the /lib/modules/4.1.22-bone21/ files.
>
> But there might be a problem in your Makefile. You should try adding 'all'
> and 'clean' as PHONY targets in your makefile.
> You can see this Makefile for reference :
> https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/examples/kernel_examples/n-blinky/module/Makefile
>
> Good Luck
>
> On Tuesday, 19 July 2016 17:06:00 UTC+5:30, Raul Piper wrote:
>>
>>
>> HI,
>> I am using this Makefile to build the kernel driver on the BBB
>> itself(already apt-get installed build-essenatials on it).
>> obj-m += myDrvr.o
>>
>> all:
>> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
>>
>> clean:
>> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
>>
>>
>> But I am getting this error :
>> make -C /lib/modules/4.1.22-bone21/build
>> M=/home/ubuntu/bb/exploringBB/chp06/GPIO/tests/hello-linux-module modules
>> Makefile:4: recipe for target 'all' failed
>>
>>
>> I checked that inside ls -l /lib/modules/  there is 4.1.22-bone21 folder
>> is present which is symbolically linked with the build pointing to
>> /path_to_kernel_sources_on_pc_WHERE_I_BUILT_MY_KERNEL
>>
>> Is this some error I did while building the image for BBB.How can I
>> compile my kernel module?
>>
>> Thanks and Rgds,
>> Rp
>
> --
> 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/j30OiI9DWMg/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/daa95f3f-8c1c-44f3-92c8-536db1a0f134%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAEwN%2BMADg3aVby8Te67cRHsP_7ZxP-KfncHAOsPar%3D9vXMvktQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] GPIO problems on ubuntu 16.04

[John Syne]

One more thing, the Linux kernel used on RaspberryPi3, etc are still running in 
32bit mode:

https://www.linux.com/news/raspberry-pi-3-still-essentially-32-bit-sbc-now 


Regards,
John




> On Jul 19, 2016, at 6:11 PM, William Hermans  wrote:
> 
> denis,
> 
> For what it's worth. Ubuntu mate does not seem very . . ."complete" on any 
> ARM platform right now. For instance, the Odroid XU4 which has 4 cores A15's 
> and 4 cores A7 uses an armv7 kernel( 32 bit ). Where the A15 cores are 
> actually 64bit cores I believe.  Same for the RaspberryPI 3 , and odroid C2 
> which both use A53 processors that are also 64bit cores . . . and this is not 
> only for Ubuntu. It for all Linux's as far as I can tell.
> 
> But the point I'm trying to make here is that Ubuntu mate is new, so give it 
> some time, and these issues which may, or may not be kernel related. To 
> settle down. So if you have to use Ubuntu, in your shoes. I'd stick with 
> 14.04. But honestly I'd never use Ubuntu on this specific hardware anyhow . . 
> . an odroid XU4 sure, but not a beaglebone.
> 
> On Tue, Jul 19, 2016 at 10:16 AM,  > wrote:
> Ok, can't be helped then. :-) Thank you for spending some time on my problem.
> 
> Am Dienstag, 19. Juli 2016 16:30:26 UTC+2 schrieb William Hermans:
> Do you happen to know a download location for a working ubuntu 16.04 
> beaglebone image with a 4.4.x kernel?
> 
> No I do not. Ubuntu on the beaglebones is not my thing . . .
> 
> On Tue, Jul 19, 2016 at 2:31 AM, > wrote:
> Hello William,
> that doesn't sound very encouraging. I just re-downloaded the image from 
> http://elinux.org/BeagleBoardUbuntu#Ubuntu_.2816.04.29 
>  , flashed it on an 
> empty uSD card loaded am335x-boneblack-emmc-
> overlay.dtb and univ-all cape to ensure it wasn't me who broke the image 
> during install. Unfortunately the kernel log showed the same errors. Then I 
> tried to fake the missing directories by creating symlinks to the existing 
> ones, but it didn't work, because symlinks can not be created in sysfs 
> directories.
> Do you happen to know a download location for a working ubuntu 16.04 
> beaglebone image with a 4.4.x kernel?
> 
> 
> Am Montag, 18. Juli 2016 19:00:52 UTC+2 schrieb William Hermans:
> Hi denis,
> 
> I do not know what to say. That Linux image you have seems to be incomplete 
> or somehow broken.
> 
> On Mon, Jul 18, 2016 at 12:56 AM, > wrote:
> Hello William,
> thank you very much for your answer. I just experimented with your solution. 
> Loading the univ-all cape and the setting P9_15 for gpio48 to hi and P8_20 
> for gpio63 to high I was able to activate and deactivate both pins. If I now 
> just load the univ-all cape at startup both GPIOs seem to behave as required 
> and are powered on by my normal startup code. Unfortunately the kernel log 
> now shows a lot of errors after startup.
> 
> [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.14-bone11 (root@a4-imx6q-wandboard-2gb) (gcc 
> version 5.3.1 20160413 (Ubuntu/Linaro 5.3.1-14ubuntu2.1) ) #1 Sun Jul 3 
> 07:00:48 UTC 2016
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] Machine model: TI AM335x BeagleBone Black
> [0.00] cma: Reserved 24 MiB at 0x9e80
> [0.00] Memory policy: Data cache writeback
> [0.00] On node 0 totalpages: 131072
> [0.00] free_area_init_node: node 0, pgdat c0b62d5c, node_mem_map 
> de36d000
> [0.00]   Normal zone: 1152 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 131072 pages, LIFO batch:31
> [0.00] CPU: All CPU(s) started in SVC mode.
> [0.00] AM335X ES2.1 (sgx neon )
> [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> [0.00] pcpu-alloc: [0] 0 
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 129920
> [0.00] Kernel command line: console=ttyO0,115200n8 
> bone_capemgr.enable_partno=univ-all 
> root=UUID=f71c90d7-7127-4727-9b6c-ec6d687c6682 ro rootfstype=ext4 rootwait 
> coherent_pool=1M quiet
> [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> [0.00] Memory: 477068K/524288K available (6817K kernel code, 865K 
> rwdata, 3604K rodata, 456K init, 858K bss, 22644K reserved, 24576K 
> cma-reserved, 0K highmem)
> [0.00] Virtual kernel memory layout:
>

Re: [beagleboard] GPIO problems on ubuntu 16.04

[John Syne]

I don’t know why William doesn’t take a quick look on the ARM website before 
making statements like this. CortexA15 is a 32bit processor. CortexA53 is a low 
power 64bit processor. 

Regards,
John




> On Jul 19, 2016, at 6:11 PM, William Hermans  wrote:
> 
> denis,
> 
> For what it's worth. Ubuntu mate does not seem very . . ."complete" on any 
> ARM platform right now. For instance, the Odroid XU4 which has 4 cores A15's 
> and 4 cores A7 uses an armv7 kernel( 32 bit ). Where the A15 cores are 
> actually 64bit cores I believe.  Same for the RaspberryPI 3 , and odroid C2 
> which both use A53 processors that are also 64bit cores . . . and this is not 
> only for Ubuntu. It for all Linux's as far as I can tell.
> 
> But the point I'm trying to make here is that Ubuntu mate is new, so give it 
> some time, and these issues which may, or may not be kernel related. To 
> settle down. So if you have to use Ubuntu, in your shoes. I'd stick with 
> 14.04. But honestly I'd never use Ubuntu on this specific hardware anyhow . . 
> . an odroid XU4 sure, but not a beaglebone.
> 
> On Tue, Jul 19, 2016 at 10:16 AM,  > wrote:
> Ok, can't be helped then. :-) Thank you for spending some time on my problem.
> 
> Am Dienstag, 19. Juli 2016 16:30:26 UTC+2 schrieb William Hermans:
> Do you happen to know a download location for a working ubuntu 16.04 
> beaglebone image with a 4.4.x kernel?
> 
> No I do not. Ubuntu on the beaglebones is not my thing . . .
> 
> On Tue, Jul 19, 2016 at 2:31 AM, > wrote:
> Hello William,
> that doesn't sound very encouraging. I just re-downloaded the image from 
> http://elinux.org/BeagleBoardUbuntu#Ubuntu_.2816.04.29 
>  , flashed it on an 
> empty uSD card loaded am335x-boneblack-emmc-
> overlay.dtb and univ-all cape to ensure it wasn't me who broke the image 
> during install. Unfortunately the kernel log showed the same errors. Then I 
> tried to fake the missing directories by creating symlinks to the existing 
> ones, but it didn't work, because symlinks can not be created in sysfs 
> directories.
> Do you happen to know a download location for a working ubuntu 16.04 
> beaglebone image with a 4.4.x kernel?
> 
> 
> Am Montag, 18. Juli 2016 19:00:52 UTC+2 schrieb William Hermans:
> Hi denis,
> 
> I do not know what to say. That Linux image you have seems to be incomplete 
> or somehow broken.
> 
> On Mon, Jul 18, 2016 at 12:56 AM, > wrote:
> Hello William,
> thank you very much for your answer. I just experimented with your solution. 
> Loading the univ-all cape and the setting P9_15 for gpio48 to hi and P8_20 
> for gpio63 to high I was able to activate and deactivate both pins. If I now 
> just load the univ-all cape at startup both GPIOs seem to behave as required 
> and are powered on by my normal startup code. Unfortunately the kernel log 
> now shows a lot of errors after startup.
> 
> [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.14-bone11 (root@a4-imx6q-wandboard-2gb) (gcc 
> version 5.3.1 20160413 (Ubuntu/Linaro 5.3.1-14ubuntu2.1) ) #1 Sun Jul 3 
> 07:00:48 UTC 2016
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] Machine model: TI AM335x BeagleBone Black
> [0.00] cma: Reserved 24 MiB at 0x9e80
> [0.00] Memory policy: Data cache writeback
> [0.00] On node 0 totalpages: 131072
> [0.00] free_area_init_node: node 0, pgdat c0b62d5c, node_mem_map 
> de36d000
> [0.00]   Normal zone: 1152 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 131072 pages, LIFO batch:31
> [0.00] CPU: All CPU(s) started in SVC mode.
> [0.00] AM335X ES2.1 (sgx neon )
> [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> [0.00] pcpu-alloc: [0] 0 
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
> pages: 129920
> [0.00] Kernel command line: console=ttyO0,115200n8 
> bone_capemgr.enable_partno=univ-all 
> root=UUID=f71c90d7-7127-4727-9b6c-ec6d687c6682 ro rootfstype=ext4 rootwait 
> coherent_pool=1M quiet
> [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
> [0.00] Memory: 477068K/524288K available (6817K kernel code, 865K 
> rwdata, 3604K rodata, 456K init, 858K bss, 22644K reserved, 24576K 
> cma-reserved, 0K highmem)
> [0.00] Virtual kernel memory layout:
>vector  : 0x - 0x1000   (   4 kB)
> 

Re: [beagleboard] GPIO problems on ubuntu 16.04

[William Hermans]

denis,

For what it's worth. Ubuntu mate does not seem very . . ."complete" on any
ARM platform right now. For instance, the Odroid XU4 which has 4 cores
A15's and 4 cores A7 uses an armv7 kernel( 32 bit ). Where the A15 cores
are actually 64bit cores I believe.  Same for the RaspberryPI 3 , and
odroid C2 which both use A53 processors that are also 64bit cores . . . and
this is not only for Ubuntu. It for all Linux's as far as I can tell.

But the point I'm trying to make here is that Ubuntu mate is new, so give
it some time, and these issues which may, or may not be kernel related. To
settle down. So if you have to use Ubuntu, in your shoes. I'd stick with
14.04. But honestly I'd never use Ubuntu on this specific hardware anyhow .
. . an odroid XU4 sure, but not a beaglebone.

On Tue, Jul 19, 2016 at 10:16 AM,  wrote:

> Ok, can't be helped then. :-) Thank you for spending some time on my
> problem.
>
> Am Dienstag, 19. Juli 2016 16:30:26 UTC+2 schrieb William Hermans:
>>
>> Do you happen to know a download location for a working ubuntu 16.04
>> beaglebone image with a 4.4.x kernel?
>>
>>
>> No I do not. Ubuntu on the beaglebones is not my thing . . .
>>
>> On Tue, Jul 19, 2016 at 2:31 AM,  wrote:
>>
>> Hello William,
>> that doesn't sound very encouraging. I just re-downloaded the image from
>> http://elinux.org/BeagleBoardUbuntu#Ubuntu_.2816.04.29 , flashed it on
>> an empty uSD card loaded am335x-boneblack-emmc-
>> overlay.dtb and univ-all cape to ensure it wasn't me who broke the image
>> during install. Unfortunately the kernel log showed the same errors. Then I
>> tried to fake the missing directories by creating symlinks to the existing
>> ones, but it didn't work, because symlinks can not be created in sysfs
>> directories.
>> Do you happen to know a download location for a working ubuntu 16.04
>> beaglebone image with a 4.4.x kernel?
>>
>>
>> Am Montag, 18. Juli 2016 19:00:52 UTC+2 schrieb William Hermans:
>>
>> Hi denis,
>>
>> I do not know what to say. That Linux image you have seems to be
>> incomplete or somehow broken.
>>
>> On Mon, Jul 18, 2016 at 12:56 AM,  wrote:
>>
>> Hello William,
>> thank you very much for your answer. I just experimented with your
>> solution. Loading the univ-all cape and the setting P9_15 for gpio48 to hi
>> and P8_20 for gpio63 to high I was able to activate and deactivate both
>> pins. If I now just load the univ-all cape at startup both GPIOs seem to
>> behave as required and are powered on by my normal startup code.
>> Unfortunately the kernel log now shows a lot of errors after startup.
>>
>> [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.14-bone11 (root@a4-imx6q-wandboard-2gb)
>> (gcc version 5.3.1 20160413 (Ubuntu/Linaro 5.3.1-14ubuntu2.1) ) #1 Sun
>> Jul 3 07:00:48 UTC 2016
>> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=
>> 50c5387d
>> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
>> instruction cache
>> [0.00] Machine model: TI AM335x BeagleBone Black
>> [0.00] cma: Reserved 24 MiB at 0x9e80
>> [0.00] Memory policy: Data cache writeback
>> [0.00] On node 0 totalpages: 131072
>> [0.00] free_area_init_node: node 0, pgdat c0b62d5c, node_mem_map
>> de36d000
>> [0.00]   Normal zone: 1152 pages used for memmap
>> [0.00]   Normal zone: 0 pages reserved
>> [0.00]   Normal zone: 131072 pages, LIFO batch:31
>> [0.00] CPU: All CPU(s) started in SVC mode.
>> [0.00] AM335X ES2.1 (sgx neon )
>> [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
>> [0.00] pcpu-alloc: [0] 0
>> [0.00] Built 1 zonelists in Zone order, mobility grouping on.
>> Total pages: 129920
>> [0.00] Kernel command line: console=ttyO0,115200n8 bone_capemgr.
>> enable_partno=univ-all root=UUID=f71c90d7-7127-4727-9b6c-ec6d687c6682 ro
>> rootfstype=ext4 rootwait coherent_pool=1M quiet
>> [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
>> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144
>> bytes)
>> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072
>> bytes)
>> [0.00] Memory: 477068K/524288K available (6817K kernel code, 865K
>> rwdata, 3604K rodata, 456K init, 858K bss, 22644K reserved, 24576K cma-
>> reserved, 0K highmem)
>> [0.00] Virtual kernel memory layout:
>>vector  : 0x - 0x1000   (   4 kB)
>>fixmap  : 0xffc0 - 0xfff0   (3072 kB)
>>vmalloc : 0xe080 - 0xff80   ( 496 MB)
>>lowmem  : 0xc000 - 0xe000   ( 512 MB)
>>pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>>modules : 0xbf80 - 0xbfe0   (   6 MB)
>>  

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[William Hermans]

>
> Actually, it's just my locally cross built kernel that have the large
> modules, for the official *.deb, the *.ko objects are separate in the
> linux-image-`uname -r`-dbg package. ;) (for gcc-4.7 + that is..)
>
> Yeah, just adding a blacklist for users who want to tune things is the
> easiest way.
>
> Regards,
>

That's pretty much what my script on
https://github.com/wphermans/bbb-cleanup does. When I first wrote this
script, for some reason the blacklist method was not working, but the fake
install was. Would be very trivial to change the script to do a "proper"
blacklist.

Question though Robert.

debian@beaglebone:~$ sudo depmod -ae/* Ignore warning */
debian@beaglebone:~$ sudo update-initramfs -u   /* Changes will take
effect next boot */

What do these two tools actually do in the context of modules and
initrd images ? I always assumed this had some

effect on what is actually loaded from an initrd, but I've never
honestly looked into it. . .




On Tue, Jul 19, 2016 at 12:06 PM, Robert Nelson 
wrote:

>
>
> On Tue, Jul 19, 2016 at 1:56 PM, John Syne  wrote:
>
>> Hi Robert,
>>
>> I was one of those users who uses Systemtap, but I always build my own
>> kernel with debug symbols enabled, so I would recommend a standard kernel
>> version without debug symbols and if you are up to it, add another build
>> with a -dbg.deb kernel/modules version. Regarding the other kernel modules
>> such as pwn, spidev, snd*(no audio on base BBB), c-can, etc, why not add
>> these to the blacklist and have users remove those from the blacklist if
>> they want these drivers available?
>>
>
> Actually, it's just my locally cross built kernel that have the large
> modules, for the official *.deb, the *.ko objects are separate in the
> linux-image-`uname -r`-dbg package. ;) (for gcc-4.7 + that is..)
>
> Yeah, just adding a blacklist for users who want to tune things is the
> easiest way.
>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYi-EJTZ6UVdXOpyKvrjhwksKqd3YFeXjPQsZz9FFUpEZg%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Kernel update to 4.4.15-ti-r35 failure

[Jason Kridner]

On Tue, Jul 19, 2016 at 4:16 PM Robert Nelson 
wrote:

> FYI, it seems to have also broken WL1835 wifi over SDIO (mmc2).

>>>
>>> OK, that wasn't the issue. ti-rt-r36 still fails with WL1835.
>>>
>>> Useful debug output:
>>>
>>> Jul 19 15:12:08 beaglebone kernel: omap_hsmmc 4781.mmc: card claims
>>> to support voltages below defined range
>>> .
>>> .
>>> .
>>> Jul 19 15:12:08 beaglebone kernel: mmc2: error -16 whilst initialising
>>> SDIO card
>>>
>>
>> Is -r37 on the way or do I need to look at this as a potential device
>> tree issue related to the new kernel and start hacking the tree again?
>>
>
> Most of the r37 builds are done, still waiting on a few "rt" builds, this
> will work right now in wheezy/jessie/stretch/sid
>
> sudo apt-get update ; sudo apt-get install linux-image-4.4.15-ti-r37
>

That did the trick! WL1835 is working out-of-the-box.


>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYjCjPbE%2BT6oMd-rsLmzzL5fvuRVeb7M7rG2s-V%3D2KM7%2Bw%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPn9e1BEwzbuLHLA3xE3XrVeK%3D7a3VdDUeZahA%3D72j-Uzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel update to 4.4.15-ti-r35 failure

[Robert Nelson]

>
> FYI, it seems to have also broken WL1835 wifi over SDIO (mmc2).
>>>
>>
>> OK, that wasn't the issue. ti-rt-r36 still fails with WL1835.
>>
>> Useful debug output:
>>
>> Jul 19 15:12:08 beaglebone kernel: omap_hsmmc 4781.mmc: card claims
>> to support voltages below defined range
>> .
>> .
>> .
>> Jul 19 15:12:08 beaglebone kernel: mmc2: error -16 whilst initialising
>> SDIO card
>>
>
> Is -r37 on the way or do I need to look at this as a potential device tree
> issue related to the new kernel and start hacking the tree again?
>

Most of the r37 builds are done, still waiting on a few "rt" builds, this
will work right now in wheezy/jessie/stretch/sid

sudo apt-get update ; sudo apt-get install linux-image-4.4.15-ti-r37

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYjCjPbE%2BT6oMd-rsLmzzL5fvuRVeb7M7rG2s-V%3D2KM7%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel update to 4.4.15-ti-r35 failure

[Jason Kridner]

On Tue, Jul 19, 2016 at 11:18 AM Jason Kridner 
wrote:

> On Tue, Jul 19, 2016 at 10:58 AM Jason Kridner <
> jason.krid...@hangerhead.com> wrote:
>
>> On Tue, Jul 19, 2016 at 9:37 AM Robert Nelson 
>> wrote:
>>
>>> Hi Steve,
>>>
>>> On Tue, Jul 19, 2016 at 5:00 AM, Steve Osselton <
>>> steve.ossel...@prismtech.com> wrote:
>>>
 Hi,

 When updating the TI kernel from 4.4.14-ti-r34 to 4.4.15-ti-r35 on
 Debian 8.5, the kernel failed to
 boot cleanly. On connecting a console, the boot process failed in
 initramfs when trying to mount the
 real boot partition (the eMMC). The mount command from initramfs was
 complaining about invalid
 parameters. Any idea about what is causing this? Edited uEnv.txt to
 refer to the older kernel and
 re-booted ok, so was fixable.

>>>
>>> Sigh, yeah it's broken on my bbb too...
>>>
>>> with r34, i was chasing why the uuid=<> option was failing to find the
>>> microSD card on the x15, i fixed that and pushed as r35..
>>>
>>
>> Mainline u-boot seems to use a 'blkid' command to set the UUID. Does that
>> work for X15?
>>
>>
>>>
>>> Then with r35, i noticed the eMMC on x15 had regressed (while the
>>> microSD was working), which i fixed in r36, by pulling the patch from 4.5.x
>>> to hard code microSD=mmc0, eMMC=mmc1...
>>>
>>> and now the bbb is broken.. blah...
>>>
>>
>> FYI, it seems to have also broken WL1835 wifi over SDIO (mmc2).
>>
>
> OK, that wasn't the issue. ti-rt-r36 still fails with WL1835.
>
> Useful debug output:
>
> Jul 19 15:12:08 beaglebone kernel: omap_hsmmc 4781.mmc: card claims to
> support voltages below defined range
> .
> .
> .
> Jul 19 15:12:08 beaglebone kernel: mmc2: error -16 whilst initialising
> SDIO card
>

Is -r37 on the way or do I need to look at this as a potential device tree
issue related to the new kernel and start hacking the tree again?


>
>
>>
>>>
>>> So, i'll revert back to r34, but leave the 4.5.x hardcode in place for
>>> the x15. ;)
>>>
>>
>> I'll be looking for the build!
>>
>>
>>>
>>> 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.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYi2%2B1GL_dBLySwAAgnd4bnOyot8i4njZe5UKmbqpRqMMQ%40mail.gmail.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPka34Ry3uHUEX5ean2D7Q%2BWhh%2B%3D%3D0tNR%2B%2BsCM8zrM4kAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Robert Nelson]

On Tue, Jul 19, 2016 at 1:56 PM, John Syne  wrote:

> Hi Robert,
>
> I was one of those users who uses Systemtap, but I always build my own
> kernel with debug symbols enabled, so I would recommend a standard kernel
> version without debug symbols and if you are up to it, add another build
> with a -dbg.deb kernel/modules version. Regarding the other kernel modules
> such as pwn, spidev, snd*(no audio on base BBB), c-can, etc, why not add
> these to the blacklist and have users remove those from the blacklist if
> they want these drivers available?
>

Actually, it's just my locally cross built kernel that have the large
modules, for the official *.deb, the *.ko objects are separate in the
linux-image-`uname -r`-dbg package. ;) (for gcc-4.7 + that is..)

Yeah, just adding a blacklist for users who want to tune things is the
easiest way.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYi-EJTZ6UVdXOpyKvrjhwksKqd3YFeXjPQsZz9FFUpEZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] GPIO problems on ubuntu 16.04

[denis . fisseler]

Ok, can't be helped then. :-) Thank you for spending some time on my 
problem.

Am Dienstag, 19. Juli 2016 16:30:26 UTC+2 schrieb William Hermans:
>
> Do you happen to know a download location for a working ubuntu 16.04 
> beaglebone image with a 4.4.x kernel?
>
>
> No I do not. Ubuntu on the beaglebones is not my thing . . .
>
> On Tue, Jul 19, 2016 at 2:31 AM, > 
> wrote:
>
> Hello William,
> that doesn't sound very encouraging. I just re-downloaded the image from 
> http://elinux.org/BeagleBoardUbuntu#Ubuntu_.2816.04.29 , flashed it on an 
> empty uSD card loaded am335x-boneblack-emmc-
> overlay.dtb and univ-all cape to ensure it wasn't me who broke the image 
> during install. Unfortunately the kernel log showed the same errors. Then I 
> tried to fake the missing directories by creating symlinks to the existing 
> ones, but it didn't work, because symlinks can not be created in sysfs 
> directories.
> Do you happen to know a download location for a working ubuntu 16.04 
> beaglebone image with a 4.4.x kernel?
>
>
> Am Montag, 18. Juli 2016 19:00:52 UTC+2 schrieb William Hermans:
>
> Hi denis,
>
> I do not know what to say. That Linux image you have seems to be 
> incomplete or somehow broken.
>
> On Mon, Jul 18, 2016 at 12:56 AM,  wrote:
>
> Hello William,
> thank you very much for your answer. I just experimented with your 
> solution. Loading the univ-all cape and the setting P9_15 for gpio48 to hi 
> and P8_20 for gpio63 to high I was able to activate and deactivate both 
> pins. If I now just load the univ-all cape at startup both GPIOs seem to 
> behave as required and are powered on by my normal startup code. 
> Unfortunately the kernel log now shows a lot of errors after startup.
>
> [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.14-bone11 (root@a4-imx6q-wandboard-2gb) (gcc 
> version 5.3.1 20160413 (Ubuntu/Linaro 5.3.1-14ubuntu2.1) ) #1 Sun Jul 3 
> 07:00:48 UTC 2016
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=
> 50c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0.00] Machine model: TI AM335x BeagleBone Black
> [0.00] cma: Reserved 24 MiB at 0x9e80
> [0.00] Memory policy: Data cache writeback
> [0.00] On node 0 totalpages: 131072
> [0.00] free_area_init_node: node 0, pgdat c0b62d5c, node_mem_map 
> de36d000
> [0.00]   Normal zone: 1152 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 131072 pages, LIFO batch:31
> [0.00] CPU: All CPU(s) started in SVC mode.
> [0.00] AM335X ES2.1 (sgx neon )
> [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> [0.00] pcpu-alloc: [0] 0 
> [0.00] Built 1 zonelists in Zone order, mobility grouping on.  
> Total pages: 129920
> [0.00] Kernel command line: console=ttyO0,115200n8 bone_capemgr.
> enable_partno=univ-all root=UUID=f71c90d7-7127-4727-9b6c-ec6d687c6682 ro 
> rootfstype=ext4 rootwait coherent_pool=1M quiet
> [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes)
> [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 
> bytes)
> [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 
> bytes)
> [0.00] Memory: 477068K/524288K available (6817K kernel code, 865K 
> rwdata, 3604K rodata, 456K init, 858K bss, 22644K reserved, 24576K cma-
> reserved, 0K highmem)
> [0.00] Virtual kernel memory layout:
>vector  : 0x - 0x1000   (   4 kB)
>fixmap  : 0xffc0 - 0xfff0   (3072 kB)
>vmalloc : 0xe080 - 0xff80   ( 496 MB)
>lowmem  : 0xc000 - 0xe000   ( 512 MB)
>pkmap   : 0xbfe0 - 0xc000   (   2 MB)
>modules : 0xbf80 - 0xbfe0   (   6 MB)
>  .text : 0xc0008000 - 0xc0a35940   (10423 kB)
>  .init : 0xc0a36000 - 0xc0aa8000   ( 456 kB)
>  .data : 0xc0aa8000 - 0xc0b80558   ( 866 kB)
>   .bss : 0xc0b83000 - 0xc0c599e4   ( 859 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.10] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps 
> every 89478484971ns
> [0.27] clocksource: timer1: mask: 0x max_cycles: 
> 0x, max_idle_ns: 79635851949 ns
> [0.37] OMAP clocksource: timer1 at 2400 Hz
> [0.000278] Console: colour dummy device 80x30
> [0.000302] WARNING: Your 'console=ttyO0' has been replaced by 'ttyS0'
> [0.000308] This ensures that you still see kern

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[John Syne]

Hi Robert,

I was one of those users who uses Systemtap, but I always build my own kernel 
with debug symbols enabled, so I would recommend a standard kernel version 
without debug symbols and if you are up to it, add another build with a 
-dbg.deb kernel/modules version. Regarding the other kernel modules such as 
pwn, spidev, snd*(no audio on base BBB), c-can, etc, why not add these to the 
blacklist and have users remove those from the blacklist if they want these 
drivers available?
 
Regards,
John




> On Jul 19, 2016, at 10:10 AM, Robert Nelson  wrote:
> 
> 
> 
> On Tue, Jul 19, 2016 at 12:06 PM, William Hermans  > wrote:
> I think it's pretty well documented here. However you could always write up 
> an eLinux or whatever wiki page . . . I do have my own web page 
> http://www.embeddedhobbyist.com/  with 
> stuff on it that is important to me. But this information for using UIO on TI 
> kernels I feel is largely useless. Because 
> 
> The method for enabling either / or will likely change in the future.
> Right now, personally I'm still favoring *bone* kernels, and I know I'm not 
> alone.
> This is really a trivial "fix". Or something that is really easy to remember 
> how to do.
> 
> @Robert, any idea on if TI plans on cleaning up the kernel module mess that 
> now "infests" TI kernels ? using something like 50M + memory needlessly . . .
> 
> It's... debug_info..
> 
> CONFIG_DEBUG_INFO=y
> # CONFIG_DEBUG_INFO_REDUCED is not set
> CONFIG_DEBUG_INFO_SPLIT=y
> CONFIG_DEBUG_INFO_DWARF4=y
> 
> "atleast" the zImage isn't bloated, but the modules are 4x/5x bigger...
> 
> a few users wanted to use systemtap:
> 
> https://wiki.archlinux.org/index.php/SystemTap 
> 
> 
> that needs debug_info..
> 
> 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 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYiME9UPiBLcQyJ7UnMxK%2Bmz%3DWXVVWZWPBRxqabg%2B--YjA%40mail.gmail.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

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

[beagleboard] pasm to clpru porting guide for PRU

[Mark A. Yoder]

I'm converting some PRU assembly code from pasm to clpru and finding there 
are some differences.  An earlier thread 

 noted 
some differences between the two (Use LDI, not MOV for loading constants 
for example).

Has anyone made a porting guide?  For example:

#define CH1BIT r30.t8 
converts to
   .asgr30.t8, CH1BIT

Thanks...

--Mark

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

Re: [beagleboard] Re: cape-universal & 4.1.x = default.. ;)

[William Hermans]

I guess maybe the thing to do would be to edit the universalio overlay file
of choice. So that it did not touch the needed pins / peripherals used by a
given cape with eeprom.

On Tue, Jul 19, 2016 at 10:54 AM, William Hermans  wrote:

> SO, after talking with Robert and finding that all these kernel modules
> that get loaded from cape_universal=enable. I wonder how this impacts other
> capes such as the Logic supply RS232 / CAN cape that automatically loads
> it's own device tree  overlay.
>
> Could capes such as this be loaded first, and then still have universal-io
> capabilities ?
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/3cd02243-1ea4-4598-8552-ae3513aefd66%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

[beagleboard] Re: cape-universal & 4.1.x = default.. ;)

[William Hermans]

SO, after talking with Robert and finding that all these kernel modules 
that get loaded from cape_universal=enable. I wonder how this impacts other 
capes such as the Logic supply RS232 / CAN cape that automatically loads 
it's own device tree  overlay.

Could capes such as this be loaded first, and then still have universal-io 
capabilities ? 

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

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[William Hermans]

Ok, thanks Robert. I am really starting to warm up to universal-io. Never
had the chance, or reason to get it working before. Now . . . I'm using it
to test custom cape circuits, and all kind of things.

Plus I really do want to write that webpage GPIO / peripheral configuration
page . . . but that may still be a while yet. Still have many other
priorities . . . and much if it has nothing to do with computers.
Unfortunately.

On Tue, Jul 19, 2016 at 10:27 AM, Robert Nelson 
wrote:

>
>
> On Tue, Jul 19, 2016 at 12:24 PM, William Hermans 
> wrote:
>
>> Ah those! most of them come from loading the cape overlay...
>>> (cape_universal=enable)
>>>
>>> Regards,
>>
>> Seriously ? Wow I had no idea. Is this a requirement, or can it be
>> changed ?  Or . . .hmmm how could one modify this behavior so that only
>> what's needed is loaded. Other than my hackish fix. Or, do we need
>> cape_universal=enable to use universal-io ? I honestly have not
>> experimented with disabling cape_universal and temptation to use universal
>> IO.
>>
>
> So the cape_universal=enable, is just to hook to more easily
> disable/enable universal-io at bootup.
>
> But yeah, what universal-io does, "everything" inside the chip get's
> enabled, except for the pinmux-ing..  Which you control (the pinmuxing) in
> userspace..
>
> It's more reliable then loading/unloading individual peripherals, but it
> has a different cost (memory and possiblly power)
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpHZS1hMrE2422UpdSbjNYFvF7uSZChJ9OGS0pbzOHeCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Robert Nelson]

On Tue, Jul 19, 2016 at 12:24 PM, William Hermans  wrote:

> Ah those! most of them come from loading the cape overlay...
>> (cape_universal=enable)
>>
>> Regards,
>
> Seriously ? Wow I had no idea. Is this a requirement, or can it be changed
> ?  Or . . .hmmm how could one modify this behavior so that only what's
> needed is loaded. Other than my hackish fix. Or, do we need
> cape_universal=enable to use universal-io ? I honestly have not
> experimented with disabling cape_universal and temptation to use universal
> IO.
>

So the cape_universal=enable, is just to hook to more easily disable/enable
universal-io at bootup.

But yeah, what universal-io does, "everything" inside the chip get's
enabled, except for the pinmux-ing..  Which you control (the pinmuxing) in
userspace..

It's more reliable then loading/unloading individual peripherals, but it
has a different cost (memory and possiblly power)

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYiKAcfVyuK03GSZ_KUZVpTtY1Wv_2WMhuyxAFHRKYKjoQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[William Hermans]

temptation <--- wtf did that come from . . . dahm spell checker lol.
*attemtping
. . .*

On Tue, Jul 19, 2016 at 10:24 AM, William Hermans  wrote:

> Ah those! most of them come from loading the cape overlay...
>> (cape_universal=enable)
>>
>> Regards,
>
> Seriously ? Wow I had no idea. Is this a requirement, or can it be changed
> ?  Or . . .hmmm how could one modify this behavior so that only what's
> needed is loaded. Other than my hackish fix. Or, do we need
> cape_universal=enable to use universal-io ? I honestly have not
> experimented with disabling cape_universal and temptation to use universal
> IO.
>
>
> On Tue, Jul 19, 2016 at 10:17 AM, Robert Nelson 
> wrote:
>
>>
>>
>> On Tue, Jul 19, 2016 at 12:14 PM, William Hermans 
>> wrote:
>>
>>> Hi Robert,
>>>
>>> Well I mean this:
>>>
>>> william@beaglebone:~$ lsmod
>>> Module  Size  Used by
>>> xt_REDIRECT 1885  1
>>> nf_nat_redirect 1790  1 xt_REDIRECT
>>> xt_tcpudp   3091  1
>>> iptable_nat 1997  1
>>> nf_conntrack_ipv4  14735  1
>>> nf_defrag_ipv4  1677  1 nf_conntrack_ipv4
>>> nf_nat_ipv4 5392  1 iptable_nat
>>> nf_nat 15031  2 nf_nat_redirect,nf_nat_ipv4
>>> nf_conntrack   98575  3 nf_nat,nf_nat_ipv4,nf_conntrack_ipv4
>>> ip_tables  11986  1 iptable_nat
>>> x_tables   17435  3 ip_tables,xt_tcpudp,xt_REDIRECT
>>> rpcsec_gss_krb523814  0
>>> nfsd  261377  2
>>> spidev  7523  0
>>> omap_aes_driver19045  0
>>> omap_sham  21340  0
>>> uio_pruss   4928  0
>>> omap_rng4423  0
>>> rng_core7703  1 omap_rng
>>> pwm_tiehrpwm4706  0
>>> pwm_tiecap  3652  0
>>> tieqep  8758  0
>>> c_can_platform  6602  0
>>> c_can   9577  1 c_can_platform
>>> can_dev11820  1 c_can
>>> snd_soc_davinci_mcasp17079  0
>>> snd_soc_edma1290  1 snd_soc_davinci_mcasp
>>> snd_soc_omap3058  1 snd_soc_davinci_mcasp
>>> snd_soc_core  155549  3
>>> snd_soc_davinci_mcasp,snd_soc_edma,snd_soc_omap
>>> snd_pcm_dmaengine   5209  2 snd_soc_core,snd_soc_omap
>>> snd_pcm83341  4
>>> snd_soc_davinci_mcasp,snd_soc_core,snd_soc_omap,snd_pcm_dmaengine
>>> snd_timer  19788  1 snd_pcm
>>> snd59495  3 snd_soc_core,snd_timer,snd_pcm
>>> soundcore   7637  1 snd
>>> spi_omap2_mcspi11148  0
>>> evdev  10695  0
>>> uio_pdrv_genirq 3539  0
>>> uio 8822  2 uio_pruss,uio_pdrv_genirq
>>>
>>> Lots of stuff that really does not need to be loaded. That, and I'm not
>>> quite sure how these modules are loaded, and what's the best way to remove
>>> them. The fixes I have here: https://github.com/wphermans/bbb-cleanup I
>>> feel are hackish, and maybe somehow incomplete . . .
>>>
>>
>>
>> Ah those! most of them come from loading the cape overlay...
>> (cape_universal=enable)
>>
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpJ0FWUc2AEW2%2Bc%3DQaPLpJABaTEEe9PBk-Mc1O_o4NRmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[William Hermans]

>
> Ah those! most of them come from loading the cape overlay...
> (cape_universal=enable)
>
> Regards,

Seriously ? Wow I had no idea. Is this a requirement, or can it be changed
?  Or . . .hmmm how could one modify this behavior so that only what's
needed is loaded. Other than my hackish fix. Or, do we need
cape_universal=enable to use universal-io ? I honestly have not
experimented with disabling cape_universal and temptation to use universal
IO.


On Tue, Jul 19, 2016 at 10:17 AM, Robert Nelson 
wrote:

>
>
> On Tue, Jul 19, 2016 at 12:14 PM, William Hermans 
> wrote:
>
>> Hi Robert,
>>
>> Well I mean this:
>>
>> william@beaglebone:~$ lsmod
>> Module  Size  Used by
>> xt_REDIRECT 1885  1
>> nf_nat_redirect 1790  1 xt_REDIRECT
>> xt_tcpudp   3091  1
>> iptable_nat 1997  1
>> nf_conntrack_ipv4  14735  1
>> nf_defrag_ipv4  1677  1 nf_conntrack_ipv4
>> nf_nat_ipv4 5392  1 iptable_nat
>> nf_nat 15031  2 nf_nat_redirect,nf_nat_ipv4
>> nf_conntrack   98575  3 nf_nat,nf_nat_ipv4,nf_conntrack_ipv4
>> ip_tables  11986  1 iptable_nat
>> x_tables   17435  3 ip_tables,xt_tcpudp,xt_REDIRECT
>> rpcsec_gss_krb523814  0
>> nfsd  261377  2
>> spidev  7523  0
>> omap_aes_driver19045  0
>> omap_sham  21340  0
>> uio_pruss   4928  0
>> omap_rng4423  0
>> rng_core7703  1 omap_rng
>> pwm_tiehrpwm4706  0
>> pwm_tiecap  3652  0
>> tieqep  8758  0
>> c_can_platform  6602  0
>> c_can   9577  1 c_can_platform
>> can_dev11820  1 c_can
>> snd_soc_davinci_mcasp17079  0
>> snd_soc_edma1290  1 snd_soc_davinci_mcasp
>> snd_soc_omap3058  1 snd_soc_davinci_mcasp
>> snd_soc_core  155549  3
>> snd_soc_davinci_mcasp,snd_soc_edma,snd_soc_omap
>> snd_pcm_dmaengine   5209  2 snd_soc_core,snd_soc_omap
>> snd_pcm83341  4
>> snd_soc_davinci_mcasp,snd_soc_core,snd_soc_omap,snd_pcm_dmaengine
>> snd_timer  19788  1 snd_pcm
>> snd59495  3 snd_soc_core,snd_timer,snd_pcm
>> soundcore   7637  1 snd
>> spi_omap2_mcspi11148  0
>> evdev  10695  0
>> uio_pdrv_genirq 3539  0
>> uio 8822  2 uio_pruss,uio_pdrv_genirq
>>
>> Lots of stuff that really does not need to be loaded. That, and I'm not
>> quite sure how these modules are loaded, and what's the best way to remove
>> them. The fixes I have here: https://github.com/wphermans/bbb-cleanup I
>> feel are hackish, and maybe somehow incomplete . . .
>>
>
>
> Ah those! most of them come from loading the cape overlay...
> (cape_universal=enable)
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqksBTTUEJHgjFP1xT_wdsc4f3-eAX9bon07cA0YhF5Zw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[William Hermans]

Sorry Robert I did not mean to reply only directly to you . . . but also .
. .

a few users wanted to use systemtap:
>
> https://wiki.archlinux.org/index.php/SystemTap
>
> that needs debug_info..
>
>
So question about this. Are these few people more important than the rest
of the users out here ? Not meant as a smart ass question seriously. I mean
if I have to I can always compile my own kernel, but not everyone has the
know how.

My idea of of images and kernels for the beaglebone has always been
minimal. Nothing wrong with perhaps compiling with modules in mind,  but
keeping things standard so people can find out easily how to change these
image properly to get where they want to be. But that's my idea . . .


On Tue, Jul 19, 2016 at 10:14 AM, William Hermans  wrote:

> Hi Robert,
>
> Well I mean this:
>
> william@beaglebone:~$ lsmod
> Module  Size  Used by
> xt_REDIRECT 1885  1
> nf_nat_redirect 1790  1 xt_REDIRECT
> xt_tcpudp   3091  1
> iptable_nat 1997  1
> nf_conntrack_ipv4  14735  1
> nf_defrag_ipv4  1677  1 nf_conntrack_ipv4
> nf_nat_ipv4 5392  1 iptable_nat
> nf_nat 15031  2 nf_nat_redirect,nf_nat_ipv4
> nf_conntrack   98575  3 nf_nat,nf_nat_ipv4,nf_conntrack_ipv4
> ip_tables  11986  1 iptable_nat
> x_tables   17435  3 ip_tables,xt_tcpudp,xt_REDIRECT
> rpcsec_gss_krb523814  0
> nfsd  261377  2
> spidev  7523  0
> omap_aes_driver19045  0
> omap_sham  21340  0
> uio_pruss   4928  0
> omap_rng4423  0
> rng_core7703  1 omap_rng
> pwm_tiehrpwm4706  0
> pwm_tiecap  3652  0
> tieqep  8758  0
> c_can_platform  6602  0
> c_can   9577  1 c_can_platform
> can_dev11820  1 c_can
> snd_soc_davinci_mcasp17079  0
> snd_soc_edma1290  1 snd_soc_davinci_mcasp
> snd_soc_omap3058  1 snd_soc_davinci_mcasp
> snd_soc_core  155549  3
> snd_soc_davinci_mcasp,snd_soc_edma,snd_soc_omap
> snd_pcm_dmaengine   5209  2 snd_soc_core,snd_soc_omap
> snd_pcm83341  4
> snd_soc_davinci_mcasp,snd_soc_core,snd_soc_omap,snd_pcm_dmaengine
> snd_timer  19788  1 snd_pcm
> snd59495  3 snd_soc_core,snd_timer,snd_pcm
> soundcore   7637  1 snd
> spi_omap2_mcspi11148  0
> evdev  10695  0
> uio_pdrv_genirq 3539  0
> uio 8822  2 uio_pruss,uio_pdrv_genirq
>
> Lots of stuff that really does not need to be loaded. That, and I'm not
> quite sure how these modules are loaded, and what's the best way to remove
> them. The fixes I have here: https://github.com/wphermans/bbb-cleanup I
> feel are hackish, and maybe somehow incomplete . . .
>
> On Tue, Jul 19, 2016 at 10:10 AM, Robert Nelson 
> wrote:
>
>>
>>
>> On Tue, Jul 19, 2016 at 12:06 PM, William Hermans 
>> wrote:
>>
>>> I think it's pretty well documented here. However you could always write
>>> up an eLinux or whatever wiki page . . . I do have my own web page
>>> http://www.embeddedhobbyist.com/ with stuff on it that is important to
>>> me. But this information for using UIO on TI kernels I feel is largely
>>> useless. Because
>>>
>>> The method for enabling either / or will likely change in the future.
>>> Right now, personally I'm still favoring *bone* kernels, and I know I'm
>>> not alone.
>>> This is really a trivial "fix". Or something that is really easy to
>>> remember how to do.
>>>
>>> @Robert, any idea on if TI plans on cleaning up the kernel module mess
>>> that now "infests" TI kernels ? using something like 50M + memory
>>> needlessly . . .
>>>
>>
>> It's... debug_info..
>>
>> CONFIG_DEBUG_INFO=y
>> # CONFIG_DEBUG_INFO_REDUCED is not set
>> CONFIG_DEBUG_INFO_SPLIT=y
>> CONFIG_DEBUG_INFO_DWARF4=y
>>
>> "atleast" the zImage isn't bloated, but the modules are 4x/5x bigger...
>>
>> a few users wanted to use systemtap:
>>
>> https://wiki.archlinux.org/index.php/SystemTap
>>
>> that needs debug_info..
>>
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpfNC%2B_BhpbnFCfgfy-TmHi0ET53MeaFZXdqBm9hzMz8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Robert Nelson]

On Tue, Jul 19, 2016 at 12:06 PM, William Hermans  wrote:

> I think it's pretty well documented here. However you could always write
> up an eLinux or whatever wiki page . . . I do have my own web page
> http://www.embeddedhobbyist.com/ with stuff on it that is important to
> me. But this information for using UIO on TI kernels I feel is largely
> useless. Because
>
> The method for enabling either / or will likely change in the future.
> Right now, personally I'm still favoring *bone* kernels, and I know I'm
> not alone.
> This is really a trivial "fix". Or something that is really easy to
> remember how to do.
>
> @Robert, any idea on if TI plans on cleaning up the kernel module mess
> that now "infests" TI kernels ? using something like 50M + memory
> needlessly . . .
>

It's... debug_info..

CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
CONFIG_DEBUG_INFO_SPLIT=y
CONFIG_DEBUG_INFO_DWARF4=y

"atleast" the zImage isn't bloated, but the modules are 4x/5x bigger...

a few users wanted to use systemtap:

https://wiki.archlinux.org/index.php/SystemTap

that needs debug_info..

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYiME9UPiBLcQyJ7UnMxK%2Bmz%3DWXVVWZWPBRxqabg%2B--YjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to decide min_free_kbytes size for BBB based custom board embedded Linux board

[Robert Nelson]

On Tue, Jul 19, 2016 at 11:11 AM, Ankur Tank  wrote:

>
> We are using BeagleBoneBlack based custom Linux board.
> It has 256MB of RAM and 4GB of eMMC.
> Currently RFS size of the project is 163MB. While RFS partition size is
> 500MB.
> For testing, we added 20 number of big files(10MB size) and started
> firmware upgrade process.
>
> During the firmware Upgrade process we see following error when roofs is
> being written,
>
> We could solve it by changing
> /proc/sys/vm/min_free_kbytes
>
> from *2005* to *4096*.
>
> *But now my doubt is what should be the ideal value for that, what factors
> we should consider while calculating it. From the kernel documentation I
> don't get that information, *
> *but I could understand one thing that is this value can not be too low or
> too high or else system will break.*
>
> Any suggestion/pointer ?
>
> [ 6676.674219] mmcqd/1: page allocation failure: order:1, mode:
> 0x200020
> [ 6676.674256] CPU: 0 PID: 612 Comm: mmcqd/1 Tainted: P   O
> 3.12.10-005-ts-armv7l #2
> [ 6676.674321] [] (unwind_backtrace+0x0/0xf4) from [<
> c0011130>] (show_stack+0x10/0x14)
> [ 6676.674355] [] (show_stack+0x10/0x14) from [] (
> warn_alloc_failed+0xe0/0x118)
> [ 6676.674383] [] (warn_alloc_failed+0xe0/0x118) from [<
> c008a3ac>] (__alloc_pages_nodemask+0x74c/0x8f8)
> [ 6676.674413] [] (__alloc_pages_nodemask+0x74c/0x8f8) from
> [] (cache_alloc_refill+0x328/0x620)
> [ 6676.674436] [] (cache_alloc_refill+0x328/0x620) from [<
> c00b3224>] (__kmalloc+0xa0/0xe8)
> [ 6676.674471] [] (__kmalloc+0xa0/0xe8) from [] (
> edma_prep_slave_sg+0x84/0x388)
> [ 6676.674505] [] (edma_prep_slave_sg+0x84/0x388) from [<
> c02ec0a0>] (omap_hsmmc_request+0x414/0x508)
> [ 6676.674544] [] (omap_hsmmc_request+0x414/0x508) from [<
> c02d6748>] (mmc_start_request+0xc4/0xe0)
> [ 6676.674568] [] (mmc_start_request+0xc4/0xe0) from [<
> c02d7530>] (mmc_start_req+0x2d8/0x38c)
> [ 6676.674589] [] (mmc_start_req+0x2d8/0x38c) from [<
> c02e4818>] (mmc_blk_issue_rw_rq+0xb4/0x9d8)
> [ 6676.674611] [] (mmc_blk_issue_rw_rq+0xb4/0x9d8) from [<
> c02e52e0>] (mmc_blk_issue_rq+0x1a4/0x468)
> [ 6676.674631] [] (mmc_blk_issue_rq+0x1a4/0x468) from [<
> c02e5c68>] (mmc_queue_thread+0x88/0x118)
> [ 6676.674657] [] (mmc_queue_thread+0x88/0x118) from [<
> c004d8b8>] (kthread+0xb4/0xb8)
> [ 6676.674681] [] (kthread+0xb4/0xb8) from [] (
> ret_from_fork+0x14/0x3c)
>

This actually smells very much like the random mmc issues we saw on "3.8.x"
based images... mmc wasn't really fixed/solid till the 3.14.x timeline...
Not sure how much of that was back-ported to 3.12.10...

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYiYgrAkSP_%2BbK-9z-abNiyr%3DdzSDzVQ9dAasSRpGTcw1Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[William Hermans]

I think it's pretty well documented here. However you could always write up
an eLinux or whatever wiki page . . . I do have my own web page
http://www.embeddedhobbyist.com/ with stuff on it that is important to me.
But this information for using UIO on TI kernels I feel is largely useless.
Because

The method for enabling either / or will likely change in the future.
Right now, personally I'm still favoring *bone* kernels, and I know I'm not
alone.
This is really a trivial "fix". Or something that is really easy to
remember how to do.

@Robert, any idea on if TI plans on cleaning up the kernel module mess that
now "infests" TI kernels ? using something like 50M + memory needlessly . .
.



On Tue, Jul 19, 2016 at 9:52 AM, Joseph Heller 
wrote:

> Finally, that worked William (&John &Robert)! I did a small check with an
> LED and am able to with it on/off now via the PRU and uio.
>
> For your consideration, I wonder how you feel like to document this more
> structurally so others can benefit from it? I was offset by some older
> posts on the forum. Next thing I just though about is to make more use of
> the .deb functionality instead of relying on script or instructions. For
> instance uio "conflicts" with remoteproc in reality, but both reside on the
> same sd-card image. Otherwise, I also understood the PRU's are not that
> much used, so maybe it;s not worth the effort to invest in this.
>
> Anyway, thanks again for the help, I'd be glad to inform/post the end
> result of my project somewhere once my time-critical part of c code as
> transferred to the PRU.
>
> On Monday, July 18, 2016 at 10:30:35 PM UTC+2, William Hermans wrote:
>
>> Well, not to mention you installed a *bone* kernel anyhow. So what we're
>> talking about is really moot. e.g. a topic for a different discussion.
>>
>> So. . . back on topic . . .
>>
>> *Download suitable linu image and reboot:*
>> william@beaglebone:~$ sudo apt-get install linux-image-4.4.14-ti-r34
>> william@beaglebone:~$ sudo reboot
>>
>> *Install git and check your dtc version:*
>> william@beaglebone:~$ sudo apt-get install git
>> william@beaglebone:~$ dtc -v
>> Version: DTC 1.4.1
>>
>> *Clone the git into a suitable location:*
>> william@beaglebone:~$ cd dev
>> git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder
>> dtb-4.4-ti --depth=1
>> william@beaglebone:~/dev$ cd dtb-4.4-ti/
>>
>> *Edit the needed board file( this will be different for every situation )*
>> william@beaglebone:~/dev/dtb-4.4-ti$ nano
>> src/arm/am335x-boneblack-emmc-overlay.dts
>> change:
>> /* #include "am33xx-pruss-uio.dtsi" */
>> to:
>> #include "am33xx-pruss-uio.dtsi"
>>
>> *Build from source, and install the board file:*
>> william@beaglebone:~/dev/dtb-4.4-ti$ make
>> william@beaglebone:~/dev/dtb-4.4-ti$ sudo make install
>>
>> *Blacklist the remoteproc drivers:*
>> william@beaglebone:~/dev/dtb-rebuilder$ sudo nano
>> /etc/modprobe.d/pruss-blacklist.conf
>> blacklist pruss
>> blacklist pruss_intc
>> blacklist pru-rproc
>> william@beaglebone:~/dev$ sudo reboot
>>
>> *Test to see if the device tree file loaded successfully:*
>> william@beaglebone:~$ lsmod |grep  uio
>> uio_pruss   4928  0
>> uio_pdrv_genirq 3539  0
>> uio 8822  2 uio_pruss,uio_pdrv_genirq
>>
>> On Mon, Jul 18, 2016 at 1:12 PM, Robert Nelson 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jul 18, 2016 at 3:08 PM, Joseph Heller 
>>> wrote:
>>>
 small progress here;
 4.4.x-ti r34 did not result in any good (only remoteproc as far as I
 could tell), no uio.

 Therefore went for the bone version, non -rt:

 cd /opt/scripts/tools/
 sudo git pull
 sudo ./update_kernel.sh --bone-kernel --lts-4_4

 which gave me
 kernel 4.4.15-bone11

 and a new dmesg after loading my dtbo:
 [Mon Jul 18 19:44:48 2016] pruss_uio 4a30.pruss: pins are not
 configured from the driver
 [Mon Jul 18 19:44:49 2016] bone-pinmux-helper
 ocp:pinctrl_generated_pinmux: could not find pctdev for node
 /ocp/interrupt-controller@4820, deferring probe

>>>
>>> ^ looks like you aren't using the dtc compiler for v4.1.x+ targets..
>>>
>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYgfQYcKT89EihmpdnORK%3D7t9M3zG7gG1SozLtQpaTtQJA%40mail.gmail.com
>>> 
>>> .
>>>
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> For more options, visit http://beagleboard.org

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Robert Nelson]

Hi Joseph,

On Tue, Jul 19, 2016 at 11:52 AM, Joseph Heller 
wrote:

> Finally, that worked William (&John &Robert)! I did a small check with an
> LED and am able to with it on/off now via the PRU and uio.
>
> For your consideration, I wonder how you feel like to document this more
> structurally so others can benefit from it? I was offset by some older
> posts on the forum. Next thing I just though about is to make more use of
> the .deb functionality instead of relying on script or instructions. For
> instance uio "conflicts" with remoteproc in reality, but both reside on the
> same sd-card image. Otherwise, I also understood the PRU's are not that
> much used, so maybe it;s not worth the effort to invest in this.
>
> Anyway, thanks again for the help, I'd be glad to inform/post the end
> result of my project somewhere once my time-critical part of c code as
> transferred to the PRU.
>

So i'm hoping, this will only be short term.  I believe everyone at ti, now
has a crystal clear idea of what users want from the pruss interface.  So
hopefully this uio/remoteproc will get fixed..  A couple notes on the
script, normally the dtb-rebuilder repo can be found here:

/opt/source/dtb-4.4-ti/

It's just for a few releases, that didn't get cloned properly.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYjmZNvGAhgDnFo9EUJcpHKSMO0UMCysCrcUKBU_WLcHPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] How to decide min_free_kbytes size for BBB based custom board embedded Linux board

[William Hermans]

I'm not sure why you feel compelled to even bother playing with this. In
20-21 years of using Linux I've never had to set this manually. But . . .

https://www.google.com/search?q=%2Fproc%2Fsys%2Fvm%2Fmin_free_kbytes&ie=utf-8
>
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/s-memory-tunables.html
>

Be cautious when setting this parameter, as both too-low and too-high
> values can be damaging and break your system.
> Setting *min_free_kbytes* too low prevents the system from reclaiming
> memory. This can result in system hangs and OOM-killing multiple processes.
> However, setting this parameter to a value that is too high (5-10% of
> total system memory) will cause your system to become out-of-memory
> immediately. Linux is designed to use all available RAM to cache file
> system data. Setting a high *min_free_kbytes* value results in the system
> spending too much time reclaiming memory.
>



On Tue, Jul 19, 2016 at 9:11 AM, Ankur Tank  wrote:

>
> We are using BeagleBoneBlack based custom Linux board.
> It has 256MB of RAM and 4GB of eMMC.
> Currently RFS size of the project is 163MB. While RFS partition size is
> 500MB.
> For testing, we added 20 number of big files(10MB size) and started
> firmware upgrade process.
>
> During the firmware Upgrade process we see following error when roofs is
> being written,
>
> We could solve it by changing
> /proc/sys/vm/min_free_kbytes
>
> from *2005* to *4096*.
>
> *But now my doubt is what should be the ideal value for that, what factors
> we should consider while calculating it. From the kernel documentation I
> don't get that information, *
> *but I could understand one thing that is this value can not be too low or
> too high or else system will break.*
>
> Any suggestion/pointer ?
>
> [ 6676.674219] mmcqd/1: page allocation failure: order:1, mode:
> 0x200020
> [ 6676.674256] CPU: 0 PID: 612 Comm: mmcqd/1 Tainted: P   O
> 3.12.10-005-ts-armv7l #2
> [ 6676.674321] [] (unwind_backtrace+0x0/0xf4) from [<
> c0011130>] (show_stack+0x10/0x14)
> [ 6676.674355] [] (show_stack+0x10/0x14) from [] (
> warn_alloc_failed+0xe0/0x118)
> [ 6676.674383] [] (warn_alloc_failed+0xe0/0x118) from [<
> c008a3ac>] (__alloc_pages_nodemask+0x74c/0x8f8)
> [ 6676.674413] [] (__alloc_pages_nodemask+0x74c/0x8f8) from
> [] (cache_alloc_refill+0x328/0x620)
> [ 6676.674436] [] (cache_alloc_refill+0x328/0x620) from [<
> c00b3224>] (__kmalloc+0xa0/0xe8)
> [ 6676.674471] [] (__kmalloc+0xa0/0xe8) from [] (
> edma_prep_slave_sg+0x84/0x388)
> [ 6676.674505] [] (edma_prep_slave_sg+0x84/0x388) from [<
> c02ec0a0>] (omap_hsmmc_request+0x414/0x508)
> [ 6676.674544] [] (omap_hsmmc_request+0x414/0x508) from [<
> c02d6748>] (mmc_start_request+0xc4/0xe0)
> [ 6676.674568] [] (mmc_start_request+0xc4/0xe0) from [<
> c02d7530>] (mmc_start_req+0x2d8/0x38c)
> [ 6676.674589] [] (mmc_start_req+0x2d8/0x38c) from [<
> c02e4818>] (mmc_blk_issue_rw_rq+0xb4/0x9d8)
> [ 6676.674611] [] (mmc_blk_issue_rw_rq+0xb4/0x9d8) from [<
> c02e52e0>] (mmc_blk_issue_rq+0x1a4/0x468)
> [ 6676.674631] [] (mmc_blk_issue_rq+0x1a4/0x468) from [<
> c02e5c68>] (mmc_queue_thread+0x88/0x118)
> [ 6676.674657] [] (mmc_queue_thread+0x88/0x118) from [<
> c004d8b8>] (kthread+0xb4/0xb8)
> [ 6676.674681] [] (kthread+0xb4/0xb8) from [] (
> ret_from_fork+0x14/0x3c)
> [ 6676.674691] Mem-info:
> [ 6676.674700] Normal per-cpu:
> [ 6676.674711] CPU0: hi:   90, btch:  15 usd:  79
> [ 6676.674739] active_anon:4889 inactive_anon:13 isolated_anon:0
> [ 6676.674739]  active_file:8082 inactive_file:43196 isolated_file:0
> [ 6676.674739]  unevictable:422 dirty:2 writeback:1152 unstable:0
> [ 6676.674739]  free:3286 slab_reclaimable:1090 slab_unreclaimable:915
> [ 6676.674739]  mapped:1593 shmem:39 pagetables:181 bounce:0
> [ 6676.674739]  free_cma:1982
> [ 6676.674800] Normal free:13144kB min:2004kB low:2504kB high:3004kB
> active_anon:19556kB inactive_anon:52kB active_file:32328kB inactive_file:
> 172784kB unevictable:o
> [ 6676.674813] lowmem_reserve[]: 0 0 0
> [ 6676.674831] Normal: 2584*4kB (UMC) 217*8kB (C) 57*16kB (C) 5*32kB (
> C) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB =
> 13144kB
> [ 6676.674885] 51661 total pagecache pages
> [ 6676.674900] 0 pages in swap cache
> [ 6676.674910] Swap cache stats: add 0, delete 0, find 0/0
> [ 6676.674918] Free swap  = 0kB
> [ 6676.674925] Total swap = 0kB
> [ 6676.674938] SLAB: Unable to allocate memory on node 0 (gfp=0x20)
> [ 6676.674949]   cache: kmalloc-8192, object size: 8192, order: 1
> [ 6676.674962]   node 0: slabs: 3/3, objs: 3/3, free: 0
> [ 6676.674984] omap_hsmmc 481d8000.mmc: prep_slave_sg() failed
> [ 6676.674997] omap_hsmmc 481d8000.mmc: MMC start dma failure
> [ 6676.676181] mmcblk0: unknown error -1 sending read/write command,
> card status 0x900
>   

Re: [beagleboard] Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

Finally, that worked William (&John &Robert)! I did a small check with an 
LED and am able to with it on/off now via the PRU and uio. 

For your consideration, I wonder how you feel like to document this more 
structurally so others can benefit from it? I was offset by some older 
posts on the forum. Next thing I just though about is to make more use of 
the .deb functionality instead of relying on script or instructions. For 
instance uio "conflicts" with remoteproc in reality, but both reside on the 
same sd-card image. Otherwise, I also understood the PRU's are not that 
much used, so maybe it;s not worth the effort to invest in this.

Anyway, thanks again for the help, I'd be glad to inform/post the end 
result of my project somewhere once my time-critical part of c code as 
transferred to the PRU. 

On Monday, July 18, 2016 at 10:30:35 PM UTC+2, William Hermans wrote:
>
> Well, not to mention you installed a *bone* kernel anyhow. So what we're 
> talking about is really moot. e.g. a topic for a different discussion.
>
> So. . . back on topic . . .
>
> *Download suitable linu image and reboot:*
> william@beaglebone:~$ sudo apt-get install linux-image-4.4.14-ti-r34
> william@beaglebone:~$ sudo reboot
>
> *Install git and check your dtc version:*
> william@beaglebone:~$ sudo apt-get install git
> william@beaglebone:~$ dtc -v
> Version: DTC 1.4.1
>
> *Clone the git into a suitable location:*
> william@beaglebone:~$ cd dev
> git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder 
> dtb-4.4-ti --depth=1 
> william@beaglebone:~/dev$ cd dtb-4.4-ti/
>
> *Edit the needed board file( this will be different for every situation )*
> william@beaglebone:~/dev/dtb-4.4-ti$ nano 
> src/arm/am335x-boneblack-emmc-overlay.dts
> change:
> /* #include "am33xx-pruss-uio.dtsi" */
> to:
> #include "am33xx-pruss-uio.dtsi"
>
> *Build from source, and install the board file:*
> william@beaglebone:~/dev/dtb-4.4-ti$ make
> william@beaglebone:~/dev/dtb-4.4-ti$ sudo make install
>
> *Blacklist the remoteproc drivers:*
> william@beaglebone:~/dev/dtb-rebuilder$ sudo nano 
> /etc/modprobe.d/pruss-blacklist.conf
> blacklist pruss
> blacklist pruss_intc
> blacklist pru-rproc
> william@beaglebone:~/dev$ sudo reboot
>
> *Test to see if the device tree file loaded successfully:*
> william@beaglebone:~$ lsmod |grep  uio
> uio_pruss   4928  0
> uio_pdrv_genirq 3539  0
> uio 8822  2 uio_pruss,uio_pdrv_genirq
>
> On Mon, Jul 18, 2016 at 1:12 PM, Robert Nelson  > wrote:
>
>>
>>
>> On Mon, Jul 18, 2016 at 3:08 PM, Joseph Heller > > wrote:
>>
>>> small progress here; 
>>> 4.4.x-ti r34 did not result in any good (only remoteproc as far as I 
>>> could tell), no uio. 
>>>
>>> Therefore went for the bone version, non -rt:
>>>
>>> cd /opt/scripts/tools/
>>> sudo git pull
>>> sudo ./update_kernel.sh --bone-kernel --lts-4_4
>>>
>>> which gave me 
>>> kernel 4.4.15-bone11
>>>
>>> and a new dmesg after loading my dtbo: 
>>> [Mon Jul 18 19:44:48 2016] pruss_uio 4a30.pruss: pins are not 
>>> configured from the driver
>>> [Mon Jul 18 19:44:49 2016] bone-pinmux-helper 
>>> ocp:pinctrl_generated_pinmux: could not find pctdev for node 
>>> /ocp/interrupt-controller@4820, deferring probe
>>>
>>
>> ^ looks like you aren't using the dtc compiler for v4.1.x+ targets..
>>
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYgfQYcKT89EihmpdnORK%3D7t9M3zG7gG1SozLtQpaTtQJA%40mail.gmail.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

[beagleboard] Re: Building drivers without source on BBB

[ZeekHuge]

Hi Raul Piper,

You should probably not worry about the /lib/modules/4.1.22-bone21/ files.

But there might be a problem in your Makefile. You should try adding 'all' 
and 'clean' as PHONY targets in your makefile.
You can see this Makefile for reference : 
https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/examples/kernel_examples/n-blinky/module/Makefile

Good Luck 

On Tuesday, 19 July 2016 17:06:00 UTC+5:30, Raul Piper wrote:
>
>
> HI, 
> I am using this Makefile to build the kernel driver on the BBB 
> itself(already apt-get installed build-essenatials on it).
> obj-m += myDrvr.o
>
> all:
> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
>
> clean:
> make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
>
>
> But I am getting this error : 
> make -C /lib/modules/4.1.22-bone21/build 
> M=/home/ubuntu/bb/exploringBB/chp06/GPIO/tests/hello-linux-module modules
> Makefile:4: recipe for target 'all' failed
>
>
> I checked that inside ls -l /lib/modules/  there is 4.1.22-bone21 folder 
> is present which is symbolically linked with the build pointing to 
> /path_to_kernel_sources_on_pc_WHERE_I_BUILT_MY_KERNEL
>
> Is this some error I did while building the image for BBB.How can I 
> compile my kernel module?
>
> Thanks and Rgds,
> Rp
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/daa95f3f-8c1c-44f3-92c8-536db1a0f134%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel update to 4.4.15-ti-r35 failure

[Jason Kridner]

On Tue, Jul 19, 2016 at 10:58 AM Jason Kridner 
wrote:

> On Tue, Jul 19, 2016 at 9:37 AM Robert Nelson 
> wrote:
>
>> Hi Steve,
>>
>> On Tue, Jul 19, 2016 at 5:00 AM, Steve Osselton <
>> steve.ossel...@prismtech.com> wrote:
>>
>>> Hi,
>>>
>>> When updating the TI kernel from 4.4.14-ti-r34 to 4.4.15-ti-r35 on
>>> Debian 8.5, the kernel failed to
>>> boot cleanly. On connecting a console, the boot process failed in
>>> initramfs when trying to mount the
>>> real boot partition (the eMMC). The mount command from initramfs was
>>> complaining about invalid
>>> parameters. Any idea about what is causing this? Edited uEnv.txt to
>>> refer to the older kernel and
>>> re-booted ok, so was fixable.
>>>
>>
>> Sigh, yeah it's broken on my bbb too...
>>
>> with r34, i was chasing why the uuid=<> option was failing to find the
>> microSD card on the x15, i fixed that and pushed as r35..
>>
>
> Mainline u-boot seems to use a 'blkid' command to set the UUID. Does that
> work for X15?
>
>
>>
>> Then with r35, i noticed the eMMC on x15 had regressed (while the microSD
>> was working), which i fixed in r36, by pulling the patch from 4.5.x to hard
>> code microSD=mmc0, eMMC=mmc1...
>>
>> and now the bbb is broken.. blah...
>>
>
> FYI, it seems to have also broken WL1835 wifi over SDIO (mmc2).
>

OK, that wasn't the issue. ti-rt-r36 still fails with WL1835.

Useful debug output:

Jul 19 15:12:08 beaglebone kernel: omap_hsmmc 4781.mmc: card claims to
support voltages below defined range
.
.
.
Jul 19 15:12:08 beaglebone kernel: mmc2: error -16 whilst initialising SDIO
card


>
>>
>> So, i'll revert back to r34, but leave the 4.5.x hardcode in place for
>> the x15. ;)
>>
>
> I'll be looking for the build!
>
>
>>
>> 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.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/beagleboard/CAOCHtYi2%2B1GL_dBLySwAAgnd4bnOyot8i4njZe5UKmbqpRqMMQ%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CA%2BT6QPnY39c%3Dei5ugQ4tkx4S1PYHCAai2eyhhM%2BRPrFJc32V8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel update to 4.4.15-ti-r35 failure

[Robert Nelson]

On Tue, Jul 19, 2016 at 9:58 AM, Jason Kridner  wrote:

>
>
> On Tue, Jul 19, 2016 at 9:37 AM Robert Nelson 
> wrote:
>
>> Hi Steve,
>>
>> On Tue, Jul 19, 2016 at 5:00 AM, Steve Osselton <
>> steve.ossel...@prismtech.com> wrote:
>>
>>> Hi,
>>>
>>> When updating the TI kernel from 4.4.14-ti-r34 to 4.4.15-ti-r35 on
>>> Debian 8.5, the kernel failed to
>>> boot cleanly. On connecting a console, the boot process failed in
>>> initramfs when trying to mount the
>>> real boot partition (the eMMC). The mount command from initramfs was
>>> complaining about invalid
>>> parameters. Any idea about what is causing this? Edited uEnv.txt to
>>> refer to the older kernel and
>>> re-booted ok, so was fixable.
>>>
>>
>> Sigh, yeah it's broken on my bbb too...
>>
>> with r34, i was chasing why the uuid=<> option was failing to find the
>> microSD card on the x15, i fixed that and pushed as r35..
>>
>
> Mainline u-boot seems to use a 'blkid' command to set the UUID. Does that
> work for X15?
>

Debian Jessie era tools (sfdisk (util-linux 2.25.x) and mkfs.ext4
(e2fsprogs 1.42.12)) don't set the PARTUUID bit unless you force GPT which
breaks other things..

e2fsprogrs 1.43, can be backported to jessie, but you still need util-linux
2.27 (which needs a few more things backported)  *( i initially went down
this path yesterday, before giving up. ;) )


>
>
>>
>> Then with r35, i noticed the eMMC on x15 had regressed (while the microSD
>> was working), which i fixed in r36, by pulling the patch from 4.5.x to hard
>> code microSD=mmc0, eMMC=mmc1...
>>
>> and now the bbb is broken.. blah...
>>
>
> FYI, it seems to have also broken WL1835 wifi over SDIO (mmc2).
>

r37 is being built right now, so everything should be good again..


>
>
>>
>> So, i'll revert back to r34, but leave the 4.5.x hardcode in place for
>> the x15. ;)
>>
>
> I'll be looking for the build!
>


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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYijk555S-S92fxACVKmBR1h8yFgT%2BBa1jUgriFC4J8yRw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Kernel update to 4.4.15-ti-r35 failure

[Jason Kridner]

On Tue, Jul 19, 2016 at 9:37 AM Robert Nelson 
wrote:

> Hi Steve,
>
> On Tue, Jul 19, 2016 at 5:00 AM, Steve Osselton <
> steve.ossel...@prismtech.com> wrote:
>
>> Hi,
>>
>> When updating the TI kernel from 4.4.14-ti-r34 to 4.4.15-ti-r35 on Debian
>> 8.5, the kernel failed to
>> boot cleanly. On connecting a console, the boot process failed in
>> initramfs when trying to mount the
>> real boot partition (the eMMC). The mount command from initramfs was
>> complaining about invalid
>> parameters. Any idea about what is causing this? Edited uEnv.txt to refer
>> to the older kernel and
>> re-booted ok, so was fixable.
>>
>
> Sigh, yeah it's broken on my bbb too...
>
> with r34, i was chasing why the uuid=<> option was failing to find the
> microSD card on the x15, i fixed that and pushed as r35..
>

Mainline u-boot seems to use a 'blkid' command to set the UUID. Does that
work for X15?


>
> Then with r35, i noticed the eMMC on x15 had regressed (while the microSD
> was working), which i fixed in r36, by pulling the patch from 4.5.x to hard
> code microSD=mmc0, eMMC=mmc1...
>
> and now the bbb is broken.. blah...
>

FYI, it seems to have also broken WL1835 wifi over SDIO (mmc2).


>
> So, i'll revert back to r34, but leave the 4.5.x hardcode in place for the
> x15. ;)
>

I'll be looking for the build!


>
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/CAOCHtYi2%2B1GL_dBLySwAAgnd4bnOyot8i4njZe5UKmbqpRqMMQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Kernel update to 4.4.15-ti-r35 failure

[Robert Nelson]

Hi Steve,

On Tue, Jul 19, 2016 at 5:00 AM, Steve Osselton <
steve.ossel...@prismtech.com> wrote:

> Hi,
>
> When updating the TI kernel from 4.4.14-ti-r34 to 4.4.15-ti-r35 on Debian
> 8.5, the kernel failed to
> boot cleanly. On connecting a console, the boot process failed in
> initramfs when trying to mount the
> real boot partition (the eMMC). The mount command from initramfs was
> complaining about invalid
> parameters. Any idea about what is causing this? Edited uEnv.txt to refer
> to the older kernel and
> re-booted ok, so was fixable.
>

Sigh, yeah it's broken on my bbb too...

with r34, i was chasing why the uuid=<> option was failing to find the
microSD card on the x15, i fixed that and pushed as r35..

Then with r35, i noticed the eMMC on x15 had regressed (while the microSD
was working), which i fixed in r36, by pulling the patch from 4.5.x to hard
code microSD=mmc0, eMMC=mmc1...

and now the bbb is broken.. blah...

So, i'll revert back to r34, but leave the 4.5.x hardcode in place for the
x15. ;)

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYi2%2B1GL_dBLySwAAgnd4bnOyot8i4njZe5UKmbqpRqMMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Issues with Enabling SPIDev on Beaglebone Black

[Will Napier]

Thank you Vinay and Rudy for your replies. I am using the Kernel
Version 3.8.13-bone79.
 
I realised about the L thing after my last post - thank you Rudy, that
is encouraging that I have successfully disabled HDMI. I have added
the suggested line in /etc/default/capemgr
(CAPE=ADAFRUIT-SP0). Following earlier advice the only other line I
have in this file is:
 
CAPE=BB-SP1-01.
 
Is this correct for my purpose (ie simply and only to use the BBB to
flash the Lenovo ROM)?
 
After adding the line you suggested, I rebooted and this is what I now
get
in /sys/devices/bone_capemgr.9/slots:
 
 : 54:PF---
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI1-01
 
I am using the guide at
https://libreboot.org/docs/install/bbb_setup.html. In "Setting up
spidev on the BBB" it advises:
 
Log on as root on the BBB, using either SSH or a serial console as
defined in #bbb_access. Make sure that you have internet access on
your BBB.
 
 
Follow the instructions at
http://elinux.org/BeagleBone_Black_Enable_SPIDEV#SPI0 up to (and
excluding) the point where it tells you to modify uEnv.txt
 
 
I did this, entering the .dtbo in the recommended location (for
SP01). Here is my uEnv.txt:
 

 
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0
 
uname_r=3.8.13-bone79
##uuid=
#dtb=
 
##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just
#works..)
 
##BeagleBone Black: HDMI (Audio/Video) disabled:
#dtb=am335x-boneblack-emmc-overlay.dtb
 
##BeagleBone Black: eMMC disabled:
#dtb=am335x-boneblack-hdmi-overlay.dtb
 
##BeagleBone Black: HDMI Audio/eMMC disabled:
#dtb=am335x-boneblack-nhdmi-overlay.dtb
 
##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
#dtb=am335x-boneblack-overlay.dtb
 
##BeagleBone Black: wl1835
#dtb=am335x-boneblack-wl1835mod.dtb
 
##BeagleBone Black: replicape
am335x-boneblack-replicape.dtb
 
##BeagleBone Green: eMMC disabled
#dtb=am335x-bonegreen-overlay.dtb
 
cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd
cape_universal=enable
 
#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M quiet init=/lib/systemd/systemd
cape_universal=enable video=HDMI-A-1:1024x768@60e
 
##Example v3.8.x
#cape_disable=capemgr.disable_partno=
#cape_enable=capemgr.enable_partno=
 
##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
#cape_enable=bone_capemgr.enable_partno=
 
##Disable HDMI/eMMC (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-
BONE-EMMC-2G
 
##Disable HDMI (v3.8.x)
cape_disable=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
 
##Disable eMMC (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONE-EMMC-2G
 
##Audio Cape (needs HDMI Audio disabled) (v3.8.x)
#cape_disable=capemgr.disable_partno=BB-BONELT-HDMI
#cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02
 
 
##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh
 
uuid=c3048a42-5170-419f-ae71-6f96bf7f6f11
 
cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0
 
optargs=quiet drm.debug=7 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-
HDMIN
capemgr.enable_partno=BB-SPI1-01
 
===
 
 
So my current questions are:
 
I am not clear from the guide what SPI things to install. SP0 &
SP1-01? or just one of them?
 
Also should the optargs entry and the capemgr.enable_partno=BB-SP1-01
be present in that file, or removed?
 
Thank you Rudy for your files. I am not sure what to do with them. Given
what I have detailed above, do I need to do anything with them?
 
And a side-question about the slots listing at the top of this post,
number 4.. why does it say 2Gb not 4Gb? I'm pretty sure I have the
4Gb. Is it that there are 2x2?
 
With thanks to you all for invaluable help.
 
Will
 
 
On Mon, 18 Jul 2016, at 09:02 PM, w...@willnapier.com wrote:
> Hello all, I am new to BBB and using it to flash the ROM on my Lenovo
> Thinkpad T400 with Libreboot, using these[1] instructions on eLinux.
>
> I disabled HDMI on the Beaglebone by opening vi and removing the
> comment from the line that says it disables HDMI.
>
> I couldn't locate the uEnv.txt file at first, because there isn't a
> /lib/ directory. It was found in /boot/
>
> But when I did this, ie reboot and look, it seems that the HDMI is
> still there:
>
> root@beaglebone:/var/lib/cloud9# cat /sys/devices/bone_capemgr.*/slots
>  : 54:PF---
>  1: 55:PF---
>  2: 56:PF---
>  3: 57:PF---
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
> root@beaglebone:/var/lib/cloud9#
> 
>
> I have now tried the advice of Vinay:
>

[beagleboard] Building drivers without source on BBB

[Raul Piper]

HI, 
I am using this Makefile to build the kernel driver on the BBB 
itself(already apt-get installed build-essenatials on it).
obj-m += myDrvr.o

all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean


But I am getting this error : 
make -C /lib/modules/4.1.22-bone21/build 
M=/home/ubuntu/bb/exploringBB/chp06/GPIO/tests/hello-linux-module modules
Makefile:4: recipe for target 'all' failed


I checked that inside ls -l /lib/modules/  there is 4.1.22-bone21 folder is 
present which is symbolically linked with the build pointing to 
/path_to_kernel_sources_on_pc_WHERE_I_BUILT_MY_KERNEL

Is this some error I did while building the image for BBB.How can I compile 
my kernel module?

Thanks and Rgds,
Rp

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

[beagleboard] Re: Beaglebone black is not enumerating as ttyUSB0

[epcmorris]

The circuitry for the USB to UART cable is in the USB plug of the cable, so 
it should enumerate as /dev/ttyUSBx without plugging it into the board. If 
it doesn't appear then there is most likely an issue with the cable or the 
PC. If you run 
dmesg | tail 
on a terminal in Ubuntu a few seconds after plugging in the cable, you 
should be able to see if any errors are detected. You could also see if it 
is detected in Windows.

Hope this helps.

On Saturday, July 16, 2016 at 6:15:13 AM UTC+1, pointers...@gmail.com wrote:
>
>
> My setup :
>
> Ubuntu 14.04 LTS dual boot with windows 7.
>
>
> I connected usb power cable which is a 5 volt supply. I also connected a 
> usb to uart serial cable, and was able to see this to be as ttyUSB0 in 
> ubuntu few days back.
>
> After I did not see this ttyUSB0 only ttyACM0 (which I think is from usb 
> power cable).
>
>
> I have one doubt what is overcurrent?
>
>
> I checked what power usb to uart cable is getting and it was 5 volts. I 
> checked the voltage on serial header of beaglebone and it was 3.3 volts. 
> How ever I am not connecting red cable on beaglebone black. 
>
>
> I am unable to understand what exactly is the problem?
>
>
> Please respond anything related to it.
>

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

[beagleboard] Re: Issues with Enabling SPIDev on Beaglebone Black

[will]

Hello all, I am new to BBB. My eventual aim is to use the BBB to flash a 
rom with libreboot on my Lenovo Thinkpad. I am using this 
 guide at eLinux. It 
says that I need to disable HDMI before I can enable SPI.
I couldn't locate the uEnv.txt file at first, because there isn't a /lib/ 
directory. It was found in /boot/

But when I do this, ie reboot and look, it seems that the HDMI is still 
there:

root@beaglebone:/var/lib/cloud9# cat /sys/devices/bone_capemgr.*/slots
0: 54:PF--- 
1: 55:PF--- 
2: 56:PF--- 
3: 57:PF--- 
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
root@beaglebone:/var/lib/cloud9# 



I have now tried the advice of Vinay:

vinaydiv...@gmail.com 
19 Feb 
Another solution is also simple, just include the line "CAPE=ADAFRUIT-SP0" 
in /etc/default/capemgr file. Then reboot and all should work fine.


This did not work. I still get the same slots listing.

I then followed this advice also from vinay:

vinaydiv...@gmail.com 
16 May 
Re: [beagleboard] Re: Issues with Enabling SPIDev on Beaglebone Black
Other recipients: rudydelo...@gmail.com, jb...@eng.ucsd.edu 
Step 1 : Go to root@beaglebone: /boot#
Step 2 : Open uEnv.txt file
Step 3 : Inside the file

You will find these lines, so do the following: In case If you dont find 
these lines for your kernel, then just append the line 
"cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0" to the end of the file.

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0

Step 4 : Reboot your BBB
Step 5 : Go to /sys/devices/platform/bone_capemgr# cat slots or dmesg to 
check.

Then check if your SPI device has been loaded.

This works with Linux beaglebone kernel 4.1.18-ti-r53

===

This didn't work. there is no /sys/devices/platform/bone_capemgr. 

I hope that given the limited purpose of using BBB I won't need to learn a 
whole lot about embedded systems, device tree overlays, etc, just in order 
to do flash my rom, however interesting it is!

Any help greatly appreciated. Will.


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

Re: [beagleboard] Re: Issues with Enabling SPIDev on Beaglebone Black

[will]

Hello all, I am new to BBB and using it to flash the ROM on my Lenovo 
Thinkpad T400 with Libreboot, using these 
 instructions on 
eLinux.

I disabled HDMI on the Beaglebone by opening vi and removing the comment 
from the line that says it disables HDMI.

I couldn't locate the uEnv.txt file at first, because there isn't a /lib/ 
directory. It was found in /boot/

But when I did this, ie reboot and look, it seems that the HDMI is still 
there:

root@beaglebone:/var/lib/cloud9# cat /sys/devices/bone_capemgr.*/slots
0: 54:PF--- 
1: 55:PF--- 
2: 56:PF--- 
3: 57:PF--- 
4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
root@beaglebone:/var/lib/cloud9# 



I have now tried the advice of Vinay:


Another solution is also simple, just include the line "CAPE=ADAFRUIT-SP0" 
in /etc/default/capemgr file. Then reboot and all should work fine.




This did not work. I still get the same slots listing.

I then followed this advice also from vinay:


Re: [beagleboard] Re: Issues with Enabling SPIDev on Beaglebone Black
Other recipients: rudydelo...@gmail.com, jb...@eng.ucsd.edu 
Step 1 : Go to root@beaglebone: /boot#
Step 2 : Open uEnv.txt file
Step 3 : Inside the file

You will find these lines, so do the following: In case If you dont find 
these lines for your kernel, then just append the line 
"cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0" to the end of the file.

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0

Step 4 : Reboot your BBB
Step 5 : Go to /sys/devices/platform/bone_capemgr# cat slots or dmesg to 
check.

Then check if your SPI device has been loaded.

This works with Linux beaglebone kernel 4.1.18-ti-r53

===

This didn't work. there is no /sys/devices/platform/bone_capemgr.


I would be very grateful for any help with this. With thanks, Will

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f55ac74f-155f-4536-8e0d-49e471e6f044%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: cryptsetup / LUKS disk encryption on Debian not working

[mr . renjithr]

Hai friend,
 Please try to execute the command as root user or use sudo command

On Wednesday, 23 July 2014 00:37:07 UTC+5:30, Niko Heeren wrote:
>
> Hello
>
> I am trying to encrypt a USB drive using the BBB and Debian wheezy (Kernel 
> 3.8.13-bone20).
>
> So the command I try is:
> cryptsetup --verbose --verify-passphrase luksFormat /dev/sda1
>
> However I get the following errors:
> Failure to communicate with kernel device-mapper driver.
> Check that device-mapper is available in the kernel.
> Cannot initialize device-mapper. Is dm_mod kernel module loaded?
> Command failed with code 38: Cannot initialize device-mapper. Is dm_mod 
> kernel module loaded?
>
> As far as my limited Linux knowledge tells me, the respective kernel 
> modules are not part of my kernel. Is that correct? Is there an easy way to 
> make this work? Or do you see alternatives to encrypt USB drives?
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/d448bfef-02a8-44ef-9a2b-fd2a4d1069bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Issues with Enabling SPIDev on Beaglebone Black

[Rudy Misek]

I've attached the SPI device tree files I used.

Hope this help ya out!!

On Tue, Jul 19, 2016 at 12:47 PM, Rudy Misek 
wrote:

> Whats crack'n Vinay!! Looks to me like Wheezy.
>
> Hey Will,
> 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
> 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
> The L in P-O-L means loaded, so in the case above it's telling you that
> the HDMI hasn't been loaded. So you've successfully disabled it.
>
> When you do this
> "Another solution is also simple, just include the line
> "CAPE=ADAFRUIT-SP0" in /etc/default/capemgr file. Then reboot and all
> should work fine"
> You'll have to do both, disable the HDMI like you've done (if you want to
> use SPI1) and load the SPI dtbo like in the step above.
> You should then see it loaded when you cat the slots. Below is what mine
> looks like (I have a few different things loaded, but you can see that the
> HDMI has been disabled and both SPI's loaded)
>
> root@beaglebone:/sys/devices# cd /sys/devices/bone_capemgr.*
> root@beaglebone:/sys/devices/bone_capemgr.9# cat slots
>  0: 54:PF---
>  1: 55:PF---
>  2: 56:PF---
>  3: 57:PF---
>  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>  6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>  7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI0-01
>  8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI1-01
>  9: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART1
> 10: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
> 11: ff:P-O-L Override Board Name,00A0,Override Manuf,AEI-UART5
> 12: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_32_f
> 13: ff:P-O-L Override Board Name,00A0,Override Manuf,am33xx_pwm
> 14: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_pwm_P9_16
> root@beaglebone:/sys/devices/bone_capemgr.9#
>
>
> check for 'spidev1.x' in /dev
> e.g
> root@beaglebone:~# cd /dev
> root@beaglebone:/dev# ls
>
> If spidev is in there, you successfully loaded the SPI
>
> This is the version of linux I'm running on my BBB
> root@beaglebone:~# uname -a
> Linux beaglebone 3.8.13-bone79 #1 SMP Tue Oct 13 20:44:55 UTC 2015 armv7l
> GNU/Linux
>
>
>
>
>
> On Tue, Jul 19, 2016 at 11:11 AM, Vinay Divakar <
> vinaydivakar1...@gmail.com> wrote:
>
>> Can you provide info about the kernel your using?
>>
>> On 18 July 2016 at 13:02,  wrote:
>>
>>> Hello all, I am new to BBB and using it to flash the ROM on my Lenovo
>>> Thinkpad T400 with Libreboot, using these
>>>  instructions on
>>> eLinux.
>>>
>>> I disabled HDMI on the Beaglebone by opening vi and removing the comment
>>> from the line that says it disables HDMI.
>>>
>>> I couldn't locate the uEnv.txt file at first, because there isn't a
>>> /lib/ directory. It was found in /boot/
>>>
>>> But when I did this, ie reboot and look, it seems that the HDMI is still
>>> there:
>>>
>>> root@beaglebone:/var/lib/cloud9# cat /sys/devices/bone_capemgr.*/slots
>>> 0: 54:PF---
>>> 1: 55:PF---
>>> 2: 56:PF---
>>> 3: 57:PF---
>>> 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>>> 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>>> 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>>> root@beaglebone:/var/lib/cloud9#
>>>
>>> 
>>>
>>> I have now tried the advice of Vinay:
>>>
>>>
>>> Another solution is also simple, just include the line
>>> "CAPE=ADAFRUIT-SP0" in /etc/default/capemgr file. Then reboot and all
>>> should work fine.
>>>
>>> 
>>>
>>>
>>> This did not work. I still get the same slots listing.
>>>
>>> I then followed this advice also from vinay:
>>> 
>>>
>>> Re: [beagleboard] Re: Issues with Enabling SPIDev on Beaglebone Black
>>> Other recipients: rudydelo...@gmail.com, jb...@eng.ucsd.edu
>>> Step 1 : Go to root@beaglebone: /boot#
>>> Step 2 : Open uEnv.txt file
>>> Step 3 : Inside the file
>>>
>>> You will find these lines, so do the following: In case If you dont find
>>> these lines for your kernel, then just append the line
>>> "cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0" to the end of the file.
>>>
>>> ##Example v4.1.x
>>> #cape_disable=bone_capemgr.disable_partno=
>>> cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0
>>>
>>> Step 4 : Reboot your BBB
>>> Step 5 : Go to /sys/devices/platform/bone_capemgr# cat slots or dmesg to
>>> check.
>>>
>>> Then check if your SPI device has been loaded.
>>>
>>> This works with Linux beaglebone kernel 4.1.18-ti-r53
>>>
>>> ===
>>>
>>> This didn't work. there is no /sys/devices/platform/bone_capemgr.
>>>
>>>
>>> I would be very grateful for any help with this. With thanks, Will
>>>
>>>
>>
>

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

Re: [beagleboard] Re: Issues with Enabling SPIDev on Beaglebone Black

[Rudy Misek]

Whats crack'n Vinay!! Looks to me like Wheezy.

Hey Will,
5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
The L in P-O-L means loaded, so in the case above it's telling you that the
HDMI hasn't been loaded. So you've successfully disabled it.

When you do this
"Another solution is also simple, just include the line "CAPE=ADAFRUIT-SP0"
in /etc/default/capemgr file. Then reboot and all should work fine"
You'll have to do both, disable the HDMI like you've done (if you want to
use SPI1) and load the SPI dtbo like in the step above.
You should then see it loaded when you cat the slots. Below is what mine
looks like (I have a few different things loaded, but you can see that the
HDMI has been disabled and both SPI's loaded)

root@beaglebone:/sys/devices# cd /sys/devices/bone_capemgr.*
root@beaglebone:/sys/devices/bone_capemgr.9# cat slots
 0: 54:PF---
 1: 55:PF---
 2: 56:PF---
 3: 57:PF---
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI0-01
 8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPI1-01
 9: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART1
10: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4
11: ff:P-O-L Override Board Name,00A0,Override Manuf,AEI-UART5
12: ff:P-O-L Override Board Name,00A0,Override Manuf,bspm_P8_32_f
13: ff:P-O-L Override Board Name,00A0,Override Manuf,am33xx_pwm
14: ff:P-O-L Override Board Name,00A0,Override Manuf,bone_pwm_P9_16
root@beaglebone:/sys/devices/bone_capemgr.9#


check for 'spidev1.x' in /dev
e.g
root@beaglebone:~# cd /dev
root@beaglebone:/dev# ls

If spidev is in there, you successfully loaded the SPI

This is the version of linux I'm running on my BBB
root@beaglebone:~# uname -a
Linux beaglebone 3.8.13-bone79 #1 SMP Tue Oct 13 20:44:55 UTC 2015 armv7l
GNU/Linux





On Tue, Jul 19, 2016 at 11:11 AM, Vinay Divakar 
wrote:

> Can you provide info about the kernel your using?
>
> On 18 July 2016 at 13:02,  wrote:
>
>> Hello all, I am new to BBB and using it to flash the ROM on my Lenovo
>> Thinkpad T400 with Libreboot, using these
>>  instructions on
>> eLinux.
>>
>> I disabled HDMI on the Beaglebone by opening vi and removing the comment
>> from the line that says it disables HDMI.
>>
>> I couldn't locate the uEnv.txt file at first, because there isn't a /lib/
>> directory. It was found in /boot/
>>
>> But when I did this, ie reboot and look, it seems that the HDMI is still
>> there:
>>
>> root@beaglebone:/var/lib/cloud9# cat /sys/devices/bone_capemgr.*/slots
>> 0: 54:PF---
>> 1: 55:PF---
>> 2: 56:PF---
>> 3: 57:PF---
>> 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
>> 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
>> 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
>> root@beaglebone:/var/lib/cloud9#
>>
>> 
>>
>> I have now tried the advice of Vinay:
>>
>>
>> Another solution is also simple, just include the line
>> "CAPE=ADAFRUIT-SP0" in /etc/default/capemgr file. Then reboot and all
>> should work fine.
>>
>> 
>>
>>
>> This did not work. I still get the same slots listing.
>>
>> I then followed this advice also from vinay:
>> 
>>
>> Re: [beagleboard] Re: Issues with Enabling SPIDev on Beaglebone Black
>> Other recipients: rudydelo...@gmail.com, jb...@eng.ucsd.edu
>> Step 1 : Go to root@beaglebone: /boot#
>> Step 2 : Open uEnv.txt file
>> Step 3 : Inside the file
>>
>> You will find these lines, so do the following: In case If you dont find
>> these lines for your kernel, then just append the line
>> "cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0" to the end of the file.
>>
>> ##Example v4.1.x
>> #cape_disable=bone_capemgr.disable_partno=
>> cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0
>>
>> Step 4 : Reboot your BBB
>> Step 5 : Go to /sys/devices/platform/bone_capemgr# cat slots or dmesg to
>> check.
>>
>> Then check if your SPI device has been loaded.
>>
>> This works with Linux beaglebone kernel 4.1.18-ti-r53
>>
>> ===
>>
>> This didn't work. there is no /sys/devices/platform/bone_capemgr.
>>
>>
>> I would be very grateful for any help with this. With thanks, Will
>>
>>
>

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

Re: [beagleboard] Re: Issues with Enabling SPIDev on Beaglebone Black

[Vinay Divakar]

Can you provide info about the kernel your using?

On 18 July 2016 at 13:02,  wrote:

> Hello all, I am new to BBB and using it to flash the ROM on my Lenovo
> Thinkpad T400 with Libreboot, using these
>  instructions on
> eLinux.
>
> I disabled HDMI on the Beaglebone by opening vi and removing the comment
> from the line that says it disables HDMI.
>
> I couldn't locate the uEnv.txt file at first, because there isn't a /lib/
> directory. It was found in /boot/
>
> But when I did this, ie reboot and look, it seems that the HDMI is still
> there:
>
> root@beaglebone:/var/lib/cloud9# cat /sys/devices/bone_capemgr.*/slots
> 0: 54:PF---
> 1: 55:PF---
> 2: 56:PF---
> 3: 57:PF---
> 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
> 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
> 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN
> root@beaglebone:/var/lib/cloud9#
>
> 
>
> I have now tried the advice of Vinay:
>
>
> Another solution is also simple, just include the line "CAPE=ADAFRUIT-SP0"
> in /etc/default/capemgr file. Then reboot and all should work fine.
>
> 
>
>
> This did not work. I still get the same slots listing.
>
> I then followed this advice also from vinay:
> 
>
> Re: [beagleboard] Re: Issues with Enabling SPIDev on Beaglebone Black
> Other recipients: rudydelo...@gmail.com, jb...@eng.ucsd.edu
> Step 1 : Go to root@beaglebone: /boot#
> Step 2 : Open uEnv.txt file
> Step 3 : Inside the file
>
> You will find these lines, so do the following: In case If you dont find
> these lines for your kernel, then just append the line
> "cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0" to the end of the file.
>
> ##Example v4.1.x
> #cape_disable=bone_capemgr.disable_partno=
> cape_enable=bone_capemgr.enable_partno=BB-SPIDEV0
>
> Step 4 : Reboot your BBB
> Step 5 : Go to /sys/devices/platform/bone_capemgr# cat slots or dmesg to
> check.
>
> Then check if your SPI device has been loaded.
>
> This works with Linux beaglebone kernel 4.1.18-ti-r53
>
> ===
>
> This didn't work. there is no /sys/devices/platform/bone_capemgr.
>
>
> I would be very grateful for any help with this. With thanks, Will
>
>

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

[beagleboard] Kernel update to 4.4.15-ti-r35 failure

[Steve Osselton]

Hi,

When updating the TI kernel from 4.4.14-ti-r34 to 4.4.15-ti-r35 on Debian 
8.5, the kernel failed to
boot cleanly. On connecting a console, the boot process failed in initramfs 
when trying to mount the
real boot partition (the eMMC). The mount command from initramfs was 
complaining about invalid
parameters. Any idea about what is causing this? Edited uEnv.txt to refer 
to the older kernel and
re-booted ok, so was fixable.

Cheers Steve.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3ee4e1ff-a968-4447-946b-2f80cb70f6ee%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.