[beagleboard] PRU programming - how to initialise and upload?
There is a lot of useful stuff regarding PRU out there, unfortunately it is not very useful for me. These examples/documentation all make use of Linux and a PRU-library doing many magic stuff - initialising PRU, uploading the PRU-program and starting it. Since I'm not using Linux/PRU-library but try to program everything for my own, I have to start a bit earlier and need to understand the whole intitialisation and upload stuff. I already tried it with AM3358 TRM which is very detailled, there I fail to understand the working principle. Means TRM tells me what registers are there and what they are doing, but it does not give me the whole picture what has to be done in which order to have it running correctly. Next I tried it with the existing Linux-drivers and PRU-libraries but don't have been very successful with reverse-engineering of it (there are too much dependencies to understand it and to get a full picture there). So...is there any description/getting started/cookbook out there that is helpful when one wants to program PRU from scratch and without the help of existing drivers/libraries? Thanks! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Freely available Yocto / OE training materials with Beaglebone Black labs
Greetings, After Linux kernel development materials with labs on the Beaglebone Black board (see http://free-electrons.com/training/kernel/), Free Electrons is happy to release new training materials on the Yocto Project and OpenEmbedded, again with practical labs on the Beaglebone Black. In particulicular, you learn how to use add support for your own board and for compiling your own applications by extending the build system. See http://free-electrons.com/blog/yocto-project-and-openembedded-training-materials-published/ for all details. Extra testing and feedback is welcome, of course! Michael. -- 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] PRU programming - how to initialise and upload?
Hi Karl, Have a look how I solved that problem in: https://github.com/modmaker/BeBoPr. The file pruss.c is the one you want. This code is from 'before' the PRU-library, but has proven stable since the BeagleBone white. Cheers, -- Bas On 3-11-2014 10:09, Karl Karpfen wrote: There is a lot of useful stuff regarding PRU out there, unfortunately it is not very useful for me. These examples/documentation all make use of Linux and a PRU-library doing many magic stuff - initialising PRU, uploading the PRU-program and starting it. Since I'm not using Linux/PRU-library but try to program everything for my own, I have to start a bit earlier and need to understand the whole intitialisation and upload stuff. I already tried it with AM3358 TRM which is very detailled, there I fail to understand the working principle. Means TRM tells me what registers are there and what they are doing, but it does not give me the whole picture what has to be done in which order to have it running correctly. Next I tried it with the existing Linux-drivers and PRU-libraries but don't have been very successful with reverse-engineering of it (there are too much dependencies to understand it and to get a full picture there). So...is there any description/getting started/cookbook out there that is helpful when one wants to program PRU from scratch and without the help of existing drivers/libraries? 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 mailto:beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: How fast/reliable is ADC sampling from the PRU
Hello jleb! There's no problem fetching the samples from the ADC subsystem and store them in the external memory block (or DRam area). You don't need both PRUSS, one can do that. But the ADC subsystem isn't fast enough. It needs 14 cycles to perform a step and a further cycle to start the step sequence. In your case that's 1 + 4 * 14 = 57 cycles at 2.4 MHz, which results in a maximum sampling rate of 42.2 kHz. Depending on the signal impedance, you may need some open delay to stabilize the input. In order to test the ADC subsystem, you may have a look at libpruio http://beagleboard.org/project/libpruio/. It can be used to configure ADC steps and fetch samples in a ring buffer. BR -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Seriously Confused
Curt Carpenter 1cjcarpenter-fodfmywu...@public.gmane.org writes: I keep searching for some sort of definitive guide to using the IO capabilities of the board, but have had no luck. There is nothing on software in the SRM, and memory-mapping to the registers described in the data sheet seems to be frowned upon. I know of no definitive guide. There are some well written blog posts but as with anything on the Internet, it's important to consider the date it was published. The bonescript analogRead module can handle this, so you could do all this from the Cloud9 browser IDE. If you want to use javascript that is, I prefer python (see next question). Can anyone point me to an entry point into all these mysteries? Where do I go to find the definitive guide to reading the analog inputs under Debian, for example? Anytime I've done ADC on the Bone I've used this python library: https://github.com/alexanderhiam/PyBBIO. The python snippet is something like this: import Adafruit_BBIO.ADC as ADC ADC.setup() ADC.read(self.pin) What commands are available? Why would anyone want to use file IO to do simple GPIO operations when it is so much faster to just memory-map the GPIO registers? This question seems to arise quite often and there are a few right answers. To me, directly using memory-map regions breaks down a certain level of software and Linux abstractions. An analogous question, perhaps, is: Why not just run everything as root? By using Linux from userspace, you are sacrificing some of the performance but you gain the ability to use a myriad of third-party libraries and your choice of programming language. You probably would get better performance if you made your own kernel module for whatever you were trying to do, but that may not be the easiest route if you just want to read an analog value. Hope some of this helps, Josh -- 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: How fast/reliable is ADC sampling from the PRU
Hi TJF, Thanks for the detailed reply. I will look into libpruio as well. However, I'm a bit confused regarding the 2.4 MHz part. Can't the ADC run at 24 MHz? (Looking at 12.2.2 in the AM335x TRM) If so, this would give me the breathing room I need, I think. Thanks! jleb On Monday, November 3, 2014 10:12:22 AM UTC-5, TJF wrote: Hello jleb! There's no problem fetching the samples from the ADC subsystem and store them in the external memory block (or DRam area). You don't need both PRUSS, one can do that. But the ADC subsystem isn't fast enough. It needs 14 cycles to perform a step and a further cycle to start the step sequence. In your case that's 1 + 4 * 14 = 57 cycles at 2.4 MHz, which results in a maximum sampling rate of 42.2 kHz. Depending on the signal impedance, you may need some open delay to stabilize the input. In order to test the ADC subsystem, you may have a look at libpruio http://beagleboard.org/project/libpruio/. It can be used to configure ADC steps and fetch samples in a ring buffer. BR -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Freely available Yocto / OE training materials with Beaglebone Black labs
Thank you very much for sharing. free-electrons docs have been always helpful. On Monday 03 November 2014 04:22 PM, Michael Opdenacker wrote: Greetings, After Linux kernel development materials with labs on the Beaglebone Black board (see http://free-electrons.com/training/kernel/), Free Electrons is happy to release new training materials on the Yocto Project and OpenEmbedded, again with practical labs on the Beaglebone Black. In particulicular, you learn how to use add support for your own board and for compiling your own applications by extending the build system. See http://free-electrons.com/blog/yocto-project-and-openembedded-training-materials-published/ for all details. Extra testing and feedback is welcome, of course! Michael. -- 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 mailto: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] please can u help us to sort out problem of gpio pins because we r not getting our led s blink
-- 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: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel
In addition to my previous comment (posted on 03/11/2014) I have also tested with v2014.10 and got the same output as before : U-Boot SPL 2014.10 (Nov 03 2014 - 15:40:04) Incorrect magic number (0x) in EEPROM Could not get board ID. Incorrect magic number (0x) in EEPROM Could not get board ID. Unknown board: assuming BeagleBone Black.Incorrect magic number (0x) in EEPROM Could not get board ID. I am getting these logs in every 1 minute(approx) in my FTDI Output. On Friday, October 31, 2014 7:36:21 PM UTC+5:30, RobertCNelson wrote: On Thu, Oct 30, 2014 at 10:50 PM, nishikan...@gmail.com javascript: wrote: Hi Andrew, Now we are using one customized board based on Beaglebone Black Design. In case of BBB TI is writing some board type configuration in the EEPROM, so during the Initial booting process it reads those information and configures the board accordingly. As we are using one fresh board we don't have anything written into the EEPROM, because of which it is failing at the U-boot every time with some errors like: U-Boot SPL 2013.01.01-00129-g6d40c2a-dirty (Oct 30 2014 - 09:58:22) Incorrect magic number (0x) in EEPROM I have tried to skip the read_eeprom () in the u-boot which reads the EEPROM header for board type, also done the Pin muxing in board/ti/am335x/mux.c but didn't get any better result out of this. As per my knowledge if we will write the same Configuration into the EEPROM as BBB then the board will boot properly. but we want to avoid that procedure. so could you please tell me is there any other method to solve this issue. Looking for a quick response from your end .. See this patch for reference (yes it's v2014.10) It is what CircuitCo uses to boot blank eeprom boards. https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.10/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch 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] USB over current pin
Hi, looking on BeagleBone Black schematic I need to free pin T16 (USB1_OCn) related to USB overcurrent protection in order to enable a second ethernet on a custom board designed at work. I was wondering if it is possible to 'relocate' this pin on a different one (using a .dts file) or modifying some kernel source file (which one ?); Thanks in advance, Gennaro Tortone -- 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] please can u help us in getting the tool chain of beagleboard xm
-- 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] What are the implications of uncontrolled power-down?
In the BBB SRM, there's this warning, We recommend that you use this method [pushing the power button for 8 s] to power down the board. It will also help prevent contamination of the SD card or the eMMC. However for the application I am interested in, I can't trust that the mains power won't fail or that my users won't simply remove the power cable at some point. What are the possible consequences if they do this? (Board or uSD card needs to be re-flashed?) Are there well-known solutions for this? I would be designing a new cape for my project, so hardware could be built in to that. Thanks, Matt -- 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: BBBAndroid: AOSP 4.4.4 (KitKat) with 3.8 kernel
Thanks for the help Robert
I have done all the changes, whatever you have mentioned in the Patch file,
but still the board is not booting up. I think only the *s_init() function
(file:board/ti/am335x/board.c)* is keep on executing repeatedly, as i can
see only this log i.e.* **Unknown board: assuming BeagleBone Black.* (*file:
**board/ti/am335x/mux.c.) *in every 1 minute(approx.)
FYI:
As the u-boot source files what you are using and what i am using are not
completely same so i did all the changes manually (instead of applying the
patch directly).
e.g. --- /home/original/am335x_evm.h2014-11-03 09:49:54.061434173 +0530
+++ include/configs/am335x_evm.h2014-11-03 10:11:11.869458684 +0530
@@ -142,6 +142,8 @@
run ramargs; \
bootm ${loadaddr}\0 \
findfdt=\
+setenv fdtfile am335x-boneblack.dtb; \
+setenv fdtbase am335x-boneblack; \
if test $board_name = A335BONE; then \
setenv fdtfile am335x-bone.dtb; fi; \
if test $board_name = A33515BB; then \
so could you please help me out for solving this issue..
On Friday, October 31, 2014 7:36:21 PM UTC+5:30, RobertCNelson wrote:
On Thu, Oct 30, 2014 at 10:50 PM, nishikan...@gmail.com javascript:
wrote:
Hi Andrew,
Now we are using one customized board based on Beaglebone Black Design.
In
case of BBB TI is writing some board type configuration in the EEPROM,
so
during the Initial booting process it reads those information and
configures
the board accordingly.
As we are using one fresh board we don't have anything written into
the
EEPROM, because of which it is failing at the U-boot every time with
some
errors like:
U-Boot SPL 2013.01.01-00129-g6d40c2a-dirty (Oct 30 2014 - 09:58:22)
Incorrect magic number (0x) in EEPROM
I have tried to skip the read_eeprom () in the u-boot which reads the
EEPROM header for board type, also done the Pin muxing in
board/ti/am335x/mux.c but didn't get any better result out of this.
As per my knowledge if we will write the same Configuration into the
EEPROM
as BBB then the board will boot properly. but we want to avoid that
procedure. so could you please tell me is there any other method to
solve
this issue.
Looking for a quick response from your end ..
See this patch for reference (yes it's v2014.10)
It is what CircuitCo uses to boot blank eeprom boards.
https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014.10/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch
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] where is 192.168.7.2 ip address defined?
I am testing Beagle Black with several distros. Each time I change distro, my host ssl client complains that remote host key changed, and refuses to let me log in, even though I specified no StrictHostKeyChecking in my .ssh/config file. I have to use ssh-agent to remove the previous key. I could possibly solve the problem by changing the target keys to the same values in all distros, but it might be simpler just to change the ip addresses to be unique. I tried changing the ip value to 192.168.7.3 in the target's /etc/udhcp.conf file, but it had no effect. Where else is the value defined? BTW, can I turn off the target's udhcpd if I am not using USB gadget? My Linux Mint host is preferring the wired connection to Beagle, which does not see the Internet, to my wireless connection, which does. -- 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] Cross-compiling SDL 1.2 for BBB.
Hi, I've been trying to setup my cross-compile tool chain for programming on the BBB through a Linux Mint box with Eclipse running in VMPlayer. So far I've been able to configure almost all the needed components properly to cross-compile and deploy using g++-4.8-arm-linux-gnueabihf (for some reason the non 'hf' version doesn't work-- I admit I am still trying to differentiate between the various flavors of arm out there that are represented by the compilers). However, I can't seem to quite get/find a cross-complied version of the SDL lib (I know SDL2) doesn't work on the BBB. I found this http://how-to-build-for-arm.wikispaces.com/sdl page with some instructions, but it doesn't seem to work quite right for me either. Further, I know there is a version of SDL 1.2 that can be apt-get from the BBB itself-- but of course this doesn't help when wanting to try to cross-compile rather than compile directly on the BBB. Lastly, though I've been able to find some rather easy/straight forward instructions for the Raspberry Pi http://www.raspberrypi.org/forums/viewtopic.php?f=67t=39667, I can't seem to find anything comparable for the Debian version of BB. Does anyone happen to have any recommendations or suggestions? 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] Cross-compiling SDL 1.2 for BBB.
On Nov 3, 2014 12:23 PM, abalduc...@gmail.com wrote: Hi, I've been trying to setup my cross-compile tool chain for programming on the BBB through a Linux Mint box with Eclipse running in VMPlayer. So far I've been able to configure almost all the needed components properly to cross-compile and deploy using g++-4.8-arm-linux-gnueabihf (for some reason the non 'hf' version doesn't work-- I admit I am still trying to differentiate between the various flavors of arm out there that are represented by the compilers). However, I can't seem to quite get/find a cross-complied version of the SDL lib (I know SDL2) doesn't work on the BBB. I found this page with some instructions, but it doesn't seem to work quite right for me either. Further, I know there is a version of SDL 1.2 that can be apt-get from the BBB itself-- but of course this doesn't help when wanting to try to cross-compile rather than compile directly on the BBB. Lastly, though I've been able to find some rather easy/straight forward instructions for the Raspberry Pi, I can't seem to find anything comparable for the Debian version of BB. Does anyone happen to have any recommendations or suggestions? Just build natively on the BBB. 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. -- 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: BeagleBone Black doesn't sometimes start. Only Power LED is on
Mikkel, You don't have to remove the whole U15. You can just give a 3.3V pull-up to the 4th PIN on the J1 connector. Then the board will not be stuck at the UBOOT anymore. My question is how to fix it from software perspective? In u-Boot source, how can we make sure it is not stuck? If anyone can answer my question, i would really appreciate it. Regards, Shu On Friday, October 31, 2014 12:19:11 PM UTC-5, mi...@mikini.dk wrote: On October 16th 2014 21.26.23 UTC+2 Gerald wrote: Is the power LED shutoff too? Gerald Hi Gerald. I'm also affected by the OP's issue of periodic failing boots on BBB (I got all REV Bs). My experience has always been with the power led lighting up and the system stuck without booting. Pressing the reset switch takes the system out of this locked up state, but neither boot switch or power switch has any effect. I am very interested in your input on the successful experiences put forward by Andrew and Marcus in May, about modifying uboot to remedy noise input on UART0_RXD (pin E15 of AM3358). I have done some tests today documenting the basic issue and some followup experiments investigating this specific cause, and I would appreciate if you could take a look and comment on the resulting speculations. You can find the details here; http://www.mikini.dk/index.php/2014/10/beaglebone-black-periodic-boot-failure-establishing-failure-rate-and-possible-cause . Executive summary; removing U15 (SN74LVC2G241: UART0 powerdown isolation) seems to remedy the boot issue on a CircuitCo-produced BBB in my possession. Although my result is inconclusive, as I was careless enough to rush myself into omitting a pre-modification test, verifying the failure rate of the unmodified BBB. Thanks in advance for your help, and for my Beagle puppies ;). Mikkel -- 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] where is 192.168.7.2 ip address defined?
Each install will change the machine name. To make your machine forget the previous time you connected you can remove the known hosts file rm ~/.ssh/knownhosts However, this will remove all your known hosts and start fresh. -- 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: Cross-compiling SDL 1.2 for BBB.
'hf' signifies hardware floating point, which the Beagle has. On Sunday, November 2, 2014 2:04:59 PM UTC-8, abald...@gmail.com wrote: Hi, I've been trying to setup my cross-compile tool chain for programming on the BBB through a Linux Mint box with Eclipse running in VMPlayer. So far I've been able to configure almost all the needed components properly to cross-compile and deploy using g++-4.8-arm-linux-gnueabihf (for some reason the non 'hf' version doesn't work-- I admit I am still trying to differentiate between the various flavors of arm out there that are represented by the compilers). However, I can't seem to quite get/find a cross-complied version of the SDL lib (I know SDL2) doesn't work on the BBB. I found this http://how-to-build-for-arm.wikispaces.com/sdl page with some instructions, but it doesn't seem to work quite right for me either. Further, I know there is a version of SDL 1.2 that can be apt-get from the BBB itself-- but of course this doesn't help when wanting to try to cross-compile rather than compile directly on the BBB. Lastly, though I've been able to find some rather easy/straight forward instructions for the Raspberry Pi http://www.raspberrypi.org/forums/viewtopic.php?f=67t=39667, I can't seem to find anything comparable for the Debian version of BB. Does anyone happen to have any recommendations or suggestions? 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: BeagleBone Black doesn't sometimes start. Only Power LED is on
Hi Shu, I think I answered this in an earlier post, cut/pasted below: Rather than making any hardware mods I decided to reconfigured u-boot to look for a specific key sequence before entering the u-boot console. To do this I firstly downloaded and rebuilt u-boot following instructions here: http://eewiki.net/display/linuxonarm/BeagleBone+Black# BeagleBoneBlack-Bootloader:U-Boot. (Testing with the default config produced the same 'failure' rate) I then modified '/include/config.h' in the u-boot source files, adding the following: #define CONFIG_AUTOBOOT_KEYED 1 #define CONFIG_AUTOBOOT_DELAY_STR uboot This now forces a user to enter the string 'uboot' before entering the u-boot console, otherwise the device will boot up normally. Rebuilding with this configuration still gave the same failure rate however. This is when I learned that the boot files on the eMMC flash are still loading before jumping to the files on the sd card I am using. So upon deleting the MLO file on the eMMC flash I had more luck. We setup a programmable power supply and a script looking at the output of uart0 to detect whether the device had successfully booted or had become stuck in u-boot, and then left it cycling power. We were then able to get many hundreds of consecutive successful boots - we only stopped the test because we decided it would probably never fail. So in the end it all came down to spurious data on uart0 - along with disabling booting from the eMMC. (we could have simply reconfigured u-boot on the eMMC in the same way, but disabling it drops a few seconds off the boot time). Thanks for all your help Gerald (and duckhunter). Regards, Andrew Glen On 4 November 2014 10:12, Shu Liu shu@vensi.com wrote: Mikkel, You don't have to remove the whole U15. You can just give a 3.3V pull-up to the 4th PIN on the J1 connector. Then the board will not be stuck at the UBOOT anymore. My question is how to fix it from software perspective? In u-Boot source, how can we make sure it is not stuck? If anyone can answer my question, i would really appreciate it. Regards, Shu On Friday, October 31, 2014 12:19:11 PM UTC-5, mi...@mikini.dk wrote: On October 16th 2014 21.26.23 UTC+2 Gerald wrote: Is the power LED shutoff too? Gerald Hi Gerald. I'm also affected by the OP's issue of periodic failing boots on BBB (I got all REV Bs). My experience has always been with the power led lighting up and the system stuck without booting. Pressing the reset switch takes the system out of this locked up state, but neither boot switch or power switch has any effect. I am very interested in your input on the successful experiences put forward by Andrew and Marcus in May, about modifying uboot to remedy noise input on UART0_RXD (pin E15 of AM3358). I have done some tests today documenting the basic issue and some followup experiments investigating this specific cause, and I would appreciate if you could take a look and comment on the resulting speculations. You can find the details here; http://www.mikini.dk/index. php/2014/10/beaglebone-black-periodic-boot-failure- establishing-failure-rate-and-possible-cause. Executive summary; removing U15 (SN74LVC2G241: UART0 powerdown isolation) seems to remedy the boot issue on a CircuitCo-produced BBB in my possession. Although my result is inconclusive, as I was careless enough to rush myself into omitting a pre-modification test, verifying the failure rate of the unmodified BBB. Thanks in advance for your help, and for my Beagle puppies ;). Mikkel -- 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/aXv6An1xfqI/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.
Re: [beagleboard] Re: BeagleBone Black doesn't sometimes start. Only Power LED is on
Andrew, I tried that already. The file ../include/config.h is automatically generated when recompiling. I added the two lines which I marked red below. After I recompiled the uboot source again, the new generated config.h file replaces the old one that i modified and does not have the two lines. My question is that have the two lines got recompiled into the u-boot.img? Or am I missing something here? /* Automatically generated - do not edit */ #define CONFIG_SERIAL11 #define CONFIG_CONS_INDEX1 #define CONFIG_NAND1 #define CONFIG_SYS_ARCH arm #define CONFIG_SYS_CPU armv7 #define CONFIG_SYS_BOARD am335x #define CONFIG_SYS_VENDOR ti #define CONFIG_SYS_SOCam33xx #define CONFIG_BOARDDIR board/ti/am335x #define CONFIG_AUTOBOOT_KEYED 1 #define CONFIG_AUTOBOOT_DELAY_STR uboot #include config_cmd_defaults.h #include config_defaults.h #include configs/am335x_evm.h #include asm/config.h #include config_fallbacks.h #include config_uncmd_spl.h -- 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: Seriously Confused
Thank you for the detailed reply Joshua. I'm still mystified by the documentation, and come to the BBB from OS-free environments where everything is done at the register level, and almost everything one needs to know is in the data sheet/TRM. I'd like to impose on you with one more question if I can (this is not a rant! Trying to get organized). I found (stumbled on) an article on reading the analog inputs on the web that works: echo BB-ADC /sys/devices/bone_capemgr.*/slots cd /sys/bus/iio/devices/iio:device0 cat in_voltage0_raw Am I correct in understanding that there is no documentation that would have pointed me to the /sys/bus/iio/devices/iio:device0 directory and given me some guidance on what it contained? I have the feeling that the docs ARE there, I just haven't located the mother ship yet :-) I haven't tried python or bonescript: sticking with C/C++ until I learn my way around the BBB first before I tackle the added complication of a new language. If I were to shift to python though, is there any particular doc I would read to learn how to do something like use the device tree and the A/Ds? If so, I might abandon C just in the interest of working on a stable, documented software platform. Appreciate your help and advice. Regards, Curt On Monday, November 3, 2014 9:17:01 AM UTC-6, Joshua Datko wrote: Curt Carpenter 1cjcarpenter...@public.gmane.org javascript: writes: I keep searching for some sort of definitive guide to using the IO capabilities of the board, but have had no luck. There is nothing on software in the SRM, and memory-mapping to the registers described in the data sheet seems to be frowned upon. I know of no definitive guide. There are some well written blog posts but as with anything on the Internet, it's important to consider the date it was published. The bonescript analogRead module can handle this, so you could do all this from the Cloud9 browser IDE. If you want to use javascript that is, I prefer python (see next question). Can anyone point me to an entry point into all these mysteries? Where do I go to find the definitive guide to reading the analog inputs under Debian, for example? Anytime I've done ADC on the Bone I've used this python library: https://github.com/alexanderhiam/PyBBIO. The python snippet is something like this: import Adafruit_BBIO.ADC as ADC ADC.setup() ADC.read(self.pin) What commands are available? Why would anyone want to use file IO to do simple GPIO operations when it is so much faster to just memory-map the GPIO registers? This question seems to arise quite often and there are a few right answers. To me, directly using memory-map regions breaks down a certain level of software and Linux abstractions. An analogous question, perhaps, is: Why not just run everything as root? By using Linux from userspace, you are sacrificing some of the performance but you gain the ability to use a myriad of third-party libraries and your choice of programming language. You probably would get better performance if you made your own kernel module for whatever you were trying to do, but that may not be the easiest route if you just want to read an analog value. Hope some of this helps, Josh -- 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.17.1-rc4 sudden reset
On Saturday, November 1, 2014 3:24:33 PM UTC-4, david turvene wrote: The system runs fine when I'm not messing around with the plugs, changing the wifi properties, or sniffing. When I do any of these the system occasionally silently reboots - I've been able to test up to 20 sniffing sessions before it reboots, sometimes it will reboot immediately when I start an monitor session. * I run the BBB headless, generally using SSH xterm. * The silent reboot happens with NO indication. NOTHING. The uart console just shows a system restart. * I triggered a watchdog NMI (it takes 22 seconds) and it showed a lot of diagnostic info - so that's not it. Further research - similar behavior was reported last year. Lot's of red herrings (USB control appeared to be the most suspicious because that's my main interface but also long threads blaming the power management unit.) Someone found that another clock source was needed for low-power state and moved the new code into u-boot. I was running with a local build from RCN's git repo described at: https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot and 2014.7 baseline. I noticed it is now at 2014.10 so I rebuilt and installed on target. The system is much more stable after testing for a lot longer than I could before. And I'm pretty sure the clocking/power is the root cause of the silent reboots so I'm checking how the clock change, to the RTC32K clock, works. Also, since I'm running from emmc, I used am335x_boneblack_defconfig to build u-boot. The only difference is it sets EMMC_BOOT but a quick grep shows it changes logic in a couple places. Anyway, it's a start... -- 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: Beaglebone Black and Web Servers?
Have answers to some of your questions. See the replies below: (i) Apache (ii)Linux (Debian or Ubuntu) Not sure if Django can be installed on the BBB. Will largely depend upon whether or not Django uses any native C/C++ libraries. On Saturday, 11 January 2014 16:37:07 UTC+13, COG wrote: Hi: I am a newbie to the Beaglebone arena and I have some questions dealing with which web server(s) to use. (i) What is a good web server(s) to use? (ii) On which Operating System? (iii) Can Django be installed on the Beaglebone Black? (iv) If Yes, what would I have to do? E.g. Where to find the install file and instructions? *Note:* I have experience programming in both Java and Python; and using the OS Ubuntu and a desktop. Regards COG -- 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: Beaglebone Black and Web Servers?
Couldn't find anything conclusive about Django and the BBB (Beaglebone Black). However I found this blog post http://internetofthings-pune.blogspot.co.nz/2013/10/home-automation-with-raspberrypi-python.html on Django and the Raspberry PI. Looking at the blog post it looks as though Django doesn't use any native C/C++ libraries, which means it can be used on both X86 (eg Linux laptop/desktop) and Arm platforms (eg BBB/Raspberry Pi). Since the Raspberry Pi uses Debian some minor changes might need to be made to install Django when using Ubuntu even though it is based on Debian. On Saturday, 11 January 2014 16:37:07 UTC+13, COG wrote: (iii) Can Django be installed on the Beaglebone Black? (iv) If Yes, what would I have to do? E.g. Where to find the install file and instructions? *Note:* I have experience programming in both Java and Python; and using the OS Ubuntu and a desktop. Regards COG -- 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: Beaglebone Black and Web Servers?
There is already nodejs installed on BBB, you can simply run webserver using it.http://nodejs.org/ On Saturday, 11 January 2014 14:37:07 UTC+11, COG wrote: Hi: I am a newbie to the Beaglebone arena and I have some questions dealing with which web server(s) to use. (i) What is a good web server(s) to use? (ii) On which Operating System? (iii) Can Django be installed on the Beaglebone Black? (iv) If Yes, what would I have to do? E.g. Where to find the install file and instructions? *Note:* I have experience programming in both Java and Python; and using the OS Ubuntu and a desktop. Regards COG -- 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: Beaglebone Black Ethernet Phy Not Detected on Boot.
Hi, I am using a BBB Rev C with latest Angstrom image and i have seen this issue with eth not getting detected at boot up. This came at the last stages of my project delivery. How can this be corrected. Does moving to the latest debian image solves this issue ? regards, Jerin George On Saturday, 26 July 2014 04:31:42 UTC+5:30, cmid...@gmail.com wrote: They phymask comes from a hardware register read by the davinci_mdio driver, which gets passed to the linux phy libraries. The problem is that the cpsw driver gets the value from device tree, which is hardcoded to address 0. Usually the values are the same (address 0), but sometimes the phy gets registered to a different address, usually in my case address 2. You calculate the address using the phymask. If you changed the phymask than, you pointing back to address 0, so that wouldn't help you. I rebuilt the dtb file. On Thursday, July 24, 2014 4:10:18 PM UTC-4, Loren Amelang wrote: On Wednesday, July 23, 2014 3:54:00 PM UTC-7, cmid...@gmail.com wrote: The davinci mdio driver should report a phymask and that value is used to update the device tree. Back when I had this problem I tried hard to find out where the phymask comes from, and never succeeded. At that time people who received a phymask of fffe booted successfully, those with fffb failed. Do you know where the mask is found and how to change it? I also remove the second phy slave from the device tree. That seems like a great idea, if only to stop all the useless messages about it never being found. Can that be done in the uEnv.txt, like when you disable HDMI, or do you have to rebuild the device tree binary? Would setting the phymask to accomplish the same thing? Loren -- 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: Beaglebone Black Ethernet Phy Not Detected on Boot.
As far as I know, and as already documented in this thread, the only reliable fix is to remove C24 and C30. On 4/11/2014 5:40 PM, Jerin George george.je...@gmail.com wrote: Hi, I am using a BBB Rev C with latest Angstrom image and i have seen this issue with eth not getting detected at boot up. This came at the last stages of my project delivery. How can this be corrected. Does moving to the latest debian image solves this issue ? regards, Jerin George On Saturday, 26 July 2014 04:31:42 UTC+5:30, cmid...@gmail.com wrote: They phymask comes from a hardware register read by the davinci_mdio driver, which gets passed to the linux phy libraries. The problem is that the cpsw driver gets the value from device tree, which is hardcoded to address 0. Usually the values are the same (address 0), but sometimes the phy gets registered to a different address, usually in my case address 2. You calculate the address using the phymask. If you changed the phymask than, you pointing back to address 0, so that wouldn't help you. I rebuilt the dtb file. On Thursday, July 24, 2014 4:10:18 PM UTC-4, Loren Amelang wrote: On Wednesday, July 23, 2014 3:54:00 PM UTC-7, cmid...@gmail.com wrote: The davinci mdio driver should report a phymask and that value is used to update the device tree. Back when I had this problem I tried hard to find out where the phymask comes from, and never succeeded. At that time people who received a phymask of fffe booted successfully, those with fffb failed. Do you know where the mask is found and how to change it? I also remove the second phy slave from the device tree. That seems like a great idea, if only to stop all the useless messages about it never being found. Can that be done in the uEnv.txt, like when you disable HDMI, or do you have to rebuild the device tree binary? Would setting the phymask to accomplish the same thing? Loren -- 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/9mctrG26Mc8/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.
Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected on Boot.
From: Andrew Glen andrewtaneg...@gmail.com Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com Date: Monday, November 3, 2014 at 9:42 PM To: beagleboard@googlegroups.com beagleboard@googlegroups.com Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected on Boot. As far as I know, and as already documented in this thread, the only reliable fix is to remove C24 and C30. If you read the full thread, Gerald say that if you remove these capacitors, the board may not start at all. Regards, John On 4/11/2014 5:40 PM, Jerin George george.je...@gmail.com wrote: Hi, I am using a BBB Rev C with latest Angstrom image and i have seen this issue with eth not getting detected at boot up. This came at the last stages of my project delivery. How can this be corrected. Does moving to the latest debian image solves this issue ? regards, Jerin George On Saturday, 26 July 2014 04:31:42 UTC+5:30, cmid...@gmail.com wrote: They phymask comes from a hardware register read by the davinci_mdio driver, which gets passed to the linux phy libraries. The problem is that the cpsw driver gets the value from device tree, which is hardcoded to address 0. Usually the values are the same (address 0), but sometimes the phy gets registered to a different address, usually in my case address 2. You calculate the address using the phymask. If you changed the phymask than, you pointing back to address 0, so that wouldn't help you. I rebuilt the dtb file. On Thursday, July 24, 2014 4:10:18 PM UTC-4, Loren Amelang wrote: On Wednesday, July 23, 2014 3:54:00 PM UTC-7, cmid...@gmail.com wrote: The davinci mdio driver should report a phymask and that value is used to update the device tree. Back when I had this problem I tried hard to find out where the phymask comes from, and never succeeded. At that time people who received a phymask of fffe booted successfully, those with fffb failed. Do you know where the mask is found and how to change it? I also remove the second phy slave from the device tree. That seems like a great idea, if only to stop all the useless messages about it never being found. Can that be done in the uEnv.txt, like when you disable HDMI, or do you have to rebuild the device tree binary? Would setting the phymask to accomplish the same thing? Loren -- 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/9mctrG26Mc8/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. -- 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: Beaglebone Black Ethernet Phy Not Detected on Boot.
Yes, and reading the thread even more fully you'll find my report of running thousands of automated test restarts with these parts removed, with a 100% success rate. We use these boards a lot, running 24-7 in this configuration, and have had zero hardware faults. With any luck we have nearly exhausted Murphy's law with our software. Andrew. On 4/11/2014 7:26 PM, John Syn john3...@gmail.com wrote: From: Andrew Glen andrewtaneg...@gmail.com Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com Date: Monday, November 3, 2014 at 9:42 PM To: beagleboard@googlegroups.com beagleboard@googlegroups.com Subject: Re: [beagleboard] Re: Beaglebone Black Ethernet Phy Not Detected on Boot. As far as I know, and as already documented in this thread, the only reliable fix is to remove C24 and C30. If you read the full thread, Gerald say that if you remove these capacitors, the board may not start at all. Regards, John On 4/11/2014 5:40 PM, Jerin George george.je...@gmail.com wrote: Hi, I am using a BBB Rev C with latest Angstrom image and i have seen this issue with eth not getting detected at boot up. This came at the last stages of my project delivery. How can this be corrected. Does moving to the latest debian image solves this issue ? regards, Jerin George On Saturday, 26 July 2014 04:31:42 UTC+5:30, cmid...@gmail.com wrote: They phymask comes from a hardware register read by the davinci_mdio driver, which gets passed to the linux phy libraries. The problem is that the cpsw driver gets the value from device tree, which is hardcoded to address 0. Usually the values are the same (address 0), but sometimes the phy gets registered to a different address, usually in my case address 2. You calculate the address using the phymask. If you changed the phymask than, you pointing back to address 0, so that wouldn't help you. I rebuilt the dtb file. On Thursday, July 24, 2014 4:10:18 PM UTC-4, Loren Amelang wrote: On Wednesday, July 23, 2014 3:54:00 PM UTC-7, cmid...@gmail.com wrote: The davinci mdio driver should report a phymask and that value is used to update the device tree. Back when I had this problem I tried hard to find out where the phymask comes from, and never succeeded. At that time people who received a phymask of fffe booted successfully, those with fffb failed. Do you know where the mask is found and how to change it? I also remove the second phy slave from the device tree. That seems like a great idea, if only to stop all the useless messages about it never being found. Can that be done in the uEnv.txt, like when you disable HDMI, or do you have to rebuild the device tree binary? Would setting the phymask to accomplish the same thing? Loren -- 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/9mctrG26Mc8/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. -- 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/9mctrG26Mc8/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.
