Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6
Just a quick update. If I didn't get it wrong so far: git bisect start git bisect good v4.0 git bisect bad v4.1-rc1 git bisect bad 6c373ca89399c5a3f7ef210ad8f63dc3437da345 # v4.0-5833-g6c373ca git bisect bad e95e7f627062be5e6ce971ce873e6234c91ffc50 # v4.0-2825-ge95e7f6 git bisect bad c4be50eee2bd4d50e0f0ca58776f685c08de69c3 # v4.0-1399-gc4be50e git bisect good1a370f4cd95e056d55ef5bf1a183880e70195e59 # v4.0-682-g1a370f4 git bisect good 3be1b98e073bdd4c1bb3144201a927c4a21330ba # v4.0-1013-g3be1b98 git bisect bad c6ab3aec4bc4beda2d6eb8ea43c6f5be3b215d3f # v4.0-rc5-193-gc6ab3ae git bisect bad ab330cf3888d8e0779fa05a243d53ba9f53a7ba9 # v4.0-rc3-96-gab330cf This results in the following suspects: https://lh3.googleusercontent.com/-YNwUnIaBp7I/VcG7DM0ugXI/AAADD34/yksejFzmH-s/s1600/bisect_visualize.png It will still take up to 3 days to pinpoint the evil commit... Thanks, Nuno -- 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] Image 2015-7-26, kernel 4.1.3-ti-r6
Hi, all I can add at this time is that I have a strong feeling that there is a hardware dependency as well.1) I ran linux-image-4.0.4-bone4 stable on two boards (Embest March 2014) for 2 days 2) After updating to some 4.1.x or 4.2.x one was stable, the other one showed the effect. I got 32 BBB (Embest March/April 2015) production yesterday and will insert minimum 10 of them into the test bed tonight. Then I let linux-image-4.0.4-bone4 run for at least 24h and we see how it behaves. -- Günter (dl4mea) -- 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] Welcome the Fall 2015 Embedded Linux class to this group
The purpose of this posting is to announce that I'm once again teaching an Embedded Linux class based on the BeagleBone Black [1]. I'm teaching as open-source as I can and have have posted many of course materials on eLinux.org [2] and github[3]. One thing new about this class is rather than offering at my home institution (Rose-Hulman), the class is being taught at the newest Indian Institute of Technology in Mandi, India. I'm always open to ideas on what topics to include in the class and suggestions for interesting course projects. For example we are starting BoneScript next week and hope to be writing simple kernel module a few weeks from now. Class, please respond to this posting. Others, please welcome my class. --Mark --Prof. Mark A. Yoder Rose-Hulman Institute of Technology [4] Indian Institute of Technology, Mandi [5] [1] http://elinux.org/Embedded_Linux,_IIT [2] http://elinux.org/index.php?title=Category:ECE597 [3] https://github.com/MarkAYoder/BeagleBoard-exercises [4] http://www.rose-hulman.edu [5] http://www.iitmandi.ac.in/ -- 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] Image 2015-7-26, kernel 4.1.3-ti-r6
Nice Job Nuno! Right now I can confirm up to 1a370f4cd95e056d55ef5bf1a183880e70195e59 I have 5/5 boards running for 21 hours.. The worst delay I've seen between reboots has been around 2.5 days.. On Wed, Aug 5, 2015 at 2:31 AM, Nuno Gonçalves nuno...@gmail.com wrote: Just a quick update. If I didn't get it wrong so far: git bisect start git bisect good v4.0 git bisect bad v4.1-rc1 git bisect bad 6c373ca89399c5a3f7ef210ad8f63dc3437da345 # v4.0-5833-g6c373ca git bisect bad e95e7f627062be5e6ce971ce873e6234c91ffc50 # v4.0-2825-ge95e7f6 git bisect bad c4be50eee2bd4d50e0f0ca58776f685c08de69c3 # v4.0-1399-gc4be50e git bisect good1a370f4cd95e056d55ef5bf1a183880e70195e59 # v4.0-682-g1a370f4 git bisect good 3be1b98e073bdd4c1bb3144201a927c4a21330ba # v4.0-1013-g3be1b98 git bisect bad c6ab3aec4bc4beda2d6eb8ea43c6f5be3b215d3f # v4.0-rc5-193-gc6ab3ae git bisect bad ab330cf3888d8e0779fa05a243d53ba9f53a7ba9 # v4.0-rc3-96-gab330cf This results in the following suspects: https://lh3.googleusercontent.com/-YNwUnIaBp7I/VcG7DM0ugXI/AAADD34/yksejFzmH-s/s1600/bisect_visualize.png It will still take up to 3 days to pinpoint the evil commit... Thanks, Nuno -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] UIO_PRUSS in Linux 3.14.y
On Tue, Aug 4, 2015 at 10:41 PM, jalodi@gmail.com wrote: Robert thanks for the reply. Aren't you currently battling with spontaneous reboots in the 4.1 series? Thought I read this here recently, but can't find the post just now. That should be solved in about another week.. Nuno has 3 more git bisect results https://gist.github.com/RobertCNelson/b52f8318e9798625b655 It takes about 3 days to confirm a good kernel. Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] How to interface a second sd card (that operates in SPI mode) under the 4.1 kernel?
I've managed to disable HIGHMEM from within the kernel. However im having trouble compiling. The usual 'make clean' and 'make all' gives me errors: root@beaglebone:/usr/src/linux-headers-4.1.2-ti-r4# make all CHK include/config/kernel.release UPD include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h make[1]: *** No rule to make target 'arch/arm/tools/gen-mach-types', needed by 'include/generated/mach-types.h'. Stop. arch/arm/Makefile:297: recipe for target 'archprepare' failed make: *** [archprepare] Error 2 How do i compile the kernel with the changes made to .config? On Tuesday, August 4, 2015 at 2:15:41 PM UTC-7, RobertCNelson wrote: On Tue, Aug 4, 2015 at 4:06 PM, Robert Nelson robert...@gmail.com javascript: wrote: On Tue, Aug 4, 2015 at 1:19 PM, thom...@googlemail.com javascript: wrote: I am using the Digilent PmodSD as the second sd card for the BBB: http://www.digilentinc.com/Products/Detail.cfm?Prod=PMOD-SD I've been following this forum: http://www.alteraforum.com/forum/showthread.php?t=19335page=4 but assumes that i have the mmc_spi driver, which isnt found in the 4.1.2-ti-r4 kernel on my beaglebone: mmc_spi.c source file doesnt exist also. root@beaglebone:~# find /lib/modules/`uname -r` -type f -name *.ko | grep mmc /lib/modules/4.1.2-ti-r4/kernel/drivers/media/mmc/siano/smssdio.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/mmc/host/sdhci.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/mmc/host/vub300.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/mmc/host/dw_mmc-exynos.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/mmc/host/dw_mmc-pltfm.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/mmc/host/ushc.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/mmc/host/dw_mmc.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/mmc/host/sdhci-pltfm.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/mmc/host/rtsx_usb_sdmmc.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/mmc/card/sdio_uart.ko root@beaglebone:~# find /lib/modules/`uname -r` -type f -name *.ko | grep spi /lib/modules/4.1.2-ti-r4/kernel/drivers/misc/ad525x_dpot-spi.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/spi/spi-butterfly.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/spi/spi-lm70llp.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/spi/spi-omap2-mcspi.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/mtd/spi-nor/spi-nor.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/scsi/scsi_transport_spi.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/net/wireless/ti/wl1251/wl1251_spi.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/net/wireless/ti/wlcore/wlcore_spi.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/net/can/spi/mcp251x.ko /lib/modules/4.1.2-ti-r4/kernel/drivers/mfd/mc13xxx-spi.ko In another forum, a person solved this by actually interfacing the second SD to the mmc lines: SPI-SD Card I dont see how this will work since mmc1 lines on the p8 header are used by the board. And when i wire my sd card to these lines the Beaglebone doesnt boot up. Also the mmc2 on the p8 header doesnt have a cmd mode pin (mmc2_cmd), so i cant use these lines. There are another set of mmc2 lines on the p9 header but its also missing a mmc2_cmd and a mmc2_clk mode pin. Any insight on how to add a second SD card? CONFIG_HIGHMEM=y i set... 472 config MMC_SPI 473 tristate MMC/SD/SDIO over SPI 474 depends on SPI_MASTER !HIGHMEM HAS_DMA 475 select CRC7 476 select CRC_ITU_T 477 help 478 Some systems access MMC/SD/SDIO cards using a SPI controller 479 instead of using a native MMC/SD/SDIO controller. This has a 480 disadvantage of being relatively high overhead, but a compensating 481 advantage of working on many systems without dedicated MMC/SD/SDIO 482 controllers. 483 484 If unsure, or if your system has no SPI master driver, say N. So rebuild the kernel without HIGHMEM, then you can enable MMC_SPI.. Note it's been depended on !HIGHMEM since it's initial upstreaming.. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=15a0580ced081a0f7dc2deea8a4812bdc5e9a109 Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: shutdown procedure required for beaglebone black ??
By doing this you can get corruption. Linux requires that you unmount the drives before powering down. There is also a Linux shutdown command that can be used. Gerald On Wed, Aug 5, 2015 at 4:07 AM, lmjeu...@gmail.com wrote: Hi Gerald, Following the instructions on the BeagleBoard.org - getting-started http://beagleboard.org/getting-started webpage, my team lead and I have been powering up the BBB by using the provided USB cable to plug our Beagle into our computers. We didn't find instructions on powering it down. So, we have been powering it down by simply pulling the cable out. By doing this, can we also get corruption? If so, where is the shutdown procedure documented? Lawrence On Sunday, October 13, 2013 at 12:19:54 PM UTC-7, Gerald wrote: Nope. If you do it the way I just said, the board is powered off after it is done. Then you can pull the power. Pull the power without letting the kernel unmount the eMMC or SD card, and you can get corruption. Gerald On Sun, Oct 13, 2013 at 1:31 PM, arunbarn...@gmail.com wrote: So pulling out the power with properly shutting down the system could corrupt the eMMC ??? On Sunday, October 13, 2013 4:39:05 PM UTC+5:30, arunbarn...@gmail.com wrote: Hi, I am trying to use the beaglebone black (in factory default settings) in a control application, where the BBB interfaces to a 20x4 character LCD, 18 button keypad, and a RS 232 connection using ttyO4 port (connects to RS 485 network using appropriate drivers). I have almost developed the hardware and the software using Eclispe C++ IDE. As I am not using any batteries or other power backup devices for the BBB, Do I have to implement a shutdown procedure for my users ?? I have made a procedure in which the user presses a combination of keys to get the shutdown option on the LCD, selecting the shutdown option runs the system(shutdown -h now) command in my C++ program. Is a shutdown procedure required for the BBB or will just pulling out the +5V power jack be sufficient. I have read in some sites that the eMMC could get corrupted causing startup issues Please advise thanks a -- 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/groups/opt_out. -- 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. -- Gerald ger...@beagleboard.org http://beagleboard.org/ -- 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: shutdown procedure required for beaglebone black ??
Section 5.10 in the SRM Rev C.1 recommends using the power button to power down the board and prevent contamination of the SD card or the eMMC. This section gives a brief explanation of why also. Chad On 8/5/2015 4:07 AM, lmjeu...@gmail.com wrote: Hi Gerald, Following the instructions on the BeagleBoard.org - getting-started http://beagleboard.org/getting-started webpage, my team lead and I have been powering up the BBB by using the provided USB cable to plug our Beagle into our computers. We didn't find instructions on powering it down. So, we have been powering it down by simply pulling the cable out. By doing this, can we also get corruption? If so, where is the shutdown procedure documented? Lawrence On Sunday, October 13, 2013 at 12:19:54 PM UTC-7, Gerald wrote: Nope. If you do it the way I just said, the board is powered off after it is done. Then you can pull the power. Pull the power without letting the kernel unmount the eMMC or SD card, and you can get corruption. Gerald On Sun, Oct 13, 2013 at 1:31 PM, arunbarn...@gmail.com javascript: wrote: So pulling out the power with properly shutting down the system could corrupt the eMMC ??? On Sunday, October 13, 2013 4:39:05 PM UTC+5:30, arunbarn...@gmail.com wrote: Hi, I am trying to use the beaglebone black (in factory default settings) in a control application, where the BBB interfaces to a 20x4 character LCD, 18 button keypad, and a RS 232 connection using ttyO4 port (connects to RS 485 network using appropriate drivers). I have almost developed the hardware and the software using Eclispe C++ IDE. As I am not using any batteries or other power backup devices for the BBB, Do I have to implement a shutdown procedure for my users ?? I have made a procedure in which the user presses a combination of keys to get the shutdown option on the LCD, selecting the shutdown option runs the system(shutdown -h now) command in my C++ program. Is a shutdown procedure required for the BBB or will just pulling out the +5V power jack be sufficient. I have read in some sites that the eMMC could get corrupted causing startup issues Please advise thanks a -- 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 javascript:. For more options, visit https://groups.google.com/groups/opt_out https://groups.google.com/groups/opt_out. -- 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. -- Chad Baker Memphis, TN -- 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] How to interface a second sd card (that operates in SPI mode) under the 4.1 kernel?
On Tue, Aug 4, 2015 at 7:32 PM, thomas...@googlemail.com wrote: I've managed to disable HIGHMEM from within the kernel. However im having trouble compiling. The usual 'make clean' and 'make all' gives me errors: root@beaglebone:/usr/src/linux-headers-4.1.2-ti-r4# make all CHK include/config/kernel.release UPD include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK include/generated/utsrelease.h UPD include/generated/utsrelease.h make[1]: *** No rule to make target 'arch/arm/tools/gen-mach-types', needed by 'include/generated/mach-types.h'. Stop. arch/arm/Makefile:297: recipe for target 'archprepare' failed make: *** [archprepare] Error 2 Sorry, that's headers root@beaglebone:/usr/src/linux-headers-4.1.2-ti-r4# make all Grab the source via: git clone -b 4.1.2-ti-r4 https://github.com/beagleboard/linux --depth=1 Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] UIO_PRUSS in Linux 3.14.y
Nice! Cheers to you and the others who are fixing 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.
Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6
I will add anecdotal comment in support of Guenter's comment about a serial port problem. Three times, I have had the ttyS0 port hardware serial console port stop working in advance of the reboot, while I could still sign in on SSH via Ethernet, and the BBB seemed to be otherwise still working. It may be the same problem, or it may be a different problem, but I suspect that the serial port is involved. --- Graham == On Wed, Aug 5, 2015 at 7:03 AM, Robert Nelson robertcnel...@gmail.com wrote: Nice Job Nuno! Right now I can confirm up to 1a370f4cd95e056d55ef5bf1a183880e70195e59 I have 5/5 boards running for 21 hours.. The worst delay I've seen between reboots has been around 2.5 days.. On Wed, Aug 5, 2015 at 2:31 AM, Nuno Gonçalves nuno...@gmail.com wrote: Just a quick update. If I didn't get it wrong so far: git bisect start git bisect good v4.0 git bisect bad v4.1-rc1 git bisect bad 6c373ca89399c5a3f7ef210ad8f63dc3437da345 # v4.0-5833-g6c373ca git bisect bad e95e7f627062be5e6ce971ce873e6234c91ffc50 # v4.0-2825-ge95e7f6 git bisect bad c4be50eee2bd4d50e0f0ca58776f685c08de69c3 # v4.0-1399-gc4be50e git bisect good1a370f4cd95e056d55ef5bf1a183880e70195e59 # v4.0-682-g1a370f4 git bisect good 3be1b98e073bdd4c1bb3144201a927c4a21330ba # v4.0-1013-g3be1b98 git bisect bad c6ab3aec4bc4beda2d6eb8ea43c6f5be3b215d3f # v4.0-rc5-193-gc6ab3ae git bisect bad ab330cf3888d8e0779fa05a243d53ba9f53a7ba9 # v4.0-rc3-96-gab330cf This results in the following suspects: https://lh3.googleusercontent.com/-YNwUnIaBp7I/VcG7DM0ugXI/AAADD34/yksejFzmH-s/s1600/bisect_visualize.png It will still take up to 3 days to pinpoint the evil commit... Thanks, Nuno -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: What happens on read/write conflict on the PRU scrartchpad?
Cool, thanks for the update Carlos! I thought a little about your problem and was wondering whether you are really at the limit of the PRUs capability: You say you have roughly 20kSps with 10bit resolution for four outputs, so roughly 200k updates of the output pins per second. That means you need roughly 10 instructions for changing the PWM outputs to their next value. What do you think of the following implementation? Is it not optimal but I think its performance should be comparable to yours but roughly 10x faster: START: XIN 10,r0,120 //fetches data from scratchpad0 - each register holds 8x4bits, where bit 0,4,8,12 defines four consecutive values for output 0, bit 1,5,9,13 for output 1 and so on. AND R30.b0, r0.b0, 0x0F //move the bits 0:3 of r0.b0 to r30.b0 (the other bits of R30.b0 are set to zero by the AND) - here it is assumed that your output pins correspond to r30[0:3]. That can easily be adapted to any other consecutive 4 bits by using a LSL instruction LSR R30.b0,r0.b0,4 //move the bits 4:7 of r0.b0 to r30.b0 (the other bits of R30.b0 are set to zero by the LSR) AND R30.b0, r0.b1, 15 //same for r0.b1 LSR R30.b0,r0.b1,4 //repeat this instruction for all other bytes up to... AND R30.b0, r29.b3, 15 LSR R30.b0,r29.b3,4 //up to here, 30*8=240 sets of 4 bits were written to the output XIN 11,r0,120 //fetches data from scratchpad1 //repeat the write operations XIN 12,r0,120 //fetches data from scratchpad2 //repeat the write operations XIN 14,r0,120 //fetches data from other PRU //repeat the write operations JMP START //here a total of 4*240=960 writes on 4 digital outputs r30[0:3] has been executed. So we have already about 9.9 bits resolution and - given an overhead of 5 cycles - an update rate of 200MHz*960/965 = roughly 199MHz. That is the actual output will be roughly 200kSps. The 960 cycles leave plenty of time for PRU1 to perform 4 LBBO operations that are 120byte wide: Typically each one should take less than 80 cyccles. So the code will look sth like LBBO from DRAM filling all registers r0:r29 XOUT 10,r0,120 LBBO from DRAM filling all registers r0:r29 XOUT 11,r0,120 LBBO from DRAM filling all registers r0:r29 XOUT 12,r0,120 LBBO from DRAM filling all registers r0:r29 XOUT 14,r0,120 //here the code will stall until PRU0 requests the data with the corresponding XIN operation. This is the simplest implementation. You can make it more sophisticated by inserting some logic into PRU1 code that modulates the output data over several cycles to get a higher output resolution. But even in this implementation, the only irregularity comes from the XIN's and the final jump operation in PRU0, which should be taken into account in the algorithm that generates the data which fills all of the registers (the value of register r29[28:31] counts twice if its in the scratchpad, and threefold if its in PRU1). This is a complication, but actually leads to a neat trick: If you want to invest some of the gained speed into higher resolution, you can increase the weight of any 4bit datapoint by inserting a loop after it that just holds that particular output value for that number of cycles (you need to reserve a register for the counter in that case, but you will still gain in resolution). If one loop of the PRU0 code takes much more than 1024 cycles, you should also insert a loop of similar length into PRU1 code in order to not have PRU1 stall more than 1024cycles for PRU0's XIN command. -- 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] Equivalent of PRU on main CPU
On Wed, Aug 5, 2015 at 11:56 AM, Lenny leonhard.neuh...@gmail.com wrote: Hello everyone, I find it a pity that the PRU runs only at 200 MHz and not at the full 1 GHz. I was wondering if there exist any linux distributions (or not linux at all) which allow to run real-time code on the main CPU. Of course, this would have to disable all linux features that are not explicitly implemented in the code, but in many cases I think that could be desirable. Has anyone ever done something like that? I guess it boils down to using an extremely minimized kernel / completely removing the OS and only running the necessary stuff, but I am by no means an expert in low-level linux programming and was wondering if there exists some code out there which would make it easier for me to start with. In the end, I would like to use more powerful instructions of the main CPU such as floating point arithmetics and the higher speed to implement PRU-like functionality for DSP in real-time. rt linux: https://rt.wiki.kernel.org/index.php/Main_Page sudo apt-get update sudo apt-get install linux-image-4.1.3-ti-rt-r7 sudo reboot but your going to find, the pru is just faster and more deterministic... Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Equivalent of PRU on main CPU
Hello everyone, I find it a pity that the PRU runs only at 200 MHz and not at the full 1 GHz. I was wondering if there exist any linux distributions (or not linux at all) which allow to run real-time code on the main CPU. Of course, this would have to disable all linux features that are not explicitly implemented in the code, but in many cases I think that could be desirable. Has anyone ever done something like that? I guess it boils down to using an extremely minimized kernel / completely removing the OS and only running the necessary stuff, but I am by no means an expert in low-level linux programming and was wondering if there exists some code out there which would make it easier for me to start with. In the end, I would like to use more powerful instructions of the main CPU such as floating point arithmetics and the higher speed to implement PRU-like functionality for DSP in real-time. Thanks in advance! -- 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] Equivalent of PRU on main CPU
Lenny, Hello, so no hands on but I have read about several technologies you may be interested in. First, TI's starterware, and bare metal should be possible - for this hardware. Also, you could directly run an executable from uboot, which is the first( second ? ) stage bootloader for the beaglebone official debian images. Thirdly . . . remoteproc could be used on a dual core processor to run a / the second core baremetal while the first core runs Linux. Or, so I think I've read. There are also RTOS's out there, and TI does have TI-RTOS i think its called. But not sure if it is capable of running on the sitara processors or not. In other words I would think it could, but have not looked into it. So all this stuff I know of, but not much in the way how. remoteproc for the beaglebone specifically has been discussed in the past on these groups. But there is not much information out there. A couple linux/documentation text files is all. And of course the kernel source it's self. Anyway, is this the kind of info you're after, or is this too basic ? On Wed, Aug 5, 2015 at 9:56 AM, Lenny leonhard.neuh...@gmail.com wrote: Hello everyone, I find it a pity that the PRU runs only at 200 MHz and not at the full 1 GHz. I was wondering if there exist any linux distributions (or not linux at all) which allow to run real-time code on the main CPU. Of course, this would have to disable all linux features that are not explicitly implemented in the code, but in many cases I think that could be desirable. Has anyone ever done something like that? I guess it boils down to using an extremely minimized kernel / completely removing the OS and only running the necessary stuff, but I am by no means an expert in low-level linux programming and was wondering if there exists some code out there which would make it easier for me to start with. In the end, I would like to use more powerful instructions of the main CPU such as floating point arithmetics and the higher speed to implement PRU-like functionality for DSP in real-time. Thanks in advance! -- 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] Equivalent of PRU on main CPU
Thanks Robert, that rt linux project seems very interesting, but as you say, it is still too high-level / multitasking in order to beat the PRU. So one would have to remove basically all the remaining functionality from rt linux to arrive at something fast and deterministic at the ns timescale i guess.. Thanks anyways! On Wednesday, August 5, 2015 at 7:00:50 PM UTC+2, RobertCNelson wrote: On Wed, Aug 5, 2015 at 11:56 AM, Lenny leonhard...@gmail.com javascript: wrote: Hello everyone, I find it a pity that the PRU runs only at 200 MHz and not at the full 1 GHz. I was wondering if there exist any linux distributions (or not linux at all) which allow to run real-time code on the main CPU. Of course, this would have to disable all linux features that are not explicitly implemented in the code, but in many cases I think that could be desirable. Has anyone ever done something like that? I guess it boils down to using an extremely minimized kernel / completely removing the OS and only running the necessary stuff, but I am by no means an expert in low-level linux programming and was wondering if there exists some code out there which would make it easier for me to start with. In the end, I would like to use more powerful instructions of the main CPU such as floating point arithmetics and the higher speed to implement PRU-like functionality for DSP in real-time. rt linux: https://rt.wiki.kernel.org/index.php/Main_Page sudo apt-get update sudo apt-get install linux-image-4.1.3-ti-rt-r7 sudo reboot but your going to find, the pru is just faster and more deterministic... Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Equivalent of PRU on main CPU
On 8/5/2015 2:41 PM, Lenny wrote: Thanks Robert, that rt linux project seems very interesting, but as you say, it is still too high-level / multitasking in order to beat the PRU. So one would have to remove basically all the remaining functionality from rt linux to arrive at something fast and deterministic at the ns timescale i guess.. Even that's not enough. The A in the Cortex-A9 CPU means Application. The processor core is designed for high speed and *NOT* deterministic operation. There are lots of tradeoffs in application processors made to allow high speeds including pipelining, caching, branch prediction, out-of-order execution, that all have a negative impact on the determinism of code execution times. You will find the PRU, which was intentionally designed for fixed operation times will be _far_ more deterministic than the ARM A9 core even though it's running at only 20% of the speed (due in large part to the intentional lack of the advanced features that _allow_ the A9 core to run at it's GHz clock rate). You can probably come close to the PRU performance determinism on a Cortex-A core if you're willing to dedicate one core of a multi-core part strictly to doing real-time, but the PRU will still probably work better. Especially if you need high-speed I/O, where the single-cycle latency to the direct PRU I/O pins will run _circles_ around anything the ARM core can do trying to talk to the GPIO pins. -- Charles Steinkuehler char...@steinkuehler.net -- 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] Equivalent of PRU on main CPU
Thanks for your post William, the idea to start an executable from uboot sounds very close to what I want i guess. My question here would be which document is equivalent to the PruReferenceGuide, such that I can find out how to talk to the various hardware pieces such as memory and inputs/outputs and the NEON core etc., and which compiler I would have to use (in the best case a C compiler with inline assembler support). And if available, a library with some useful functions such as a accessing serial port (USB) and maybe even Ethernet (though i guess that would require interrupts and all sorts of other overhead) would be just perfect! But actually I have just now looked into starterware ( http://processors.wiki.ti.com/index.php/StarterWare_02.00.01.01_User_Guide#Serial_Peripherals), and it really looks amazingly close to what I had in mind. There are lots of examples and I guess i'll start testing some of them. @Charles: Thanks for the warning :) Im still still a noob when it comes to processor architecture. The application I have in mind (FIR filter) is computationally intensive, but does not need a huge data throughput (few MSps would be enough, which I know I can delegate to the PRU if necessary). I found the idea of using the main processor appealing as I read somewhere about its SIMD capability (doing 16 or 32 multiplications and accumulates simultaneously, which would theoretically allow something like 16-32Gflops, right?), and floating point arithmetics. So if you confirm that all those advantages are lost somewhere in the communication between core and dedicated modules, that would be a pity but indeed save me a lot of time :) And for curiosity/ease of later implementation/number of available input-output ports: What delay and number of necessary instructions can I expect for exchanging one or multiple bits between the main processor and a GPIO port? More than 10 cycles? Thanks so much for your suggestins and help! -- 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] Equivalent of PRU on main CPU
Hello again Lenny, Yeah I have not looked into uboot very deeply. But it does have at least some Ethernet, USB, and Serial functionality. I say some because I'm not sure how extensive it is. For example with the builtin ethernet stuff, you can boot over TFTP and NFS, but beyond that . . . not sure what can be done with it. Also I'm pretty sure there is some I2C functionality built in too. NO personal hands on with it though . . . Anyway, yeah, I'd listen to Charles, and Robert, as they've probably both had their hands into the lower level stuff more than I have. I was just tossing some things out there for you to read on when and if you got the time . . . As I was kind of in the same boat you are in - But a couple years ago. I was also thinking maybe super low level baremetal, but decided a good long while ago that it was not really worth it for me. PRU's ? Sure, but baremetal Sitara . . .Yeah not for me hehe On Wed, Aug 5, 2015 at 1:12 PM, Lenny leonhard.neuh...@gmail.com wrote: Thanks for your post William, the idea to start an executable from uboot sounds very close to what I want i guess. My question here would be which document is equivalent to the PruReferenceGuide, such that I can find out how to talk to the various hardware pieces such as memory and inputs/outputs and the NEON core etc., and which compiler I would have to use (in the best case a C compiler with inline assembler support). And if available, a library with some useful functions such as a accessing serial port (USB) and maybe even Ethernet (though i guess that would require interrupts and all sorts of other overhead) would be just perfect! But actually I have just now looked into starterware ( http://processors.wiki.ti.com/index.php/StarterWare_02.00.01.01_User_Guide#Serial_Peripherals), and it really looks amazingly close to what I had in mind. There are lots of examples and I guess i'll start testing some of them. @Charles: Thanks for the warning :) Im still still a noob when it comes to processor architecture. The application I have in mind (FIR filter) is computationally intensive, but does not need a huge data throughput (few MSps would be enough, which I know I can delegate to the PRU if necessary). I found the idea of using the main processor appealing as I read somewhere about its SIMD capability (doing 16 or 32 multiplications and accumulates simultaneously, which would theoretically allow something like 16-32Gflops, right?), and floating point arithmetics. So if you confirm that all those advantages are lost somewhere in the communication between core and dedicated modules, that would be a pity but indeed save me a lot of time :) And for curiosity/ease of later implementation/number of available input-output ports: What delay and number of necessary instructions can I expect for exchanging one or multiple bits between the main processor and a GPIO port? More than 10 cycles? Thanks so much for your suggestins and help! -- 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] Equivalent of PRU on main CPU
I just thought I'd toss this out there though. Over the last 2-3 months I've been working on a project that Involves socketCAN, and forming NEMA 2000 fastpackets from socketCAN frames in real time. Then pushing the data in the form of JSON out a webserver ( web sockets ), in real time as well. So up until last night I was working on all this in a quad core 4 GB RAM virtual machine( virtualbox ). canplayer was eating up around 58% CPU on a single core, while my two processes were taking around 8% between the two. quad cores - 3Ghz. Imagine my surprise last night that canplayer only uses 2% CPU, and the two processes I'm working on use 0% - In fact, the webserver only shows up in atop about half the time- heh. My point is: The beaglebone may not have but 1/3 the CPU frequency, and a LOT less memory. It may also do some things such as compile large projects slower, or even sometimes a lot slower. But do not let it fool you. It is still a beast. On Wed, Aug 5, 2015 at 1:55 PM, William Hermans yyrk...@gmail.com wrote: Hello again Lenny, Yeah I have not looked into uboot very deeply. But it does have at least some Ethernet, USB, and Serial functionality. I say some because I'm not sure how extensive it is. For example with the builtin ethernet stuff, you can boot over TFTP and NFS, but beyond that . . . not sure what can be done with it. Also I'm pretty sure there is some I2C functionality built in too. NO personal hands on with it though . . . Anyway, yeah, I'd listen to Charles, and Robert, as they've probably both had their hands into the lower level stuff more than I have. I was just tossing some things out there for you to read on when and if you got the time . . . As I was kind of in the same boat you are in - But a couple years ago. I was also thinking maybe super low level baremetal, but decided a good long while ago that it was not really worth it for me. PRU's ? Sure, but baremetal Sitara . . .Yeah not for me hehe On Wed, Aug 5, 2015 at 1:12 PM, Lenny leonhard.neuh...@gmail.com wrote: Thanks for your post William, the idea to start an executable from uboot sounds very close to what I want i guess. My question here would be which document is equivalent to the PruReferenceGuide, such that I can find out how to talk to the various hardware pieces such as memory and inputs/outputs and the NEON core etc., and which compiler I would have to use (in the best case a C compiler with inline assembler support). And if available, a library with some useful functions such as a accessing serial port (USB) and maybe even Ethernet (though i guess that would require interrupts and all sorts of other overhead) would be just perfect! But actually I have just now looked into starterware ( http://processors.wiki.ti.com/index.php/StarterWare_02.00.01.01_User_Guide#Serial_Peripherals), and it really looks amazingly close to what I had in mind. There are lots of examples and I guess i'll start testing some of them. @Charles: Thanks for the warning :) Im still still a noob when it comes to processor architecture. The application I have in mind (FIR filter) is computationally intensive, but does not need a huge data throughput (few MSps would be enough, which I know I can delegate to the PRU if necessary). I found the idea of using the main processor appealing as I read somewhere about its SIMD capability (doing 16 or 32 multiplications and accumulates simultaneously, which would theoretically allow something like 16-32Gflops, right?), and floating point arithmetics. So if you confirm that all those advantages are lost somewhere in the communication between core and dedicated modules, that would be a pity but indeed save me a lot of time :) And for curiosity/ease of later implementation/number of available input-output ports: What delay and number of necessary instructions can I expect for exchanging one or multiple bits between the main processor and a GPIO port? More than 10 cycles? Thanks so much for your suggestins and help! -- 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] Equivalent of PRU on main CPU
Hehe, a beast indeed :) I downloaded the StarterWare software and I like it. I'll summarize my current understanding, and if someone wants to correct me in case its necessary, I'll be glad: As far as I understand, StarterWare does not use an OS overhead, so you get to execute your code directly in the MPU - bare metal access so to say. I imagine the same can be accomplished by properly embedding your compiled file into a bootloader at the right place. The provided examples are reasonably clear, for example to set a GPIO pin, you find the instruction GPIOPinWrite(GPIO_INSTANCE_ADDRESS, GPIO_INSTANCE_PIN_NUMBER, GPIO_PIN_LOW); Checking what is behind is really a simple instruction HWREG(baseAdd + GPIO_CLEARDATAOUT) = (1 pinNumber); where the macro HWREG only provides a properly shaped pointer to the address in brackets. Using these examples is equivalent to a painful and time-consuming study of the TRM, where you can find the addresses of all those registers. So as far as I understand, this operation should also only take the equivalent of one single assembler instruction after compilation. Two questions now remain: 1) how many cycles does it take the MPU to execute this instruction (or any other one - this is not specified in the TRM but I am sure it is somewhere in the ARM documention) 2) how long does it take until the value arrives at the output pin The second question aims at Charles concern. Again, from the TRM i deduce that for example the GPIO modules are connected to the MPU through the L4 interconnect. The interface clock rate is specified in the GPIO chapter of the TRM to be 100 MHz. Now I do not understand how this bus works in detail, but the fact that it can handle several sources and destinations simultaneously raises the concern that there is a buffer involved that comes with some extra latency. But I would assume that by running only the one code snippet that I define, and no OS processes in the background, that all other devices are disabled, and therefore the bus is really only used when my program does so. So there should be top prority handling for my packets and therefore they should arrive with minimal, and up to clock missynchronization, deterministic delay. So I would just estimate a delay of a few interface clock cycles, so a latency less than - say - 1/20MHz. Is my reasoning correct here or do I forget something? I guess my next steps will be reading on the MPU itself, as to whether one can hope to implement really fast algorithms on a very low level here. If Im not mistaken, this https://web.eecs.umich.edu/~prabal/teaching/eecs373-f10/readings/ARMv7-M_ARM.pdf is the document to read. A first glance tells me that maybe I'll understand what the A in Cortex-A9 actually means on a low level :) If there is a catch that I am not aware of - thanks for letting me know! -- 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] Equivalent of PRU on main CPU
On 8/5/2015 3:12 PM, Lenny wrote: @Charles: Thanks for the warning :) Im still still a noob when it comes to processor architecture. The application I have in mind (FIR filter) is computationally intensive, but does not need a huge data throughput (few MSps would be enough, which I know I can delegate to the PRU if necessary). I found the idea of using the main processor appealing as I read somewhere about its SIMD capability (doing 16 or 32 multiplications and accumulates simultaneously, which would theoretically allow something like 16-32Gflops, right?), and floating point arithmetics. So if you confirm that all those advantages are lost somewhere in the communication between core and dedicated modules, that would be a pity but indeed save me a lot of time :) The Cortex-A9 core should be great at running a FIR filter, particularly if you can use the NEON SIMD instructions. The problem with the application style processors (and the optimizations that make them fast) is you create uncertainty and variable delay in responding to a real-world event (like an interrupt for a new chunk of data). For the BBB, you can get around 75 uS worst-case latency is a good estimate. If you have a mechanism to DMA (or use the PRU to collect and write) samples into main memory, the ARM should be fine at running the FIR filter, but you should bunch samples together and only fire an interrupt for processing every N samples (or you're wasting a *LOT* of time in IRQ overhead). And for curiosity/ease of later implementation/number of available input-output ports: What delay and number of necessary instructions can I expect for exchanging one or multiple bits between the main processor and a GPIO port? More than 10 cycles? The ARM core should see about the same latency as the PRU when talking to the GPIO. Writes will typically be posted and won't cost time on the CPU as long as you don't write so fast you saturate the interconnect. Reads will generally stall the CPU and should take on the order of a couple hundred nanoseconds: https://github.com/machinekit/machinekit/blob/master/src/hal/drivers/hal_pru_generic/pru_generic.p#L137-L165 The interconnect may be somewhat faster for the ARM core, but talking to the GPIO is going to be *WAY* slower than talking to main memory, which is itself much slower than the CPU core frequency. -- Charles Steinkuehler char...@steinkuehler.net -- 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] Equivalent of PRU on main CPU
On 8/5/2015 4:49 PM, Lenny wrote: Hehe, a beast indeed :) I downloaded the StarterWare software and I like it. I'll summarize my current understanding, and if someone wants to correct me in case its necessary, I'll be glad: As far as I understand, StarterWare does not use an OS overhead, so you get to execute your code directly in the MPU - bare metal access so to say. I imagine the same can be accomplished by properly embedding your compiled file into a bootloader at the right place. The provided examples are reasonably clear, for example to set a GPIO pin, you find the instruction GPIOPinWrite(GPIO_INSTANCE_ADDRESS, GPIO_INSTANCE_PIN_NUMBER, GPIO_PIN_LOW); Checking what is behind is really a simple instruction HWREG(baseAdd + GPIO_CLEARDATAOUT) = (1 pinNumber); where the macro HWREG only provides a properly shaped pointer to the address in brackets. Using these examples is equivalent to a painful and time-consuming study of the TRM, where you can find the addresses of all those registers. So as far as I understand, this operation should also only take the equivalent of one single assembler instruction after compilation. Two questions now remain: 1) how many cycles does it take the MPU to execute this instruction (or any other one - this is not specified in the TRM but I am sure it is somewhere in the ARM documention) 2) how long does it take until the value arrives at the output pin The second question aims at Charles concern. Again, from the TRM i deduce that for example the GPIO modules are connected to the MPU through the L4 interconnect. The interface clock rate is specified in the GPIO chapter of the TRM to be 100 MHz. Now I do not understand how this bus works in detail, but the fact that it can handle several sources and destinations simultaneously raises the concern that there is a buffer involved that comes with some extra latency. But I would assume that by running only the one code snippet that I define, and no OS processes in the background, that all other devices are disabled, and therefore the bus is really only used when my program does so. So there should be top prority handling for my packets and therefore they should arrive with minimal, and up to clock missynchronization, deterministic delay. So I would just estimate a delay of a few interface clock cycles, so a latency less than - say - 1/20MHz. Is my reasoning correct here or do I forget something? See my previous mail, the numbers for the PRU will likely closely match what you can do on the ARM core, since the interconnect is going to be the limiting factor to performance. tl;dr: Writes will go fast, but won't show up at the pin for a while. Reads will take about 165 nS. I guess my next steps will be reading on the MPU itself, as to whether one can hope to implement really fast algorithms on a very low level here. If Im not mistaken, this https://web.eecs.umich.edu/~prabal/teaching/eecs373-f10/readings/ARMv7-M_ARM.pdf is the document to read. A first glance tells me that maybe I'll understand what the A in Cortex-A9 actually means on a low level :) Um...that's the -M manual, you want the -A manual, specifically the Cortex-A9. Just get it straight from the source: http://www.arm.com/products/processors/cortex-a/cortex-a9.php ...click the resources tab. -- Charles Steinkuehler char...@steinkuehler.net -- 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] BBB DPLL boot problem
Hey guys, new user here. I got an issue with my BBB and I thought maybe somebody here could help me. After fiddling around with my bbb debugging a custom made cape, it stopped booting at all. When I plug in a serial debug cable to read the boot messages i get the following: U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54) DPLL locking failed for 0x44e00490 ### ERROR ### Please RESET the board ### When I reset it, I get the message again. I tried to google the error message and had no success finding a solution or any other issue similar to that. Does anybody have any idea on what might have caused that error? Any idea on what could be done to fix it? Is there hope for my BBB? 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.
Re: [beagleboard] BBB DPLL boot problem
On Wed, Aug 5, 2015 at 3:48 PM, fabiohmante...@gmail.com wrote: Hey guys, new user here. I got an issue with my BBB and I thought maybe somebody here could help me. After fiddling around with my bbb debugging a custom made cape, it stopped booting at all. When I plug in a serial debug cable to read the boot messages i get the following: U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54) DPLL locking failed for 0x44e00490 ### ERROR ### Please RESET the board ### When I reset it, I get the message again. I tried to google the error message and had no success finding a solution or any other issue similar to that. Does anybody have any idea on what might have caused that error? Any idea on what could be done to fix it? Is there hope for my BBB? What does it do, when your custom cape is removed? Regards, -- Robert Nelson https://rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Unnable to read MSP430 with BeagelBone.
I have a script in python build thats reads the data from the msp430 using the usb serial. But when I ran this script in BeageleBone I justo get a blank enter. I must be missing something. I already tried the rules in here http://energia.nu/guide/guide_linux/ Please some advice. I think the problem has to do with the drives or smt like that. My second guess is the power but i have the BB connect to a 5v 2.5A -- http://imco.org.mx/ Instituto Mexicano para la Competitividad A.C. Musset No.32, Polanco, CP11560. México D.F. Twitter: @IMCOmx http://twitter.com/imcomx | Facebook: /IMCOmx http://facebook.com/imcomx | YouTube: /IMCOmexico http://youtube.com/imcomexico -- 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] Much hardware failures with Element14-boards
Hi, I currently have a set of 20 BBB's that come from Element14 and show a lot of failures: - microSD card of one could not be accessed - one died after some weeks without any reason, board is bricked now - one stalls during boot after a few days, also connecting power does not always turn the Power-LED on Since this is quite a large failure rate: anybody else making such experiences with these non-original boards? -- 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] CAD-Model for BBB?
Hi, is there a CAD-model available of the BBB and perhaps of one (standard) cape? 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] Adding PRU eCAP to beaglebone-universal-io
You are my hero! Renaming the dtbo was all it took and my PRU eCAP test worked on the first try. Now that I know it works, this feels like the kind of thing I should submit as a pull request. Assuming that's alright with you, I'm guessing my next steps are to clean this up a bit, drop my custom-named version, also add and test the same mapping on P8_15, then duplicate all of that in the universaln and universala versions, too. Is there anything else I'm missing? Thanks so much! Cheers, Nicholas -- 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.
