[beagleboard] Re: Using UART
Hello! Many thanks for your answer! I also found that the UART DeviceTree are already available. I have just the problem with echo and cat that he send sometimes more Characters. When I send Hello I receive Hello When I send again Hello, I receive HHello Did you have an idea? Minicom I have to study how it works. 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.
[beagleboard] Re: own cape - booting problem
Hello Again! Just want to ask again, if someone has a link or can help me, to set my DeviceTree at Bootstart. Right now with uEnv.txt he load the DeviceTree after booting. Thanks a lot! -- 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?
Sounds great...I'll have a look at it! 2014-11-03 13:10 GMT+01:00 Bas Laarhoven s...@xs4all.nl: 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. 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/a72KDrDjcFA/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: starterware emmc beaglebone black
By the way: your own link contains the information that MMC is not supported: http://processors.wiki.ti.com/index.php/StarterWare_MMCSD_Driver#Features_not_supported ;-) Am Dienstag, 28. Oktober 2014 05:23:22 UTC+1 schrieb Jason Kridner: On Mon, Oct 27, 2014 at 5:16 AM, karlka...@gmail.com javascript: wrote: Starterware does not support access to eMMC. To do that, you would have to implement MMC-support to their HSMMCSD-library in order to make MLO able to boot APPs from there. Have you done anything to confirm what you are saying? It would be helpful to say when you suspect something vs. when you know something. Neither the bootloader is in ROM nor the MLO app make any use of Starterware, so if Starterware supports eMMC or not is irrelevant to if you can boot a Starterware application from eMMC using the ROM and MLO. There's no reason you couldn't skip MLO entirely unless your Staterware image is particularly large. If you want to use MLO, again, there's no reason that couldn't target a Starterware application. Also, as far as I know, MMC-support is not required to use an eMMC as it should support one of the other modes. [1] http://processors.wiki.ti.com/index.php/StarterWare_MMCSD_Driver [2] http://processors.wiki.ti.com/index.php/StarterWare_MMC Am Donnerstag, 16. Oktober 2014 22:28:31 UTC+2 schrieb TheMdv18: Hi everybody, My question is, I can boot starterware examples in flash EMMC (MLO+app), I did this in uSD card, but want to use the USB or Serial to flash EMMC and boot my application. There is anyway to do this ? 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...@googlegroups.com javascript:. 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: Seriously Confused
Curt Carpenter 1cjcarpen...@att.net wrote: [-- text/plain, encoding 7bit, charset: UTF-8, 97 lines --] 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 agree with you (previous questions as well) the documentation of the BBB I/O is lacking in many ways, it's *very* difficult to get into it. Seeing how some of the code works (e.g. Adafruit I/O libraries) I think the people who wrote that code had the same problem! :-) 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 ... and that's the *real* raw value, not the pseudo-raw value that the Adafruit libraries give you. 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? Apart from the zillion page processor documentation I think you're right. I have the feeling that the docs ARE there, I just haven't located the mother ship yet :-) The 'mother ship' is google searching as far as I can tell, there is no decent, high level overview that a reasonably proficient software person can pick up and use. 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. I think you're making life harder for yourself using C/C++. I'm a C/C++ programmer (30 or more years, now retired) but use Python on the BBB and many other places. Python is a nice, regular, intelligible language. Unless you need the absolute ultimate in speed it will do all you want on the BBB. As someone else pointed out, to read the ADC using Python you just do:- import Adafruit_BBIO.ADC as ADC ADC.setup() ADC.read(self.pin) You have to install the Adafruit BBIO library first of course. The documentation of the Adafruit libraries isn't all *that* comprehensive but they're pretty simple so no problem really. As I pointed out above though the code is a little odd in places, for example the 'raw' value returned by the Adafruit library is simple the processed value (which is in millivolts) divided by 1800 which isn't my idea of a raw value! -- Chris Green · -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there Shu et al. On 2014-11-03 22:12, Shu Liu wrote: 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. Really? My first hunch after reading Andrew and Marcus' posts was also that the RX line just needed to be tied down. But after seeing that R165 already does this, my suspicion was that it might be caused by the SN74LVC2G241 doing some hiccups on the CPU during early power because of OE and _OE being constantly active. This is contradicted of your above experience, or at least also makes the noise dependent on the 241's 1A input, which agreed does also seem plausible. Inserting a pull up as you suggest, however does make this and R165 a voltage divider keeping the B_UART0_RX input on ~1.4V (at least when 3V3 and DGND has stabilized). Have you tried if the uart0 port is functional after this modification? Inspired by your input I've now done more tests which confirms your experiences. Find them here; http://www.mikini.dk/index.php/2014/11/beaglebone-black-periodic-boot-failure-fixing-b_uart0_rx-with-voltage-divider Funny thing though, I tried increasing the pull down done by R165 (100k-45k), that didn't alleviate the problem as I kind-of expected. Could the issue be that DGND and/or 3V3 actually isn't stable in periods where the 241 has power and is gating 1A through to 1Y? My question is how to fix it from software perspective? In u-Boot source, how can we make sure it is not stuck? I've yet only skimmed the posts about the software fix, as I prefer understanding the problem fully before settling on a fix. I regard issues like this as a hardware flaw, and it needs to be fixed in hardware. There might be software workarounds that can mend the symptoms on already existing boards, but that is part 2 for me so I'm not there, yet. One suggestion could be that the uart driver/uboot itself flushes the uart fifo during initialization, so that uboot only reacts on input made during the execution of the code that checks for interactivity. My guess is that the fifo gets filled with characters generated from noise early during power up, and it just sits there until uboot comes around yanking it out and interpreting it. I haven't looked at the uboot code yet, so this is pure speculation. Regards, - -- Mikkel ,= ,-_-. =. ((_/)o o(\_)) `-'(. .)`-' \_/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUWLpWAAoJEJ2luFWzaTSaMEIIALOoGbABZn5F8Vbi9FQI92P/ I8PFMNp06ybldLHDORJpWpXRnOjIm2Ix5xSFKH5loyUqatoTjeg9ASfAB8m0AeKl JcD/c8lkzC8Z91Ygm7vZtx6SC/09VXuWSd6x6mWvzf1tI9NmCaMReGMalvrLN58X CxfFriqliE9qouI3kOHIJp8FVAmyMFnzxOukgIpU56LV8xTOWwNIot7Q4dK9GXIg Twv+VPzKtSfW5mqKZKP6fhHqGmifWYcV19VI5onue0/rpBrPQM6w4NoJFOcRjTVA ijAuWiDTsgh5/949VOHJl5ansB9KqMn8DJe/2cBrCREUgBSB1B3yKxNa1kzDP2I= =SB8K -END PGP SIGNATURE- -- 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] Whci PRU-C-compiler is recommended?
Hi, it seems there are two C-compilers available that are able to generate PRU-code. One from TI and one introduced here in this board. But...which one is recommended to be used? That's what I found out so far, may be somebody can add some missing information to make it easier to choose one: TI's PRU-C-compiler is - available at http://software-dl.ti.com/codegen/non-esd/downloads/beta.htm - BETA - can be used to create ARM-objects (which can be linked to a bare metal application and loaded to PRU on start-up automatically?) Community/Open Source PRU-C-compiler is - avaialble at https://github.com/dinuxbg/gnupru - BETA - GCC-based and therefore more stable -- 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
Have you had *any* resets since the upgrade to the new u-boot version? I've also been suspecting u-boot, hence my Meaning that I'm also running an old u-boot. in the last post. Op dinsdag 4 november 2014 00:18:43 UTC+1 schreef david turvene: 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: Querries from IIT Kharagpur
On Tuesday, November 4, 2014 1:53:24 AM UTC+5:30, Arvind Kumar Gupta wrote: Dear Sir/Madam We are looking for Beagle Boards for a research project at IIT Kharagpur. We have few queries regarding the board BeagleBone Black 1. It has 7 analog pins. Are those pins multiplexed? or it can acquire data from 7 channels simultaneously. These are multiplexed pins. Maximum sample rate that can be expected would of the order of 100k Sa/s 2. Do you have any supported DAC and ADC module for this board? You can connect and sample an external ADC using the onboard Programmable Real-Time Units (PRUs) , if internal ADC does not satisfy your requirements. For DAC, depending on the requirements, PWM outputs may be lowpass filtered to create an analog signal. Regards Abhishek Please contact @8388906976 for any further queries. -- , Arvind Kumar Gupta Research Scholar IIT Kharagpur Contact No. 08388906976 Alternate E-mail Id: akgup...@gmail.com javascript: -- 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: 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? Ok. You enticed me to provide a more detailed answer :) I started thinking about the question, How do I use the ADC on this board and the answer can't be just: use python? I'll try to point out some assumptions and links to docs. I'm not an expert on this, so perhaps there is a better way. 1.) You have to know that the linux kernel is the mechanism to provide software interfaces to the hardware. 2.) The kernel does have documentation for most major subsystems. Granted, some documentation is in the form of comments, but it is there. If you downloaded the kernel or use the free electrons site to search for adc you'd find this: http://lxr.free-electrons.com/source/drivers/staging/iio/Documentation/overview.txt. This is the root documentation on using the kernel's Industrial I/O subsystem or IIO. If you root around in that directory, you'll find the definitive guide to using this interface. 2.a.) The kernel documentation often assumes you are familiar with the kernel :) It's a bit circular I guess. There is a great book, Linux Device Drivers, which is available for free: http://lwn.net/Kernel/LDD3/. The kernel version is quite old now (2.6) but the *basics* are helpful for understanding what's going on. Just remember that it was a snapshot in time. OK. So that's the IIO interface. But how do you know the BeagleBone has the hardware to use it? There a few pieces of knowledge you have to connect here. The first is that one would expect a driver for TI's ADC for the AM335x to be in the kernel. Some more searching through the sources reveals this: https://github.com/beagleboard/linux/blob/master/drivers/iio/adc/ti_am335x_adc.c That looks like a likely candidate. Then, we need a method to map this driver to the hardware. The more generic question is, how does the kernel know what hardware lies beneath it? From what I understand, this is done with the *device tree.* So, you need to find the device tree file that defines the use of this driver. This looks like it here: https://github.com/beagleboard/linux/blob/e29980c36939818c225a233284535cff73d9ed53/arch/arm/boot/dts/am33xx.dtsi#L808 But, that's a generic device tree for the AM3XX series, what about the more specific BeagleBone black? More searching: https://github.com/beagleboard/linux/search?p=2q=am33xx.dtsi From there you should see the mapping to the registers in the TRM. I'm not familiar with the particular driver *at all*, so this may not be the correct pairing. :) However, this is the process that generally works for me and I don't think it's too off base. If it is, hopefully somebody will correct me here. 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: Seriously Confused
As a quick speed comparison on the BeagleBone Black. If you program a GPIO line to just toggle up and down in a loop . In Python, using the file system I/O, the line will toggle up and down at about 6 kHz. If you program in C, under Debian, using a tight loop to toggle the line up and down on memory mapped I/O, the line will toggle up and down at about 2.2 MHz. Almost a 3 orders of magnitude improvement. I have read, that in assembler on the PRU, you can get it to toggle at 200 MHz, another two orders of magnitude. So, if you are doing something where response time in the milliseconds is good enough then Python is great. If you are teaching kids to program, then Python seems great. If you are looking for response times in the microseconds, then you need to be closer to the metal with something like C. If you are looking for an example of a C I/O library for BBB GPIO, and some off the peripherals, including the ADC, then look at: https://github.com/VegetableAvenger/BBBIOlib --- Graham On Sunday, November 2, 2014 5:10:18 PM UTC-6, Curt Carpenter wrote: Hello. I am trying to figure out how to use I/O with my BBB running Debian, but the more I try the more confused I get. For example: I try to read the analog inputs using information I find on the web. Per instructions, I enter echo cape-bone-iio /sys/devices/bone_capemgr.*/slots which indeed adds something to slots. Then the instructions say to enter cat /sys/devices/ocp.2/helper.11/AIN1 but I discover that there is no directory named ocp.2 in /sys/devices, or anywhere else that I can find. There is an ocp.3, but it doesn't contain helper.11 ... and so on. 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. 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? 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? -- 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] Updating PinMux setting via /dev/mem has no effect
I have attempted to adjust the pinmux settings for a gpio programatically using mmap() and a write out to the appropriate register. This does not throw exception or any other error however no changes are made. Reading the mmap()'ed location returns pretty reasonable and believable results so I know I am hitting the right location. For example, on my BBB GPIOs 50 and 51 are currently in mux mode 6 (ehrpwm1A_mux1 and ehrpwm1B_mux1) and the pinmux control registers for these are at offsets 0x848 and 0x84c from the 0x44e1000 control register. I can read the memory at these positions just fine and the return values are 0x06 (mux mode 6). Attempting to write a 0x07 to either of these locations to enable mux mode 7 does not error but the value at that memory location remains 0x06. Is there any reason why this should not work? After all the capemanager and cape universal drivers seem to be able to change these settings at runtime. I would very much appreciate any advice and insights anybody has into this issue. Oh yeah, before anybody goes to the trouble of beating me up about it, I am aware that the Device Tree is the recommended way of changing this sort of pinmuxing and for my project I could, and probably will, do it that way. Nevertheless, is there a reason the ocp muxing cannot be adjusted at runtime (as root) by writing to the appropriate GPIO control register location? -- 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: Whci PRU-C-compiler is recommended?
Hi Karl, The PRU GAS and LD ports should be in a good shape. But the PRU GCC port has not yet reached beta. Judge for yourself: - PRU GCC has not been battle tested on a big project. - Only two small examples are currently used to sanity check the pru gcc releases. - PRU GCC has no known bugs. If you can take a little risk and don't mind checking the compiler-generated assembler, then go ahead and try PRU GCC. If you want an ASAP, no hassles C compiler for PRU, TI's one would be a more suitable choice right now. Regards, Dimitar On Tuesday, November 4, 2014 2:11:23 PM UTC+2, Karl Karpfen wrote: Hi, it seems there are two C-compilers available that are able to generate PRU-code. One from TI and one introduced here in this board. But...which one is recommended to be used? That's what I found out so far, may be somebody can add some missing information to make it easier to choose one: TI's PRU-C-compiler is - available at http://software-dl.ti.com/codegen/non-esd/downloads/beta.htm - BETA - can be used to create ARM-objects (which can be linked to a bare metal application and loaded to PRU on start-up automatically?) Community/Open Source PRU-C-compiler is - avaialble at https://github.com/dinuxbg/gnupru - BETA - GCC-based and therefore more stable -- 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] PRU0 base address
OK, I'm sure it is a stupid question but I don't find it in AM335x TRM...there the offset of PRU_CTRL-register is defined with 0x. But what is the base address? I found a definition 0x4a322000 in one of Starterware headers but this seems to be wrong. So what is correct base address for PRU0 registers and RAM areas? -- 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: Whci PRU-C-compiler is recommended?
OK, I'll try GCC version! Just wanted to collect some information regarding both compilers in this thread... 2014-11-04 17:47 GMT+01:00 dinu...@gmail.com: Hi Karl, The PRU GAS and LD ports should be in a good shape. But the PRU GCC port has not yet reached beta. Judge for yourself: - PRU GCC has not been battle tested on a big project. - Only two small examples are currently used to sanity check the pru gcc releases. - PRU GCC has no known bugs. If you can take a little risk and don't mind checking the compiler-generated assembler, then go ahead and try PRU GCC. If you want an ASAP, no hassles C compiler for PRU, TI's one would be a more suitable choice right now. Regards, Dimitar On Tuesday, November 4, 2014 2:11:23 PM UTC+2, Karl Karpfen wrote: Hi, it seems there are two C-compilers available that are able to generate PRU-code. One from TI and one introduced here in this board. But...which one is recommended to be used? That's what I found out so far, may be somebody can add some missing information to make it easier to choose one: TI's PRU-C-compiler is - available at http://software-dl.ti.com/codegen/non-esd/downloads/ beta.htm - BETA - can be used to create ARM-objects (which can be linked to a bare metal application and loaded to PRU on start-up automatically?) Community/Open Source PRU-C-compiler is - avaialble at https://github.com/dinuxbg/gnupru - BETA - GCC-based and therefore more stable -- 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/rwNrqudk0Ug/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: How fast/reliable is ADC sampling from the PRU
Hello jleb! Sorry for the late answer. I did some testing, meanwhile, and it seems that you're right. The ADC subsystem is clocked by CLK_M_OSC directly at 24 MHz. (First, I thought there's an additionaly pre-scaler in the PRCM.) Find attached a libpruio measurement from four channels, connected to a PWM output by different voltage dividers. The PWM frequency and the sampling rate are configured that way that a complete period plus two pixels get shown in the window. The result is as expected, and even if I increase the frequencies, all looks good up to a sampling rate of 200 kHz. -- 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 link Graham -- I think that library will be very useful as a guide, and I'll try using it as my point of entry for a few weeks and see what progress I can make in parallel with exploring the other docs that Joshua has pointed me to. I note the author of the library relies a lot on mmap, which suits me -- although I think I can understand the arguments for NOT using it from a software professional's perspective. It will be a while before I'm ready to tackle the PRU -- and my 'scope is only useful up to 50MHz or so anyway :-) I don't have any need to toggle anything at 200MHz -- but the thought is pretty amazing. Thanks again. Curt On Tuesday, November 4, 2014 9:37:39 AM UTC-6, Graham wrote: As a quick speed comparison on the BeagleBone Black. If you program a GPIO line to just toggle up and down in a loop . In Python, using the file system I/O, the line will toggle up and down at about 6 kHz. If you program in C, under Debian, using a tight loop to toggle the line up and down on memory mapped I/O, the line will toggle up and down at about 2.2 MHz. Almost a 3 orders of magnitude improvement. I have read, that in assembler on the PRU, you can get it to toggle at 200 MHz, another two orders of magnitude. So, if you are doing something where response time in the milliseconds is good enough then Python is great. If you are teaching kids to program, then Python seems great. If you are looking for response times in the microseconds, then you need to be closer to the metal with something like C. If you are looking for an example of a C I/O library for BBB GPIO, and some off the peripherals, including the ADC, then look at: https://github.com/VegetableAvenger/BBBIOlib --- Graham -- 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.
I build SDL1.2 natively on the BBB for BeagleSNES. I use the framebuffer for video, ALSA audio, and the joystick subsystem without any issue. I have not tried the X11 video target because I have only worked with the framebuffer, but there isn't a reason why it would not work just as well. There is currently no framebuffer target in 2.0. I have added a rudimentary BeagleBone Black video target to my 2.0 codebase as I continue to work on getting the kinks worked out of the SGX-based OpenGL ES on the framebuffer with the 3.17 kernel. With the features of the BBB still in flux, I would stick with 1.2 for your development for now. Disable as much of SDL as you can via the configure script when you build natively. I don't remember having to enable swap to build SDL, though I definitely have to enable it to build BeagleSNES natively. I had to pull in a few dev packages to get the headers that I needed to build SDL, but it has been so long since I have done it that I don't remember which ones. Andrew On Sunday, November 2, 2014 5:04:59 PM UTC-5, 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.
[beagleboard] Using BBB for compiling stuff for another embedded platform
Hi, ist possible, to compile (NOT crosscompile!) stuff for this board: http://www.acmesystems.it/arietta CPU is an Atmel AT91SAM9G25 SoC (ARM9 @ 400Mhz)... (no FPU) Thank you very much for any help in advance! Best regards, mcc -- 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: Multiple SPI Kernel Drivers on the Same SPI Bus?
I think you are making this much more difficult than it needs to be.
The standard linux SPI device works fine for talking to any slave
device. What you need to do is to connect one device to CS0 and the
other device to CS1, and then tell the (one) driver to use one or the
other chip select when you open() the slave. If you had two drivers
controlling the same SPI hardware, then you could interleave register
accesses! You don't want to do that. You want each SPI read, write, or
ioctl to access one of your devices in an atomic manner.
If the standard SPI driver you are using does not support anything but
CS0, then you need to add support for the other chip select.
On 10/28/2014 7:16 PM, miltmob...@gmail.com wrote:
On Saturday, October 25, 2014 4:43:02 PM UTC-7, bra...@gmail.com wrote:
*Background*
I have a Beagle Bone Black cape with both a Nordic nRF51822 and TI
CC2520. Both of these devices are on the SPI0 bus. I have kernel
drivers that work for each separately on Debian 3.8.13.
*Goal*
I would like to be able to load both kernel drivers at the same
time and have them share the SPI bus.
*Issue*
While I have figured out how to make each kernel driver take
control of the SPI0 bus when loaded separately, I can't seem to
get them to each have access when loaded together. I'm far from an
expert on device tree overlays and am not sure how to glue
everything together so that the kernel drives are successfully loaded.
Here is my code so far in the kernel driver that pertains to
creating the SPI device for the nRF51822. I create a struct
spi_driver with config information and then call
module_spi_driver() to init, etc. (copied from
/linux/drivers/net/ieee802154/cc2520.c). The probe() function
callback sets up a character device and configures some GPIOs
(that code needs to be updated to work with device tree, but for
now it should be fine).
|
staticintnrf51822_spi_probe(structspi_device *spi_device)
{
ERR(KERN_INFO,Inserting SPI protocol driver.\n);
nrf51822_spi_device =spi_device;
//
// Create a buffer to move data over the character device
//
...
//
// Setup the interrupt from the nRF51822
//
...
//
// Configure the character device in /dev
//
...
return0;
}
staticintnrf51822_spi_remove(structspi_device *spi_device)
{
ERR(KERN_INFO,Removing SPI protocol driver.);
nrf51822_spi_device =NULL;
// Free memory and close things
}
staticconststructspi_device_id nrf51822_ids[]={
{nrf51822,},
{},
};
MODULE_DEVICE_TABLE(spi,nrf51822_ids);
staticconststructof_device_id nrf51822_of_ids[]={
{.compatible =brad,nrf51822,},
{},
};
MODULE_DEVICE_TABLE(of,nrf51822_of_ids);
// Configure SPI
staticstructspi_driver nrf51822_spi_driver ={
.driver ={
.name =nrf51822_name,
.owner =THIS_MODULE,
.bus =spi_bus_type,
.of_match_table =of_match_ptr(nrf51822_of_ids),
},
.id_table =nrf51822_ids,
.probe =nrf51822_spi_probe,
.remove =nrf51822_spi_remove,
};
// This I believe will load this driver correctly
// and cause it to be probed when it is needed.
module_spi_driver(nrf51822_spi_driver);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
|
And here is my attempt at a device overlay. I'm only claiming a
single GPIO which I use as an interrupt from the nRF51822 back to
the beagle bone.
|
/dts-v1/;
/plugin/;
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
/*identification */
part-number = BB-BONE-NRF51822;
version = 00A0;
/*state the resources thiscape uses */
exclusive-use =
/*the pin header uses */
/*GPIO */
P9.16, /*InterruptfromNRF51822 */
/*the hardware ip uses */
gpio1_19;
fragment@0 {
target = am33xx_pinmux;
__overlay__ {
bb_cc2520_gpio_pins:
pinmux_bb_2520_gpio_pins {
compatible = nrf51822;
pinctrl-single,pins =
/*GPIO */
0x04C 0x2F
/*ehrpwm1b.gpio1_19,INPUT |MODE7 */
;
};
};
};
fragment@1 {
target = ocp;
__overlay__ {
nrf51822 {
compatible = brad,nrf51822;
/*the power control gpio */
interrupt-gpio = gpio1 19 0x0;
[beagleboard] write new sd card image
Hello! I downloaded this file via Bittorrent and direct: Debian (BeagleBone, BeagleBone Black - 2GB SD) 2014-05-14 http://debian.beagleboard.org/images/bone-debian-7.5-2014-05-14-2gb.img.xz I use Win32 Disk Imager and generate the sd card. I put the card into the BBB, press USER button and Power up. All 4 LED are on. I release the button and from the LED is only 1 on and keep on. I made some teste with the DeviceTree and have to reflash the eMMC. Because the BBB doesn´t start. I connect the serial debug cable ... and see that he are not booting from sd card? When I check MD5 Hash at Win32 Disk Imager, I get another as on the website, where I download the image. Or is the website Hash for the .xzFile and not for the .img file? \0\030\0\r\n U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)\r\n reading args\r\n spl_load_image_fat_os: error reading image args, err - -1\r\n reading u-boot.img\r\n reading u-boot.img\r\n \r\n \r\n U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)\r\n \r\n I2C: ready\r\n DRAM: 512 MiB\r\n NAND: 0 MiB\r\n MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1\r\n *** Warning - readenv() failed, using default environment\r\n \r\n Net: ethaddr not set. Validating first E-fuse MAC\r\n Could not get PHY for cpsw: addr 0\r\n cpsw, usb_ether\r\n Hit any key to stop autoboot: 1 \b\b\b 0 \r\n gpio: pin 53 (gpio 53) value is 1\r\n mmc0 is current device\r\n gpio: pin 54 (gpio 54) value is 1\r\n SD/MMC found on device 0\r\n reading uEnv.txt\r\n 1672 bytes read in 5 ms (326.2 KiB/s)\r\n gpio: pin 55 (gpio 55) value is 1\r\n Loaded environment from uEnv.txt\r\n Importing environment from mmc ...\r\n Checking if uenvcmd is set ...\r\n gpio: pin 56 (gpio 56) value is 1\r\n Running uenvcmd ...\r\n reading zImage\r\n 4103240 bytes read in 226 ms (17.3 MiB/s)\r\n reading initrd.img\r\n 2957458 bytes read in 165 ms (17.1 MiB/s)\r\n reading /dtbs/am335x-boneblack.dtb\r\n 25926 bytes read in 9 ms (2.7 MiB/s)\r\n Kernel image @ 0x8200 [ 0x00 - 0x3e9c48 ]\r\n ## Flattened Device Tree blob at 8800\r\n Booting using the fdt blob at 0x8800\r\n Using Device Tree in place at 8800, end 88009545\r\n \r\n Starting kernel ...\r\n \r\n Uncompressing Linux... done, booting the kernel.\r\n [0.378378] omap2_mbox_probe: platform not supported\r\n [0.532918] tps65217-bl tps65217-bl: no platform data provided\r\n [0.596810] bone-capemgr bone_capemgr.9: slot #0: No cape found\r\n [0.633918] bone-capemgr bone_capemgr.9: slot #1: No cape found\r\n [0.671026] bone-capemgr bone_capemgr.9: slot #2: No cape found\r\n [0.708135] bone-capemgr bone_capemgr.9: slot #3: No cape found\r\n [0.722803] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN conflict P8.45 (#5:BB-BONELT-HDMI)\r\n [0.732415] bone-capemgr bone_capemgr.9: slot #6: Failed verification\r\n [0.739161] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 BB-BONELT-HDMIN:00A0 (prio 2)\r\n [0.756685] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed\r\n [0.819747] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8\r\n [0.831432] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22\r\n [0.838714] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single\r\n [1.044647] Unhandled fault: external abort on non-linefetch (0x1008) at 0xe089c000\r\n [1.052776] Internal error: : 1008 [#1] SMP THUMB2\r\n [1.057847] Modules linked in:\r\n [1.061092] CPU: 0Not tainted (3.8.13-bone50 #1)\r\n [1.066442] PC is at cpsw_probe+0x348/0x960\r\n [1.070871] LR is at ioremap_page_range+0x95/0xf8\r\n [1.075841] pc : [c0324484]lr : [c0254815]psr: a033\r\n [1.075841] sp : df071e18 ip : fp : df0d3400\r\n [1.087964] r10: c081de48 r9 : de5fb800 r8 : de5fbd90\r\n [1.093474] r7 : de5fb800 r6 : de5fbd40 r5 : r4 : e089c000\r\n [1.100361] r3 : 8000 r2 : r1 : e089d000 r0 : e089c000\r\n [1.107245] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment kernel\r\n [1.115132] Control: 50c5387d Table: 9e2a4019 DAC: 0015\r\n [1.121200] Process swapper/0 (pid: 1, stack limit = 0xdf070240)\r\n [1.127536] Stack: (0xdf071e18 to 0xdf072000)\r\n [1.132146] 1e00: c00b5629\r\n [1.140774] 1e20: c086b9b8 c086b9b8 de5fbd40 de5fba98 df0d3410 de5fe688 df071e90\r\n [1.149408] 1e40: df071e90 c00fdd53 c086b9b8 de5fe688 de2927c0\r\n [1.158038] 1e60: de5fe688 c00fdc8f de5fe688 df071e90 de5fe708 df0d5d48 c00fe507\r\n [1.166673] 1e80: df0494b8 c00492af df0d3444 0020 0008 df0d3410 c09189ec\r\n [1.175306] 1ea0: df0d3410 c088aa58 c0800925 0100 c081de48 c02c6e19\r\n [1.183931] 1ec0: c02c6e09 c02c62bb
Re: [beagleboard] Using BBB for compiling stuff for another embedded platform
On Nov 4, 2014 9:53 AM, meino.cra...@gmx.de wrote: Hi, ist possible, to compile (NOT crosscompile!) stuff for this board: http://www.acmesystems.it/arietta CPU is an Atmel AT91SAM9G25 SoC (ARM9 @ 400Mhz)... (no FPU) Thank you very much for any help in advance! Then run debian wheezy 'armel', it's built for armv4t so it'll run on both devices. Best regards, mcc -- 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.
[beagleboard] Re: Updating PinMux setting via /dev/mem has no effect
Write access to the Control Module pad registers is only possible for the ARM CPU in protected mode. Neither mmaped C code nor the PRUSS can write these registers. That's hard-coded in the AM33xx logic, no feedback on failure. BTW: Beside the universal device tree overlay from Charles Steinkuehler I made a similar overlay that is a bit more complete and uses hexadecimal numbers instead of human readable text for the pin modes. For me, that's easier to handle in source code. The overlay and a tool to create similar overlays with different pin claiming is included in the libpruio http://beagleboard.org/project/libpruio/ package. -- 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] 2GB or 4GB Image on Rev.C?
Hello! Must I flash a SD card with the Debian 4GB Image, or can I use also the 2GB Image? I have a BBB 4GB Rev C 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] Update system time on boot (wireless)
So use init. init scripts work fine along side systemd. Albeit boot times may be slightly slower. The package name you want is ntpdate, e.g. *apt-get install ntpdate* You may also want to configure locales via . . . *dpkg-reconfigure locales* http://www.embeddedhobbyist.com/debian-tips/beaglebone-black/beaglebone-black-init-scripts-default-gatewayand-ntpdate/ On Tue, Nov 4, 2014 at 9:17 AM, Kevin Osborn kevin.osbor...@gmail.com wrote: On bootup, my BBB comes up with an always wrong date/time. Since it has not battery, I understand this. So, I want the BBB to query NTP to get the correct date on bootup. I am also running wireless, so it has to happen after the wireless connects. I am confused on how to accomplish this with the current Debian and systemd. Previous instructions say to just install ntp. But this doesn't appear to do anything. I do see timedated and time-sync, but I am unsure if those are what I want or how to configure them. If I run ntpdate manually, it works fine. I also see that cron.daily is also set to run ntpdate. In the syslog, I also see two calls to set system time from two different IP addresses. Those times are off by years. If I run ntpdate against those IP addresses, it runs fine. Other documentation talks about ntpdate.service or timedatectl (coming in Jessie?), but that doesn't exist here. I also tried setting /etc/adjtime to LOCAL instead of UTC. I do actually want local time. I also linked /etc/localtime to /use/share/.../America/Los_Angeles. Mostly I am just trying to figure out how to get started here. I am unfortunately rather unfamiliar with systemd. 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] write new sd card image
Please retest with: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-10-22 On Nov 4, 2014 10:20 AM, faimbs fai...@gmail.com wrote: Hello! I downloaded this file via Bittorrent and direct: Debian (BeagleBone, BeagleBone Black - 2GB SD) 2014-05-14 http://debian.beagleboard.org/images/bone-debian-7.5-2014-05-14-2gb.img.xz I use Win32 Disk Imager and generate the sd card. I put the card into the BBB, press USER button and Power up. All 4 LED are on. I release the button and from the LED is only 1 on and keep on. I made some teste with the DeviceTree and have to reflash the eMMC. Because the BBB doesn´t start. I connect the serial debug cable ... and see that he are not booting from sd card? When I check MD5 Hash at Win32 Disk Imager, I get another as on the website, where I download the image. Or is the website Hash for the .xzFile and not for the .img file? \0\030\0\r\n U-Boot SPL 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)\r\n reading args\r\n spl_load_image_fat_os: error reading image args, err - -1\r\n reading u-boot.img\r\n reading u-boot.img\r\n \r\n \r\n U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54)\r\n \r\n I2C: ready\r\n DRAM: 512 MiB\r\n NAND: 0 MiB\r\n MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1\r\n *** Warning - readenv() failed, using default environment\r\n \r\n Net: ethaddr not set. Validating first E-fuse MAC\r\n Could not get PHY for cpsw: addr 0\r\n cpsw, usb_ether\r\n Hit any key to stop autoboot: 1 \b\b\b 0 \r\n gpio: pin 53 (gpio 53) value is 1\r\n mmc0 is current device\r\n gpio: pin 54 (gpio 54) value is 1\r\n SD/MMC found on device 0\r\n reading uEnv.txt\r\n 1672 bytes read in 5 ms (326.2 KiB/s)\r\n gpio: pin 55 (gpio 55) value is 1\r\n Loaded environment from uEnv.txt\r\n Importing environment from mmc ...\r\n Checking if uenvcmd is set ...\r\n gpio: pin 56 (gpio 56) value is 1\r\n Running uenvcmd ...\r\n reading zImage\r\n 4103240 bytes read in 226 ms (17.3 MiB/s)\r\n reading initrd.img\r\n 2957458 bytes read in 165 ms (17.1 MiB/s)\r\n reading /dtbs/am335x-boneblack.dtb\r\n 25926 bytes read in 9 ms (2.7 MiB/s)\r\n Kernel image @ 0x8200 [ 0x00 - 0x3e9c48 ]\r\n ## Flattened Device Tree blob at 8800\r\n Booting using the fdt blob at 0x8800\r\n Using Device Tree in place at 8800, end 88009545\r\n \r\n Starting kernel ...\r\n \r\n Uncompressing Linux... done, booting the kernel.\r\n [0.378378] omap2_mbox_probe: platform not supported\r\n [0.532918] tps65217-bl tps65217-bl: no platform data provided\r\n [0.596810] bone-capemgr bone_capemgr.9: slot #0: No cape found\r\n [0.633918] bone-capemgr bone_capemgr.9: slot #1: No cape found\r\n [0.671026] bone-capemgr bone_capemgr.9: slot #2: No cape found\r\n [0.708135] bone-capemgr bone_capemgr.9: slot #3: No cape found\r\n [0.722803] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN conflict P8.45 (#5:BB-BONELT-HDMI)\r\n [0.732415] bone-capemgr bone_capemgr.9: slot #6: Failed verification\r\n [0.739161] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 BB-BONELT-HDMIN:00A0 (prio 2)\r\n [0.756685] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed\r\n [0.819747] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by 44e10800.pinmux; cannot claim for gpio-leds.8\r\n [0.831432] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22\r\n [0.838714] pinctrl-single 44e10800.pinmux: could not request pin 21 on device pinctrl-single\r\n [1.044647] Unhandled fault: external abort on non-linefetch (0x1008) at 0xe089c000\r\n [1.052776] Internal error: : 1008 [#1] SMP THUMB2\r\n [1.057847] Modules linked in:\r\n [1.061092] CPU: 0Not tainted (3.8.13-bone50 #1)\r\n [1.066442] PC is at cpsw_probe+0x348/0x960\r\n [1.070871] LR is at ioremap_page_range+0x95/0xf8\r\n [1.075841] pc : [c0324484]lr : [c0254815]psr: a033\r\n [1.075841] sp : df071e18 ip : fp : df0d3400\r\n [1.087964] r10: c081de48 r9 : de5fb800 r8 : de5fbd90\r\n [1.093474] r7 : de5fb800 r6 : de5fbd40 r5 : r4 : e089c000\r\n [1.100361] r3 : 8000 r2 : r1 : e089d000 r0 : e089c000\r\n [1.107245] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment kernel\r\n [1.115132] Control: 50c5387d Table: 9e2a4019 DAC: 0015\r\n [1.121200] Process swapper/0 (pid: 1, stack limit = 0xdf070240)\r\n [1.127536] Stack: (0xdf071e18 to 0xdf072000)\r\n [1.132146] 1e00: c00b5629\r\n [1.140774] 1e20: c086b9b8 c086b9b8 de5fbd40 de5fba98 df0d3410 de5fe688 df071e90\r\n [1.149408] 1e40: df071e90 c00fdd53 c086b9b8 de5fe688 de2927c0\r\n [1.158038] 1e60: de5fe688 c00fdc8f de5fe688 df071e90 de5fe708 df0d5d48 c00fe507\r\n [1.166673] 1e80: df0494b8 c00492af df0d3444
Re: [beagleboard] 2GB or 4GB Image on Rev.C?
On Nov 4, 2014 10:36 AM, faimbs fai...@gmail.com wrote: Hello! Must I flash a SD card with the Debian 4GB Image, or can I use also the 2GB Image? Well, i list the 2gb image as for 'all' Should be self explanatory. -- 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 11:36 PM To: beagleboard@googlegroups.com beagleboard@googlegroups.com Subject: 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. Hi Andrew, I accept that you have done these tests, but removing test two capacitors from the reset line means the device will come out of reset before the power supply has stabilized and without a capacitor, the reset switch will bounce several times. That is not a good idea. Perhaps you are just lucky given your setup, but removing C24 and C30 is a bad idea. Making these capacitors smaller may fix your problem but I suggest that you do have something there to delay the reset line. Regards, John 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
Re: [beagleboard] Re: BeagleBone Black doesn't sometimes start. Only Power LED is on
Mikkel,
You can give a 3.3v directly or use a small resistor to make the voltage on
the 4th pin of J1 higher than 3V. That should work. We rebooted a board
over hundreds of time by using an app on Linux. It did not fail a single
time.
We found this accidently by using serial cable and the board never fails to
boot when the cable is connected. The serial cable gives the 3.3v to the
4th pin which is the UART0_RX.
We tried to figure out what cause the problem and found a weird thing. We
measured the UART3_RX(D16), UART3_TX(D15), UART4_RX(pin11 on header P9) and
UART4_TX(pin13 on header P9). They are all 3.3V and they are in UART mode.
We removed the R165 which is the pull down resistor on the UART0_RX line.
The UART0_RX is around 1.4V and sometimes floating. We also checked the
device tree. The internal pull up of the UART0_RX is turned on.
uart0_pins: pinmux_uart0_pins {
pinctrl-single,pins =
0x170 (PIN_INPUT_PULLUP | MUX_MODE0) /* uart0_rxd.uart0_rxd */
We do not know why the UART0_RX is not getting 3.3V, can you please check
the voltage on both UART0_TX and UART0_RX when U15 is removed?
Again, If somebody can tell me how to fix it in uboot or from software
perspective, I would really appreciate it.
Regards,
Shu
--
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 won't boot up (PWR Led does a single quick blink)
Hi, There should be a short on board. The U2 shuts itself down to prevent the high current draw which is caused by the short. That is why the LED goes off after it blinks once. Regards, Shu On Monday, October 27, 2014 10:56:34 PM UTC-5, s...@kopi-d.com wrote: I am in the same situation. Was trying out new images. Did an forced SD change to a non-bootable bbb. Now it won't boot. Just a pwr blink then dead. Are there any other ways to recover other than RMA? PMIC replacement or reflashing of bootloader? Sam On Wednesday, June 18, 2014 9:53:25 PM UTC+8, Gerald wrote: Request an RMA. http://beagleboard.org/Support/RMA And read this. http://www.elinux.org/Beagleboard:BeagleBoneBlack#Hardware Gerald On Mon, Jun 9, 2014 at 5:54 PM, v...@victor.so wrote: My BBB (A5A) was working fine with ARM Arch (installed on the eMMC), but since yesterday it won't turn on. I don't know what changed. When I plug the power source or the USB cable the PWR Led quickly blinks, but the board doesn't turn on. If I press the POWER button, the PWR led does a single blink too, but it doesn't proceed to boot. I also tried to boot from the SD card, but It didn't work. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Multiple SPI Kernel Drivers on the Same SPI Bus?
use GPIO as slave selects
http://www.nagavenkat.adurthi.com/2014/02/spi-communication-beaglebone-black-as-master-to-arduino-as-slave/
On Sunday, October 26, 2014 10:43:02 AM UTC+11, bra...@gmail.com wrote:
*Background*
I have a Beagle Bone Black cape with both a Nordic nRF51822 and TI CC2520.
Both of these devices are on the SPI0 bus. I have kernel drivers that work
for each separately on Debian 3.8.13.
*Goal*
I would like to be able to load both kernel drivers at the same time and
have them share the SPI bus.
*Issue*
While I have figured out how to make each kernel driver take control of
the SPI0 bus when loaded separately, I can't seem to get them to each have
access when loaded together. I'm far from an expert on device tree overlays
and am not sure how to glue everything together so that the kernel drives
are successfully loaded.
Here is my code so far in the kernel driver that pertains to creating the
SPI device for the nRF51822. I create a struct spi_driver with config
information and then call module_spi_driver() to init, etc. (copied from
/linux/drivers/net/ieee802154/cc2520.c). The probe() function callback
sets up a character device and configures some GPIOs (that code needs to be
updated to work with device tree, but for now it should be fine).
static int nrf51822_spi_probe(struct spi_device *spi_device)
{
ERR(KERN_INFO, Inserting SPI protocol driver.\n);
nrf51822_spi_device = spi_device;
//
// Create a buffer to move data over the character device
//
...
//
// Setup the interrupt from the nRF51822
//
...
//
// Configure the character device in /dev
//
...
return 0;
}
static int nrf51822_spi_remove(struct spi_device *spi_device)
{
ERR(KERN_INFO, Removing SPI protocol driver.);
nrf51822_spi_device = NULL;
// Free memory and close things
}
static const struct spi_device_id nrf51822_ids[] = {
{nrf51822, },
{},
};
MODULE_DEVICE_TABLE(spi, nrf51822_ids);
static const struct of_device_id nrf51822_of_ids[] = {
{.compatible = brad,nrf51822, },
{},
};
MODULE_DEVICE_TABLE(of, nrf51822_of_ids);
// Configure SPI
static struct spi_driver nrf51822_spi_driver = {
.driver = {
.name = nrf51822_name,
.owner = THIS_MODULE,
.bus = spi_bus_type,
.of_match_table = of_match_ptr(nrf51822_of_ids),
},
.id_table = nrf51822_ids,
.probe = nrf51822_spi_probe,
.remove = nrf51822_spi_remove,
};
// This I believe will load this driver correctly
// and cause it to be probed when it is needed.
module_spi_driver(nrf51822_spi_driver);
MODULE_LICENSE(GPL);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
And here is my attempt at a device overlay. I'm only claiming a single
GPIO which I use as an interrupt from the nRF51822 back to the beagle bone.
/dts-v1/;
/plugin/;
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
/* identification */
part-number = BB-BONE-NRF51822;
version = 00A0;
/* state the resources this cape uses */
exclusive-use =
/* the pin header uses */
/* GPIO */
P9.16, /* Interrupt from NRF51822 */
/* the hardware ip uses */
gpio1_19;
fragment@0 {
target = am33xx_pinmux;
__overlay__ {
bb_cc2520_gpio_pins: pinmux_bb_2520_gpio_pins {
compatible = nrf51822;
pinctrl-single,pins =
/* GPIO */
0x04C 0x2F /* ehrpwm1b.gpio1_19,
INPUT | MODE7 */
;
};
};
};
fragment@1 {
target = ocp;
__overlay__ {
nrf51822 {
compatible = brad,nrf51822;
/* the power control gpio */
interrupt-gpio = gpio1 19 0x0;
/* the muxing */
pinctrl-names = default;
pinctrl-0 = nrf51822_pins;
};
};
};
};
The end effect is that my probe() function in the kernel driver is never
called, even after loading the overlay and kernel module.
How do I set things up so that two kernel modules can both use SPI0? Has
anyone tried this? Everything I've looked at appears to assume only one
device is attached to the SPI bus so it can specify the SPI pins in its
.dts file (but I could be wrong about that).
Thanks for any help or direction.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed
Re: [beagleboard] Updating PinMux setting via /dev/mem has no effect
You have to be in privileged mode to change pinmux. My approach is creating a kernel module for it like this ( https://github.com/chunsj/nxctrl/tree/master/nxpmx) Or you can use PRU for this, I've heard that someone really do this in his library (I cannot remember its name). However to control PRU you might need to be in privileged mode to enable PRU and others... Last but most official method is use of device tree and reboot. If your kernel is 3.8.16, you can use device tree overlay. I hope this can help you. On Wed, Nov 5, 2014 at 1:46 AM, Nic Cyn ofitsel...@gmail.com wrote: I have attempted to adjust the pinmux settings for a gpio programatically using mmap() and a write out to the appropriate register. This does not throw exception or any other error however no changes are made. Reading the mmap()'ed location returns pretty reasonable and believable results so I know I am hitting the right location. For example, on my BBB GPIOs 50 and 51 are currently in mux mode 6 (ehrpwm1A_mux1 and ehrpwm1B_mux1) and the pinmux control registers for these are at offsets 0x848 and 0x84c from the 0x44e1000 control register. I can read the memory at these positions just fine and the return values are 0x06 (mux mode 6). Attempting to write a 0x07 to either of these locations to enable mux mode 7 does not error but the value at that memory location remains 0x06. Is there any reason why this should not work? After all the capemanager and cape universal drivers seem to be able to change these settings at runtime. I would very much appreciate any advice and insights anybody has into this issue. Oh yeah, before anybody goes to the trouble of beating me up about it, I am aware that the Device Tree is the recommended way of changing this sort of pinmuxing and for my project I could, and probably will, do it that way. Nevertheless, is there a reason the ocp muxing cannot be adjusted at runtime (as root) by writing to the appropriate GPIO control register location? -- 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.
[beagleboard] Expand NY 2014 Meetup
Hello all, Is anyone going to the Engadget Expand NY 2014 conference this weekend. PM me if you want to meetup! We can chitchat over drinks and coffee! -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Chu, On 2014-11-04 21:40, Shu Liu wrote: You can give a 3.3v directly or use a small resistor to make the voltage on the 4th pin of J1 higher than 3V. That should work. We rebooted a Well, that is interesting, as it isn't consistent with my findings. I guess you missed that I use a 82k5 ohms resistor as pull up. That's where the 3,3V*(100k/(100k+82,5k)= 1.81V level on B_UART0_RX/J4.1 is from (which I misstated as the 82k2's voltage drop of 1.4V in previous post). This is close to, but not surpassing, the high level voltage of U15 which is 2V at 3.3V VCC (datasheet p. 3), thus it will interpret my B_UART0_RX as a low level. As my modification also solves the issue, your assumption about your fix (a high level at J4.1/B_UART0_RX (U15.2/1A)) is not true. board over hundreds of time by using an app on Linux. It did not fail a single time. Nice, thought about doing something like that too while manually plug/unplugging ;). Is that application available somewhere? It would be nice to fully automate the test to really hammer this issue. How do you notify the application of successful boot? Another BBB and some IO's? We found this accidently by using serial cable and the board never fails No-one can plan for good stuff, it just shows up. Nice find, I remember having read your posting about it somewhere. We measured the UART3_RX(D16), UART3_TX(D15), UART4_RX(pin11 on header P9) and UART4_TX(pin13 on header P9). They are all 3.3V and they are in UART mode. Pins configurable for UART3 is used for MMC/MII, so I guess it is UART1 on TX;D15/P9.24 and RX;D16/P9.26 you have measured? We removed the R165 which is the pull down resistor on the UART0_RX line. The UART0_RX is around 1.4V and sometimes floating. We also checked the device tree. The internal pull up of the UART0_RX is turned on. Peculiar, as it should never float. We do not know why the UART0_RX is not getting 3.3V, can you please check the voltage on both UART0_TX and UART0_RX when U15 is removed? I'll definitely look into this tomorrow. Including taking this measurement. Again, If somebody can tell me how to fix it in uboot or from software perspective, I would really appreciate it. Got hints or pointers on bulding uboot for BBB? There's a lot of different how-tos/blogs out there. Regads, - -- Mikkel ,= ,-_-. =. ((_/)o o(\_)) `-'(. .)`-' \_/ -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUWY+ZAAoJEJ2luFWzaTSaM34H/1SOSvouAWoFQcngSqhuw6Z0 TjLhyZpfNmhRc4/Ykh4Wn4iW1oPL4WXYXJ35ePY5TAt69eQbuvDGhkpN2FMz/Seb n1tbz4jz1fhXS1UYFT9ogJ4KuzE1YdQe4+GeTThEfsHCglTJGGuKSYVA4A/0uw0k wRb7URXZYZ2JKAklPu+349UCJc+7oNBWtLiFV6CV/psuLq25wpwcmoq5qYnepOVK BtKG+clu3IIXKlT+lzQb043KdAnCWOnKbs434robS1HUAQyuUBxrDz5+yu+2RW2B LX2jfDXFHRjQ5dxR/WRdbk2MGJdlBkynV78vvYKi7IOWP9mSwQMm7sdGTIvIhNE= =m/NP -END PGP SIGNATURE- -- 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] Using BBB for compiling stuff for another embedded platform
Robert Nelson robertcnel...@gmail.com [14-11-04 19:20]: On Nov 4, 2014 9:53 AM, meino.cra...@gmx.de wrote: Hi, ist possible, to compile (NOT crosscompile!) stuff for this board: http://www.acmesystems.it/arietta CPU is an Atmel AT91SAM9G25 SoC (ARM9 @ 400Mhz)... (no FPU) Thank you very much for any help in advance! Then run debian wheezy 'armel', it's built for armv4t so it'll run on both devices. Best regards, mcc -- 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. Hi Robert, thank for email! :) On my Beaglebone Black I am using Gentoo (hf), which I dont want to swap with debian or any other distribution. Is it possible to install a hardfloat and a softfloat compiler simultanously on my BBB. And is my assumption correct, that nothing else should be changed with exception of the gcc? Best regards, Meino -- 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 a lot for the elaborate reply and testing. Much appreciated. Seems like this is the way to go. I'll probably pester you soon with questions regarding libpruio! :) Cheers, jleb On Tuesday, November 4, 2014 11:57:48 AM UTC-5, TJF wrote: Hello jleb! Sorry for the late answer. I did some testing, meanwhile, and it seems that you're right. The ADC subsystem is clocked by CLK_M_OSC directly at 24 MHz. (First, I thought there's an additionaly pre-scaler in the PRCM.) Find attached a libpruio measurement from four channels, connected to a PWM output by different voltage dividers. The PWM frequency and the sampling rate are configured that way that a complete period plus two pixels get shown in the window. The result is as expected, and even if I increase the frequencies, all looks good up to a sampling rate of 200 kHz. -- 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] Using BBB for compiling stuff for another embedded platform
On Nov 4, 2014 7:18 PM, meino.cra...@gmx.de wrote: Robert Nelson robertcnel...@gmail.com [14-11-04 19:20]: On Nov 4, 2014 9:53 AM, meino.cra...@gmx.de wrote: Hi, ist possible, to compile (NOT crosscompile!) stuff for this board: http://www.acmesystems.it/arietta CPU is an Atmel AT91SAM9G25 SoC (ARM9 @ 400Mhz)... (no FPU) Thank you very much for any help in advance! Then run debian wheezy 'armel', it's built for armv4t so it'll run on both devices. Best regards, mcc -- 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. Hi Robert, thank for email! :) On my Beaglebone Black I am using Gentoo (hf), which I dont want to swap with debian or any other distribution. Is it possible to install a hardfloat and a softfloat compiler simultanously on my BBB. And is my assumption correct, that nothing else should be changed with exception of the gcc? On gentoo, wouldn't you have to adjust the use flags for armv5 then rebuild all the libs/GCC first? Otherwise you'd just be cross compiling for the atmel chip.. Best regards, Meino -- 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.
HI Andrew John, Thank you for your reply. I guess that leaves me with no choice but to tweak the hardware also update the kernel to the latest version by Robert. Hopefully that will fix the issue for ever. I will keep you posted on the status. regards, Jerin On Wednesday, 5 November 2014 01:23:28 UTC+5:30, john3909 wrote: From: Andrew Glen andrewt...@gmail.com javascript: Reply-To: beagl...@googlegroups.com javascript: beagl...@googlegroups.com javascript: Date: Monday, November 3, 2014 at 11:36 PM To: beagl...@googlegroups.com javascript: beagl...@googlegroups.com javascript: Subject: 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. Hi Andrew, I accept that you have done these tests, but removing test two capacitors from the reset line means the device will come out of reset before the power supply has stabilized and without a capacitor, the reset switch will bounce several times. That is not a good idea. Perhaps you are just lucky given your setup, but removing C24 and C30 is a bad idea. Making these capacitors smaller may fix your problem but I suggest that you do have something there to delay the reset line. Regards, John Andrew. On 4/11/2014 7:26 PM, John Syn john...@gmail.com javascript: wrote: From: Andrew Glen andrewt...@gmail.com javascript: Reply-To: beagl...@googlegroups.com javascript: beagl...@googlegroups.com javascript: Date: Monday, November 3, 2014 at 9:42 PM To: beagl...@googlegroups.com javascript: beagl...@googlegroups.com javascript: 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...@gmail.com javascript: 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...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You
Re: [beagleboard] 2GB or 4GB Image on Rev.C?
Ah, ok. Thank you! Then I don´t know why he doesn´t boot from SD Card :-( Also the MD5 checksum in Win32 Disk Imager is different to the MD5 on the website. Downloaded it 2 times. In Windows I can read the SD card after writing. -- 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] 2GB or 4GB Image on Rev.C?
On Wed, Nov 5, 2014 at 12:11 AM, faimbs fai...@gmail.com wrote: Ah, ok. Thank you! Then I don´t know why he doesn´t boot from SD Card :-( Also the MD5 checksum in Win32 Disk Imager is different to the MD5 on the website. Downloaded it 2 times. the md5sum's are generated on the *.img.xz Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] 2GB or 4GB Image on Rev.C?
Ok, thank you! Then the MD5 is fine. Just test now the 4GB image ... also the serial debug cable is connected. Is there a line, where I can see if there is a problem with sd card? Or should I post the output here? -- 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] 2GB or 4GB Image on Rev.C?
On Wed, Nov 5, 2014 at 12:27 AM, faimbs fai...@gmail.com wrote: Ok, thank you! Then the MD5 is fine. Just test now the 4GB image ... also the serial debug cable is connected. Is there a line, where I can see if there is a problem with sd card? Or should I post the output here? Since it's not working by default. Try with holding the boot button down before and while you plug in the 5volt dc power. You can let off the button when teh 4 led's light up.. All the logging/debugging for flashing the eMMC comes over the serial, so you could log that and post to pastebin.com and in can take a look at it. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] 2GB or 4GB Image on Rev.C?
Hi Robert! Thank you for your help! The 4GB image are working, the 2GB are not working for me. Now he flash the eMMC. I try later again the 2GB, because now I know what he write to serial port. 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.
