[beagleboard] Re: beaglebone rc_startup_routine[1278]: timeout reached while waiting for pwm driver

[laytonhu]

Thank you! If possible, could you please give me more detailed instruction 
on how to solve this? Maybe some links would be very helpful!

On Monday, May 6, 2019 at 5:09:27 AM UTC-7, ithinu wrote:
>
> It was something like new OS on an sd card, but something outdated in the 
> booting sequence on the EEPROM and I needed to fill the latter with 
> zeros... something strange like that if I remember well.
>
> On Monday, May 6, 2019 at 1:58:10 PM UTC+2, layt...@gmail.com wrote:
>>
>> Hello, I have the same problem here so I cannot run on boot either. Have 
>> you solved this problem? 
>> I'm looking forward to hearing from you, thank you!
>>
>> On Monday, January 14, 2019 at 5:21:43 AM UTC-8, ith...@gmail.com wrote:
>>>
>>> I use 
>>> http://strawsondesign.com/docs/images/BBB-blank-debian-9.5-iot-armhf-2018-10-07-4gb.img.xz
>>>  
>>> from http://strawsondesign.com/docs/librobotcontrol/flashing.html. I 
>>> flashed it into the built-in eMMc as the page told that it is better so.
>>>
>>> Then I configured librobotcontrol to use rc_balance as told here 
>>> http://strawsondesign.com/#!edumip-software, which gave an error:
>>>
>>> $ systemctl status robotcontrol.service
>>> ● robotcontrol.service - robotcontrol
>>>Loaded: loaded (/lib/systemd/system/robotcontrol.service; enabled; 
>>> vendor preset: enabled)
>>>Active: failed (Result: exit-code) since Sun 2018-10-07 16:42:07 UTC; 
>>> 13s ago
>>>   Process: 1278 ExecStartPre=/usr/bin/rc_startup_routine (code=exited, 
>>> status=255)
>>>
>>> Oct 07 16:42:06 beaglebone systemd[1]: Starting robotcontrol...
>>> Oct 07 16:42:07 beaglebone rc_startup_routine[1278]: timeout reached 
>>> while waiting for pwm driver
>>> Oct 07 16:42:07 beaglebone rc_startup_routine[1278]: TIMEOUT REACHED
>>> Oct 07 16:42:07 beaglebone systemd[1]: robotcontrol.service: Control 
>>> process exited, code=exited status=255
>>> Oct 07 16:42:07 beaglebone systemd[1]: Failed to start robotcontrol.
>>> Oct 07 16:42:07 beaglebone systemd[1]: robotcontrol.service: Unit 
>>> entered failed state.
>>> Oct 07 16:42:07 beaglebone systemd[1]: robotcontrol.service: Failed with 
>>> result 'exit-code'.
>>>
>>> $ uname -a
>>> Linux beaglebone 4.14.71-ti-r80 #1 SMP PREEMPT Fri Oct 5 23:50:11 UTC 
>>> 2018 armv7l GNU/Linux
>>>
>>> I guess the hardware is ok, as I previously used some old image from 
>>> https://www.hackster.io/edumip/edumip-13a29c and rc_balance was fine.
>>>
>>>

-- 
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/c0127e8c-8747-4267-a020-c15c02785d47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: libpruio (fast and easy D/A - I/O)

[Hans Leeuw]

>
> Hi TJF,
>

It is not the impedance I think, but it was interesting to go back to the 
normal io example 1.c. The behaviour is different. Output when using that 
example (but without leftshift):

00000000
  C37   13  9B75  199  E340  1A4
  C3B   13  9B75  199  E360  1A5
  C37   12  9BD5  197  E360  1A4
  C37   11  9B85  199  E340  1A5
  C38   13  9B75  199  E360  1A5
  C37   13  9BA4  197  E350  1A5
  C37   12  9BA4  197  E350  1A5
  C37   12  9B74  197  E350  1A5
  C37   12  9B75  197  E350  1A5
  C37   12  9B75  197  E350  1A5
  C37   12  9B75  197  E350  1A5
  C37   12  9B75  197  E350  1A5 

So that is ok!!!
But now, when adapting the syntax and using ringbuffer mode (and I hope I 
did the syntax ok):

#include "stdio.h"
#include "libpruio/pruio.h" // include header
#include 

int main(int argc, char **argv)
{
int i, n;
pruIo *io = pruio_new(PRUIO_DEF_ACTIVE, 4, 0x98, 0);

  pruio_adc_setStep(io, 7, 0, 1, 0, 0);//Step 1, AIN-0
  pruio_adc_setStep(io, 8, 1, 1, 0, 0);   //Step 2, AIN-1
  pruio_adc_setStep(io, 9, 2, 1, 0, 0);   //Step 3, AIN-2
  pruio_adc_setStep(io, 10, 3, 1, 0, 0);//Step 4, AIN-3
  pruio_adc_setStep(io, 11, 4, 1, 0, 0);   //Step 5, AIN-4
  pruio_adc_setStep(io, 12, 5, 1, 0, 0);//Step 6, AIN-5
  pruio_adc_setStep(io, 13, 6, 1, 0, 0);   //Step 7, AIN-6
  pruio_adc_setStep(io, 14, 7, 1, 0, 0);   //Step 8, AIN-7
  
if (pruio_config(io, 220500, 255<<7 , 45352, 0)){ // upload (default) 
settings, start IO mode
   printf("config failed (%s)\n", io->Errr);}  
if (pruio_rb_start(io)) printf("rb_start failed (%s)\n", io->Errr); // 
start measurement   //Starts in rb_mode
printf("initialized\n");
usleep(1);
/* now current ADC samples are available for AIN-0 to AIN-7 in array 
io->Adc->Value[] */
for(n = 1; n <= 13; n++) { //   print some lines
for(i = 0; i < 8; i++) //all steps
 printf(" %4X", io->Adc->Value[i + (8 * n)]); //  output one 
channel in hex
printf("\n"); // next line
}
/* we're done */
   pruio_destroy(io);/* destroy driver structure */
   return 0;
}

output:

  8EF   B7  477F  10F  E3F   47  19F
  72F   A7  357F  117  E3F   4F  1A3
  60F   97  2DF   13  11B  E3F   4F  1A3
  557   8F  2B7   17  11F  E3F   4F  1A7
  4DF   8F  2A7   17  11F  E3F   4F  1A7
  49F   7F  29F   17  127  E3F   4F  1A7
  477   7F  29F   17  127  E3F   4F  1A7
  45F   7F  29F   17  127  E4F   53  1A7
  44F   7F  29F   17  127  E3F   4F  1A7
  447   7F  29F   17  127  E3F   4F  1A7
  43F   7F  29F   17  127  E3F   53  1A7
  43F   7F  29F   1B  127  E3F   53  1A7
  43F   7F  29F   17  127  E3F   53  1A7

There are definitely some interesting differences in the output. Loose from 
the  difference in resolution some of the inputs (Ain-0, Ain-1, Ain-2, 
Ain-6) cause very different output from the values that come from the 
minimal code ADC example while Ain-3, Ain-4, Ain-5, Ain-7 are more or less 
the same except for the resolution thing. (Pull-down activated in the 
minimal example?). The battery is connected to Ain-5 in both situations 
using a 10kΩ potmeter on that channel, the other channels are floating so 
maybe we should not pay too much attention to the absolute differences but 
we do see that the resolution thing seems connected to rb-mode unless my 
syntax is false.

Looking for a clue...

Best, Hans.

-- 
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/f70258ef-5c00-483d-ac8a-a4438b78ea0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: DS1820 on wire temp sensor using U-boot, kernel 4.14.71-ti-r80

[Jim F]

If you decide instead to try to get 1 W working with drivers, we failed at
it on 4.14. Something changed on the way to 4.19 and we got it working
there. If I had notes to share I would...if I find them.

Jim

On Tue, May 7, 2019, 10:46 AM TJF  Hi!
>
> When using the libpruw1 driver
>  you
> won't need any device tree overlay . This driver uses libpruio
> 
> for pinmuxing. Specify any (free) header pin in your source code for the W1
> bus. The driver handles more than a single DS18S20 at this bus. Multiple
> sensors can measure simultanuosly. The driver also provides a logging
> feature to measure the bus state over a certain time period (for wiring
> tests). Examples are included in GIT repo.
>
> Regards
>
> --
> 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/2a5fb489-dd03-43bd-a487-cab7d55378b6%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/CAGS%2B2h_L8g8MySpyELq71GfchxC5wpUHVT6FvUdkY-nbAr-SJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: DS1820 on wire temp sensor using U-boot, kernel 4.14.71-ti-r80

[walterc]

Jim - I think it would be a good exercise to do it with the drivers too.  I 
compiled a dtbo file but I am such a novice at this.  Where do I put that 
file so it loads on boot?  Is there anything else I need to do to get it to 
load and how can I confirm that it loaded? (

It's been two decades since I did this kind of work and a lot has changed 
to say the least!)  

On Tuesday, May 7, 2019 at 2:35:36 PM UTC-4, Jim F wrote:
>
> If you decide instead to try to get 1 W working with drivers, we failed at 
> it on 4.14. Something changed on the way to 4.19 and we got it working 
> there. If I had notes to share I would...if I find them.
>
> Jim 
>
> On Tue, May 7, 2019, 10:46 AM TJF  
> wrote:
>
>> Hi!
>>
>> When using the libpruw1 driver 
>>  you 
>> won't need any device tree overlay . This driver uses libpruio 
>>  
>> for pinmuxing. Specify any (free) header pin in your source code for the W1 
>> bus. The driver handles more than a single DS18S20 at this bus. Multiple 
>> sensors can measure simultanuosly. The driver also provides a logging 
>> feature to measure the bus state over a certain time period (for wiring 
>> tests). Examples are included in GIT repo.
>>
>> Regards
>>
>> -- 
>> 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 beagl...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/2a5fb489-dd03-43bd-a487-cab7d55378b6%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/fa22f1a1-f5c4-4b41-b750-6a7b5794a7f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: DS1820 on wire temp sensor using U-boot, kernel 4.14.71-ti-r80

[walterc]

Thanks!  I'll check this out!

On Tuesday, May 7, 2019 at 10:46:42 AM UTC-4, TJF wrote:
>
> Hi!
>
> When using the libpruw1 driver 
>  you 
> won't need any device tree overlay . This driver uses libpruio 
>  
> for pinmuxing. Specify any (free) header pin in your source code for the W1 
> bus. The driver handles more than a single DS18S20 at this bus. Multiple 
> sensors can measure simultanuosly. The driver also provides a logging 
> feature to measure the bus state over a certain time period (for wiring 
> tests). Examples are included in GIT repo.
>
> Regards
>

-- 
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/927d7928-66a8-4f63-a64d-6f698e20648b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBGW and Node Red: No BB palate/ can’t access analog pins

[phillip . bogdanovich]

Hello all. I’m running the latest version of Debian per the BB wiki and I’m 
attempting to connect to analog pins via node red to no avail. After several 
days of reading I cannot find any  BB specific help with Node Red that’s 
recent. Everything I’ve read suggests using the BB palate which is no longer 
supported and I can’t get the palate to load anyway. Any help is greatly 
appreciated. 

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

[beagleboard] BBGW and Node Red

[phillip . bogdanovich]

Hello All. I’m running the most recent version of Debian and am attempting to 
use node red. After several days of searching I can’t find any real support to 
aid me in plugging in analog pins into a flow. The BB specific palate won’t 
load and this seems to be due to the BB palate being sidelined. Any help is 
greatly appreciated. 

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

[beagleboard] Re: PRU remoteproc[12] not appearing under /sys/class/remoteproc/

[hugh . frater]

I have the exact same issue, except my output from version.sh indicates the 
board id eeprom is programmed correctly? Any other ideas Robert?... I'm 
playing around with migrating our device from 8.7 with 4.4 kernel up to 
something more recent and am coming up against this PRU issue...

On Wednesday, 10 April 2019 03:06:45 UTC+1, eth...@uw.edu wrote:
>
>
> I've just set up a new Debian 9.5 (kernel 14.4.71-ti-r80) image 
> 
>  
> and made the following changes to /boot/uEnv.txt:
>
> disable_uboot_overlay_video=1
> uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
>
> I've also disabled loading of the uio modules. (
> /etc/modprobe.d/pruss-blacklist.conf)
> blacklist uio
> blacklist uio_pdrv_genirq
>
> However, I don't see any evidence that the rproc module has loaded the PRU:
> "uio\|pru"
>
> Specifically, there is no module for the PRU in /sys/class/remoteproc/. 
> remoteproc0 appears, but this is for the M3 power management unit.
>
> Am I doing anything wrong? or is there an additional step to allow use of 
> the PRUs? What should I look at to debug this issue?
>

-- 
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/26fa-76fd-42f1-aae8-bf7dba75d049%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: DS1820 on wire temp sensor using U-boot, kernel 4.14.71-ti-r80

[TJF]

Hi!

When using the libpruw1 driver 
 you 
won't need any device tree overlay . This driver uses libpruio 
 
for pinmuxing. Specify any (free) header pin in your source code for the W1 
bus. The driver handles more than a single DS18S20 at this bus. Multiple 
sensors can measure simultanuosly. The driver also provides a logging 
feature to measure the bus state over a certain time period (for wiring 
tests). Examples are included in GIT repo.

Regards

-- 
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/2a5fb489-dd03-43bd-a487-cab7d55378b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Device tree compiler throws error dtc: invalid option — '@'

[Robert Nelson]

On Mon, May 6, 2019 at 6:58 AM  wrote:
>
> Thanks for posting solution. where is the new version of dtc reside? I ran 
> the dtc again but it's still showing the old version (1.4.0) and dtc does not 
> support the -@.I also tried looking through the directory where i ran 
> that script, but dtc no where to be found.

Use "any" one of these official dtc release:

v1.4.4
v1.4.6
v1.4.7
v1.5.0

https://git.kernel.org/pub/scm/utils/dtc/dtc.git/

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/CAOCHtYj3uZRDFd%2BHiio6v3jZO8YnpT3Ha%3D6bf76F2swyUZbDmA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] apt-get warning and error

[Robert Nelson]

On Tue, May 7, 2019 at 4:45 AM geohei  wrote:
>
>
> Hi.
>
> When updating my BeagleBone Black running Debian 8, I get this here:
>
> root@bbb-one:~# apt-get update
> Hit http://security.debian.org jessie/updates InRelease
> Hit http://repos.rcn-ee.com jessie InRelease
> Ign http://ftp.us.debian.org jessie InRelease
> Get:1 http://security.debian.org jessie/updates/main armhf Packages [802 
> kB]
> Hit http://ftp.us.debian.org jessie-updates InRelease
> Get:2 http://repos.rcn-ee.com jessie/main armhf Packages [1013 kB]
> Hit http://ftp.us.debian.org jessie Release.gpg
> Hit http://ftp.us.debian.org jessie Release
> Get:3 http://security.debian.org jessie/updates/contrib armhf Packages 
> [994 B]
> Get:4 http://security.debian.org jessie/updates/non-free armhf Packages 
> [4416 B]
> Get:5 http://ftp.us.debian.org jessie/main armhf Packages [8898 kB]
> Get:6 http://ftp.us.debian.org jessie/contrib armhf Packages [44.3 kB]
> Get:7 http://ftp.us.debian.org jessie/non-free armhf Packages [74.9 kB]
> Fetched 10.8 MB in 18s (581 kB/s)
> W: Failed to fetch 
> http://ftp.us.debian.org/debian/dists/jessie-updates/InRelease  Unable to 
> find expected entry 'main/binary-armhf/Packages' in Release file (Wrong 
> sources.list entry or malformed file)
>
> E: Some index files failed to download. They have been ignored, or old 
> ones used instead.
>
> sources.list shows:
>
> root@bbb-one:~# cat /etc/apt/sources.list
> deb http://ftp.us.debian.org/debian/ jessie main contrib non-free
> #deb-src http://ftp.us.debian.org/debian/ jessie main contrib non-free
>
> deb http://ftp.us.debian.org/debian/ jessie-updates main contrib non-free
> #deb-src http://ftp.us.debian.org/debian/ jessie-updates main contrib 
> non-free
>
> deb http://security.debian.org/ jessie/updates main contrib non-free
> #deb-src http://security.debian.org/ jessie/updates main contrib non-free
>
> #deb http://ftp.debian.org/debian jessie-backports main contrib non-free
> ##deb-src http://ftp.debian.org/debian jessie-backports main contrib 
> non-free
>
> #Kernel source (repos.rcn-ee.com) : 
> https://github.com/RobertCNelson/linux-stable-rcn-ee
> #
> #git clone https://github.com/RobertCNelson/linux-stable-rcn-ee
> #cd ./linux-stable-rcn-ee
> #git checkout `uname -r` -b tmp
> #
> deb [arch=armhf] http://repos.rcn-ee.com/debian/ jessie main
> #deb-src [arch=armhf] http://repos.rcn-ee.com/debian/ jessie main
>
> It's in an operational environment, hence I cannot test a lot.
>
> What do the W: and E: messages mean and how do I get rid of them?

Here is full writeup..

https://www.lucas-nussbaum.net/blog/?p=947

Quick Answer, "disable" [deb http://ftp.us.debian.org/debian/
jessie-updates main contrib non-free], it's no longer needed for
"jessie"

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

[beagleboard] Linux Interrupt priorities

[Jonas Hjulstad]

Hi!
I've been looking into the interrupt controllers on the BeagleBone Black, 
and I'm trying to find out how Linux is
locking down the upper priorities of the controller. 

Context:
I'm trying to find figure out how a interrupt could be passed from a module 
in the PRU_ICSS subsystem to interrupt
the Cortex A8, in order to let external peripherals control the program 
flow. 

Loadable kernel modules have given some insight into how interrupt handlers 
could be setup, but I'm still unsure
of how Linux is limiting priorities. and how the processor initiates the 
handler when an interrupt request has been received. 

I'm not looking for a solution to the issue(I'm going to try RT-Linux or 
Xenomai), just how Linux is restricting access to the highest priorities.

Is it possible to override priorites by writing to the Interrupt 
Controllers registers?

-- 
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/4d916fe5-978b-484d-95f2-6c0cdc8dbbd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] apt-get warning and error

[geohei]

Hi.

When updating my BeagleBone Black running Debian 8, I get this here:

root@bbb-one:~# apt-get update
Hit http://security.debian.org jessie/updates InRelease
Hit http://repos.rcn-ee.com jessie InRelease
Ign http://ftp.us.debian.org jessie InRelease
Get:1 http://security.debian.org jessie/updates/main armhf Packages 
[802 kB]
Hit http://ftp.us.debian.org jessie-updates InRelease
Get:2 http://repos.rcn-ee.com jessie/main armhf Packages [1013 kB]
Hit http://ftp.us.debian.org jessie Release.gpg
Hit http://ftp.us.debian.org jessie Release
Get:3 http://security.debian.org jessie/updates/contrib armhf Packages 
[994 B]
Get:4 http://security.debian.org jessie/updates/non-free armhf Packages 
[4416 B]
Get:5 http://ftp.us.debian.org jessie/main armhf Packages [8898 kB]
Get:6 http://ftp.us.debian.org jessie/contrib armhf Packages [44.3 kB]
Get:7 http://ftp.us.debian.org jessie/non-free armhf Packages [74.9 kB]
Fetched 10.8 MB in 18s (581 kB/s)
W: Failed to fetch 
http://ftp.us.debian.org/debian/dists/jessie-updates/InRelease  Unable to 
find expected entry 'main/binary-armhf/Packages' in Release file (Wrong 
sources.list entry or malformed file)

E: Some index files failed to download. They have been ignored, or old 
ones used instead.

sources.list shows:

root@bbb-one:~# cat /etc/apt/sources.list
deb http://ftp.us.debian.org/debian/ jessie main contrib non-free
#deb-src http://ftp.us.debian.org/debian/ jessie main contrib non-free

deb http://ftp.us.debian.org/debian/ jessie-updates main contrib 
non-free
#deb-src http://ftp.us.debian.org/debian/ jessie-updates main contrib 
non-free

deb http://security.debian.org/ jessie/updates main contrib non-free
#deb-src http://security.debian.org/ jessie/updates main contrib 
non-free

#deb http://ftp.debian.org/debian jessie-backports main contrib non-free
##deb-src http://ftp.debian.org/debian jessie-backports main contrib 
non-free

#Kernel source (repos.rcn-ee.com) : 
https://github.com/RobertCNelson/linux-stable-rcn-ee
#
#git clone https://github.com/RobertCNelson/linux-stable-rcn-ee
#cd ./linux-stable-rcn-ee
#git checkout `uname -r` -b tmp
#
deb [arch=armhf] http://repos.rcn-ee.com/debian/ jessie main
#deb-src [arch=armhf] http://repos.rcn-ee.com/debian/ jessie main

It's in an operational environment, hence I cannot test a lot.

What do the W: and E: messages mean and how do I get rid of them?
 
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/6a64ac50-c1f8-4797-928c-0af6412e66fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.