Re: [beagleboard] BBXM HDMI issue on ubuntu-14.04.1 with LXDE
No, no display on the TV. After the command: ubuntu@arm:~$ xrandr -display :0.0 -q Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 2048 x 2048 DVI-D-1 connected 1280x1024+0+0 160mm x 90mm 1280x1024 60.0* 720x57650.0 720x48060.0 59.9 -- 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] Beaglebone Black Ethernet Phy Not Detected on Boot.
Hi Pratik, As I studied the latest kernel code (3.8.13-bone67), I noticed that the patch https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/SRlnumt0LoMJ mentioned by Jay @ Control Module Industries is already there, but apparently it doesn't help. After a lot of experiments with U-Boot, I'm more convinced that the problem cannot be solved with U-Boot only. Actually, I included those rewriting commands I mentioned earlier https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/1FuI_i5KW10J in the bootcmd variable and rebuilt the U-Boot. But that didn't work at all, i.e. the required registers of LAN8710A http://ww1.microchip.com/downloads/en/DeviceDoc/8710a.pdf transceiver weren't rewritten (maybe some delay is required before and after those commands). I also tried rewriting them manually in U-Boot command line, as I mentioned earlier, but this time I tried various combinations of Soft Reset, Power Down and Restart Auto-Negotiate commands afterwards. It was all futile. Even when transceiver settings like PHY address, mode, etc. are correct (as a result of rewriting them manually), the processor doesn't recognize the transceiver after reset command by U-Boot. And the state of some transceiver registers, containing info about its link partner, indicates that this is the problem of the link partner, i.e. the processor. And in this case, only a power-on or button reset can bring the processor to the state where it can detect the transceiver. Also, I read the processor Ethernet Subsystem registers in U-Boot, both when the transceiver is detected and when it is not. And the difference seems to be in the way the processor uses the content of MDIOALIVE register (the PHY acknowledge status register), because in both cases that content is correct. For example, if the the transceiver powers up with PHY address 0 then the bit 0 of MDIOALIVE is set to 1, if the transceiver powers up with PHY address 2, the bit 2 of MDIOALIVE is set to 1, etc. So, this means that the processor gets the acknowledge from PHY with address 2 after trying to access it, according to the page 2212 of AM335x Sitara Processors Manual http://www.ti.com/lit/ug/spruh73k/spruh73k.pdf, and knows that a transceiver with PHY address 2 is around. But then, may be some time later, the processor fails to get the data from the transceiver, because it tries to read by a wrong PHY address, which is reflected by the state of the MDIOUSERACCESS0 register (page 2216 of AM335x manual). When the PHY address is 0, the content of MDIOUSERACCESS0 is 0x23e01058, which means that the data 0x1058 (bits 15-0) was read from the PHY address 0 (bits 20-16), from the PHY register 31 (bits 25-21) and PHY acknowledged the read transaction (bit 29). When the PHY address is 2, the content of MDIOUSERACCESS0 is 0x0020, i.e. the processor attempted to read from PHY address 0 (despite of the content of MDIOALIVE suggesting that PHY address is 2) and, of course, failed. This failure happens somewhere in U-Boot code (I guess, in drivers/net/davinci_emac.c), of course, but the same seems to happen in the kernel code (drivers/net/ethernet/ti/davinci_mdio.c) in spite of that patch, whose purpose is to update the device tree using the content of MDIOALIVE register. Maybe all this happens because the step 4 of the MDIO module initialization procedure, mentioned on page 1972 of AM335x manual, is not present in the code? In that step, it is necessary to save the PHY address in the MDIOUSERPHYSEL0 register, to monitor the the link status of the respective PHY. Alex On Saturday, November 29, 2014 5:54:34 PM UTC+1, rathod@gmail.com wrote: Hi Alex, What I tried to say that the fix I applied had same logic which was described by Jay @ Control Module Industries in this discussion. Since I can not use device tree features of latest kernels, I made the changes which can fit in kernel 3.2 which is supplied by TI Android code. In my tests (which included many resets) it seem to be working fine. I also believe that rebuilding the kernel is not dangerous as long as we know what we are doing. :) Regards, Pratik On Saturday, 29 November 2014 21:52:21 UTC+5:30, alexschn...@gmail.com wrote: to myersco...@gmail.com: Hi, I noticed that simply pushing RESET button actually helps sometimes, in my recent experiments. At the same time, pushing POWER button may not help sometimes. I have an impression that this issue is a bit different by different people. Have you tried resetting the board by means of RESET button many times, without init 1 command, to see whether RESET button alone can help? Regards, Alex On Friday, November 28, 2014 11:43:15 PM UTC+1, myersco...@gmail.com wrote: Ok, so this just happened to me. What I think ultimately caused it in my case is the OS hung on shutdown, so I had to hard-power-off the board with the power button. When it came back up, no network :/ Connected
Re: [beagleboard] tun module missing in kernel 3.14.25-ti-r37
I can confirm a working tun module with openvpn with the updated kernel 3.14.25-ti-r38. Thanks! On Wednesday, December 3, 2014 12:12:01 AM UTC+1, RobertCNelson wrote: On Tue, Dec 2, 2014 at 5:06 PM, toni incog toni@gmail.com javascript: wrote: Uhhh, will this lead to a new kernel which I can upgrade to? It will take some time before i've learned how to cross compile kernel modules. It will, i need to also rebase against (1).. Usually I queue up the changes and push a build later in the week (thursday ish).. 1: http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-3.14.y Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Learn Embedded Systems
Hello all, I want learn more about embedded systems. I have a lot of free time. I wrote the http://elinux.org/Building_for_BeagleBone, where I download all the source code for BBB, the latest kernel from linus, config, build and run. What's the next thing that I could do learn more about developing embedded systems ? Maybe deal with yocto could be good, but what kind of things a embedded system engineer should know and have done at least one time in life ? I also have a intel edison and a IFC6410 from qualcomm. Thanks Best Reagards -- Lucas A. Tanure Alves +55 (19) 988176559 -- 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] Learn Embedded Systems
Lucas Tanure ltan...@gmail.com [14-12-06 17:56]: Hello all, I want learn more about embedded systems. I have a lot of free time. I wrote the http://elinux.org/Building_for_BeagleBone, where I download all the source code for BBB, the latest kernel from linus, config, build and run. What's the next thing that I could do learn more about developing embedded systems ? Maybe deal with yocto could be good, but what kind of things a embedded system engineer should know and have done at least one time in life ? I also have a intel edison and a IFC6410 from qualcomm. Thanks Best Reagards -- Lucas A. Tanure Alves +55 (19) 988176559 -- 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. Hello Lucas, learn writing good C-Code and invent kernel drivers for different I2C-,SPI-, CAN- and other busses-devices like sensors, meters, and such. Port Linux to another architeture. A system engineer needs engineering power...the spirit to invent things himself. That's engineering. ...where no man has gone before..., you know ;) Best regard, 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: PRU C Project - from device tree to program execution
Hey Peter, thank you for your guide. Im a bit stuk with my own projekt. I wrote and succesfully debugged some code for reading from an ADC with CCS and a JTAG probe. I also checked the shared ram mecanism for the host/PRU communication by manipulating it via Memory Browser. It works well from the PRU side. I also wired some LED' s for debugging for when I'm trying out with the Linux (Ubuntu). So as I can see i have done all the steps you mentioned below. But when I load the PRU-Programm with prussdrv_exec_program (PRU_NUM, ./text.bin); nothing is happening with the PRU. First line in the the program should switch the Debug LED's from previus state. The right pinmuxxing can be seen when applying the devicetree overlay - one LED lights up as experienced with CCS and JTAG manipulating the control module. So I wonder wy my PRU doesnt seem to run the program. Do you know any way to look inside the PRU from linux? with kind regards Philipp -- 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: PRU C Project - from device tree to program execution
Um, and what about the data.bin file? I see you only use the text.bin file. Am Sonntag, 7. Dezember 2014 01:51:44 UTC+1 schrieb Phil W.: Hey Peter, thank you for your guide. Im a bit stuk with my own projekt. I wrote and succesfully debugged some code for reading from an ADC with CCS and a JTAG probe. I also checked the shared ram mecanism for the host/PRU communication by manipulating it via Memory Browser. It works well from the PRU side. I also wired some LED' s for debugging for when I'm trying out with the Linux (Ubuntu). So as I can see i have done all the steps you mentioned below. But when I load the PRU-Programm with prussdrv_exec_program (PRU_NUM, ./text.bin); nothing is happening with the PRU. First line in the the program should switch the Debug LED's from previus state. The right pinmuxxing can be seen when applying the devicetree overlay - one LED lights up as experienced with CCS and JTAG manipulating the control module. So I wonder wy my PRU doesnt seem to run the program. Do you know any way to look inside the PRU from linux? with kind regards Philipp -- 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] Servo PWM: Getting IOError: [Errno 2] No such file or directory: '/slots'
Hi, On my BBB running Ubuntu 14 I am using adafruit py libs to for servo control. But I get the following error. Same with P9_14. Any idea why I am getting this and what I should do to make it go away? Thanks a lot! import Adafruit_BBIO.PWM as PWM PWM.start(P8_13, 95.0, 60) IOError: [Errno 2] No such file or directory: '/slots' Sid -- 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 throwing NMIs and time outs
This is an off-shoot from the issue entitled wifi unreliable but a completely different issue. I'm very pleased with the TL-WN722N wifi plug, BTW. My setup: - BBB rev C - Debian 7.7 and 3.18-0-rc3-bone1 custom build using RCN image-builder - USB 4-port hub - Tenda W311M (Ralink RT537) wifi plug as control interface - TP-Link TL-WN722N (Atheros AR9271) wifi plug as RFMON monitor interface - external 1.5A power supply My application is a wifi sniffer for SOHO networks using dumpcap saving to a file on the sdcard and then offloading the file to another system for analysis. When I use a capture filter on a single wifi MAC it works well. When I capture on all MACs, it works well for about five minutes (~50K 802.11 frames) and then the kernel starts complaining - periodically generating a mix of NMIs and bus timeouts and my SSH session stops - but it looks like the RFMON interface continues to capture 80211 frames. See attached file for the console capture. When I kill the RFMON capture, things settle down and I can reconnect via SSH. I think this is a case of the CPU running hard handling high-priority tasks so the watchdog and SPI bus are not serviced in the necessary time windows. I'll dig into this more tomorrow - ftrace, dynamic debug poles in the driver, etc (yes,that will place a greater burden on the CPU but hopefully it will point me to something.) Conceptually the kernel shouldn't schedule the 80211 receive tasklets if they are consuming too much of the CPU - but I'm not clear how that would happen. Any advice/experience with this will be appreciated. Dave -- 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. issue.141206 Description: Binary data
[beagleboard] Re: PRU C Project - from device tree to program execution
I don't know of a way to debug the PRU. I'd start with a very simple C program. You can start with setting the interrupt telling the loader the program is halting. Next, enable the OCP, then go into a tight loop toggling a pin. // Enable OCP master ports - this enables pinmux pins to R30 R31 host ram access (all the BBB GPIO ports such) CT_CFG.SYSCFG_bit.STANDBY_INIT = 0; That should let you know the PRU is loaded and running and it is able to access pins. -- 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] Upstream kernel status?
Hi, Is there any place where I can see ongoing progress or status of am335x upstream support? I would love to see something like this (from the sunxi folks): http://linux-sunxi.org/Linux_mainlining_effort Of course such a page is asking for a lot. Most specifically, I am wondering when the upstream kernel will support turning off the board at shutdown, which I think is a PMIC feature. Fedora follows the upstream kernel very closely, and the beaglebone works very well for me except for this power down issue. Thanks, Adam -- 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: PRU C Project - from device tree to program execution
If all your variables are in the .bss segment (uninitialized variables) then you only need to load the text.bin file. -- 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] Upstream kernel status?
On Dec 6, 2014 10:53 PM, Adam Goode a...@spicenitz.org wrote: Hi, Is there any place where I can see ongoing progress or status of am335x upstream support? I would love to see something like this (from the sunxi folks): http://linux-sunxi.org/Linux_mainlining_effort Of course such a page is asking for a lot. Most specifically, I am wondering when the upstream kernel will support turning off the board at shutdown, which I think is a PMIC feature. Fedora follows the upstream kernel very closely, and the beaglebone works very well for me except for this power down issue. Full pmic shutdown should fully work as of the up coming v3.19-rc merge. It took a rtc cleanup and some bike shedding on the power off DTS name Thanks, Adam -- 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.
