Re: [beagleboard] Purpose of the GND_OSC zero ohm resistors?
Thanks for the info, John. I thought it might have something to do with that. If I get a chance I'll have to pick up that book - thanks for the suggestion! I see in the earlier BBB designs the GND_OSC wasn't connected to the main DGND. Only later were they connected (via those zero ohm resistors), and that apparently helped the BBB function better. To me it seems that would introduce more switching noise (as John put it) than leaving them not connected to DGND. I guess I'm a little confused about John's use of the word isolated (If you don’t isolate the OSC gnd...) - were you suggesting the zero ohm resistors acted as isolation from digital ground in this case? Gerald - do you mean that I could connect the GND_OSC net to the DGND net directly, or were you saying that I didn't need to connect those two at all (as in the earlier versions of the BBB)? What's the reason for having the resistors on the BBB if they're not needed? I was speculating that maybe you weren't initially sure if connecting the ground nets together would solve the ground bounce problem or maybe introduce worse problems, so you used those resistors to allow yourself the ability to leave them unpopulated in the event that it caused more issues than it solved (rather than re-spin new boards without the connection at all). -- 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] LCD4 Cape Overlay Goof?
On 12/4/2014 5:47 PM, Robert Nelson wrote: On Thu, Dec 4, 2014 at 5:35 PM, Charles Steinkuehler char...@steinkuehler.net wrote: There seems to be a problem with the LCD4-00A1 cape overlay. The overlay includes support for four buttons, while the actual board seems to have five, and one of the four GPIO pins configured in the overlay is *NOT* actually used by the hardware (per the schematic). Before I send in a patch, it seems like this would have been identified and fixed before now. Am I just missing the proper overlay somehow? I am building the kernel using the scripts from (tag 3.8.13-bone68): It's 5 key's, when i redid this for v3.14.x and tested lcd4-01-00a1/4dcape-43(t)... https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-common-pinmux.dtsi#L355 That matches what I expect based on the schematic, and differs from the 3.8.13 overlay. It's a travel day for me, but I'll format a patch for 3.8.13 and send it out soonish. -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
RE: [beagleboard] xeno_16550A driver install on Debian 3.8.13-bone67
Have you looked into using a PRU for the real time data capture? There are two PRU units that run independently from the am335x processor. They are dedicated 200mz 32 bit microcontrollers with 8k program 8k data. They also have the ability to interface with the BBB pins - even shift in up to 28 bits at a time. You can program in C or Assembly and get very tight timing loops to capture data. The PRU memory is accessible to the am335x, so you can build a buffer of real time data and collect it from Linux when it has time. -- 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] BBXM HDMI issue on ubuntu-14.04.1 with LXDE
Robert, Before connection to the TV: xrandr -display :0.0 -q Screen 0: minimum 320 x 200, current 720 x 480, maximum 2048 x 2048 DVI-D-1 connected 720x480+0+0 160mm x 90mm 800x60056.2 720x480 (0x43) 27.0MHz h: width 720 start 736 end 798 total 858 skew0 clock 31.5KHz v: height 480 start 489 end 495 total 525 clock 60.0Hz After connection to the TV: ubuntu@arm:~$ xrandr -display :0.0 -q Screen 0: minimum 320 x 200, current 720 x 480, maximum 2048 x 2048 DVI-D-1 connected 720x480+0+0 160mm x 90mm 1280x1024 60.0 720x57650.0 720x48060.0*59.9 Leo On 4 December 2014 at 20:14, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Dec 4, 2014 at 1:11 PM, Leo738 oo.he...@gmail.com wrote: Added .txt to end of attached filename Okay, looks like xorg tried to set it up with what it wanted.. What does xrandr show? (this is from the serial/ssh:) 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 338mm x 270mm 1280x1024 60.0*+ 1152x864 75.0 1024x768 75.1 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 a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/vG7c6_ckX6M/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. -- Regards, Owen -- 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] BBXM HDMI issue on ubuntu-14.04.1 with LXDE
My current uEnv.txt: cat /boot/uEnv.txt #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0 uname_r=3.17.1-armv7-x3 #dtb= uuid=f25adba4-d22e-462e-adaf-bfb0013c91f1 #Force HDMI resolution for LG42LV550T-ZA #From: https://groups.google.com/forum/?hl=en-GB#!searchin/beagleboard/HDMI/beagleboard/TOCarHIhVI8/_UxUKnOIJ9UJ #cmdline=video=DVI-D-1:1024x768@60e #or: cmdline=video=DVI-D-1:1920x1080@60e #cmdline=quiet On 5 December 2014 at 14:14, Owen O'Hehir oo.he...@gmail.com wrote: Robert, Before connection to the TV: xrandr -display :0.0 -q Screen 0: minimum 320 x 200, current 720 x 480, maximum 2048 x 2048 DVI-D-1 connected 720x480+0+0 160mm x 90mm 800x60056.2 720x480 (0x43) 27.0MHz h: width 720 start 736 end 798 total 858 skew0 clock 31.5KHz v: height 480 start 489 end 495 total 525 clock 60.0Hz After connection to the TV: ubuntu@arm:~$ xrandr -display :0.0 -q Screen 0: minimum 320 x 200, current 720 x 480, maximum 2048 x 2048 DVI-D-1 connected 720x480+0+0 160mm x 90mm 1280x1024 60.0 720x57650.0 720x48060.0*59.9 Leo On 4 December 2014 at 20:14, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Dec 4, 2014 at 1:11 PM, Leo738 oo.he...@gmail.com wrote: Added .txt to end of attached filename Okay, looks like xorg tried to set it up with what it wanted.. What does xrandr show? (this is from the serial/ssh:) 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 338mm x 270mm 1280x1024 60.0*+ 1152x864 75.0 1024x768 75.1 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 a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/vG7c6_ckX6M/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. -- Regards, Owen -- Regards, Owen -- 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] BBXM HDMI issue on ubuntu-14.04.1 with LXDE
On Fri, Dec 5, 2014 at 8:14 AM, Owen O'Hehir oo.he...@gmail.com wrote: Robert, Before connection to the TV: xrandr -display :0.0 -q Screen 0: minimum 320 x 200, current 720 x 480, maximum 2048 x 2048 DVI-D-1 connected 720x480+0+0 160mm x 90mm 800x60056.2 720x480 (0x43) 27.0MHz h: width 720 start 736 end 798 total 858 skew0 clock 31.5KHz v: height 480 start 489 end 495 total 525 clock 60.0Hz After connection to the TV: ubuntu@arm:~$ xrandr -display :0.0 -q Screen 0: minimum 320 x 200, current 720 x 480, maximum 2048 x 2048 DVI-D-1 connected 720x480+0+0 160mm x 90mm 1280x1024 60.0 720x57650.0 720x48060.0*59.9 Does the display light up when you do: xrandr -display :0.0 --output DVI-D-1 --mode 1280x1024 --rate 60 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] xeno_16550A driver install on Debian 3.8.13-bone67
On 12/5/2014 7:41 AM, Peter Gregory wrote: Have you looked into using a PRU for the real time data capture? I'd recommend considering this for the SPI interface. The PRU can probably bit-bang the SPI fast enough for your needs, and you won't have any issues generating small 1-2 uS pauses. Basically, just replace the SPI hardware with a PRU emulated version that supports the timing constraints you require. Everything else sounds like it's working OK. -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Wifi unreliable
Small update, I got the TL-WN722N to work. Since yesterday evening it is online, hope it will stay that way. The biggest problem was that wlan0 was already taken from the old dongle, so it now runs on wlan3. first I followed this instructions: (not sure if I had to :)) https://wiki.debian.org/ath9k_htc Then I had some problems that I would see wlan3 in iwconfig, but wicd-curses would not be able to access it (added wlan3 in prefs) I think adding wlan3 to /etc/network/interfaces did the trick for me. thanks for all the suggestions, I think I am now happy (until the next problem...) On Tue, Dec 2, 2014 at 8:38 PM, Robert Nelson robertcnel...@gmail.com wrote: On Tue, Dec 2, 2014 at 7:34 PM, david turvene dturv...@gmail.com wrote: Correct, that firmware currently isn't in a *.deb package yet, so we manually add that firmware for the bb.org images. @RCN - I'm using your *great* image-builder scripts and integrating my kernel and u-boot. The beagleboard.org_image.sh, etc. don't seem to have the ath9k firmware, or a way to get it. Is there a list of files you add when doing the bb.org images? as long as: include_firmware=enable... https://github.com/RobertCNelson/omap-image-builder/blob/master/scripts/chroot.sh#L782 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 a topic in the Google Groups BeagleBoard group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/gOXPkNF9uco/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: Wifi unreliable
On Fri, Dec 5, 2014 at 8:40 AM, Thomas Feix thomas0f...@gmail.com wrote: Small update, I got the TL-WN722N to work. Since yesterday evening it is online, hope it will stay that way. The biggest problem was that wlan0 was already taken from the old dongle, so it now runs on wlan3. first I followed this instructions: (not sure if I had to :)) https://wiki.debian.org/ath9k_htc Then I had some problems that I would see wlan3 in iwconfig, but wicd-curses would not be able to access it (added wlan3 in prefs) I think adding wlan3 to /etc/network/interfaces did the trick for me. thanks for all the suggestions, I think I am now happy (until the next problem...) You can cleanup the old (not plugged in) devices in: /etc/udev/rules.d/70-persistent-net.rules To get back down to wlan0.. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: RTL-SDR dropping samples, RT throttling problem?
Hi Adam, I'm going to plow on and get a dongle anyway. I'll plan to report back here in a couple of weeks. Thanks much for the link, which looks like a monster time-saver. Charles On Thursday, December 4, 2014 9:36:12 PM UTC-5, Adam Caldwell wrote: I haven't had time to further troubleshoot this problem, sorry. The stick I'm using is some random stick I picked up cheap on amazon from china. rtl_test identifies as: Realtek, RTL2838UHIDIR, SN: 0001 Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner lsusb identifies as: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T I did find a premade image for doing RTL-SDR stuff on the BBB here, which sounds promising: http://www.kd0cq.com/2014/08/packed-full-beaglebone-black-img-file-rtl-sdr-gnuradio-gqrx-lots-more-on-ubuntu-14-04/ On Thu, Dec 4, 2014 at 6:59 AM, charle...@gmail.com javascript: wrote: Hi Adam, I'm thinking of doing an RTL-SDR project with the BBB, as well. Sorry I can't lend any advice, yet, since it's just concept stage for me right now. I may have some insight in a week or two since a satcom project here in NYC may be moving from using the RPi to the BBB. Have you had any further success with your BBB setup? Would you mind telling me which stick you're using? Thanks much. Charles On Tuesday, November 18, 2014 5:55:02 PM UTC-5, adam.c...@gmail.com wrote: I'm attempting to use a RTL-SDR stick on my BBB, but too many samples are being dropped to be stable. When running the test program rtl_test, a typical output is like this: Sampling at 2048000 S/s. Reporting PPM error measurement every 10 seconds... Press ^C after a few minutes. Reading samples in async mode... lost at least 68 bytes real sample rate: 2048506 current PPM: 248 cumulative PPM: 248 real sample rate: 1613474 current PPM: -212171 cumulative PPM: -108885 lost at least 33108 bytes [snip] lost at least 33820 bytes lost at least 568 bytes real sample rate: 2231729 current PPM: 89712 cumulative PPM: -42138 real sample rate: 2047938 current PPM: -30 cumulative PPM: -31448 A perhaps telling dmesg output occurs when I start the test program: sched: RT throttling activated The same stick has no problem on my laptop and a Raspberry Pi. I'm running debian jessie and I tested kernel kernel versions 3.8.13-bone67, 3.14.23-ti-r34, and 3.18.0-rc5-bone1 which all had the problem. Any thoughts? -- 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] xeno_16550A driver install on Debian 3.8.13-bone67
Thanks, I've considered the PRU's and abandoned them as they are too specific for the Sitara. There is a project request to find a solution that is not locked to processor specific features. Nor was a suggested Arduino slave approved. But in time, I surely will test out these PRUs. Regards Terje -Original Message- From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On Behalf Of Charles Steinkuehler Sent: 5. desember 2014 15:33 To: beagleboard@googlegroups.com Subject: Re: [beagleboard] xeno_16550A driver install on Debian 3.8.13-bone67 On 12/5/2014 7:41 AM, Peter Gregory wrote: Have you looked into using a PRU for the real time data capture? I'd recommend considering this for the SPI interface. The PRU can probably bit-bang the SPI fast enough for your needs, and you won't have any issues generating small 1-2 uS pauses. Basically, just replace the SPI hardware with a PRU emulated version that supports the timing constraints you require. Everything else sounds like it's working OK. -- Charles Steinkuehler char...@steinkuehler.net -- 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/l2sKZCHEXbU/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: Wifi unreliable
Thanks, good to know! Though at this point I might go with the mantra: never change a running system :D On Friday, December 5, 2014 9:44:02 AM UTC-5, RobertCNelson wrote: On Fri, Dec 5, 2014 at 8:40 AM, Thomas Feix thoma...@gmail.com javascript: wrote: Small update, I got the TL-WN722N to work. Since yesterday evening it is online, hope it will stay that way. The biggest problem was that wlan0 was already taken from the old dongle, so it now runs on wlan3. first I followed this instructions: (not sure if I had to :)) https://wiki.debian.org/ath9k_htc Then I had some problems that I would see wlan3 in iwconfig, but wicd-curses would not be able to access it (added wlan3 in prefs) I think adding wlan3 to /etc/network/interfaces did the trick for me. thanks for all the suggestions, I think I am now happy (until the next problem...) You can cleanup the old (not plugged in) devices in: /etc/udev/rules.d/70-persistent-net.rules To get back down to wlan0.. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Wifi unreliable
On Fri, Dec 5, 2014 at 9:17 AM, Tommi thomas0f...@gmail.com wrote: Thanks, good to know! Though at this point I might go with the mantra: never change a running system :D Nah... Keep modifying till it breaks, then using your notes don't go as far. ;) Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Wifi unreliable
I have been using Win all my life until I started with the beaglebone - Not easy to change habits :P -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Please Help! install_kernel not working on newly setup sd card.
First - I'd like to say the work done by Robert C Nelson, and others in this group is fantastic. I created an SD card from Roberts site that looks something like this: Linux arm 3.14.22-ti-r31 #1 SMP PREEMPT Fri Oct 24 20:50:46 UTC 2014 armv7l GNU/Linux Is that PREEMPT_RT patched by default? Excellent. The problem I'm having, is that I want to build a new kernel (3.14.4-bone4) from Robert's git repo. https://github.com/RobertCNelson/linux-dev/tree/3.14.4-bone4 I followed the instructions to get it, build it, modify system.sh, and install it to the SD card I've got. It looks like it's all working... here's the output: - Trying: [/dev/sdb1] Partition: [/dev/sdb1] trying: [vfat], [ext4] Partition: [extX] Installing 3.14.4-bone4 to /dev/sdb1 `/home/mike/linux-dev-3.14.4-bone4/deploy/3.14.4-bone4.zImage' - `/home/mike/linux-dev-3.14.4-bone4/deploy/disk/boot/zImage' Installing 3.14.4-bone4-dtbs.tar.gz to /dev/sdb1 Installing 3.14.4-bone4-modules.tar.gz to /dev/sdb1 Installing 3.14.4-bone4-firmware.tar.gz to /dev/sdb1 `/home/mike/linux-dev-3.14.4-bone4/deploy/config-3.14.4-bone4' - `/home/mike/linux-dev-3.14.4-bone4/deploy/disk/boot/config-3.14.4-bone4' /home/mike/linux-dev-3.14.4-bone4 - This script has finished... For verification, always test this media with your end device... But, when I put the card in and boot holding down the button, it still boots with the original kernel on the card. Anybody got a guess at why? I mounted the SD Card on my #! machine and the file system isn't what I expected. I expected: /dev/sdb1 -- some small vfat with boot/uboot /dev/sdb2 -- everything else It looks like it's all on /dev/sdb1 as ext4. and inside /boot, I see the zImage file that was copied over by install_kernel.sh, but there's also a vmlinuz file. I'm guessing the install_me.sh for the 3.x.x-ti kernel types sets up a different boot structure, and that's why zImage is getting ignored. Can somebody please clarify? -- 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] Please Help! install_kernel not working on newly setup sd card.
On Fri, Dec 5, 2014 at 10:56 AM, Mike Zahalan mikezaha...@gmail.com wrote: First - I'd like to say the work done by Robert C Nelson, and others in this group is fantastic. I created an SD card from Roberts site that looks something like this: Linux arm 3.14.22-ti-r31 #1 SMP PREEMPT Fri Oct 24 20:50:46 UTC 2014 armv7l GNU/Linux Is that PREEMPT_RT patched by default? Excellent. The problem I'm having, is that I want to build a new kernel (3.14.4-bone4) from Robert's git repo. Wrong repo/branch... (the 3.14-bone is eol..) https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-3.14.y I don't advertise it because it's in a solid state of re-basing against ti's 3.14 tree.. It's best to just use: https://github.com/beagleboard/linux/tree/3.14 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] Purpose of the GND_OSC zero ohm resistors?
From: Seth transistorbo...@gmail.com Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com Date: Friday, December 5, 2014 at 5:07 AM To: beagleboard@googlegroups.com beagleboard@googlegroups.com Subject: Re: [beagleboard] Purpose of the GND_OSC zero ohm resistors? Thanks for the info, John. I thought it might have something to do with that. If I get a chance I'll have to pick up that book - thanks for the suggestion! I see in the earlier BBB designs the GND_OSC wasn't connected to the main DGND. Only later were they connected (via those zero ohm resistors), and that apparently helped the BBB function better. To me it seems that would introduce more switching noise (as John put it) than leaving them not connected to DGND. I guess I'm a little confused about John's use of the word isolated (If you don¹t isolate the OSC gnd...) - were you suggesting the zero ohm resistors acted as isolation from digital ground in this case? Gerald - do you mean that I could connect the GND_OSC net to the DGND net directly, or were you saying that I didn't need to connect those two at all (as in the earlier versions of the BBB)? What's the reason for having the resistors on the BBB if they're not needed? I was speculating that maybe you weren't initially sure if connecting the ground nets together would solve the ground bounce problem or maybe introduce worse problems, so you used those resistors to allow yourself the ability to leave them unpopulated in the event that it caused more issues than it solved (rather than re-spin new boards without the connection at all). GND represents the return path for each signal, so DGND represents the return path for digital circuits and GND_OSC represents the return path for the OSC circuit. Ideally, you create a reference point (normally GND pin of the power plug and then using a star topology, you connect to each of the GND circuits, such as AGND, DGND, etc. This way, no GND circuit will see the return current of the other circuits. Normally, the PCB layout software won¹t allow you to connect nets of different names, so you use zero ohm resistors to connect these nets on the PCB. If GND_OSC isn¹t connected to DGND, then it will be connected inside the chip and this isn¹t ideal. Measure the voltage signal between GND_OSC and DGND with and without the zero ohm resistor. You will see the noise between the two nets increase without the zero ohm resistor. BTW, the zero ohm resistor isn¹t idea either and we normally have special schematic symbols that allow us to connect two nets with different names. The PCB representation is just a copper trace which connects the two nets together, but most important is that you can move this copper trace so that it is close to the reference point (normally the GND pin of the power connector). Hope this helps. Regards, John -- 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] Where is the MLO and u-boot.img
Hi, I've just downloaded Robert Nelson's debian image of https://rcn-ee.net/deb/microsd/wheezy/bone-debian-7.7-console-armhf-2014-10-29-2gb.img.xz and flashed it to an SDcard. I discovered that there is no MLO or u-boot.img in the first partition. I thought that was ok since I understand that without pressing the boot button the system would look for the MLO and the u-boot.img on the first partition of the eMMC, but would boot with the kernel image on the SDcard. The u-boot version on the eMMC is U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54). As expected, the system booted up successfully with the new kernel. Out of curiosity, I booted again pressing the boot button, and expecting an error. But to my surprise, again the system booted successfully, using a u-boot from I don't know where with a new version number U-Boot 2014.10-00019-gbfd789c (Oct 15 2014 - 11:56:05). Can anyone explain to me what happened? Where does this u-boot come from? Thanks, Ricky Chang -- 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] TI PRU Cape demos: tiobj2bin fails
I am trying to build (in Windows 7) the PRU_LED0 demo for the TI PRU Cape (for Beaglebone black) using CCSv6 and AM335X_Starterware_02_00_01_01. The compilation works to give PRU_LED0.out but then when I use the tiob2bin.bat batch file to create the .bin file to load onto an SD card I get the following message: Unexpected target: unknown at script/mkhex4bin.pl line 261. error: -image requires ROMS directive I have seen some other posts with this error message but none seem to help my issue (e.g. use legacy coff not eabi; use armofd.exe and armhex.exe etc.). I have tried using both the PRU cape suggested post build step in CCSv6 and also running the commands directly on the .out file. Any help to proceed past this stumbling block gratefully received. B -- 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] Where is the MLO and u-boot.img
On Fri, Dec 5, 2014 at 9:10 AM, Ricky Chang rickyc8...@gmail.com wrote: Hi, I've just downloaded Robert Nelson's debian image of https://rcn-ee.net/deb/microsd/wheezy/bone-debian-7.7-console-armhf-2014-10-29-2gb.img.xz and flashed it to an SDcard. I discovered that there is no MLO or u-boot.img in the first partition. I thought that was ok since I understand that without pressing the boot button the system would look for the MLO and the u-boot.img on the first partition of the eMMC, but would boot with the kernel image on the SDcard. The u-boot version on the eMMC is U-Boot 2014.04-00014-g47880f5 (Apr 22 2014 - 13:23:54). As expected, the system booted up successfully with the new kernel. Out of curiosity, I booted again pressing the boot button, and expecting an error. But to my surprise, again the system booted successfully, using a u-boot from I don't know where with a new version number U-Boot 2014.10-00019-gbfd789c (Oct 15 2014 - 11:56:05). Can anyone explain to me what happened? Where does this u-boot come from? It's all magic voodoo. ;) We are utilizing a feature first introduced by TI in their omap4430 generation of the 'bootrom'. MLO/u-boot.img are dd'ed below the 1Mb position. It should help out users who accidently decide to delete MLO/u-boot.img from the first partition and wonder why it doesn't boot. 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] TI PRU Cape demos: tiobj2bin fails
Try running hexpru with the following command options
-b
-image
ROMS {
PAGE 0:
text: o = 0x0, l = 0x1000, files={text.bin}
PAGE 1:
data: o = 0x0, l = 0x1000, files={data.bin}
}
--
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] Please Help! install_kernel not working on newly setup sd card.
Thanks Robert! Those scripts in your EOLd repo are so promising/helpful. Due to some CAN bugs, I think I'm going to either have to patch 3.14.something, or go for a new kernel like 3.17.x I noticed you've got 3.17 stuff here: http://rcn-ee.net/deb/wheezy-armhf/v3.17.2-bone5/ But if I needed to get the source to patch/rebuild, how would you recommend I go about doing that? On Friday, December 5, 2014 9:10:25 AM UTC-8, RobertCNelson wrote: On Fri, Dec 5, 2014 at 10:56 AM, Mike Zahalan mikez...@gmail.com javascript: wrote: First - I'd like to say the work done by Robert C Nelson, and others in this group is fantastic. I created an SD card from Roberts site that looks something like this: Linux arm 3.14.22-ti-r31 #1 SMP PREEMPT Fri Oct 24 20:50:46 UTC 2014 armv7l GNU/Linux Is that PREEMPT_RT patched by default? Excellent. The problem I'm having, is that I want to build a new kernel (3.14.4-bone4) from Robert's git repo. Wrong repo/branch... (the 3.14-bone is eol..) https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-3.14.y I don't advertise it because it's in a solid state of re-basing against ti's 3.14 tree.. It's best to just use: https://github.com/beagleboard/linux/tree/3.14 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] Please Help! install_kernel not working on newly setup sd card.
On Fri, Dec 5, 2014 at 5:34 PM, Mike Zahalan mikezaha...@gmail.com wrote: Thanks Robert! Those scripts in your EOLd repo are so promising/helpful. Due to some CAN bugs, I think I'm going to either have to patch 3.14.something, or go for a new kernel like 3.17.x I noticed you've got 3.17 stuff here: http://rcn-ee.net/deb/wheezy-armhf/v3.17.2-bone5/ But if I needed to get the source to patch/rebuild, how would you recommend I go about doing that? So can on omap is getting a big push for v3.19-rc (as v3.18.0 should be tagged this sunday) it'll still be a couple weeks before v3.19-rc0 will be bootable.. either use: v3.14.x https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-3.14.y or, v3.18-rc: https://github.com/RobertCNelson/bb-kernel/tree/am33x-v3.18 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] Please Help! install_kernel not working on newly setup sd card.
Excellent - thank you, Robert. You mentioned OMAP... I'm still trying to figure out how to tell what commits end up in a given release. For example: https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/drivers/net/can/c_can/c_can_platform.c Latest Commit: https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/commit/drivers/net/can/c_can/c_can_platform.c?id=a7380db5f0d6dd94981e73da08d8fa863ee72235 Is that part of what's getting pushed for v3.19-rc? How do I look that up? On Friday, December 5, 2014 3:49:15 PM UTC-8, RobertCNelson wrote: On Fri, Dec 5, 2014 at 5:34 PM, Mike Zahalan mikez...@gmail.com javascript: wrote: Thanks Robert! Those scripts in your EOLd repo are so promising/helpful. Due to some CAN bugs, I think I'm going to either have to patch 3.14.something, or go for a new kernel like 3.17.x I noticed you've got 3.17 stuff here: http://rcn-ee.net/deb/wheezy-armhf/v3.17.2-bone5/ But if I needed to get the source to patch/rebuild, how would you recommend I go about doing that? So can on omap is getting a big push for v3.19-rc (as v3.18.0 should be tagged this sunday) it'll still be a couple weeks before v3.19-rc0 will be bootable.. either use: v3.14.x https://github.com/RobertCNelson/ti-linux-kernel-dev/tree/ti-linux-3.14.y or, v3.18-rc: https://github.com/RobertCNelson/bb-kernel/tree/am33x-v3.18 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] Please Help! install_kernel not working on newly setup sd card.
On Fri, Dec 5, 2014 at 6:15 PM, Mike Zahalan mikezaha...@gmail.com wrote: Excellent - thank you, Robert. You mentioned OMAP... I'm still trying to figure out how to tell what commits end up in a given release. For example: https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/log/drivers/net/can/c_can/c_can_platform.c Latest Commit: https://git.kernel.org/cgit/linux/kernel/git/tmlind/linux-omap.git/commit/drivers/net/can/c_can/c_can_platform.c?id=a7380db5f0d6dd94981e73da08d8fa863ee72235 Is that part of what's getting pushed for v3.19-rc? How do I look that up? https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/?id=refs%2Ftags%2Fnext-20141205qt=grepq=dcan 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.
