[beagleboard] About BeagleBoard XM's System RAM

[Cheolmin Jung]

Hi, all

I am currently working on RAM dump analyzer program and I have 496MB 
physical ram dump image.

The problem with it is that I don't know the start offset of ram dump 
Image. 

I wonder what base address of physical RAM is? is it 0x8000 ? Cuz I saw 
some lines on the beagleboard XM manual such as..






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

Re: [beagleboard] Re: Ad-hoc network together with access point

[liyaoshi]

 2 WiFi antenna with in 1 adapter ???

How do you config it ?

And . if you mean use 2 adapters , maybe you can show ifconfig -a result

As my previous experience .

brctl addif br0 wlan0 wlan1

if bridge mode dont work , try router mode

eg

iptables -t nat -A POSTROUTING -s 192.168.0.1/24 -o wlan0

find more result from google to fit your case .


2014-08-15 9:36 GMT+08:00 :

> Hi all ,
>
> I am sorry.I know this is not going to help , but i had a query.How did
> you establish an ad-hoc connection between the beaglebone and your laptop.I
> use a macbook and the beagle distribution is debian.I tried using
> wicd-curses but that did not help.Any help on this is greatly appreciated.
>
> Regards,
> Vivak Katla
>
>
> On Thursday, 7 August 2014 12:21:27 UTC-4, paullo...@gmail.com wrote:
>>
>> Hi,all
>>
>> I am using five BeagleBone Black with 2 WiFi antenna connected to each
>> BeagleBone Black.
>>
>> On each BeagleBone Black, one of the WiFi antenna is configured for an
>> ad-hoc network, the other WiFi antenna is configured as an access point to
>> allow mobile devices to join the ad-hoc network via the access point.
>>
>> The result is that the mobile devices can get associated to the access
>> point and access a web server in the ad-hoc network.
>>
>> However, the mobile device of Access Point 1 (AP1) is not able to
>> communicate with the mobile devices of Access Point 2 (AP2).
>>
>> I have add in the route of the subnet of mobile devices of AP2 in AP1 and
>> vice versa.
>>
>> Did anyone has experience in configuring ad-hoc network together with
>> access point on a single BeagleBone Black?
>>
>> Is it possible?
>>
>> Thank you.
>>
>> Rdgs,
>> Paul
>>
>>  --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update

[Alexander Hayman]

I checked the difference between the dts's.  It looks like the only 
difference that matters is the panel-info {  bpp } value.  BB-BONE has a 
bpp of 24.  BB-VIEW has a bpp of 32.  The display-timings information is 
all identical.

Would it then make sense that the image is scaled and the colors are 
corrupted if the 4D Systems screen is using the BB-VIEW dtb file with the 
slightly higher bpp value?

Alex

On Friday, August 15, 2014 2:41:05 PM UTC-4, Alexander Hayman wrote:
>
>  I am using Robert's bb-kernel git repo to build the kernel.  It looks 
> like we are using the exact same compiler.
> Linux version 3.8.13-bone62 (root@debian) (gcc version 4.7.3 20130328 
> (prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 
> 2013.04) )
>
> I noticed that you are passing specific commands to the capemgr. 
> "capemgr.enable_partno=BB-VIEW-LCD4-01"  This I am not doing.  Should I be 
> doing this? If I force it to capemgr.enable_partno=BB-BONE-LCD4-01, then 
> maybe it will work even if your patch is installed?
>
> This is what the detection of the screen looks like on my kernel without 
> the patches.  Maybe the kernel is getting confused and using BB-VIEW dtb 
> for my LCD instead of BB-BONE dtb?
>
> [0.725548] bone-capemgr bone_capemgr.9: Baseboard: 
> 'A335BNLT,00A5,4110BBBK'
> [0.725572] bone-capemgr bone_capemgr.9: 
> compatible-baseboard=ti,beaglebone-black
> [0.755349] bone-capemgr bone_capemgr.9: slot #0: No cape found
> [0.792456] bone-capemgr bone_capemgr.9: slot #1: No cape found
> [0.829564] bone-capemgr bone_capemgr.9: slot #2: No cape found
> [0.859739] bone-capemgr bone_capemgr.9: slot #3: '4D 4.3 LCD CAPE- 
> 4DCAPE-43T ,00A1,4D SYSTEMS  ,BB-BONE-LCD4-01'
> [0.859839] bone-capemgr bone_capemgr.9: slot #4: specific override
> [0.859859] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 4
> [0.859873] bone-capemgr bone_capemgr.9: slot #4: 
> 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
> [0.859945] bone-capemgr bone_capemgr.9: slot #5: specific override
> [0.859963] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 5
> [0.859977] bone-capemgr bone_capemgr.9: slot #5: 
> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
> [0.860046] bone-capemgr bone_capemgr.9: slot #6: specific override
> [0.860063] bone-capemgr bone_capemgr.9: bone: Using override eeprom 
> data at slot 6
> [0.860077] bone-capemgr bone_capemgr.9: slot #6: 
> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
> [0.860405] bone-capemgr bone_capemgr.9: loader: before slot-3 
> BB-BONE-LCD4-01:00A1 (prio 0)
> [0.860420] bone-capemgr bone_capemgr.9: loader: check slot-3 
> BB-BONE-LCD4-01:00A1 (prio 0)
> [0.860500] bone-capemgr bone_capemgr.9: loader: before slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1)
> [0.860512] bone-capemgr bone_capemgr.9: loader: check slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1)
> [0.860585] bone-capemgr bone_capemgr.9: loader: before slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [0.860598] bone-capemgr bone_capemgr.9: loader: check slot-5 
> BB-BONELT-HDMI:00A0 (prio 1)
> [0.860632] bone-capemgr bone_capemgr.9: initialized OK.
> [0.861126] bone-capemgr bone_capemgr.9: loader: after slot-3 
> BB-BONE-LCD4-01:00A1 (prio 0)
> [0.861145] bone-capemgr bone_capemgr.9: slot #3: Requesting part 
> number/version based 'BB-BONE-LCD4-01-00A1.dtbo
> [0.861167] bone-capemgr bone_capemgr.9: slot #3: Requesting firmware 
> 'BB-BONE-LCD4-01-00A1.dtbo' for board-name '4D 4.3 LCD CAPE- 4DCAPE-43T 
> ', version '00A1'
> [0.861186] bone-capemgr bone_capemgr.9: slot #3: dtbo 
> 'BB-BONE-LCD4-01-00A1.dtbo' loaded; converting to live tree
> [0.861686] bone-capemgr bone_capemgr.9: slot #3: #4 overlays
>
>
> On 8/13/2014 3:06 PM, Scott Michel wrote:
>  
>  Alexander:
>
> Short answer: It works for me. :-)
>
>  It turns out that a colleague has an Element-14 4.3" LCD cape here at 
> work. I just booted up after changing uEnv.txt. Hard to work on the BBB at 
> that screen resolution, but I don't have the image compression that you 
> experienced. 
>
>  I'm not at the most recent tag on Robert's tree, but I could test it 
> later this week. But given that the E-14 4.3" LCD cape works, it makes me 
> wonder if the problem isn't with the DTB's pixel and dot clocking params?
>  
>  Now, I'll admit that I compiled my kernel with the 4.7.3 20130328 
> prerelease compiler, so that could have made a difference if there were a 
> compiler bug:
>
> [0.00] Linux version 3.8.13-bone53 (-@) (gcc 
> version 4.7.3 20130328 (prerelease) (crosstool-NG 
> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) ) #40 SMP Fri May 
> 30 13:18:49 PDT 2014
> [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), 
> cr=50c5387d
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
> instruction cache
> [0

[beagleboard] Re: ADC reading by PRU

[Rodrigo Caropreso]

Hello,

Sorry for the delay on answering the mails group, but on the beginning of 
the week I do not have much time available to work on the BeagleBone issues.

I've downloaded the most recent Angstrom image (on the site) and I've just 
updated the BeagleBone Black now.

Regarding the segmentation fault: I was following the instructions on this 
page: http://boxysean.com/blog/2012/08/12/first-steps-with-the-beaglebone-pru/

The seg fault has happened in the execution of the sample: 
./PRU_memAccessPRUDataRam

The info was something like:

AM33XX INFO: Initializing example. INFO: Executing example.
Segmentation fault.

(The remaining messages were not showed).

Since is is a sample code, I was thinking that this code would be reliable 
enough to confirm iif my BBB's PRU is correctly configured and running.

In fact I'm trying to read analog data (ADC) using PRU (because the usual 
way, using the file system is not fast enough for what I need - but I 
accept any suggestions to get data from ADC in a 10KHz sample rate ).

I was planning to use the libpruio Library (my assembly is a little bit 
rusty and this library should help me to achieve this task) but last week 
I've got stuck into this seg fault issue.

Now, with an updated OS, I'll try to follow these path again (perhaps I'll 
be more lucky this time).

Is it possible to use the libpruio (and PRUSSDRV) on Angstrom or should I 
install Ubuntu or Debian instead?

Thanks for all your information and best regards,

Rodrigo.







Em terça-feira, 8 de abril de 2014 07h15min31s UTC-3, Youngtae Jo escreveu:
>
> I've tried to find some example of ADC reading by PRU for my project, but 
> I couldn't find it.
> And I made that of source code and attach here for some people who have 
> the same problem with me.
> I hope it will be helpful.
>
> [ AM335x ARM-CORE PRU ADC Example ]
>  - Sequence of example
>  1. Install compiling environment of PRU
>  2. Enable PRU 
>  3. Enable ADC 
>  4. Example source
> - This example source collects ADC data from AIN0 pin with 16khz 
> sampling rate.
> - The collected data are saved into "Results.txt" file.
> - The example source are "Makefile", "ADCCollector.c", "ADCCollector.p", 
> "ADCCollector.hp"
>
> [ Install compile environment ]
>  1. Get a copy of the am335x_pru_package -> 
> https://github.com/beagleboard/am335x_pru_package
> You also can download the am335x_pru_package here -> 
> https://github.com/beagleboard/am335x_pru_package/archive/master.zip
>  2. If you downloaded the archive, unpack it somewhere under your home 
> directory.
>  3. Make a new directory /usr/include/pruss/ and copy the files prussdrv.h 
>  
> and pruss_intc_mapping.h into it (from 
> am335x_pru_package-master/pru_sw/app_loader/include). 
> Check the permissions; if you used the .zip file, these headers will 
> likely have the execute bits on. 
> It doesn't really hurt anything, but is certainly not what you want.
>  4. Change directory to 
> am335x_pru_package-master/pru_sw/app_loader/interface 
> then run: CROSS_COMPILE= make (note the space between the = and the 
> command).
>  5. The previous step should have created four files in 
> am335x_pru_package-master/pru_sw/app_loader/lib: libprussdrv.a, 
> libprussdrvd.a, libprussdrvd.so and libprussdrv.so. 
> Copy these all to /usr/lib then run ldconfig.
>  6. Change directory to am335x_pru_package-master/pru_sw/utils/pasm_source 
> then run source linuxbuild to create a pasm executable one directory 
> level up. 
>  - If linuxbuild doesn't have permission to execution, give the permission 
> by run this
>: chmod +x linuxbuild
> Copy it to /usr/bin and make sure you can run it. 
> If you invoke it with no arguments, you should get a usage statement.
>  
> [ Enable PRU ]
>  Before using PRU, we need to enable the PRU core, you can do it as shown 
> below
>  # echo BB-BONE-PRU-01 > /sys/devices/bone_capemgr.8/slots
>
> [ Enable ADC ]
>  Before using ADC, we also need to enable ADC, you can do it as shown below
>  # echo cape-bone-iio > /sys/devices/bone_capemgr.*/slots
>  
> [ ADC Example - Makefile]
> CFLAGS+=-Wall -Werror
> LDLIBS+= -lpthread -lprussdrv
>
> all: ADCCollector.bin ADCCollector
>
> clean:
> rm -f ADCCollector *.o *.bin
>
> ADCCollector.bin: ADCCollector.p
> pasm -b $^
>
> ADCCollector: ADCCollector.o
>
> [ ADC Example - ADCCollector.p]
> // Developed by Youngtae Jo in Kangwon National University (April-2014)
>
> // This program collects ADC from AIN0 with certain sampling rate.
> // The collected data are stored into PRU shared memory(buffer) first.
> // The host program(ADCCollector.c) will read the stored ADC data
> // This program uses double buffering technique. 
> // The host program can recognize the buffer status by buffer status 
> variable
> // 0 means empty, 1 means first buffer is ready, 2 means second buffer is 
> ready.
> // When each buffer is ready, host program read ADC data from the buffer.
>
>
> .origin 0 // offset of the start of the cod

[beagleboard] Re: Device tree overlays may load manually, but not at boot.

[Jason Lange]

I found this:
*"...POSIX says that a non-interactive
shell must not generate pathnames for a redirection; an interactive
shell may do so, provided there is exactly one match.."
*

 
So although:
echo BB-SPIDEV0  >  /sys/devices/bone_capemgr.*/slots

might work when you are doing it manually,
you need to do something like this:

#!/bin/sh -e
> slots=$(ls /sys/devices/bone_capemgr.*/slots)
> echo BB-SPIDEV0 > $slots
> echo BB-SPIDEV1 > $slots
> exit
>
 
to make it run in a plain sh script 

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

[beagleboard] Re: Device tree overlays may load manually, but not at boot.

[Jason Lange]

I found this:

*"...POSIX says that a non-interactive shell must not generate pathnames 
> for a redirection; an interactive shell may do so, provided there is 
> exactly one match.." *

 
So although:
echo BB-SPIDEV0  >  /sys/devices/bone_capemgr.*/slots

might work when you are doing it manually,
you need to do something like this:

#!/bin/sh -e
> slots=$(ls /sys/devices/bone_capemgr.*/slots)
> echo BB-SPIDEV0 > $slots
> echo BB-SPIDEV1 > $slots
> exit
>
 
to make it run in a plain sh script 

On Friday, 15 August 2014 12:03:36 UTC-7, Jason Lange wrote:
>
>
> running it manually as root starting with /bin/bash then using vi to 
> change to /bin/sh I get this:
>
> root@sqr1 ~ # cd /usr/local/bin 
> root@sqr1 /usr/local/bin # mv startSPI.sh.hid startSPI.sh 
> root@sqr1 /usr/local/bin # ./startSPI.sh 
> root@sqr1 /usr/local/bin # 
> root@sqr1 /usr/local/bin # vi ./startSPI.sh 
> root@sqr1 /usr/local/bin # 
> root@sqr1 /usr/local/bin # ./startSPI.sh 
> ./startSPI.sh: 3: ./startSPI.sh: cannot create 
> /sys/devices/bone_capemgr.*/slots: Directory nonexistent
> ./startSPI.sh: 4: ./startSPI.sh: cannot create 
> /sys/devices/bone_capemgr.*/slots: Directory nonexistent
>
> I don't understand why.
>
>
> On Thursday, 14 August 2014 09:02:32 UTC-7, Terje Froysa wrote:
>>
>>
>> Dear Forum,
>>
>> I have now turned the web outside-in to find an answer to this question.
>> I see a lot of subjects touching the subject, but the answers and 
>> suggestions are mostly in the hear-say category and points in different 
>> directions putting me off in an endless ghost-hunt.
>>
>> I have been testing various overlays, some loads without problems, other 
>> won't load but can be manually loaded after boot.
>> I can even rename an overlay that loads and it stops loading even if the 
>> content is identical.
>> I have changed the sequence of loading proving that the file system is 
>> ready at the time of loading.
>>
>> I have tested the suggested solutions from:
>> http://elinux.org/BeagleBone_Black_Enable_SPIDEV
>>
>> The .dtbo files does not load at boot, but can be loaded manually later. 
>> And working when loaded!
>> The boot log gives no clue of what the problem may be.
>>
>>
>>- Is it the content of the .dtbo?
>>- Is it the name of the .dtbo file?
>>
>> Please advice
>> Best regards
>> Terje Froysa
>>
>> *Running system:*
>>
>> debian@beaglebone:~$ uname -a
>> Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l 
>> GNU/Linux
>> *Boot log showing BB-SPI1-SWP-01 not loading:*
>> debian@beaglebone:~$ dmesg |grep BB-
>> [ 0.00] Kernel command line: console=tty0 console=ttyO0,115200n8 
>> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN 
>> capemgr.enable_partno=BB-I2C1,BB-SPI1-SWP-01 
>> root=UUID=5a42a22f-1771-4c44-93ef-8879c38b63d9 ro rootfstype=ext4 rootwait 
>> fixrtc quiet init=/lib/systemd/systemd
>> [ 0.565888] bone-capemgr bone_capemgr.9: Skipping disabled cape with 
>> part# BB-BONELT-HDMI
>> [ 0.565937] bone-capemgr bone_capemgr.9: Skipping disabled cape with 
>> part# BB-BONELT-HDMIN
>> [ 0.714324] bone-capemgr bone_capemgr.9: slot #4: 
>> 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
>> [ 0.714439] bone-capemgr bone_capemgr.9: slot #5: 
>> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
>> [ 0.714540] bone-capemgr bone_capemgr.9: slot #6: 
>> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
>> [ 0.714612] bone-capemgr bone_capemgr.9: enabled_partno part_number 
>> 'BB-I2C1', version 'N/A', prio '0'
>> [ 0.714653] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
>> Name,00A0,Override Manuf,BB-I2C1'
>> [ 0.714725] bone-capemgr bone_capemgr.9: enabled_partno part_number 
>> 'BB-SPI1-SWP-01', version 'N/A', prio '0'
>> [ 0.714762] bone-capemgr bone_capemgr.9: slot #8: 'Override Board 
>> Name,00A0,Override Manuf,BB-SPI1-SWP-01'
>> [ 0.714928] bone-capemgr bone_capemgr.9: Skipping loading of disabled 
>> cape with part# BB-BONELT-HDMI
>> [ 0.714943] bone-capemgr bone_capemgr.9: Skipping loading of disabled 
>> cape with part# BB-BONELT-HDMIN
>> [ 0.715135] bone-capemgr bone_capemgr.9: loader: before slot-4 
>> BB-BONE-EMMC-2G:00A0 (prio 1)
>> [ 0.715149] bone-capemgr bone_capemgr.9: loader: check slot-4 
>> BB-BONE-EMMC-2G:00A0 (prio 1)
>> [ 0.715228] bone-capemgr bone_capemgr.9: loader: before slot-7 
>> BB-I2C1:00A0 (prio 0)
>> [ 0.715240] bone-capemgr bone_capemgr.9: loader: check slot-7 
>> BB-I2C1:00A0 (prio 0)
>> [ 0.715732] bone-capemgr bone_capemgr.9: loader: check slot-4 
>> BB-BONE-EMMC-2G:00A0 (prio 1)
>> [ 0.718442] bone-capemgr bone_capemgr.9: loader: after slot-7 
>> BB-I2C1:00A0 (prio 0)
>> [ 0.718462] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
>> number/version based 'BB-I2C1-00A0.dtbo
>> [ 0.718477] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
>> 'BB-I2C1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
>> [ 0.718506] bone-capemgr bone_capemgr.9: slot #7: dtbo 
>> 'BB-I2C1-00A0.dtbo' 

Re: [beagleboard] "unable to find remote helper for 'https'"

[Don deJuan]

On 08/15/2014 12:46 PM, Robert Nelson wrote:
> On Fri, Aug 15, 2014 at 2:13 PM, Imran Faisal  wrote:
>> hi,
>>
>> I am new to Beagle bone and trying to install Gentoo linux on it.
>>
>> i am struck up at the while running the command "git clone
>> https://github.com/beagleboard/meta-beagleboard.git";
>>
>> it throws an error "unable to find remote helper for 'https'"
>>
>> Can someone please help me with this issue.
> Looks like your version of git was built without curl support.. fix that..
>
> Regards,
>
or possibly does not have all the needed curl pkgs installed.

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

Re: [beagleboard] "unable to find remote helper for 'https'"

[Robert Nelson]

On Fri, Aug 15, 2014 at 2:13 PM, Imran Faisal  wrote:
> hi,
>
> I am new to Beagle bone and trying to install Gentoo linux on it.
>
> i am struck up at the while running the command "git clone
> https://github.com/beagleboard/meta-beagleboard.git";
>
> it throws an error "unable to find remote helper for 'https'"
>
> Can someone please help me with this issue.

Looks like your version of git was built without curl support.. fix that..

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

[beagleboard] "unable to find remote helper for 'https'"

[Imran Faisal]

hi,

I am new to Beagle bone and trying to install Gentoo linux on it.

i am struck up at the while running the command "git clone
https://github.com/beagleboard/meta-beagleboard.git";

it throws an error "unable to find remote helper for 'https'"

Can someone please help me with this issue.

Regards,
Imran

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

[beagleboard] Re: Device tree overlays may load manually, but not at boot.

[Jason Lange]

running it manually as root starting with /bin/bash then using vi to change 
to /bin/sh I get this:

root@sqr1 ~ # cd /usr/local/bin 
root@sqr1 /usr/local/bin # mv startSPI.sh.hid startSPI.sh 
root@sqr1 /usr/local/bin # ./startSPI.sh 
root@sqr1 /usr/local/bin # 
root@sqr1 /usr/local/bin # vi ./startSPI.sh 
root@sqr1 /usr/local/bin # 
root@sqr1 /usr/local/bin # ./startSPI.sh 
./startSPI.sh: 3: ./startSPI.sh: cannot create 
/sys/devices/bone_capemgr.*/slots: Directory nonexistent
./startSPI.sh: 4: ./startSPI.sh: cannot create 
/sys/devices/bone_capemgr.*/slots: Directory nonexistent

I don't understand why.


On Thursday, 14 August 2014 09:02:32 UTC-7, Terje Froysa wrote:
>
>
> Dear Forum,
>
> I have now turned the web outside-in to find an answer to this question.
> I see a lot of subjects touching the subject, but the answers and 
> suggestions are mostly in the hear-say category and points in different 
> directions putting me off in an endless ghost-hunt.
>
> I have been testing various overlays, some loads without problems, other 
> won't load but can be manually loaded after boot.
> I can even rename an overlay that loads and it stops loading even if the 
> content is identical.
> I have changed the sequence of loading proving that the file system is 
> ready at the time of loading.
>
> I have tested the suggested solutions from:
> http://elinux.org/BeagleBone_Black_Enable_SPIDEV
>
> The .dtbo files does not load at boot, but can be loaded manually later. 
> And working when loaded!
> The boot log gives no clue of what the problem may be.
>
>
>- Is it the content of the .dtbo?
>- Is it the name of the .dtbo file?
>
> Please advice
> Best regards
> Terje Froysa
>
> *Running system:*
>
> debian@beaglebone:~$ uname -a
> Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l 
> GNU/Linux
> *Boot log showing BB-SPI1-SWP-01 not loading:*
> debian@beaglebone:~$ dmesg |grep BB-
> [ 0.00] Kernel command line: console=tty0 console=ttyO0,115200n8 
> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN 
> capemgr.enable_partno=BB-I2C1,BB-SPI1-SWP-01 
> root=UUID=5a42a22f-1771-4c44-93ef-8879c38b63d9 ro rootfstype=ext4 rootwait 
> fixrtc quiet init=/lib/systemd/systemd
> [ 0.565888] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# 
> BB-BONELT-HDMI
> [ 0.565937] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# 
> BB-BONELT-HDMIN
> [ 0.714324] bone-capemgr bone_capemgr.9: slot #4: 
> 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
> [ 0.714439] bone-capemgr bone_capemgr.9: slot #5: 
> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
> [ 0.714540] bone-capemgr bone_capemgr.9: slot #6: 
> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
> [ 0.714612] bone-capemgr bone_capemgr.9: enabled_partno part_number 
> 'BB-I2C1', version 'N/A', prio '0'
> [ 0.714653] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
> Name,00A0,Override Manuf,BB-I2C1'
> [ 0.714725] bone-capemgr bone_capemgr.9: enabled_partno part_number 
> 'BB-SPI1-SWP-01', version 'N/A', prio '0'
> [ 0.714762] bone-capemgr bone_capemgr.9: slot #8: 'Override Board 
> Name,00A0,Override Manuf,BB-SPI1-SWP-01'
> [ 0.714928] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape 
> with part# BB-BONELT-HDMI
> [ 0.714943] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape 
> with part# BB-BONELT-HDMIN
> [ 0.715135] bone-capemgr bone_capemgr.9: loader: before slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1)
> [ 0.715149] bone-capemgr bone_capemgr.9: loader: check slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1)
> [ 0.715228] bone-capemgr bone_capemgr.9: loader: before slot-7 
> BB-I2C1:00A0 (prio 0)
> [ 0.715240] bone-capemgr bone_capemgr.9: loader: check slot-7 BB-I2C1:00A0 
> (prio 0)
> [ 0.715732] bone-capemgr bone_capemgr.9: loader: check slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1)
> [ 0.718442] bone-capemgr bone_capemgr.9: loader: after slot-7 BB-I2C1:00A0 
> (prio 0)
> [ 0.718462] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
> number/version based 'BB-I2C1-00A0.dtbo
> [ 0.718477] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
> 'BB-I2C1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
> [ 0.718506] bone-capemgr bone_capemgr.9: slot #7: dtbo 'BB-I2C1-00A0.dtbo' 
> loaded; converting to live tree
> [ 0.720710] bone-capemgr bone_capemgr.9: loader: before slot-8 
> BB-SPI1-SWP-01:00A0 (prio 0)
> [ 0.720724] bone-capemgr bone_capemgr.9: loader: check slot-8 
> BB-SPI1-SWP-01:00A0 (prio 0)
> [ 0.720740] bone-capemgr bone_capemgr.9: loader: after slot-8 
> BB-SPI1-SWP-01:00A0 (prio 0)
> [ 0.720754] bone-capemgr bone_capemgr.9: slot #8: Requesting part 
> number/version based 'BB-SPI1-SWP-01-00A0.dtbo
> [ 0.720770] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware 
> 'BB-SPI1-SWP-01-00A0.dtbo' for board-name 'Override Board Name', version 
> '00A0'
> [ 0.721636] bone-capemgr bone_capemgr.9: loader: done slot-7 BB-I2C1:00A0 
> (prio 0)

Re: [beagleboard] Re: Device tree overlays may load manually, but not at boot.

[Robert Nelson]

On Fri, Aug 15, 2014 at 1:48 PM, Jason Lange  wrote:
> Hello,
>
> I've had similar problems, and similar frustration with existing
> instructions.
>
> My workaround was to put this line in /etc/rc.local:
>
> /usr/local/bin/startSPI.sh  > /dev/null &
>
> I believe that the output redirect and the & will prevent this line from
> hanging initiation if anything goes wrong.  But I don't know for sure...
> (anyone care to comment?)
>
>  ...and adding a startSPI.sh in /usr/local/bin/ with contents like this:
>
> #!/bin/bash
>
> echo CUSTOM-SPIDEV0 > /sys/devices/bone_capemgr.*/slots
> echo CUSTOM-SPIDEV1 > /sys/devices/bone_capemgr.*/slots
>
> exit
>
> Note: the shebang line calls /bin/bash not /bin/sh.  /bin/sh --> /bin/dash
> in debian  and it didn't like the wild-card *  which I believe might be
> necessary... (anyone care to comment?

I get away with it:
https://github.com/RobertCNelson/omap-image-builder/blob/master/target/init_scripts/capemgr-debian.sh#L19

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: [beagleboard] USB problems on Rev C (not sure which revision)

[Robert Nelson]

On Fri, Aug 15, 2014 at 9:53 AM,   wrote:
> I just received my first BBB Rev C a few weeks ago and am having some
> problems with powered USB hubs.  First of all I'm trying to determine which
> revision of Rev C the board is.  The sticker just says 'C' with no number.
> Does this indicate it's a C1?
>
> I need to run both a webcam and a USB WiFi module (RTL8192cu.)  Both the
> webcam and WiFi module work great if plugged directly into the USB Host port
> one at a time.  In addition, if I use the powered USB hub with the WiFi
> module it still works great.  But if I plug in the webcam to the USB port
> (by itself or along with the WiFi) i get no access to it.
>
> I can plug in other devices (i.e. a DVB SDR, or a thumb drive) along with
> the WiFi module and it still works.  It just seems to be the webcam that
> puts it over the top.

Sounds like that webcam requires almost all the usb bandwidth.
Remember usb is a shared bus.  Find a different webcam.

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

[beagleboard] Re: Device tree overlays may load manually, but not at boot.

[Jason Lange]

Hello,

I've had similar problems, and similar frustration with existing 
instructions.

My workaround was to put this line in /etc/rc.local:

/usr/local/bin/startSPI.sh  > /dev/null &

I believe that the output redirect and the & will prevent this line from 
hanging initiation if anything goes wrong.  But I don't know for sure... 
(anyone care to comment?)

 ...and adding a startSPI.sh in /usr/local/bin/ with contents like this:

#!/bin/bash

echo CUSTOM-SPIDEV0 > /sys/devices/bone_capemgr.*/slots
echo CUSTOM-SPIDEV1 > /sys/devices/bone_capemgr.*/slots

exit

Note: the shebang line calls /bin/bash not /bin/sh.  /bin/sh --> /bin/dash 
in debian  and it didn't like the wild-card *  which I believe might be 
necessary... (anyone care to comment?

I hope this is useful.

Cheers.


On Thursday, 14 August 2014 09:02:32 UTC-7, Terje Froysa wrote:
>
>
> Dear Forum,
>
> I have now turned the web outside-in to find an answer to this question.
> I see a lot of subjects touching the subject, but the answers and 
> suggestions are mostly in the hear-say category and points in different 
> directions putting me off in an endless ghost-hunt.
>
> I have been testing various overlays, some loads without problems, other 
> won't load but can be manually loaded after boot.
> I can even rename an overlay that loads and it stops loading even if the 
> content is identical.
> I have changed the sequence of loading proving that the file system is 
> ready at the time of loading.
>
> I have tested the suggested solutions from:
> http://elinux.org/BeagleBone_Black_Enable_SPIDEV
>
> The .dtbo files does not load at boot, but can be loaded manually later. 
> And working when loaded!
> The boot log gives no clue of what the problem may be.
>
>
>- Is it the content of the .dtbo?
>- Is it the name of the .dtbo file?
>
> Please advice
> Best regards
> Terje Froysa
>
> *Running system:*
>
> debian@beaglebone:~$ uname -a
> Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l 
> GNU/Linux
> *Boot log showing BB-SPI1-SWP-01 not loading:*
> debian@beaglebone:~$ dmesg |grep BB-
> [ 0.00] Kernel command line: console=tty0 console=ttyO0,115200n8 
> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN 
> capemgr.enable_partno=BB-I2C1,BB-SPI1-SWP-01 
> root=UUID=5a42a22f-1771-4c44-93ef-8879c38b63d9 ro rootfstype=ext4 rootwait 
> fixrtc quiet init=/lib/systemd/systemd
> [ 0.565888] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# 
> BB-BONELT-HDMI
> [ 0.565937] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# 
> BB-BONELT-HDMIN
> [ 0.714324] bone-capemgr bone_capemgr.9: slot #4: 
> 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
> [ 0.714439] bone-capemgr bone_capemgr.9: slot #5: 
> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
> [ 0.714540] bone-capemgr bone_capemgr.9: slot #6: 
> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
> [ 0.714612] bone-capemgr bone_capemgr.9: enabled_partno part_number 
> 'BB-I2C1', version 'N/A', prio '0'
> [ 0.714653] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
> Name,00A0,Override Manuf,BB-I2C1'
> [ 0.714725] bone-capemgr bone_capemgr.9: enabled_partno part_number 
> 'BB-SPI1-SWP-01', version 'N/A', prio '0'
> [ 0.714762] bone-capemgr bone_capemgr.9: slot #8: 'Override Board 
> Name,00A0,Override Manuf,BB-SPI1-SWP-01'
> [ 0.714928] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape 
> with part# BB-BONELT-HDMI
> [ 0.714943] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape 
> with part# BB-BONELT-HDMIN
> [ 0.715135] bone-capemgr bone_capemgr.9: loader: before slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1)
> [ 0.715149] bone-capemgr bone_capemgr.9: loader: check slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1)
> [ 0.715228] bone-capemgr bone_capemgr.9: loader: before slot-7 
> BB-I2C1:00A0 (prio 0)
> [ 0.715240] bone-capemgr bone_capemgr.9: loader: check slot-7 BB-I2C1:00A0 
> (prio 0)
> [ 0.715732] bone-capemgr bone_capemgr.9: loader: check slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1)
> [ 0.718442] bone-capemgr bone_capemgr.9: loader: after slot-7 BB-I2C1:00A0 
> (prio 0)
> [ 0.718462] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
> number/version based 'BB-I2C1-00A0.dtbo
> [ 0.718477] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
> 'BB-I2C1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
> [ 0.718506] bone-capemgr bone_capemgr.9: slot #7: dtbo 'BB-I2C1-00A0.dtbo' 
> loaded; converting to live tree
> [ 0.720710] bone-capemgr bone_capemgr.9: loader: before slot-8 
> BB-SPI1-SWP-01:00A0 (prio 0)
> [ 0.720724] bone-capemgr bone_capemgr.9: loader: check slot-8 
> BB-SPI1-SWP-01:00A0 (prio 0)
> [ 0.720740] bone-capemgr bone_capemgr.9: loader: after slot-8 
> BB-SPI1-SWP-01:00A0 (prio 0)
> [ 0.720754] bone-capemgr bone_capemgr.9: slot #8: Requesting part 
> number/version based 'BB-SPI1-SWP-01-00A0.dtbo
> [ 0.720770] bone-capemgr bone_capemgr.9: slot #8: Requesting firmware 
> '

Re: [beagleboard] BBB runs fine through usb but will not display anything through hdmi

[Gerald Coley]

Try plugging in the HDMI before you release the board from reset. Make sure
the ground of the supply to the monitor is the same as the power supply of
the board.

Gerald



On Fri, Aug 15, 2014 at 2:00 AM, justtryingtolearn 
wrote:

> Ive read through the manual a few times but could have missed something.
>
> From the usb side everything works, web server, bonescript interactive
> guide, cloud9, ect
>
> However from the hdmi/standalone side
>
> 1.   Plug in power supply via barrel plug (tried 1A, 1.5A 2.5A and 7A
> 5v supplies)
>
> 2.   Once heartbeat starts flashing plug in hdmi
>
> 3.   And… nothing… sometimes the display turns black like it’s trying
> to work, others nothing at all,  ive tried with and w/o mice/keyboard
>
> One time it did boot, but the display was flickering every few seconds, I
> could not get the mouse or keyboard to work the board seemed “frozen” (with
> and without usb hub)
>
> Also attempted to boot from flash drive with no luck.
>
> I know the monitor, mouse and keyboard are good, setup a raspberry pi this
> morning.
>
> The only problem I can think of would be the hdmi cable, contacted the
> seller to see if they will ship another one. Other than that any ideas? I
> bet it’s something silly simple…usually is… really excited to get it
> running, when it did boot it loaded much faster than the pi
>
>
> have the c version
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Setting up TFTP and NFS

[John Syn]

From:  William Hermans 
Reply-To:  "beagleboard@googlegroups.com" 
Date:  Friday, August 15, 2014 at 10:28 AM
To:  "beagleboard@googlegroups.com" 
Subject:  Re: [beagleboard] Setting up TFTP and NFS

> I do not need to read an article or google John, I've had tons of experience
> with both.
The problem I have is when you make disparaging remarks about other distros.
In reality the other distros work fine and you are only having trouble with
them because you haven¹t spent a lot of time with them. I had trouble with
Debian, but only because I¹ve spent more time with Ubuntu. I¹m sure if I
took the time to work with Debian, it would work fine for me also. If Mint
was so bad, no one would be using it; but they have a big following. It just
so happens that you and I aren¹t one of them.

Regards,
John
> 
> 
> 
> On Fri, Aug 15, 2014 at 9:37 AM, John Syn  wrote:
>> 
>> From:  William Hermans 
>> Reply-To:  "beagleboard@googlegroups.com" 
>> Date:  Thursday, August 14, 2014 at 11:55 PM
>> 
>> To:  "beagleboard@googlegroups.com" 
>> Subject:  Re: [beagleboard] Setting up TFTP and NFS
>> 
 Debian might be perceived as more stable, but it uses old version of almost
 every package and the core repository is way smaller than Ubuntu so you
 have to hunt around for other repos to find the packages you need and then
 Debian becomes less stable.
>>> 
>>> Hunt around for what packages ? In the context of the current discussion
>>> I've never had to "hunt" for anything. I've had to compile my own stuff from
>>> sources when I wanted something custom . . . Now if you want cutting edge
>>> stuff, you're almost certainly going to run into trouble no matter what
>>> distro you use. But that is not what we're talking about. We're talking
>>> about running a distro in a VM for the sole purpose of supporting the
>>> Beaglebone black.
>> The following article does a pretty fair comparison of Ubuntu vs Debian.
>> 
>> http://www.udemy.com/blog/debian-vs-ubuntu/
>> 
>> Just search google for ³Ubuntu vs Debian² and there are many more articles
>> that help explain which OS is right for you.
>> 
>> Regards,
>> John
>>> 
>>> 
>>> 
>>> On Thu, Aug 14, 2014 at 10:55 PM, John Syn  wrote:
 
 From:  Brian Anderson 
 Reply-To:  "beagleboard@googlegroups.com" 
 Date:  Thursday, August 14, 2014 at 12:48 PM
 To:  "beagleboard@googlegroups.com" 
 Subject:  Re: [beagleboard] Setting up TFTP and NFS
 
> 
>> If you want my opinion, ditch Linux mint *NOW*. Personally I will not use
>> anything other than Debian for a support system to the BBB, and would
>> NEVER use X for this purpose. Especially in a VM . . .
>> 
>> Yeah yeah, Linux mint is based on Ubuntu and Debian( testing ) (
>> depending on version ), but thats part of the problem.
>> 
> 
> Hmmm, OK!  Would you like to enumerate why you wouldn't use Mint?  I was
> under the impression the Mint-17 is based upon Ubuntu 14.04LTS, and thus
> fairly stable.  Personally, I can't stand Unity...but YMMV.  What distro
> would you suggest?
> 
> Well, at the moment, all I have is my MBP laptop to support this effort.
> So, either I setup NFS on the MAC and hope for the best, or use a VM
> running some Linux.  I thought I'd give the VM approach a try as a first
> step in order to not introduce native MAC NFS vagaries into the mix.
> Probably could try that option now that I have things limping along.
> 
> When you say NEVER use X, I'm assuming you mean running X windows on a dev
> env (Linux Mint)?  I'm not running X on the BBB (well, I do often use X
> forwarding to the MAC/XQuartz for stuff like (gasp) emacs, xterm, ...).
> My thought was to do dev on the MAC (straight away or via a VM) using a
> shared file system between the MAC and BBB so I didn't have to copy files
> around, nor risk loosing everything if the BBB goes toes in the air or the
> uSD craps out.
 I have a MBP which I love, but I wouldn¹t use it for development for the
 same reasons I wouldn¹t use Windows for development and that is because
 neither support case sensitive file system. Also, OSX tools are quite old
 and sometime incompatible with their GNU equivalents (options are different
 more often than not compared to GNU versions), so you have to use MacPort,
 HomeBrew, Fink, etc. Regarding Mint, Ubuntu, Debian, etc, there isn¹t
 really much between them other than personal preferences. There are both
 benefits and downsides to each, so choose one and stay with it. Truly
 speaking, each one needs some work to get it stable and working the way you
 want. Debian might be perceived as more stable, but it uses old version of
 almost every package and the core repository is way smaller than Ubuntu so
 you have to hunt around for other repos to find the packages you need and
 then Debian becomes less stable. Ubuntu was a bit flaky for a while

Re: [beagleboard] USB problems on Rev C (not sure which revision)

[Gerald Coley]

There is only one Rev C board. Rev C is the version of the board. The
sticker saying Rev C indicated Rev C. Not REV C1 which does not exist.

Gerald



On Fri, Aug 15, 2014 at 9:53 AM,  wrote:

> I just received my first BBB Rev C a few weeks ago and am having some
> problems with powered USB hubs.  First of all I'm trying to determine which
> revision of Rev C the board is.  The sticker just says 'C' with no number.
>  Does this indicate it's a C1?
>
> I need to run both a webcam and a USB WiFi module (RTL8192cu.)  Both the
> webcam and WiFi module work great if plugged directly into the USB Host
> port one at a time.  In addition, if I use the powered USB hub with the
> WiFi module it still works great.  But if I plug in the webcam to the USB
> port (by itself or along with the WiFi) i get no access to it.
>
> I can plug in other devices (i.e. a DVB SDR, or a thumb drive) along with
> the WiFi module and it still works.  It just seems to be the webcam that
> puts it over the top.
>
> I am powering the BBB with a 2.5a wall wart, and the USB hub is being
> powered with a 2.0a wall wart (switching.)  I'm pretty sure there is plenty
> of power.  Maybe it's noisy?  How do I start to debug this?
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [beagleboard] Beagleboard-xm avaliability

[Gerald Coley]

16 weeks assuming the minimum order has been placed by an
authorized distributor..

Gerald



On Fri, Aug 15, 2014 at 12:14 PM,  wrote:

> What is the standard leadtime of the beagleboard-xm? If i am trying to
> plan ahead... i need to know how far ahead of a order i should be. 8 weeks,
> 12 weeks, 20 weeks?
>
>
> On Tuesday, August 5, 2014 11:00:30 AM UTC-7, Gerald wrote:
>
>> I do not know. If we have, it would not be something you would see.
>>
>> Gerald
>>
>>
>>
>> On Tue, Aug 5, 2014 at 12:37 PM,  wrote:
>>
>>> Have you guys given them a confirmation date?
>>>
>>>
>>> On Tuesday, August 5, 2014 6:49:00 AM UTC-7, Gerald wrote:
>>>
 We are building a batch of boards for DigiKey in the next couple of
 weeks. They placed an order.

 Gerald



 On Tue, Aug 5, 2014 at 8:22 AM, julianofabreu via BeagleBoard <
 beagl...@googlegroups.com> wrote:

>  I have the same problem, I bought beagleboards on Jameco and the
> order ship date was changed from August to October.
> I really need to buy around 60 beagles.
>
>
>
> On Thursday, July 31, 2014 10:24:24 AM UTC-3, Antonio Solorzano wrote:
>
>> I have placed a order for 40 units.
>> On Jul 30, 2014 11:53 AM, "Gerald Coley" 
>> wrote:
>>
>>>  They only sale though distributors so it is up to
>>> the distributor to handle this.The idea of setting up
>>> a production line, loading the parts to build one board would make the 
>>> cost
>>> of this board around $500. Orders would need to be entered by
>>> the distributors. I am not sure any of them would be willing to order
>>> 1500 boards just so they can sell you one board. It is basic supply and
>>> demand. If we have real demand then we will supply.
>>>
>>>  If you want one board ask around the community and see if anyone
>>> has one to sale.
>>>
>>>
>>> Gerald
>>>
>>>
>>>
>>> On Wed, Jul 30, 2014 at 11:47 AM,  wrote:
>>>
 Hello,
 I placed a order with Digikey on July 2, 2014. I have yet to
 received a due date or dock date, Digi has been trying to get a date, i
 have tried to email Rod at CircuitCo.
 Its been almost 4 weeks with nothing... no type of answers. Where
 can i get help with this issue?


 On Wednesday, June 18, 2014 7:07:04 AM UTC-7, Gerald wrote:

> If the distributors orders boards from us, we will build them. It
> has not been discontinued. But, unless they order boards, we cannot 
> ship
> them boards.
>
> Gerald
>
>
>
> On Thu, Jun 5, 2014 at 4:04 PM, Francisco de Souza Júnior <
> fsju...@gmail.com> wrote:
>
>> Hi,
>>
>> I'm looking for a Beagleboard-xm to buy in all distributors
>> sugested by beagleboard.org (digikey, mouser, farnell etc) but
>> there is no board avaliable to buy!
>>
>> The Beagleboard-xm has been discontinuated?
>>
>>
>> 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...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to the Google
 Groups "BeagleBoard" group.
 To unsubscribe from this group and stop receiving emails from it,
 send an email to beagleboard...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>  --
>>> For more options, visit http://beagleboard.org/discuss
>>> ---
>>> You received this message because you are subscribed to a topic in
>>> the Google Groups "BeagleBoard" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>> pic/beagleboard/cDyFEX6W_i0/unsubscribe.
>>>  To unsubscribe from this group and all its topics, send an email to
>>> beagleboard...@googlegroups.com.
>>>
>>> For more options, visit https://groups.google.com/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...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>

  --
>>> For more options, visit http://beagl

[beagleboard] BBB runs fine through usb but will not display anything through hdmi

[justtryingtolearn]

 

Ive read through the manual a few times but could have missed something.

>From the usb side everything works, web server, bonescript interactive 
guide, cloud9, ect

However from the hdmi/standalone side

1.   Plug in power supply via barrel plug (tried 1A, 1.5A 2.5A and 7A 
5v supplies)

2.   Once heartbeat starts flashing plug in hdmi

3.   And… nothing… sometimes the display turns black like it’s trying 
to work, others nothing at all,  ive tried with and w/o mice/keyboard

One time it did boot, but the display was flickering every few seconds, I 
could not get the mouse or keyboard to work the board seemed “frozen” (with 
and without usb hub)

Also attempted to boot from flash drive with no luck.

I know the monitor, mouse and keyboard are good, setup a raspberry pi this 
morning.

The only problem I can think of would be the hdmi cable, contacted the 
seller to see if they will ship another one. Other than that any ideas? I 
bet it’s something silly simple…usually is… really excited to get it 
running, when it did boot it loaded much faster than the pi 


have the c version

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

[beagleboard] Re: Copy eMMC Image On Ubuntu 13.10 BeagleBone Black

[sean . luis . stecker]

Actually I misspoke, the image is just under 2 GB not over 2 GB but the 
original point still stands.

On Thursday, August 14, 2014 2:20:16 PM UTC-4, sean.lui...@gmail.com wrote:
>
> Hello,
>
> I want to set up a master BBB running Ubuntu 13.10 saucy from the eMMC. I 
> then would like to duplicate everything about that master board and stick 
> it on a new board, including users, files and services. I'm wondering if 
> this is possible.
>
> I have already tried the procedure listed at 
> http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents but it 
> doesn't seem to work. I can extract an image file from the master, but all 
> attempts to flash the image onto the new BBB have not succeeded. When I 
> hold the S2 button and power on the device, the USR0 light blinks shortly 
> as expected but then persists after only 20 seconds, but the image file is 
> over 2GB so it should take longer than that.
>
>  I have tried altering the if to be /dev/mmcblk0 considering that is what 
> fdisk returns for me when run on the master. I have tried the bs at 10M as 
> well as altering it to 1M and gone to no avail. I have deleted everything 
> off of the new BBB when it is mounted on Windows and nothing happened. I 
> have set the primary partition on the uSD card to be active. I have tried 
> writing the resulting image to the uSD using Win32DiskImager.
>
> I'm wondering if anyone has any ideas as to either a solution to my 
> current method or an alternative that is just as good.
>
> Thanks.
>

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

Re: [beagleboard] Re: Minecraft Server

[Alien Glow]

Surpisingly, the RasPi outperforms the BBB quite often.


On Tue, Jun 24, 2014 at 2:57 PM, William Hermans  wrote:

> If an rPI can run minecraft server, so can the BBB. NO need to overclock,
> or use something else.  Will it be good enough ? No idea.
>
>
> On Tue, Jun 24, 2014 at 11:52 AM, Micka  wrote:
>
>> look at ODROID
>>
>> http://www.hardkernel.com/main/products/prdt_info.php?g_code=G137510300620
>>
>> enjoy,
>>
>>
>> On Tue, Jun 24, 2014 at 7:26 AM,  wrote:
>>
>>> It's possible, but overclocking the cpu and installing a fan on your
>>> case would definitely help.
>>>
>>> On Saturday, May 12, 2012 12:30:11 PM UTC-4, Soranne wrote:

 Does anyone know if it is possible to run a Minecraft Server on the
 beaglebone? and how?
 I mean the server needs a lot of RAM, is there anyway to compile java
 for arm so that is quicker on anything like that?
 Because i know that some people have managed to run one on the
 raspberry pi...

 Thank you

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

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

[beagleboard] USB problems on Rev C (not sure which revision)

[warcher1us]

I just received my first BBB Rev C a few weeks ago and am having some 
problems with powered USB hubs.  First of all I'm trying to determine which 
revision of Rev C the board is.  The sticker just says 'C' with no number. 
 Does this indicate it's a C1?

I need to run both a webcam and a USB WiFi module (RTL8192cu.)  Both the 
webcam and WiFi module work great if plugged directly into the USB Host 
port one at a time.  In addition, if I use the powered USB hub with the 
WiFi module it still works great.  But if I plug in the webcam to the USB 
port (by itself or along with the WiFi) i get no access to it.

I can plug in other devices (i.e. a DVB SDR, or a thumb drive) along with 
the WiFi module and it still works.  It just seems to be the webcam that 
puts it over the top.

I am powering the BBB with a 2.5a wall wart, and the USB hub is being 
powered with a 2.0a wall wart (switching.)  I'm pretty sure there is plenty 
of power.  Maybe it's noisy?  How do I start to debug this?

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

[beagleboard] Re: Ad-hoc network together with access point

[vivak24]

Hi all ,

I am sorry.I know this is not going to help , but i had a query.How did you 
establish an ad-hoc connection between the beaglebone and your laptop.I use 
a macbook and the beagle distribution is debian.I tried using wicd-curses 
but that did not help.Any help on this is greatly appreciated.

Regards,
Vivak Katla

On Thursday, 7 August 2014 12:21:27 UTC-4, paullo...@gmail.com wrote:
>
> Hi,all
>
> I am using five BeagleBone Black with 2 WiFi antenna connected to each 
> BeagleBone Black.
>
> On each BeagleBone Black, one of the WiFi antenna is configured for an 
> ad-hoc network, the other WiFi antenna is configured as an access point to 
> allow mobile devices to join the ad-hoc network via the access point.
>
> The result is that the mobile devices can get associated to the access 
> point and access a web server in the ad-hoc network.
>  
> However, the mobile device of Access Point 1 (AP1) is not able to 
> communicate with the mobile devices of Access Point 2 (AP2). 
>
> I have add in the route of the subnet of mobile devices of AP2 in AP1 and 
> vice versa.
>
> Did anyone has experience in configuring ad-hoc network together with 
> access point on a single BeagleBone Black?
>
> Is it possible?
>
> Thank you.
>
> Rdgs,
> Paul
>
>

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

Re: [beagleboard] Beagleboard-xm avaliability

[solorzano . tony]

What is the standard leadtime of the beagleboard-xm? If i am trying to plan 
ahead... i need to know how far ahead of a order i should be. 8 weeks, 12 
weeks, 20 weeks?

On Tuesday, August 5, 2014 11:00:30 AM UTC-7, Gerald wrote:
>
> I do not know. If we have, it would not be something you would see.
>
> Gerald
>
>
>
> On Tue, Aug 5, 2014 at 12:37 PM, > 
> wrote:
>
>> Have you guys given them a confirmation date?
>>
>>
>> On Tuesday, August 5, 2014 6:49:00 AM UTC-7, Gerald wrote:
>>
>>> We are building a batch of boards for DigiKey in the next couple of 
>>> weeks. They placed an order.
>>>
>>> Gerald
>>>
>>>
>>>
>>> On Tue, Aug 5, 2014 at 8:22 AM, julianofabreu via BeagleBoard <
>>> beagl...@googlegroups.com> wrote:
>>>
  I have the same problem, I bought beagleboards on Jameco and the 
 order ship date was changed from August to October.
 I really need to buy around 60 beagles.



 On Thursday, July 31, 2014 10:24:24 AM UTC-3, Antonio Solorzano wrote:

> I have placed a order for 40 units. 
> On Jul 30, 2014 11:53 AM, "Gerald Coley"  
> wrote:
>
>>  They only sale though distributors so it is up to 
>> the distributor to handle this.The idea of setting up 
>> a production line, loading the parts to build one board would make the 
>> cost 
>> of this board around $500. Orders would need to be entered by 
>> the distributors. I am not sure any of them would be willing to order 
>> 1500 boards just so they can sell you one board. It is basic supply and 
>> demand. If we have real demand then we will supply.
>>
>>  If you want one board ask around the community and see if anyone has 
>> one to sale. 
>>
>>
>> Gerald
>>
>>
>>
>> On Wed, Jul 30, 2014 at 11:47 AM,  wrote:
>>
>>> Hello,
>>> I placed a order with Digikey on July 2, 2014. I have yet to 
>>> received a due date or dock date, Digi has been trying to get a date, i 
>>> have tried to email Rod at CircuitCo. 
>>> Its been almost 4 weeks with nothing... no type of answers. Where 
>>> can i get help with this issue?
>>>
>>>
>>> On Wednesday, June 18, 2014 7:07:04 AM UTC-7, Gerald wrote:
>>>
 If the distributors orders boards from us, we will build them. It 
 has not been discontinued. But, unless they order boards, we cannot 
 ship 
 them boards.

 Gerald



 On Thu, Jun 5, 2014 at 4:04 PM, Francisco de Souza Júnior <
 fsju...@gmail.com> wrote:

> Hi,
>
> I'm looking for a Beagleboard-xm to buy in all distributors 
> sugested by beagleboard.org (digikey, mouser, farnell etc) but 
> there is no board avaliable to buy! 
>
> The Beagleboard-xm has been discontinuated? 
>
>
> 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...@googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
>

  -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, 
>>> send an email to beagleboard...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to a topic in 
>> the Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/beagleboard/cDyFEX6W_i0/unsubscribe.
>>  To unsubscribe from this group and all its topics, send an email to 
>> beagleboard...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/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...@googlegroups.com.

 For more options, visit https://groups.google.com/d/optout.

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

Re: [beagleboard] Re: Enable LCD4 adding .dts to Kernel source v3.1x ?

[stefanoiu]

Hi Cedric,

I'm trying to make a LCD4 to work with this 3.15 kernel but I have no luck.
Can you tell me what changes did you make?

Thanks!

Regards,
Razvan

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

Re: [beagleboard] Re: 3 proposed patches for next 3.8.13-bone5x update

[Alexander Hayman]

I am using Robert's bb-kernel git repo to build the kernel.  It looks
like we are using the exact same compiler.
Linux version 3.8.13-bone62 (root@debian) (gcc version 4.7.3 20130328
(prerelease) (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro
GCC 2013.04) )

I noticed that you are passing specific commands to the capemgr.
"capemgr.enable_partno=BB-VIEW-LCD4-01"  This I am not doing.  Should I
be doing this? If I force it to capemgr.enable_partno=BB-BONE-LCD4-01,
then maybe it will work even if your patch is installed?

This is what the detection of the screen looks like on my kernel without
the patches.  Maybe the kernel is getting confused and using BB-VIEW dtb
for my LCD instead of BB-BONE dtb?

[0.725548] bone-capemgr bone_capemgr.9: Baseboard:
'A335BNLT,00A5,4110BBBK'
[0.725572] bone-capemgr bone_capemgr.9:
compatible-baseboard=ti,beaglebone-black
[0.755349] bone-capemgr bone_capemgr.9: slot #0: No cape found
[0.792456] bone-capemgr bone_capemgr.9: slot #1: No cape found
[0.829564] bone-capemgr bone_capemgr.9: slot #2: No cape found
[0.859739] bone-capemgr bone_capemgr.9: slot #3: '4D 4.3 LCD CAPE-
4DCAPE-43T ,00A1,4D SYSTEMS  ,BB-BONE-LCD4-01'
[0.859839] bone-capemgr bone_capemgr.9: slot #4: specific override
[0.859859] bone-capemgr bone_capemgr.9: bone: Using override eeprom
data at slot 4
[0.859873] bone-capemgr bone_capemgr.9: slot #4:
'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
[0.859945] bone-capemgr bone_capemgr.9: slot #5: specific override
[0.859963] bone-capemgr bone_capemgr.9: bone: Using override eeprom
data at slot 5
[0.859977] bone-capemgr bone_capemgr.9: slot #5:
'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
[0.860046] bone-capemgr bone_capemgr.9: slot #6: specific override
[0.860063] bone-capemgr bone_capemgr.9: bone: Using override eeprom
data at slot 6
[0.860077] bone-capemgr bone_capemgr.9: slot #6:
'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
[0.860405] bone-capemgr bone_capemgr.9: loader: before slot-3
BB-BONE-LCD4-01:00A1 (prio 0)
[0.860420] bone-capemgr bone_capemgr.9: loader: check slot-3
BB-BONE-LCD4-01:00A1 (prio 0)
[0.860500] bone-capemgr bone_capemgr.9: loader: before slot-4
BB-BONE-EMMC-2G:00A0 (prio 1)
[0.860512] bone-capemgr bone_capemgr.9: loader: check slot-4
BB-BONE-EMMC-2G:00A0 (prio 1)
[0.860585] bone-capemgr bone_capemgr.9: loader: before slot-5
BB-BONELT-HDMI:00A0 (prio 1)
[0.860598] bone-capemgr bone_capemgr.9: loader: check slot-5
BB-BONELT-HDMI:00A0 (prio 1)
[0.860632] bone-capemgr bone_capemgr.9: initialized OK.
[0.861126] bone-capemgr bone_capemgr.9: loader: after slot-3
BB-BONE-LCD4-01:00A1 (prio 0)
[0.861145] bone-capemgr bone_capemgr.9: slot #3: Requesting part
number/version based 'BB-BONE-LCD4-01-00A1.dtbo
[0.861167] bone-capemgr bone_capemgr.9: slot #3: Requesting firmware
'BB-BONE-LCD4-01-00A1.dtbo' for board-name '4D 4.3 LCD CAPE-
4DCAPE-43T ', version '00A1'
[0.861186] bone-capemgr bone_capemgr.9: slot #3: dtbo
'BB-BONE-LCD4-01-00A1.dtbo' loaded; converting to live tree
[0.861686] bone-capemgr bone_capemgr.9: slot #3: #4 overlays


On 8/13/2014 3:06 PM, Scott Michel wrote:
> Alexander:
>
> Short answer: It works for me. :-)
>
> It turns out that a colleague has an Element-14 4.3" LCD cape here at
> work. I just booted up after changing uEnv.txt. Hard to work on the
> BBB at that screen resolution, but I don't have the image compression
> that you experienced.
>
> I'm not at the most recent tag on Robert's tree, but I could test it
> later this week. But given that the E-14 4.3" LCD cape works, it makes
> me wonder if the problem isn't with the DTB's pixel and dot clocking
> params?
>
> Now, I'll admit that I compiled my kernel with the 4.7.3 20130328
> prerelease compiler, so that could have made a difference if there
> were a compiler bug:
>
> [0.00] Linux version 3.8.13-bone53 (-@) (gcc
> version 4.7.3 20130328 (prerelease) (crosstool-NG
> linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) ) #40 SMP Fri
> May 30 13:18:49 PDT 2014
> [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: Generic AM33XX (Flattened Device Tree), model:
> TI AM335x BeagleBone
> [0.00] Memory policy: ECC disabled, Data cache writeback
> [0.00] On node 0 totalpages: 130816
> [0.00] free_area_init_node: node 0, pgdat c0880640,
> node_mem_map c08fb000
> [0.00]   Normal zone: 1024 pages used for memmap
> [0.00]   Normal zone: 0 pages reserved
> [0.00]   Normal zone: 129792 pages, LIFO batch:31
> [0.00] AM335X ES2.1 (l2cache sgx neon )
> [0.00] PERCPU: Embedded 9 pages/cpu @c0d0b000 s14080 r8192
> d14592 u36864
> [0.00] pcpu-alloc: s14080 r8192 d14592 u36864 alloc=9*4096

Re: [beagleboard] Re: Device tree overlays may load manually, but not at boot.

[Terje Froysa]

> Ok, thanks!

 
I'll have to cope with that solution.
I really appreciate that you took your time to explain this.
>From  what I have read from the web, there is a lot of mis-leading 
information and a lot of confused people (me included).
 
The nice thing with Linux is that there is always a work-a-round (even if 
you must construct one yourself).
The draw-back is that the information can be hard to find.
 
I have been working with embedded programming for over 30 years. 
Mostly bottom up with homemade preemtive RTOS and VME VRTX etc. but I am a 
newbi to Linux though.
 
Best regards
Terje Froysa
 

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

Re: [beagleboard] Setting up TFTP and NFS

[William Hermans]

I do not need to read an article or google John, I've had tons of
experience with both.


On Fri, Aug 15, 2014 at 9:37 AM, John Syn  wrote:

>
> From: William Hermans 
> Reply-To: "beagleboard@googlegroups.com" 
> Date: Thursday, August 14, 2014 at 11:55 PM
>
> To: "beagleboard@googlegroups.com" 
> Subject: Re: [beagleboard] Setting up TFTP and NFS
>
> *Debian might be perceived as more stable, but it uses old version of
>> almost every package and the core repository is way smaller than Ubuntu so
>> you have to hunt around for other repos to find the packages you need and
>> then Debian becomes less stable.*
>>
>
> Hunt around for what packages ? In the context of the current discussion
> I've never had to "hunt" for anything. I've had to compile my own stuff
> from sources when I wanted something custom . . . Now if you want cutting
> edge stuff, you're almost certainly going to run into trouble no matter
> what distro you use. But that is not what we're talking about. We're
> talking about running a distro in a VM for the sole purpose of supporting
> the Beaglebone black.
>
> The following article does a pretty fair comparison of Ubuntu vs Debian.
>
> http://www.udemy.com/blog/debian-vs-ubuntu/
>
> Just search google for “Ubuntu vs Debian” and there are many more articles
> that help explain which OS is right for you.
>
> Regards,
> John
>
>
>
>
> On Thu, Aug 14, 2014 at 10:55 PM, John Syn  wrote:
>
>>
>> From: Brian Anderson 
>> Reply-To: "beagleboard@googlegroups.com" 
>> Date: Thursday, August 14, 2014 at 12:48 PM
>> To: "beagleboard@googlegroups.com" 
>> Subject: Re: [beagleboard] Setting up TFTP and NFS
>>
>>
>> If you want my opinion, ditch Linux mint *NOW*. Personally I will not use
>>> anything other than Debian for a support system to the BBB, and would NEVER
>>> use X for this purpose. Especially in a VM . . .
>>>
>>> Yeah yeah, Linux mint is based on Ubuntu and Debian( testing ) (
>>> depending on version ), but thats part of the problem.
>>>
>>>
>> Hmmm, OK!  Would you like to enumerate why you wouldn't use Mint?  I was
>> under the impression the Mint-17 is based upon Ubuntu 14.04LTS, and thus
>> fairly stable.  Personally, I can't stand Unity...but YMMV.  What distro
>> would you suggest?
>>
>> Well, at the moment, all I have is my MBP laptop to support this effort.
>> So, either I setup NFS on the MAC and hope for the best, or use a VM
>> running some Linux.  I thought I'd give the VM approach a try as a first
>> step in order to not introduce native MAC NFS vagaries into the mix.
>> Probably could try that option now that I have things limping along.
>>
>> When you say NEVER use X, I'm assuming you mean running X windows on a
>> dev env (Linux Mint)?  I'm not running X on the BBB (well, I do often use X
>> forwarding to the MAC/XQuartz for stuff like (gasp) emacs, xterm, ...).  My
>> thought was to do dev on the MAC (straight away or via a VM) using a shared
>> file system between the MAC and BBB so I didn't have to copy files around,
>> nor risk loosing everything if the BBB goes toes in the air or the uSD
>> craps out.
>>
>> I have a MBP which I love, but I wouldn’t use it for development for the
>> same reasons I wouldn’t use Windows for development and that is because
>> neither support case sensitive file system. Also, OSX tools are quite old
>> and sometime incompatible with their GNU equivalents (options are different
>> more often than not compared to GNU versions), so you have to use MacPort,
>> HomeBrew, Fink, etc. Regarding Mint, Ubuntu, Debian, etc, there isn’t
>> really much between them other than personal preferences. There are both
>> benefits and downsides to each, so choose one and stay with it. Truly
>> speaking, each one needs some work to get it stable and working the way you
>> want. Debian might be perceived as more stable, but it uses old version of
>> almost every package and the core repository is way smaller than Ubuntu so
>> you have to hunt around for other repos to find the packages you need and
>> then Debian becomes less stable. Ubuntu was a bit flaky for a while, but
>> 14.04 is much better and the distro I use daily.
>>
>> Regards,
>> John
>>
>>
>>
>> I'm all ears on suggestions for a good dev setup though!
>>
>> Cheers,
>>
>> ba
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Trying to boot 3.16 kernel on Beaglebone White

[Robert Nelson]

On Fri, Aug 15, 2014 at 11:01 AM, Steven Rostedt  wrote:
>
>
> On Friday, August 15, 2014 11:23:25 AM UTC-4, RobertCNelson wrote:
>>
>>
>> Humm, off hand i'm not sure what config is causing the reboot lockup.
>> i know in my v3.16.x kitchen_sink_config it's rebooting..
>>
>
> Can you email me that config please: rost...@goodmis.org
>

It's right here:

https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.16/patches/defconfig

ubuntu@arm:~$ uname -a
Linux arm 3.16.1-bone3 #1 Fri Aug 15 01:58:32 UTC 2014 armv7l armv7l
armv7l GNU/Linux
ubuntu@arm:~$ sudo reboot
[sudo] password for ubuntu:
ubuntu@arm:~$
Broadcast message from ubuntu@arm
(/dev/ttyO0) at 17:11 ...

The system is going down for reboot NOW!
[   37.854354] reboot: Restarting system

U-Boot SPL 2014.07-00016-g329fca9 (Jul 28 2014 - 12:35:02)
reading u-boot.img
reading u-boot.img

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: [beagleboard] Re: Device tree overlays may load manually, but not at boot.

[Robert Nelson]

On Fri, Aug 15, 2014 at 11:08 AM, Terje Froysa  wrote:
>> Thanks again for your quick reply!
>
>
> With "as intended" I refer to the lecture given at:
> http://elinux.org/BeagleBone_Black_Enable_SPIDEV
> and many other lectures i have studied made me think that I (anyone) could
> throw out predefined pin configurations and ad-hoc substitute them with my
> own in the /lib/firmware directory.

That "works" for the old Angstrom image. I 'can' make it work the same
way with debian, however there will be a 2 minute delay on bootup
thanks to udev on bootup.

> When I find the .dtbo working by placing them /lib/firmware and using "echo
> .dtbo > $SLOTS, I (of course) get confused when the files are not
> accepted (and with no explanation) during boot.
> The confusion arises (like you say) when no other .dtbo file is accepted
> during boot but the "built ins" while no information is given but "loading
> failed".
> Replacing an existing .dtbo and finding that the pins were configured as the
> origninal file suggests that the content of the /lib/firmware .dtbo's
> doesn't seem to count at all.
>
> I have used some 4-5 working days on this subject convinced that it all had
> to be my mistake since I couldn't find any consistent information about
> this. All documents and lectures on the web seemed to tell that loading
> custom ad-hoc .dtbo's by uEnv.txt was feasible.
>
> You are the first to tell me that the Linux cape configurations have to be
> furnished by anyone but ourselves. We are making a one-of-a-kind cape in a
> scientific research context. It really shouldn't be necessary to submit a
> short-sighted experiment although in professional context. We are doing
> changes steadily and plan to use BBB in many different activities (also in
> cooperation with the NTNU, Norwegian University of Technology). I don't
> think we will want to overthrow you with numerous patches for different
> projects.
>
> Well, I'm learning, but knowledge is sometime hard to obtain.
> In 1987, as a Unix system responsible, I learned the saying:
> "Manuals...? Which manuals...? This is Unix my son, you gotta know!" :-)
>
> I guess I have to do a script running after boot that loads the .dtbo and
> reconfigures the pins.

see:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Loading_custom_capes

It's already setup for you to use it in the image.

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: [beagleboard] Setting up TFTP and NFS

[John Syn]

From:  William Hermans 
Reply-To:  "beagleboard@googlegroups.com" 
Date:  Thursday, August 14, 2014 at 11:55 PM
To:  "beagleboard@googlegroups.com" 
Subject:  Re: [beagleboard] Setting up TFTP and NFS

>> Debian might be perceived as more stable, but it uses old version of almost
>> every package and the core repository is way smaller than Ubuntu so you have
>> to hunt around for other repos to find the packages you need and then Debian
>> becomes less stable.
> 
> Hunt around for what packages ? In the context of the current discussion I've
> never had to "hunt" for anything. I've had to compile my own stuff from
> sources when I wanted something custom . . . Now if you want cutting edge
> stuff, you're almost certainly going to run into trouble no matter what distro
> you use. But that is not what we're talking about. We're talking about running
> a distro in a VM for the sole purpose of supporting the Beaglebone black.
The following article does a pretty fair comparison of Ubuntu vs Debian.

http://www.udemy.com/blog/debian-vs-ubuntu/

Just search google for ³Ubuntu vs Debian² and there are many more articles
that help explain which OS is right for you.

Regards,
John
> 
> 
> 
> On Thu, Aug 14, 2014 at 10:55 PM, John Syn  wrote:
>> 
>> From:  Brian Anderson 
>> Reply-To:  "beagleboard@googlegroups.com" 
>> Date:  Thursday, August 14, 2014 at 12:48 PM
>> To:  "beagleboard@googlegroups.com" 
>> Subject:  Re: [beagleboard] Setting up TFTP and NFS
>> 
>>> 
 If you want my opinion, ditch Linux mint *NOW*. Personally I will not use
 anything other than Debian for a support system to the BBB, and would NEVER
 use X for this purpose. Especially in a VM . . .
 
 Yeah yeah, Linux mint is based on Ubuntu and Debian( testing ) ( depending
 on version ), but thats part of the problem.
 
>>> 
>>> Hmmm, OK!  Would you like to enumerate why you wouldn't use Mint?  I was
>>> under the impression the Mint-17 is based upon Ubuntu 14.04LTS, and thus
>>> fairly stable.  Personally, I can't stand Unity...but YMMV.  What distro
>>> would you suggest?
>>> 
>>> Well, at the moment, all I have is my MBP laptop to support this effort.
>>> So, either I setup NFS on the MAC and hope for the best, or use a VM running
>>> some Linux.  I thought I'd give the VM approach a try as a first step in
>>> order to not introduce native MAC NFS vagaries into the mix.  Probably could
>>> try that option now that I have things limping along.
>>> 
>>> When you say NEVER use X, I'm assuming you mean running X windows on a dev
>>> env (Linux Mint)?  I'm not running X on the BBB (well, I do often use X
>>> forwarding to the MAC/XQuartz for stuff like (gasp) emacs, xterm, ...).  My
>>> thought was to do dev on the MAC (straight away or via a VM) using a shared
>>> file system between the MAC and BBB so I didn't have to copy files around,
>>> nor risk loosing everything if the BBB goes toes in the air or the uSD craps
>>> out.
>> I have a MBP which I love, but I wouldn¹t use it for development for the same
>> reasons I wouldn¹t use Windows for development and that is because neither
>> support case sensitive file system. Also, OSX tools are quite old and
>> sometime incompatible with their GNU equivalents (options are different more
>> often than not compared to GNU versions), so you have to use MacPort,
>> HomeBrew, Fink, etc. Regarding Mint, Ubuntu, Debian, etc, there isn¹t really
>> much between them other than personal preferences. There are both benefits
>> and downsides to each, so choose one and stay with it. Truly speaking, each
>> one needs some work to get it stable and working the way you want. Debian
>> might be perceived as more stable, but it uses old version of almost every
>> package and the core repository is way smaller than Ubuntu so you have to
>> hunt around for other repos to find the packages you need and then Debian
>> becomes less stable. Ubuntu was a bit flaky for a while, but 14.04 is much
>> better and the distro I use daily.
>> 
>> Regards,
>> John
>>> 
>>> 
>>> I'm all ears on suggestions for a good dev setup though!
>>> 
>>> Cheers,
>>> 
>>> ba
>>> 
>>> -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you are subscribed to the Google Groups
>>> "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to beagleboard+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>> -- 
>> For more options, visit http://beagleboard.org/discuss
>> --- 
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you

Re: [beagleboard] Re: Device tree overlays may load manually, but not at boot.

[Terje Froysa]

>
> Thanks again for your quick reply!

 
With "as intended" I refer to the lecture given at:
*http://elinux.org/BeagleBone_Black_Enable_SPIDEV* 

and many other lectures i have studied made me think that I (anyone) could 
throw out predefined pin configurations and ad-hoc substitute them with my 
own in the /lib/firmware directory.
 
When I find the .dtbo working by placing them /lib/firmware and using "echo 
.dtbo > $SLOTS, I (of course) get confused when the files are not 
accepted (and with no explanation) during boot.
The confusion arises (like you say) when no other .dtbo file is accepted 
during boot but the "built ins" while no information is given but "loading 
failed".
Replacing an existing .dtbo and finding that the pins were configured as 
the origninal file suggests that the content of the /lib/firmware .dtbo's 
doesn't seem to count at all.
 
I have used some 4-5 working days on this subject convinced that it all had 
to be my mistake since I couldn't find any consistent information about 
this. All documents and lectures on the web seemed to tell that loading 
custom ad-hoc .dtbo's by uEnv.txt was feasible.
 
You are the first to tell me that the Linux cape configurations have to be 
furnished by anyone but ourselves. We are making a one-of-a-kind cape in a 
scientific research context. It really shouldn't be necessary to submit a 
short-sighted experiment although in professional context. We are doing 
changes steadily and plan to use BBB in many different activities (also in 
cooperation with the NTNU, Norwegian University of Technology). I don't 
think we will want to overthrow you with numerous patches for different 
projects.
 
Well, I'm learning, but knowledge is sometime hard to obtain.
In 1987, as a Unix system responsible, I learned the saying:
"Manuals...? Which manuals...? This is Unix my son, you gotta know!" :-)
 
I guess I have to do a script running after boot that loads the .dtbo and 
reconfigures the pins.
 
Best regards
Terje Froysa
 

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

Re: [beagleboard] Trying to boot 3.16 kernel on Beaglebone White

[Steven Rostedt]

On Friday, August 15, 2014 11:23:25 AM UTC-4, RobertCNelson wrote:
>
>
> Humm, off hand i'm not sure what config is causing the reboot lockup. 
> i know in my v3.16.x kitchen_sink_config it's rebooting.. 
>
>
Can you email me that config please: rost...@goodmis.org

Thanks!

-- 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Updated bone101

[Jason Kridner]

Thanks.

On Tue, Aug 12, 2014 at 10:48 AM, mtn_beagle
 wrote:
> Jason,
> The 101 page linked to through your github page still discusses the updating
> of the Angstrom image. With Rev C shipping with Debian, should there be two
> links for updating or is Angstrom no longer being updated?

Angstrom continues to get updated, but there hasn't been a community
push to verify the new images and have them pushed up to
http://beagleboard.org/latest-images. If I get sufficient requests,
I'll update that page with one of the newer Angstrom images. For now,
there is just the last Angstrom image that was used for production
images.

> Additionally, the
> BBB spec still indicates 2MB eMMC.

See 
https://github.com/beagleboard/bone101/commit/49b9139baf068ba5573b093e977fc47ff09e7d90
and let me know if this fixes it.


>
> Regards,
> David Richards
>
>
> On Monday, August 11, 2014 9:35:28 AM UTC-6, Jason Kridner wrote:
>>
>> I've just pushed an update to the bone101 presentation up on github:
>>
>> http://beagleboard.github.io/
>>
>> Having a github pages representation should make it much easier for people
>> to push patches, so I hope you'll take this opportunity to check it all out
>> and report/fix issues in the documentation that ships on the boards.
>>
>> Now that Jekyll is being used, we won't be able to do a simple git clone
>> to put the content onto the boards as Jekyll will need to be run to process
>> the content. I'll be working with Robert to enable that operation, but would
>> also love any hints on the best way to keep the repository on the boards
>> something that is easily editable. Not having a macro for the baseurl was
>> just proving too difficult.
>>
>> This is also in preparation to merging a Google Summer of Code project
>> that has the intention to make adding new tutorials to bone101 much easier.
>> You can get some info at http://beagleboard.org/gsoc, but there will be
>> further information coming out about it in the next few days as coding is
>> wrapping up and documentation is being finalized.
>>
>> Regards,
>> Jason
>
> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to the Google Groups
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [beagleboard] Trying to boot 3.16 kernel on Beaglebone White

[Robert Nelson]

On Fri, Aug 15, 2014 at 10:23 AM, Robert Nelson  wrote:
> On Fri, Aug 15, 2014 at 10:13 AM, Steven Rostedt  wrote:
>>>
>>
>> I still have a minor issue. Nothing too big as I can still get work done.
>>
>> One, is that the kernel does not keep the NIC mac address and just assigns a
>> new random one on boot.
>> This makes my dhcp server not give it the right ip address.
>
> I believe the in-kernel efuse mac address read (via dt) was NAK'ed and
> they asked to have u-boot set it up instead. (which u-boot doesn't' do
> yet either.)  Just can't find the discussion on l-o/l-a-k list's.

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/220371.html

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: [beagleboard] Trying to boot 3.16 kernel on Beaglebone White

[Robert Nelson]

On Fri, Aug 15, 2014 at 10:13 AM, Steven Rostedt  wrote:
>>
>
> I still have a minor issue. Nothing too big as I can still get work done.
>
> One, is that the kernel does not keep the NIC mac address and just assigns a
> new random one on boot.
> This makes my dhcp server not give it the right ip address.

I believe the in-kernel efuse mac address read (via dt) was NAK'ed and
they asked to have u-boot set it up instead. (which u-boot doesn't' do
yet either.)  Just can't find the discussion on l-o/l-a-k list's.

For these boards in my build farm, i'm just doing the 'hwaddress' override:

echo "hwaddress ether ${override_mac}" >> /etc/network/interfaces

>
> The second is that it does not reboot. It gets down to:
>
> Starting Notify Audit System and Update UTMP about System Shutdown...
> Stopping Remount API VFS...
> Stopped Remount API VFS[  OK
> ]
> Stopping Temporary Directory...
> Stopping Remount Root FS...
> Stopped Remount Root FS[  OK
> ]
> Stopped Temporary Directory[  OK
> ]
> Started Notify Audit System and Update UTMP about System Shutdown  [  OK
> ]
> Started Console System Reboot Logging  [  OK
> ]
>
>
> and then hangs. (this is the Angsbroem distro).
>
> Note, the supplied kernel comes keeps the NIC mac addr and reboots fine.

Humm, off hand i'm not sure what config is causing the reboot lockup.
i know in my v3.16.x kitchen_sink_config it's rebooting..

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: [beagleboard] Trying to boot 3.16 kernel on Beaglebone White

[Steven Rostedt]

>
>
>
I still have a minor issue. Nothing too big as I can still get work done.

One, is that the kernel does not keep the NIC mac address and just assigns 
a new random one on boot.
This makes my dhcp server not give it the right ip address.

The second is that it does not reboot. It gets down to:

Starting Notify Audit System and Update UTMP about System Shutdown...   
   
Stopping Remount API VFS... 
   
Stopped Remount API VFS[ 
 OK  ]
Stopping Temporary Directory... 
   
Stopping Remount Root FS... 
   
Stopped Remount Root FS[ 
 OK  ]
Stopped Temporary Directory[ 
 OK  ]
Started Notify Audit System and Update UTMP about System Shutdown  [ 
 OK  ]
Started Console System Reboot Logging  [ 
 OK  ]


and then hangs. (this is the Angsbroem distro).

Note, the supplied kernel comes keeps the NIC mac addr and reboots 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Trying to boot 3.16 kernel on Beaglebone White

[Steven Rostedt]

> > multi_v7_defconfig doesn't have the regular enabled: 
> > 
> > CONFIG_REGULATOR_TPS65217 
>
> and: 
>
> CONFIG_MFD_TPS65217 
>
> needs to be enabled to allow CONFIG_REGULATOR_TPS65217 
>

Thank you very much! I also had one other thing wrong, because it didn't 
originally work.
I was currently using  am335x-evm.dtb instead of am335x-bone.dtb. I 
used am335x-bone.dtb first
but changed it while debugging. I needed to put it back to boot with the 
above added configs.

Again, thanks for you quick reply!

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

Re: [beagleboard] Trying to boot 3.16 kernel on Beaglebone White

[Robert Nelson]

On Fri, Aug 15, 2014 at 9:31 AM, Robert Nelson  wrote:
> On Fri, Aug 15, 2014 at 9:19 AM, Steven Rostedt  wrote:
>> Hi everyone :-)
>>
>> I'm trying to test a fix for arm on the latest Linux kernel, and since my
>> snowball board recently died, I decided to test it
>> out on my beaglebone white. But I'm having trouble with it. Here's what I've
>> done so far:
>>
>> First, I updated u-boot to the latest at git://git.denx.de/u-boot.git
>>
>> I moved the kernel that came with the board to my tftp server and boot it
>> via:
>> bootcmd=bootp; run mmcargs; bootm
>> mmcargs=setenv bootargs console=${console} ${optargs} root=${mmcroot}
>> rootfstype=${mmcrootfstype}
>> console=ttyO0,115200n8
>> mmcroot=/dev/mmcblk0p2 ro
>> mmcrootfstype=ext4 rootwait
>>
>> This works fine when I boot the supplied kernel (3.2). But when I build and
>> boot my own kernel
>> (I've tried 3.13,3.14,3.15 and 3.16, and latest git) it stops at:
>>
>> [2.201723] omap_hsmmc 4806.mmc: unable to get vmmc regulator -517
>> [2.208937] platform 4806.mmc: Driver omap_hsmmc requests probe
>> deferral
>> [2.217172] Waiting for root device /dev/mmcblk0p2...
>>
>> I build the kernel as
>>
>> CROSS_COMPILE=arm-unknown-linux-gnueabi- make ARCH=arm multi_v7_defconfig
>
> multi_v7_defconfig doesn't have the regular enabled:
>
> CONFIG_REGULATOR_TPS65217

and:

CONFIG_MFD_TPS65217

needs to be enabled to allow CONFIG_REGULATOR_TPS65217

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: [beagleboard] Trying to boot 3.16 kernel on Beaglebone White

[Robert Nelson]

On Fri, Aug 15, 2014 at 9:19 AM, Steven Rostedt  wrote:
> Hi everyone :-)
>
> I'm trying to test a fix for arm on the latest Linux kernel, and since my
> snowball board recently died, I decided to test it
> out on my beaglebone white. But I'm having trouble with it. Here's what I've
> done so far:
>
> First, I updated u-boot to the latest at git://git.denx.de/u-boot.git
>
> I moved the kernel that came with the board to my tftp server and boot it
> via:
> bootcmd=bootp; run mmcargs; bootm
> mmcargs=setenv bootargs console=${console} ${optargs} root=${mmcroot}
> rootfstype=${mmcrootfstype}
> console=ttyO0,115200n8
> mmcroot=/dev/mmcblk0p2 ro
> mmcrootfstype=ext4 rootwait
>
> This works fine when I boot the supplied kernel (3.2). But when I build and
> boot my own kernel
> (I've tried 3.13,3.14,3.15 and 3.16, and latest git) it stops at:
>
> [2.201723] omap_hsmmc 4806.mmc: unable to get vmmc regulator -517
> [2.208937] platform 4806.mmc: Driver omap_hsmmc requests probe
> deferral
> [2.217172] Waiting for root device /dev/mmcblk0p2...
>
> I build the kernel as
>
> CROSS_COMPILE=arm-unknown-linux-gnueabi- make ARCH=arm multi_v7_defconfig

multi_v7_defconfig doesn't have the regular enabled:

CONFIG_REGULATOR_TPS65217

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

[beagleboard] Trying to boot 3.16 kernel on Beaglebone White

[Steven Rostedt]

Hi everyone :-)

I'm trying to test a fix for arm on the latest Linux kernel, and since my 
snowball board recently died, I decided to test it
out on my beaglebone white. But I'm having trouble with it. Here's what 
I've done so far:

First, I updated u-boot to the latest at git://git.denx.de/u-boot.git

I moved the kernel that came with the board to my tftp server and boot it 
via:
bootcmd=bootp; run mmcargs; bootm
mmcargs=setenv bootargs console=${console} ${optargs} root=${mmcroot} 
rootfstype=${mmcrootfstype}
console=ttyO0,115200n8
mmcroot=/dev/mmcblk0p2 ro
mmcrootfstype=ext4 rootwait

This works fine when I boot the supplied kernel (3.2). But when I build and 
boot my own kernel
(I've tried 3.13,3.14,3.15 and 3.16, and latest git) it stops at:

[2.201723] omap_hsmmc 4806.mmc: unable to get vmmc regulator -517
[2.208937] platform 4806.mmc: Driver omap_hsmmc requests probe 
deferral
[2.217172] Waiting for root device /dev/mmcblk0p2...

I build the kernel as

CROSS_COMPILE=arm-unknown-linux-gnueabi- make ARCH=arm multi_v7_defconfig
CROSS_COMPILE=arm-unknown-linux-gnueabi- make ARCH=arm dtbs
CROSS_COMPILE=arm-unknown-linux-gnueabi- make ARCH=arm LOADADDR=0x80008000 
-j8 zImage modules
cat arch/arm/boot/zImage arch/arm/boot/dts/am335x-evm.dtb > 
arch/arm/boot/zImage.beagle; mkimage -A arm -O linux -C none -T kernel -a 
0x80008000 -e 0x80008000 -d arch/arm/boot/zImage.beagle 
arch/arm/boot/uImage.beagle

Then I scp the uImage.beagle to my tftp server as the image to load, and 
reboot the beaglebone white.

I added debugging into the kernel to see what's happening. There's three 
times that the above error is shown.
That -517 is -EPROBE_DEFER. In drivers/regulator/core.c: 
regulator_dev_lookup() I added printks that look like so:

regulator_supply_alias(&dev, &supply);

printk("dev=%p of_node=%p\n", dev, dev ? dev->of_node : NULL);
/* first do a dt based lookup */
if (dev && dev->of_node) {
printk("dev=%s node=%s\n", dev->init_name, dev->of_node->name);
node = of_get_regulator(dev, supply);
if (node) {
list_for_each_entry(r, ®ulator_list, list) {
printk("r=%p dev=%s %s\n", r,
   r->dev.init_name,
   r->dev.of_node ? r->dev.of_node->name : "(NULL)");
if (r->dev.parent &&
node == r->dev.of_node)
return r;
}
printk("FAILED\n");
*ret = -EPROBE_DEFER;
return NULL;
} else {

Here's the output for that:

[1.843192] dev=cf0d6610 of_node=cfce38e4
[1.847374] dev=(null) node=mmc
[1.850666] prop_name=vmmc-supply
[1.854162] found regnode=regulator
[1.857803] r=cf18a000 dev=(null) fixedregulator
[1.862639] r=cf00a000 dev=(null) fixedregulator
[1.867455] r=cf049c00 dev=(null) (NULL)
[1.871542] FAILED

I don't know if this is a dts problem or what. But I doubt it's a hardware 
issue as I can boot the supplied 3.2 kernel with no problem.

Anyone have any ideas on how to get pass this. My workaround may be to just 
boot an nfs filesystem, but I really don't
feel like setting that up at the moment.

Thanks!

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

Re: [beagleboard] Re: Device tree overlays may load manually, but not at boot.

[Robert Nelson]

On Fri, Aug 15, 2014 at 9:06 AM, Terje Froysa  wrote:
> Thanks for your reply.
>
> We intend to use this BBB professionally and need to change the pin
> configurations at boot.

So the problem is..?

> From your reply it seem to me that device overlays cannot be used as
> intended.

Define "as intended": the overlays work. So unless you like waiting 2
minutes for udev to find the firmware under /lib/firmware/, they are
going to be "built-in"...

> We can remove and add predefined modules, but not change them...
> Is this really true?

If "BB-SPIDEV1-00A0.dtbo" is builtin, you can't name something else
that and expect your version to be loaded.. The file "build-in" has
preference..


> Does that mean that we cannot design a cape with our own ID and
> corresponding dtbo?

submit a patch like everyone else, and we will roll your "cape" in
like everyone else..

https://github.com/beagleboard/linux/blob/3.8/firmware/capes/BB-BEAGLELOGIC-00A0.dts
https://github.com/beagleboard/linux/blob/3.8/firmware/capes/BB-BONE-REPLICAP-00A1.dts
https://github.com/beagleboard/linux/blob/3.8/firmware/capes/cape-bone-argus-00A0.dts

> If yes, what will you recommend for us to do to solve the problem?
>
> If I generate a complete new am335x-boneblack.dtb, will that do?
> Or do we have to re-compile the kernel?

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

Re: [beagleboard] Re: Device tree overlays may load manually, but not at boot.

[Terje Froysa]

Thanks for your reply.
 
We intend to use this BBB professionally and need to change the pin 
configurations at boot.
>From your reply it seem to me that device overlays cannot be used as 
intended.
We can remove and add predefined modules, but not change them... 
Is this really true?
Does that mean that we cannot design a cape with our own ID and 
corresponding dtbo?
 
If yes, what will you recommend for us to do to solve the problem?

   - If I generate a complete new am335x-boneblack.dtb, will that do?
   - Or do we have to re-compile the kernel?

 
Best regards
Terje Froysa
 

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

Re: [beagleboard] Re: Device tree overlays may load manually, but not at boot.

[Robert Nelson]

On Fri, Aug 15, 2014 at 7:05 AM, Terje Froysa  wrote:
> Update:
> Originally there was a "BB-SPIDEV1-00A0.dtbo" in the /lib/firmware
> directory.

They are "built-into" the kernel, thus any "modifications" to the
files under /lib/firmware/ would be ignored.. thus we removed them, as
they just confused users.

> This file loads when enabled in the uEnv.txt.
> The file is unique in the system (checked with find / )
> Pin configuration of the pins if no .dtbo is loaded is 0x27.
> Experiments:
>
> Changing the name of the original file (and in the uEnv.txt)
>
> The loading fails under boot.
>
> Compiling the "BB-SPI1-SWP-01-00A0.dts" into a file named
> "BB-SPIDEV1-00A0.dtbo" and copying it til /lib/firmware.
> This file swaps the D0 and D1 pins.
>
> The load works, but the pin configuration is identical with the original
> file loaded, i.e. D0/D1 are not swapped...??

Because "BB-SPIDEV1-00A0.dtbo" is built-in, thus the modified version
is not loaded..

>  Compiling same file into "BB-SPIDEV1-SWP-00A0.dtbo", cp to /lib/firmware.
> Removing overlay file load in uEnv.txt and loading BB-SPIDEV1-SWP manually.
>
> The manual load works and pins configuration is changed, D0/D1 are swapped!

It should make sense with the above^

Regards,

-- 
Robert Nelson
http://www.rcn-ee.com/

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

[beagleboard] Re: Device tree overlays may load manually, but not at boot.

[Terje Froysa]

Update:
Originally there was a "BB-SPIDEV1-00A0.dtbo" in the /lib/firmware 
directory. 
This file loads when enabled in the uEnv.txt.
The file is unique in the system (checked with find / )
Pin configuration of the pins if no .dtbo is loaded is 0x27.
*Experiments:*

   1. Changing the name of the original file (and in the uEnv.txt)
  - The loading fails under boot.
   2. Compiling the "BB-SPI1-SWP-01-00A0.dts" into a file 
   named "BB-SPIDEV1-00A0.dtbo" and copying it til /lib/firmware.
   This file swaps the D0 and D1 pins.
  - The load works, but the* pin configuration is identical with the 
  original file loaded, i.e. D0/D1 are not swapped*...??
   3.  Compiling same file into "BB-SPIDEV1-SWP-00A0.dtbo", cp to 
   /lib/firmware. 
   Removing overlay file load in uEnv.txt and loading BB-SPIDEV1-SWP 
   manually.
  - The manual load works and *pins configuration is changed, D0/D1 are 
  swapped!*
   
Can anyone please explain this enigma??
Is there at all any down-to-earth documentation on this subject except for 
all the hear-says?
 
Best regards
Terje Froysa

On Thursday, August 14, 2014 6:02:32 PM UTC+2, Terje Froysa wrote:

>
> Dear Forum,
>
> I have now turned the web outside-in to find an answer to this question.
> I see a lot of subjects touching the subject, but the answers and 
> suggestions are mostly in the hear-say category and points in different 
> directions putting me off in an endless ghost-hunt.
>
> I have been testing various overlays, some loads without problems, other 
> won't load but can be manually loaded after boot.
> I can even rename an overlay that loads and it stops loading even if the 
> content is identical.
> I have changed the sequence of loading proving that the file system is 
> ready at the time of loading.
>
> I have tested the suggested solutions from:
> http://elinux.org/BeagleBone_Black_Enable_SPIDEV
>
> The .dtbo files does not load at boot, but can be loaded manually later. 
> And working when loaded!
> The boot log gives no clue of what the problem may be.
>
>
>- Is it the content of the .dtbo?
>- Is it the name of the .dtbo file?
>
> Please advice
> Best regards
> Terje Froysa
>
> *Running system:*
>
> debian@beaglebone:~$ uname -a
> Linux beaglebone 3.8.13-bone50 #1 SMP Tue May 13 13:24:52 UTC 2014 armv7l 
> GNU/Linux
> *Boot log showing BB-SPI1-SWP-01 not loading:*
> debian@beaglebone:~$ dmesg |grep BB-
> [ 0.00] Kernel command line: console=tty0 console=ttyO0,115200n8 
> capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN 
> capemgr.enable_partno=BB-I2C1,BB-SPI1-SWP-01 
> root=UUID=5a42a22f-1771-4c44-93ef-8879c38b63d9 ro rootfstype=ext4 rootwait 
> fixrtc quiet init=/lib/systemd/systemd
> [ 0.565888] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# 
> BB-BONELT-HDMI
> [ 0.565937] bone-capemgr bone_capemgr.9: Skipping disabled cape with part# 
> BB-BONELT-HDMIN
> [ 0.714324] bone-capemgr bone_capemgr.9: slot #4: 
> 'Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G'
> [ 0.714439] bone-capemgr bone_capemgr.9: slot #5: 
> 'Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI'
> [ 0.714540] bone-capemgr bone_capemgr.9: slot #6: 
> 'Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN'
> [ 0.714612] bone-capemgr bone_capemgr.9: enabled_partno part_number 
> 'BB-I2C1', version 'N/A', prio '0'
> [ 0.714653] bone-capemgr bone_capemgr.9: slot #7: 'Override Board 
> Name,00A0,Override Manuf,BB-I2C1'
> [ 0.714725] bone-capemgr bone_capemgr.9: enabled_partno part_number 
> 'BB-SPI1-SWP-01', version 'N/A', prio '0'
> [ 0.714762] bone-capemgr bone_capemgr.9: slot #8: 'Override Board 
> Name,00A0,Override Manuf,BB-SPI1-SWP-01'
> [ 0.714928] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape 
> with part# BB-BONELT-HDMI
> [ 0.714943] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape 
> with part# BB-BONELT-HDMIN
> [ 0.715135] bone-capemgr bone_capemgr.9: loader: before slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1)
> [ 0.715149] bone-capemgr bone_capemgr.9: loader: check slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1)
> [ 0.715228] bone-capemgr bone_capemgr.9: loader: before slot-7 
> BB-I2C1:00A0 (prio 0)
> [ 0.715240] bone-capemgr bone_capemgr.9: loader: check slot-7 BB-I2C1:00A0 
> (prio 0)
> [ 0.715732] bone-capemgr bone_capemgr.9: loader: check slot-4 
> BB-BONE-EMMC-2G:00A0 (prio 1)
> [ 0.718442] bone-capemgr bone_capemgr.9: loader: after slot-7 BB-I2C1:00A0 
> (prio 0)
> [ 0.718462] bone-capemgr bone_capemgr.9: slot #7: Requesting part 
> number/version based 'BB-I2C1-00A0.dtbo
> [ 0.718477] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware 
> 'BB-I2C1-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
> [ 0.718506] bone-capemgr bone_capemgr.9: slot #7: dtbo 'BB-I2C1-00A0.dtbo' 
> loaded; converting to live tree
> [ 0.720710] bone-capemgr bone_capemgr.9: loader: before slot-8 
> BB-SPI1-SWP-01:00A0 (prio 0)
> [ 0.720724] bone-capemgr bone_capemgr.9: loader: check slot-8 
> B

Re: [beagleboard] Setting up TFTP and NFS

[William Hermans]

>
> *login as: william*
> *william@sanitized's password:*
> *Linux arm 3.8.13-bone47 #1 SMP Mon Apr 14 04:38:52 MST 2014 armv7l*
>
> *The programs included with the Debian GNU/Linux system are free software;*
> *the exact distribution terms for each program are described in the*
> *individual files in /usr/share/doc/*/copyright.*
>
> *Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent*
> *permitted by applicable law.*
> *Last login: Fri Aug 15 02:07:19 2014 from 192.168.0.2*
> *$ sudo iperf -c 192.168.0.2*
> *[sudo] password for william:*
> **
> *Client connecting to 192.168.0.2, TCP port 5001*
> *TCP window size: 21.0 KByte (default)*
> **
> *[  3] local 192.168.0.1 port 58475 connected with 192.168.0.2 port 5001*
> *[ ID] Interval   Transfer Bandwidth*
> *[  3]  0.0-10.0 sec   162 MBytes   136 Mbits/sec*
> *$ sudo iperf -s*
> *[sudo] password for william:*
> **
> *Server listening on TCP port 5001*
> *TCP window size: 85.3 KByte (default)*
> **
> *[  4] local 192.168.0.1 port 5001 connected with 192.168.0.2 port 35283*
> *[ ID] Interval   Transfer Bandwidth*
> *[  4]  0.0-10.2 sec  44.1 MBytes  36.4 Mbits/sec*
>


So *17MB/s reads*, and *4.55MB/s writes*. Write speed is probably this low
because the rootfs sits on a fast ethernet NFS share network. Which
"coincidentally" is roughly half the NFS share's network speed. Reads from
a Windows 7 x64 based iperf server is just under 15MB/s, but with no real
way to serve up a Linux type filesystem.


On Fri, Aug 15, 2014 at 12:12 AM, William Hermans  wrote:

> Brian I see where your source of confusion is coming from. Right now after
> spending a few hours reading through various configuration files and making
> adjustment as needed . . . I'm very aggravated.
>
> Mostly due to the fact that I spent a great deal of time figuring all this
> out last year, and now it's different. To the point where I'm seriously
> considering ditching the latest images, and stick with the slightly older
> images I have working perfectly already.
>
>
> On Thu, Aug 14, 2014 at 11:55 PM, William Hermans 
> wrote:
>
>> *Debian might be perceived as more stable, but it uses old version of
>>> almost every package and the core repository is way smaller than Ubuntu so
>>> you have to hunt around for other repos to find the packages you need and
>>> then Debian becomes less stable.*
>>>
>>
>> Hunt around for what packages ? In the context of the current discussion
>> I've never had to "hunt" for anything. I've had to compile my own stuff
>> from sources when I wanted something custom . . . Now if you want cutting
>> edge stuff, you're almost certainly going to run into trouble no matter
>> what distro you use. But that is not what we're talking about. We're
>> talking about running a distro in a VM for the sole purpose of supporting
>> the Beaglebone black.
>>
>>
>> On Thu, Aug 14, 2014 at 10:55 PM, John Syn  wrote:
>>
>>>
>>>  From: Brian Anderson 
>>> Reply-To: "beagleboard@googlegroups.com" 
>>> Date: Thursday, August 14, 2014 at 12:48 PM
>>> To: "beagleboard@googlegroups.com" 
>>> Subject: Re: [beagleboard] Setting up TFTP and NFS
>>>
>>>
>>> If you want my opinion, ditch Linux mint *NOW*. Personally I will not
 use anything other than Debian for a support system to the BBB, and would
 NEVER use X for this purpose. Especially in a VM . . .

 Yeah yeah, Linux mint is based on Ubuntu and Debian( testing ) (
 depending on version ), but thats part of the problem.


>>> Hmmm, OK!  Would you like to enumerate why you wouldn't use Mint?  I was
>>> under the impression the Mint-17 is based upon Ubuntu 14.04LTS, and thus
>>> fairly stable.  Personally, I can't stand Unity...but YMMV.  What distro
>>> would you suggest?
>>>
>>> Well, at the moment, all I have is my MBP laptop to support this
>>> effort.  So, either I setup NFS on the MAC and hope for the best, or use a
>>> VM running some Linux.  I thought I'd give the VM approach a try as a first
>>> step in order to not introduce native MAC NFS vagaries into the mix.
>>> Probably could try that option now that I have things limping along.
>>>
>>> When you say NEVER use X, I'm assuming you mean running X windows on a
>>> dev env (Linux Mint)?  I'm not running X on the BBB (well, I do often use X
>>> forwarding to the MAC/XQuartz for stuff like (gasp) emacs, xterm, ...).  My
>>> thought was to do dev on the MAC (straight away or via a VM) using a shared
>>> file system between the MAC and BBB so I didn't have to copy files around,
>>> nor risk loosing everything if the BBB goes toes in the air or the uSD
>>> craps out.
>>>
>>> I have a MBP which I love, but I wouldn’t use it for development for the
>>> same reasons I wouldn’t use Windows for developme

[beagleboard] Re: Reading BeagleBone Serial Number

[Oscar Castiblanco]

Hi,

Based on the BBB System manual, the serial number is placed on byte 76 with 
a length of 12 bytes.
Why are you reading from byte 16 a length of 12 bytes? 
Isn't it just a piece of the Board Name?
What is the meaning of this data? 5002BBBK6670 ??

On Friday, February 10, 2012 4:56:05 PM UTC+1, Shawn wrote:
>
> We are looking for a way to read the serial number of the BeagleBone 
> programmatically.  As I understand it in the BeagleBone Rev A manual 
> (sections 5.1 and 7.11), this serial number is written into EEPROM on 
> I2C0.  I'm new to EEPROM and I2C and accessing it from software so 
> bare with me. 
>
> I only see /dev/i2c-1 and /dev/i2c-3 available in the OS.  So my first 
> question is: Is /dev/i2c-1 actually the I2C0 where, according to 
> section 5.1 in the manual, the EEPROM is? 
>
> Next, I kept investigating under the assumption that /dev/i2c-1 is 
> actually I2C0 and came across i2detect which I was able to run to get 
> a map of that I2C which shows a map of which addresses on that I2C 
> have something.  It showed something at addresses 0x24, 0x35, 0x50 and 
> 0x51.  Finding some documentation online where the EEPROM typically 
> exists suggests that what is in 0x50 and 0x51 are the EEPROM data. 
> The i2cdetect output also shows that these areas are unavailable 
> suggesting that something has them locked such as a driver. 
>
> Some more investigating brought up the eeprom command and that command 
> also states that the base-address of eeproms is 0x50 but complains 
> that it can't open i2c at /dev/i2c-0.  Which makes sense since /dev/ 
> i2c-0 doesn't exist or isn't mounted.  So, back to my original 
> question and asking really should there be a /dev/i2c-0? 
>
> I also came across the eeprog which would allow me to read from the 
> EEPROM, but attempting to read from 0x50 and 0x51 on /dev/i2c-1 fails 
> stating that it doesn't exist or isn't readable.  Which makes me 
> believe that something in Linux does have this locked/mounted/ 
> whatever. 
>
> So my main question is, what mechanism should be used to read (and 
> potentially write to since section 5.1 of the manual also states that 
> this EEPROM is provided for SW applications to use as well if desired) 
> the EEPROM data? 
>
> Please bare in mind, I'm not a Linux or hardware guru, so if you can 
> provide a bit of explanation to your answers, it would be very much 
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Setting up TFTP and NFS

[William Hermans]

Brian I see where your source of confusion is coming from. Right now after
spending a few hours reading through various configuration files and making
adjustment as needed . . . I'm very aggravated.

Mostly due to the fact that I spent a great deal of time figuring all this
out last year, and now it's different. To the point where I'm seriously
considering ditching the latest images, and stick with the slightly older
images I have working perfectly already.


On Thu, Aug 14, 2014 at 11:55 PM, William Hermans  wrote:

> *Debian might be perceived as more stable, but it uses old version of
>> almost every package and the core repository is way smaller than Ubuntu so
>> you have to hunt around for other repos to find the packages you need and
>> then Debian becomes less stable.*
>>
>
> Hunt around for what packages ? In the context of the current discussion
> I've never had to "hunt" for anything. I've had to compile my own stuff
> from sources when I wanted something custom . . . Now if you want cutting
> edge stuff, you're almost certainly going to run into trouble no matter
> what distro you use. But that is not what we're talking about. We're
> talking about running a distro in a VM for the sole purpose of supporting
> the Beaglebone black.
>
>
> On Thu, Aug 14, 2014 at 10:55 PM, John Syn  wrote:
>
>>
>>  From: Brian Anderson 
>> Reply-To: "beagleboard@googlegroups.com" 
>> Date: Thursday, August 14, 2014 at 12:48 PM
>> To: "beagleboard@googlegroups.com" 
>> Subject: Re: [beagleboard] Setting up TFTP and NFS
>>
>>
>> If you want my opinion, ditch Linux mint *NOW*. Personally I will not use
>>> anything other than Debian for a support system to the BBB, and would NEVER
>>> use X for this purpose. Especially in a VM . . .
>>>
>>> Yeah yeah, Linux mint is based on Ubuntu and Debian( testing ) (
>>> depending on version ), but thats part of the problem.
>>>
>>>
>> Hmmm, OK!  Would you like to enumerate why you wouldn't use Mint?  I was
>> under the impression the Mint-17 is based upon Ubuntu 14.04LTS, and thus
>> fairly stable.  Personally, I can't stand Unity...but YMMV.  What distro
>> would you suggest?
>>
>> Well, at the moment, all I have is my MBP laptop to support this effort.
>> So, either I setup NFS on the MAC and hope for the best, or use a VM
>> running some Linux.  I thought I'd give the VM approach a try as a first
>> step in order to not introduce native MAC NFS vagaries into the mix.
>> Probably could try that option now that I have things limping along.
>>
>> When you say NEVER use X, I'm assuming you mean running X windows on a
>> dev env (Linux Mint)?  I'm not running X on the BBB (well, I do often use X
>> forwarding to the MAC/XQuartz for stuff like (gasp) emacs, xterm, ...).  My
>> thought was to do dev on the MAC (straight away or via a VM) using a shared
>> file system between the MAC and BBB so I didn't have to copy files around,
>> nor risk loosing everything if the BBB goes toes in the air or the uSD
>> craps out.
>>
>> I have a MBP which I love, but I wouldn’t use it for development for the
>> same reasons I wouldn’t use Windows for development and that is because
>> neither support case sensitive file system. Also, OSX tools are quite old
>> and sometime incompatible with their GNU equivalents (options are different
>> more often than not compared to GNU versions), so you have to use MacPort,
>> HomeBrew, Fink, etc. Regarding Mint, Ubuntu, Debian, etc, there isn’t
>> really much between them other than personal preferences. There are both
>> benefits and downsides to each, so choose one and stay with it. Truly
>> speaking, each one needs some work to get it stable and working the way you
>> want. Debian might be perceived as more stable, but it uses old version of
>> almost every package and the core repository is way smaller than Ubuntu so
>> you have to hunt around for other repos to find the packages you need and
>> then Debian becomes less stable. Ubuntu was a bit flaky for a while, but
>> 14.04 is much better and the distro I use daily.
>>
>> Regards,
>> John
>>
>>
>>
>> I'm all ears on suggestions for a good dev setup though!
>>
>> Cheers,
>>
>> ba
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>  --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to beagleboard+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message becau