[beagleboard] Re: Image 2015-07-19
On Monday, July 27, 2015 at 10:27:52 AM UTC-6, dl4mea wrote: I meanwhile tried if a 1k resistor from Vbat-Sense to ground helps: No, does not. Summarizing my feeling: Feeding +5V to the back side USB helps a little, 1k resistor over Vbat-Sense does not help. You might want to try connecting TP5 (BAT) to TP6 (BAT_SENSE). You can use a resistor if you want, but BAT_SENSE is a high impedance input. These terminals would normally be connected to each other at the battery. On the BBB they are not connected to anything. The PMIC sends test currents out the BAT pin and measures the resulting voltages on the BAT_SENSE pin. These functions can't work if they are not connected. The measured voltage on BAT_SENSE may drift depending upon the leakage currents at the floating input. Dennis Cote -- 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] My BBB does not work anymore
On Saturday, July 18, 2015 at 6:27:12 PM UTC-6, Gerald wrote: As written in the manual the 5V switch for the USB host port power will not. The board will be damaged. Gerald, The OP said he applied the 8V to the USB mini connector. I take that to mean P4, rather than the USB host port on P3. P4 does not have a USB power switch. It only connects to the ESD clamp U10, the PMIC USB input, and the SOC USB0_VBUS pins. The ESD clamp can safely handle the 8V input. The PMIC may be able to handle the 8V input, though it is greater than the recommended operating range max of 5.8V, since it is less that the absolute max of 20 V. However, the AM335x has a absolute max rating of only 5.25 V, so it is quite probably damaged. Dennis Cote -- 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 intermittently rebooting.
On Wednesday, July 22, 2015 at 1:55:55 AM UTC-6, dl4mea wrote: What about adding a 1k resistor from the VBat+ input to ground, just for safety? That should not be necessary. The battery detection logic is complicated, but seems quite robust. Again from the datasheet: 9.3.13 Battery Detection and Recharge Whenever the battery voltage falls below VRCH, IBAT(DET) is pulled from the battery for a duration tDET to determine if the battery has been removed. If the voltage on the BAT pin remains above VLOWV, it indicates that the battery is still connected. If the charger is enabled (CH_EN = 1), a new battery charging cycle begins. If the BAT pin voltage falls below VLOWV in the battery detection test, it indicates that the battery has been removed. The device then checks for battery insertion: it turns on the charging path and sources IPRECHG out of the BAT pin for duration tDET. If the voltage does not rise above VRCH, it indicates that a battery has been inserted, and a new charge cycle can begin. If, however, the voltage does rise above VRCH, it is possible that a fully charged battery has been inserted. To check for this, IBAT(DET) is pulled from the battery for tDET and if the voltage falls below VLOWV, no battery is present. The battery detection cycle continues until the device detects a battery or the charger is disabled. When the battery is removed from the system the charger will also flag a BATTEMP error indicating that the TS input is not connected to a thermistor. The one problem I see with the BBB design is that the test currents are applied to the BAT terminals and the battery voltage is measured on the BAT_SENSE terminal. Normally these would be connected at the battery, but they are not connected at all on the BBB. Perhaps connecting TP5 and TP6 with a jumper wire will help. Dennis Cote -- 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 intermittently rebooting.
On Tuesday, July 21, 2015 at 8:06:49 AM UTC-6, lisarden wrote: By the way I with my collegues spent some time on investigating this issue and found in the tps65217 datasheet that all three power source Vac, Vusb and Vbat should not be enabled at the same time. Only two of them should. Because of the reason that BBB is a universal enthusiast's board all three power sources are left floating, which contradicts with tps65217 architecture. We figured out that if the most of users use only a barrel connector or USB then Vbat input should be grounded. I don't know if this solution fixes the random reboot issue but at least it complies with the TPS65217 architecture. Probably anybody should try to ground the Vbat input and see how the board behaves. I was reviewing the TPS65217 datasheet and I think this may be the area of concern (from section 9.3.9.1): The linear charger periodically applies a 10-mA current source to the BAT pin to check for the presence of a battery. This will cause the BAT terminal to float up to 3 V which may interfere with AC removal detection and the ability to switch from AC to USB input. For this reason, it is not recommended to use both AC and USB inputs when the battery is absent. Since the battery is absent for most BBB users, TI recommends using AC or USB power, but not both. Furthermore, the TPS65217 has internal sinks on the AC and USB inputs, so it should not be necessary to short either input to ground when it is not used as long as the input sinks have not been forced off by the software. 9.3.9.4 AC and USB Input Discharge AC and USB inputs have 90-µA internal current sinks which are used to discharge the input pins to avoid false detection of an input source. The AC sink is enabled when USB is a valid supply and VAC is below the detection threshold. Likewise, the USB sink is enabled when AC is a valid supply and VUSB is below the detection limit. Both current sinks can be forced OFF by setting the [ACSINK, USBSINK] bits to 11b. Both bits are located in register 0x01 (PPATH). NOTE [ACSINK, USBSINK] = 01b and 10b combinations are not recommended as these may lead to unexpected enabling and disabling of the current sinks. 9 Perhaps someone can check if these are being set to something other than 00b. Dennis Cote -- 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: BBB power led blinking, revived after several power button presses
On Monday, January 26, 2015 at 12:56:31 PM UTC-7, mjc wrote: The BeagleBone Black BlueSteel Basic seem to be extremely sensitive to the rise time of the 5V power supply at startup. 1 ms or longer is a problem, and it is not at all unusual for power supply to be slower than this. 200 us is reliable. From the datasheet for the TPS65217 PMIC used on the BBB, section 9.3.9.1, TI seems to agree. Note that the rise time of VAC and VUSB must be less than 50 ms for the detection circuits to operate properly. If the rise time is longer than 50 ms, the IC may fail to power up. HTH Dennis Cote -- 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 fails to complete Jessie flasher
I tried to flash my BBB rev A5C with the 2014-10-22 Debian Jessie lxqt flasher from http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-10-22. The flashing never completed, at least the user LEDs never changed from the cylon flashing pattern. I left the board run overnight. I have attached a log from the serial debug port. Just in case the flasher had worked even though it never completed, I tried booting from the eMMC. This started but dropped out to a shell. I have also attached a log from the serial console for that boot. My BBB correctly boots and runs the 2014-10-22 standalone lxde image from the same site using a different SD card. I verified the md5sum of the image file I downloaded. Any idea why the flasher fails? Has anyone else used this flasher successfully? 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. U-Boot SPL 2014.10-00019-gbfd789c (Oct 15 2014 - 11:56:05) U-Boot 2014.10-00019-gbfd789c (Oct 15 2014 - 11:56:05), Build: jenkins-github_Bootloader-Builder-43 Watchdog enabled I2C: ready DRAM: 512 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 gpio: pin 53 (gpio 53) value is 1 switch to partitions #0, OK mmc0 is current device gpio: pin 54 (gpio 54) value is 1 Checking for: /uEnv.txt ... reading uEnv.txt 760 bytes read in 6 ms (123 KiB/s) gpio: pin 55 (gpio 55) value is 1 Loaded environment from uEnv.txt Importing environment from mmc ... Checking if uenvcmd is set ... gpio: pin 56 (gpio 56) value is 1 Running uenvcmd ... 696 bytes read in 73 ms (8.8 KiB/s) 6923136 bytes read in 451 ms (14.6 MiB/s) 2355598 bytes read in 189 ms (11.9 MiB/s) 84819 bytes read in 200 ms (414.1 KiB/s) Kernel image @ 0x8200 [ 0x00 - 0x69a380 ] ## Flattened Device Tree blob at 8800 Booting using the fdt blob at 0x8800 Loading Ramdisk to 8fdc, end 818e ... OK Loading Device Tree to 8fda8000, end 8fdbfb52 ... OK Starting kernel ... [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.14.19-ti-r30 (root@a6-imx6q-wandboard-2gb) (gcc version 4.9.1 (Debian 4.9.1-16) ) #1 SMP PREEMPT Mon Oct 13 17:36:06 UTC 2014 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: TI AM335x BeagleBone Black [0.00] cma: CMA: reserved 24 MiB at 9e00 [0.00] Memory policy: Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] AM335X ES2.0 (sgx neon ) [0.00] PERCPU: Embedded 10 pages/cpu @df9b1000 s16768 r8192 d16000 u40960 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129536 [0.00] Kernel command line: console=tty0 console=ttyO0,115200n8 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait fixrtc init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] Memory: 471772K/522240K available (8374K kernel code, 751K rwdata, 3260K rodata, 468K init, 5820K bss, 50468K reserved, 0K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc0b64a3c (11635 kB) [0.00] .init : 0xc0b65000 - 0xc0bda180 ( 469 kB) [0.00] .data : 0xc0bdc000 - 0xc0c97f04 ( 752 kB) [0.00].bss : 0xc0c97f04 - 0xc1247110 (5821 kB) [0.00] Preemptible hierarchical RCU implementation. [0.00] RCU restricting CPUs from NR_CPUS=2 to nr_cpu_ids=1. [0.00] RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1 [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] IRQ: Found an INTC at 0xfa20 (revision 5.0) with 128 interrupts [0.00] Total of 128 interrupts on 1 active controller [0.00] OMAP clockevent source: timer2 at 2400 Hz [0.17] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956969942ns [
Re: [beagleboard] BBB fails to complete Jessie flasher
On Friday, October 24, 2014 8:54:17 AM UTC-6, RobertCNelson wrote: Give it another run, it should only take about 10 minutes.. I should find a switch for a progress bar in rsync.. Hi Robert, I tried it again and it hung right after: Begin: Running /scripts/init-bottom ... done. I rewrote the image file to the SD card and tried again. This time it took about 10 minutes to copy the first partition as indicated by the time stamp. Copying: /dev/mmcblk0p1 - /dev/mmcblk1p1 rsync: /boot/uboot/ - /tmp/boot/ Copying: /dev/mmcblk0p2 - /dev/mmcblk1p2 [ 584.455920] EXT4-fs (mmcblk1p2): mounted filesystem with ordered data mode. Opts: (null) rsync: / - /tmp/rootfs/ It has been copying the second partition for about 1/2 hour. I guess I will try a different SD card. I think the progress bar is a good idea. The version of rsync in Jessie should support the --info=progress2 option. Some hints can be found at http://www.cyberciti.biz/faq/show-progress-during-file-transfer/ Dennis Cote -- 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 fails to complete Jessie flasher
On Friday, October 24, 2014 10:49:32 AM UTC-6, RobertCNelson wrote: That's exactly what i was testing this morning: I'm glad to hear that. I reran the flasher using a different SD card and it finally completed. It finished with all user LEDs turned on. (It seems that the end state of the LEDs has changed from all on, to all off, and back to all on). It took about 10 minutes for the first partition and about 6 minutes for the second. I booted into ldqt, but it seems very minimal. There are no applications installed, not even a terminal program. I guess its back to the command line. Dennis Cote -- 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 fails to complete Jessie flasher
On Friday, October 24, 2014 11:19:03 AM UTC-6, RobertCNelson wrote: But the big change, it's using qt 5.3.2 on the backend, so it's really easy for end users to develop applications vs the old gtk2 backend we used on wheezy.. Yes... that is why I wanted to try it out. We plan on using qt based applications for our project. Are there any QT demo programs installed by default? BTW, when I first booted into Jessie the lxqt application menu was empty. I got nothing when I left clicked my mouse. I got a configuration menu when I right clicked. I played with the configuration, changed the menu file to lxqt-config.menu, and later changed it back to the lxde-application menu. Somewhere along the line the the Application menu started working. Its all good now, but I had no application menu when I said it was minimal. Dennis Cote -- 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 fails to complete Jessie flasher
On Friday, October 24, 2014 1:05:03 PM UTC-6, RobertCNelson wrote: Actually the whole desktop lxqt so all the lxqt-xyz apps are native qt 5.3.2 applications. qterminal and cmst are also qt5 applications. I knew that, but I was wondering if there was something that might show off the 3D capabilities of the SGX module. That is odd, i know the icons are messed up initially, so there's a few tweaks we need to do for the first startup.. Also, I noticed that the lxqt-panel program is burning up nearly 20% of the CPU all the time, even when sitting idle, or the display blanked by DPMS. They must be polling for some status change or something. I have also noticed that the file icons in the file manager are sometimes missing on startup, but can be restored by changing the file manager preferences to select a different icon theme, and then changing it back. I see that there is no web browser installed. Do you know which one they might use? Finally, the dpkg-reconfigure program is not installed so it can't be used to set the timezone (as indicated at http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Timezone). I just set the /etc/timezone file and copied the zoneinfo file from /usr/share/zoneinfo/area/city to /etc/localtime. Dennis Cote -- 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 fails to complete Jessie flasher
On Friday, October 24, 2014 2:51:55 PM UTC-6, RobertCNelson wrote: Ah, well that's the plan.. Just not ready.. https://github.com/rcn-ee/repos/tree/master/qtbase That's good to hear. I'll look for it later. I'm trying to get chromium 38 built, but fighting the out of memory linker stage. (really need to find a 4GB cortex-a15 board.) I'm also looking at http://www.qupzilla.com/ which uses qt's webkit... Also good to hear. It's there, just got a be root: debian@beaglebone:~$ dpkg-reconfigure tzdata /usr/sbin/dpkg-reconfigure must be run as root Right you are. I got a command not found error when I tried, and which returned nothing so I did it by hand. I must have typed it wrong each time (I seem to suffer from dyslexic typing some times). Thanks for the help. Dennis Cote -- 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 fails to complete Jessie flasher
On Friday, October 24, 2014 3:12:19 PM UTC-6, Dennis Cote wrote: It's there, just got a be root: debian@beaglebone:~$ dpkg-reconfigure tzdata /usr/sbin/dpkg-reconfigure must be run as root Right you are. I got a command not found error when I tried, and which returned nothing so I did it by hand. I must have typed it wrong each time (I seem to suffer from dyslexic typing some times). Actually, a little more testing shows the problem is related to the terminal used. When I use the QTerminal application, I get the following: debian@beaglebone:~$ dpkg-reconfigure tzdata bash: dpkg-reconfigure: command not found debian@beaglebone:~$ which dpkg-reconfigure debian@beaglebone:~$ sudo which dpkg-reconfigure /usr/sbin/dpkg-reconfigure When I use the a text or serial console I get the following: debian@beaglebone:~$ dpkg-reconfigure tzdata /usr/sbin/dpkg-reconfigure must be run as root debian@beaglebone:~$ which dpkg-reconfigure /usr/sbin/dpkg-reconfigure I had originally tried using a QTerminal, and it looked like it wasn't installed. Using sudo I can see that it is. Why do the different consoles produce different results? I suspect it is a login shell vs a non-login shell thing again. Dennis Cote -- 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] Kernel panic with 2014-08-05 standalone debian image
On Wednesday, August 20, 2014 9:40:25 AM UTC-6, RobertCNelson wrote: It's those mmc cards and the mmc host driver in v3.8.x, we've patched/cherrypicked/backported what we can, but a newer kernel will work better in most cases.. Since it looks like you aren't using any capes, you have two options: sudo apt-get update #new bone ti branch: sudo apt-get install linux-image-3.14.17-ti-r10 The update to the ti kernel worked. It has been running for 5 days now without hanging. Thanks. Dennis Cote -- 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] Kernel panic with 2014-08-05 standalone debian image
Since upgrading to the 14-08-05 image my BBB has been locking up after operating for a while (minutes to hours). I finally setup a terminal on the serial console and captured everything until it hung. I am getting a kernel panic. I have attached the captured console log from boot to hang. I have tried two different SD cards (one 4GB, one 8GB) with the same result. Does anyone have any ideas about what may be causing this? Dennis Cote -- 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. U-Boot SPL 2014.07-00016-g329fca9 (Jul 28 2014 - 12:35:02) reading u-boot.img reading u-boot.img U-Boot 2014.07-00016-g329fca9 (Jul 28 2014 - 12:35:02), Build: jenkins-github_Bo otloader-Builder-375 I2C: ready DRAM: 512 MiB NAND: 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 0 gpio: pin 53 (gpio 53) value is 1 switch to partitions #0, OK mmc0 is current device gpio: pin 54 (gpio 54) value is 1 SD/MMC found on device 0 Checking for: /uEnv.txt ... Checking for: /boot.scr ... Checking for: /boot/boot.scr ... Checking for: /boot/uEnv.txt ... gpio: pin 55 (gpio 55) value is 1 778 bytes read in 39 ms (18.6 KiB/s) Loaded environment from /boot/uEnv.txt Checking if uname_r is set in /boot/uEnv.txt... gpio: pin 56 (gpio 56) value is 1 Running uname_boot ... loading /boot/vmlinuz-3.8.13-bone62 ... 5600984 bytes read in 342 ms (15.6 MiB/s) loading /boot/dtbs/3.8.13-bone62/am335x-boneblack.dtb ... 25926 bytes read in 68 ms (372.1 KiB/s) loading /boot/initrd.img-3.8.13-bone62 ... 2861098 bytes read in 191 ms (14.3 MiB/s) Kernel image @ 0x8200 [ 0x00 - 0x5576d8 ] ## Flattened Device Tree blob at 8800 Booting using the fdt blob at 0x8800 Loading Ramdisk to 8fd45000, end 882a ... OK Loading Device Tree to 8fd3b000, end 8fd44545 ... OK Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.372095] omap2_mbox_probe: platform not supported [0.526941] tps65217-bl tps65217-bl: no platform data provided [0.590995] bone-capemgr bone_capemgr.9: slot #0: No cape found [0.628101] bone-capemgr bone_capemgr.9: slot #1: No cape found [0.665210] bone-capemgr bone_capemgr.9: slot #2: No cape found [0.702320] bone-capemgr bone_capemgr.9: slot #3: No cape found [0.717908] bone-capemgr bone_capemgr.9: slot #6: BB-BONELT-HDMIN conflict P8 .45 (#5:BB-BONELT-HDMI) [0.727523] bone-capemgr bone_capemgr.9: slot #6: Failed verification [0.734261] bone-capemgr bone_capemgr.9: loader: failed to load slot-6 BB-BON ELT-HDMIN:00A0 (prio 2) [0.750669] omap_hsmmc mmc.5: of_parse_phandle_with_args of 'reset' failed [0.813932] pinctrl-single 44e10800.pinmux: pin 44e10854 already requested by44e10800.pinmux; cannot claim for gpio-leds.8 [0.825598] pinctrl-single 44e10800.pinmux: pin-21 (gpio-leds.8) status -22 [0.832873] pinctrl-single 44e10800.pinmux: could not request pin 21 on devic e pinctrl-single Loading, please wait... systemd-fsck[225]: rootfs: clean, 78491/230608 files, 405432/922368 blocks Debian GNU/Linux 7 beaglebone ttyO0 default username:password is [debian:temppwd] Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian The IP Address for usb0 is: 192.168.7.2 beaglebone login: [ 27.698539] tilcdc 4830e000.fb: timeout waiting for framedo ne [ 31.128209] tilcdc 4830e000.fb: timeout waiting for framedone [ 47.101340] libphy: PHY 4a101000.mdio:01 not found [ 47.106451] net eth0: phy 4a101000.mdio:01 not found on slave 1 [ 52.675918] libphy: PHY 4a101000.mdio:01 not found [ 52.681045] net eth0: phy 4a101000.mdio:01 not found on slave 1 [ 57.662972] libphy: PHY 4a101000.mdio:01 not found [ 57.668241] net eth0: phy 4a101000.mdio:01 not found on slave 1 [ 642.958292] tilcdc 4830e000.fb: timeout waiting for framedone [ 943.025085] tilcdc 4830e000.fb: timeout waiting for framedone [39462.519701] libphy: PHY 4a101000.mdio:01 not found [39462.524922] net eth0: phy 4a101000.mdio:01 not found on slave 1 [39462.932134] libphy: PHY 4a101000.mdio:01 not found [39462.937230] net eth0: phy 4a101000.mdio:01 not found on slave 1 [39464.813914] libphy: PHY 4a101000.mdio:01 not found [39464.819010] net eth0: phy 4a101000.mdio:01 not found on slave 1 [59220.520811] INFO: task mmcqd/0:72 blocked for more than 60 seconds. [59220.527557] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [59220.535924] Kernel panic - not syncing: hung_task: blocked tasks [59220.542307] [c00111f1] (unwind_backtrace+0x1/0x9c) from [c04c8b75] (panic
[beagleboard] Re: Efficient synchronous serial read with gpio
On Tuesday, May 13, 2014 4:46:29 AM UTC-6, haeusler...@gmail.com wrote: I have recently purchased a Freetronics IR Temperature sensor and have been using it on the Beaglebone Black. I have been using the supplied c++ arudino code which I modified to access GPIO pins on the BBB. However it uses 60-80% of the cpu when running. The synchronous serial algorithm is inefficient as it uses while loops to wait for the clock to cycle. Is there a better, more efficient, way to read synchronous serial over gpio pins? Hi, Looking at the driver code, this device has an interface that is almost SPI, except that the clock is driven by the device and the chip select (what they call aquire) is driven by the BBB. Because it is not standard SPI you can't use the SPI interface on the BBB. The best you could do would be to change the mode of the clock input pin so that it generates an interrupt on each rising edge. Your interrupt handler would read the data line and collect 1 bit at each interrupt. The interrupt handler would build the 5 data bytes, and save them into the data array and then signal the main application when all 5 bytes have been read. The main application would take the acquire signal low to start the measurement, then wait (suspended by the kernel) until the I/O complete signal was received from the interrupt handler. It would then release the acquire signal and process the data in the buffer as it does now. This would replace all the busy waiting with 40 short interrupt handler executions, and a short burst of activity at the beginning and end of each measurement. The CPU load would probably be too low to measure. HTH Dennis Cote -- 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] Connecting UART0 RTS and CTS to J1 for new BBB
On Wednesday, April 30, 2014 4:29:58 PM UTC-6, Charles Steinkuehler wrote: Well, I'm not Gerald, but I'll be surprised if anything is changing on the PCB. The change to a 4G eMMC requires no changes to the PCB and are being made to improve margin, so don't expect to see any new parts. The eMMC may not require a new PCB layout, but the PCB has been revised for other minor changes in the past. I simply thought it might make sense to do both at the same time. On the other hand, why don't you just use P9.21 and P9.22 for the uart0 rts/cts lines? I suspect Gerald didn't tie them on the main board because they are available on the expansion headers. I also require SPI0 so those pins are already allocated. BTW, I noticed that in the expansion header pinout tables in the SRM, some signals are prefixed with PR1_. what is the significance of this prefix? Is it related to the PRU processors? Dennis Cote -- 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] Connecting UART0 RTS and CTS to J1 for new BBB
On Thursday, May 1, 2014 12:08:02 PM UTC-6, Gerald wrote: I see. One of those commercial guys. I thought so. You say that like it is a negative thing. I can almost hear the sigh afterwards. I don't understand your resentment of commercial users. You have done a masterful job designing a board with lots of CPU power, and flexible I/O. You then decided to build the board in large volume to push the selling price as low as possible. The design is open and well documented so it is easy to work with. It is also well supported by both the community and TI. The same features that make it appealing to your hobbyist audience also make it appealing to potential commercial users. I understand that some commercial users have put a strain on your production capacity, but you are selling through distributors like Avnet, Arrow, Digi-Key and Mouser that primarily deal with commercial customers. These customers expect to be able to buy products from them in volume. If you had only sold through the likes of Adafruit, Sprkfun, and Jameco I suspect you would not have had this problem, but the BBB also wouldn't be the successful product it has become. I suspect that you may resent commercial users for making profits off your design without paying you directly for it. This is the same issue faced by anyone doing open hardware or software development. IBM has made a lot of money selling Linux systems without paying the Linux developers for their software. On the other hand IBM has contributed a great deal of expert time and effort to Linux development. I think a similar thing is happening with the BBB. TI provides a lot of support to the Beaglebone community to encourage the adoption of their Sitara processors in commercial products. Given the good design, relatively low price, and direct support by TI, some of those commercial users will chose to use the BBB. They do so because they can't build their own custom board for anywhere near the cost of the BBB, principally because of the volume production. But that production volume is, in large part, supported by those very same commercial users. Perhaps the BBB is, or was, under priced as some have said. I think it will still be a good value at $55. I don't think things would have been much different if the original price had been higher, unless it was so much higher that it was no longer attractive to the hobbyist users either. Hobbyist weren't running out to buy the TI EVM boards before the BBB became available, because they simply cost too much. I also think that you will get a lot of community support from commercial users in the long run. I try to answer questions on the forums when I can. I am still learning myself, so I try to refrain from answering unless I know the answer. Commercial use means there will be users who have HAD to get things to work, and they will be able to guide others through their struggles with the same issues. I know this is getting somewhat off topic, but I thought it was worth saying. Commercial users aren't inherently bad guys. Dennis Cote -- 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] Connecting UART0 RTS and CTS to J1 for new BBB
On Thursday, May 1, 2014 2:14:21 PM UTC-6, Gerald wrote: There is no resentment. We just don't support commercial users of the boards with the BeagleBoard LOGO on it as we have stated. I don't know if the boards I would buy from CircuitCo will have the BeagleBoard logo or not. I assume not, but it hasn't been discussed yet. Will you support commercial use of the same board without the logo? :-) Everything is there for you to build it yourself. Go for it. No strings attached. Not quite everything is there. The key missing piece is the production volume which is the one of the principal determining factors in the cost. You, and others, are being disingenuous when you say go build your own. You know that will not be economically viable for most users, commercial or otherwise. The BBB is what it is because of the production volume. Without that it is nothing more than another nice design. Dennis Cote -- 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] Connecting UART0 RTS and CTS to J1 for new BBB
On Thursday, May 1, 2014 2:53:36 PM UTC-6, Gerald wrote: If you get boards from anyone without the logo, they are in fact at that point your board. So you can do whatever you like. Make whatever changes you want. And, you can build the board as long as you want. I am aware of the many benefits of making our own board, as well as the associated costs. I was actually asking a facetious question about support for a board without the logo, but that got me thinking about what you mean by support. The BBB SRM says: These design materials referred to in this document are *NOT SUPPORTED* and DO NOT constitute a reference design. Only “community” support is allowed via resources at BeagleBoard.org/discuss. So it seems like the boards with a logo are not supported either. In fact the first five pages of the SRM are full of disclaimers of various sorts. I understand that this is required in this day and age of lawyers with itchy trigger fingers. So what is it really that you are providing to the community users that you don't provide to commercial users? Once we change a board, we no longer make the old revision. If I start making changes for commercial users, then I am faced with the task of making sure none of the other commercial users are upset with these changes,I end up being a free product engineering department for all these commercial users. I choose not to go down that path. I can't win no matter what I do. This is where I think you show that you believe that commercial users have different expectations that your community users. If you simply remove the word commercial from your statement above, you have an equally true statement. You shouldn't be making changes simply because users, commercial or not, request them. Rather, you should be making changes only when you believe they will improve the product. Commercial users should not expect any preferential treatment for their suggestions, but at the same time their suggestions should not be discarded for no other reason that the source is a commercial user. The good ideas should and will stand on their own merit. Also, all commercial users are well aware of the potential problems that could result from a BBB design change that adversely effects their use of the board. That is where the open design becomes a life saver. If you do make a breaking change we can always make our own boards using the prevoius design, though it will undoubtedly cost more. In addition, the change you want means I have to add a bigger buffer. More cost. PCB layout charges. New stencils.Change the PP program. Scrap the current buffer and order new buffers and try to get them in here fast enough not to shutdown my production line. Multiply this by say 500 commercial users. I don't want you to make a change, I have merely suggested what I believe is an improvement that could be made. Furthermore, I would not suggest scrapping any parts. You said you 80,000 PCB to use up with the current design. You can use up your stock building those boards, and then depending upon how you implement the change (you could use a different 4 channel buffer, or place two of the same 2 channel buffer parts) you may not have to waste any parts even if you currently have more than 80K in stock. At your current production rate of about 12K per month you should have about 6 months to revise the board and order the new stencils and new parts (if required). As I said before there would be some NRE costs, but those are spread thin over the 100K quantities you are ordering boards in. I don't understand your multiply by 500 concept. Just because you have 500 commercial users doesn't mean that all of them have suggestions for design improvements. Furthermore, even if many do have suggestions, that doesn't mean that all of those are widely applicable improvements, Ultimately, that is up to you to decide. Finally, if you do decide to implement an improvement, that does not preclude you from making multiple change in one revision. You can spread the NRE costs over multiple change done in parallel. You have already made seven revisions from A4 to C, and you will probably make some more along the way. You can surely pool the good ideas into the next release and continue on. In any case I think I have beaten this horse to death. I probably won't be able to wait 6 months for a new release with this feature, so I will have to find a different way to do what I need, but I still think it is an improvement worth considering. Dennis Cote -- 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] Connecting UART0 RTS and CTS to J1 for new BBB
Hi, This question is meant for Gerald Coley since he is the only one who can answer it. Gerald, is there any reason (aside from cost) that you didn't connect the UART0 RTS and CTS lines (balls E17 and E18) to the J1 header for the serial console? In my project I need all the LCD lines which eliminates using the RTS/CTS lines on UART2 through UART5. I also need I2C1 and I2C2, so I can't use UART1 at all. That leaves only UART0 with handshaking lines. Unfortunately, those lines have been left as no connects on the current BBB. I see that you are planning to release a new revision of the BBB, so I was wondering if you might consider connecting these lines to the J1 header. I realize you will also need to add another SN74LVC2G241 buffer for power down isolation and its associated bypass capacitor, and another pulldown resistor for the CTS input signal, but they are all small parts and fairly low cost. I believe E17, UART0 RTS, should be buffered and drive J1 pin 2, the FTDI CTS input. Similarly E18, UART0 CTS, should be connected to the buffered output from J1 pin 6, the FTDI RTS output. Is this something you might consider doing on the next revision of the BBB, or perhaps a later rev if it is too late for the next revision? Perhaps a little bit of the increased price can go towards this increased functionality (in addition to the larger eMMC), instead of going to increase the margins for the manufacturers (which I agree is very important if the BBB is to be successful in the long term). Thanks for your consideration. Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Thursday, March 20, 2014 11:57:11 AM UTC-6, RobertCNelson wrote: On Thu, Mar 20, 2014 at 12:47 PM, Dennis Cote den...@harding.cajavascript: wrote: On Thursday, March 20, 2014 11:29:10 AM UTC-6, RobertCNelson wrote: However it works better if you add it via xset/xsetroot: root@beaglebone:~# cat /home/debian/.xsessionrc #!/bin/sh xset -dpms xset s off xsetroot -cursor_name left_ptr and just remove the [Option SWCursor true] line from /etc/X11/xorg.conf Robert, My .xsessionrc file looks identical to yours, and I did not have SWCursor anywhere in my xorg.conf file, so there was nothing to remove. My mouse pointer definitely becomes invisible when I logout. okay, so when i switch back to v3.8, i see this now too.. Weird, as v3.13.x it works. Might just have to go back to the xorg.conf workaround. Hi Robert, I hope this isn't a repeat. I thought I posted a similar message earlier today, but it has not showed up in the group (at least for me), so I am retrying. Today I downloaded and installed a fresh copy of the latest, 2014-04-14, Debian image. Previously I had been using your update scripts to update my installation to the latest version, but I noticed there wasn't an update script for this version when I did a git pull in the /opt/scripts directory. While using the new version I noticed that I had the same problems with my mouse pointer becoming invisible whenever I log out of LXDE, and the DPMS screen blanking being disabled, that I had reported earlier. To correct this I removed the ~/.xsessionrc file to get the default, On, state for the dpms screen blanking. I also had to add the following line to the end of the Device section of the /etc/X11/xorg.conf file. Without this line I had no mouse pointer at all. Option SWCursor true I now have a mouse pointer that remains visible across LXDE logout/login cycles, and my screen now turns off after 10 minutes of inactivity. I really think this a better default setup since the BBB behave like a standard desktop PC (I have a USB keyboard and mouse, and an HDMI monitor). New users will get correct and standard operation. More experienced users can change these behaviors if they need to (to disable screen blanking on a kiosk for example), especially if there are clear instructions on how to do so. While testing the changes to the ~/.xsessionrc file I notice that I am getting a ~/.xsession-errors file created on each reboot. This file contains the following message: Openbox-Message: Unable to find a valid menu file /usr/share/lxde/openbox/menu.xml Dennis Cote -- 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] AIN max voltage exceeded
On Thursday, April 10, 2014 7:41:56 AM UTC-6, Gerald wrote: In fact, i am considering not doing one on the next board. It is a lot of work. Oh, please don't do that. I read the SRM and review the schematics regularly. It is extremely useful to have all that detailed documentation. Maybe there are some (possibly even a majority) that don't read the SRM, but for those of us who do it is very valuable. Please don't punish us for the crimes of others. Thanks again for all the hard work. Dennis Cote -- 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 to disable clkout2 and use mcasp0_axr1 on shared pin 41?
On Sunday, April 6, 2014 4:47:25 AM UTC-6, Miroslav Rudišin wrote: It is false, because clock control is on gpio3[21]. Hi Miroslav, You might want to double check what you are doing here. The clock control is on gpio1_27 as shown on page 3 of the schematic. Pin V17 is hardwired to the output enable of the 24.576 MHz oscillator. It can turn the oscillator on or off. This output must be turned on to use the HDMI audio. Gpio3_21 is connected to the oscillator output and used as a high speed clock input when the SOC is driving audio to the HDMI framer. If the oscillator output is disabled by gpio1_27 then the gpio3_21 pin can be used for other functions. HTH Dennis Cote -- 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: Debian boot - need a little help
On Thursday, April 3, 2014 9:47:31 PM UTC-6, Doug wrote: Why is ethernet not supported at initial boot? Hi Doug, The Debian images use wicd to start the network interfaces instead of the /etc/network/interfaces file to avoid a possible delay on boot when the BBB is not connected to a wired network. Unfortunately, at least in my experience, wicd is not set to enable the wired ethernet interface by default. I had to go into the wicd preferences page and check Always show wired interface, and then manually click the connect button on the wicd main screen. I only had to do this manually once, and ever since it has automatically re-connected the wired ethernet interface. The eth0 lines in my /etc/network/interfaces file are still commented out. HTH Dennis Cote -- 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: QT5 eglfs problem on embedded linux (TI am355x evm starter kit)
On Thursday, April 3, 2014 12:35:38 AM UTC-6, Morix Dev wrote: I haven't do anything special about SGX drivers, using the stock one provided by TI pre-built images. Do you think that I should recompile somehow SGX drivers? Why? Thanks for the info. I didn't notice you were using the TI EVM and their 3.2 kernel. I though you were using the BBB with one of the newer 3.8 kernels. My understanding is that the SGX drivers don't work with the current BBB kernels. Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Tuesday, April 1, 2014 7:34:37 AM UTC-6, RobertCNelson wrote: The is problem with the default 3.8 kernel, if your not using any cape's switch to the 3.13.x based kernel cd /opt/script/tools/ git pull sudo ./update_kernel.sh --beta-kernel I just thought others might want to know that switching to the 3.13.6-bone8 kernel also changes the resolution of the HDMI display output from 720p (i.e. 1280 x 720) to 1280 x 960, a 33% increase in display real estate. I suspect there is no audio at this resolution, but I have a monitor connected and not a TV, so I can't tell. HTH Dennis Cote -- 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: QT5 eglfs problem on embedded linux (TI am355x evm starter kit)
On Wednesday, March 26, 2014 7:23:34 AM UTC-6, mori...@gmail.com wrote: I’ve just cross-compiled QT 5.2.1 for ARM and I am using it on a TI AM335x EVM (Starter Kit) board. Hi, Would you be able to describe in detail the process you used to build and run QT 5.2, and the SGX 3D graphics accelerator drivers? If not, could you point me to the instructions you used? Thanks. Dennis Cote -- 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 to use clock output (CLKOUT2)
On Tuesday, April 1, 2014 10:47:39 AM UTC-6, Gregory Holst wrote: So I did a little searching and found some help in the documentation for the processor http://www.ti.com/lit/ug/spruh73j/spruh73j.pdf on page 880. It shows a formula for the frequency but I don't understand the M and Ns. It has something to do with the phase locked loop and creating a super high frequency clock using some fancy circuitry and I really just need to find the default values of M and N to confirm that the output will be around 24Mhz. Can anyone interpret this documentation to give me a better idea of what I can expect on the CLKOUT pins on the beaglebone black? Gregory, You can probably use the 24.576 MHz output of the HDMI oscillator that is available on P9 pin 25. The oscillator is enabled by GPIO 1-27, so you can enable using this output it even if you have disabled the HDMI output for some reason. It should be enabled by default. If you use this oscillator output, you can't use GPIO 3-21 since they share the same expansion header pin. HTH Dennis Cote -- 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: CPU speed and kernel builds
On Friday, March 21, 2014 8:24:50 AM UTC-6, cwrse...@gmail.com wrote: Okay, I'm officially confused. I've been trying to increase the speed of my BBB from the default 550MHz to 1GHz, and failing; How are you measuring the CPU frequency? I have noticed that cpufreq-info gives different answers depending upon the arguments. With no arguments mine always returns 300 MHz when running with the 300 1000 ondemand governor. If I use the cpufreq-info -f command I get the same results, always 300 MHz, both at idle and under load. If I use the sudo cpufreq-info -w command, I get 300 MHz at idle and 1000 MHz under load. The -w option reads the frequency from the hardware and requires root privledges. HTH Dennis Cote -- 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: Hello World Program GSOC 2014
On Friday, March 21, 2014 12:43:11 PM UTC-6, Florin Maticu wrote: Hello World program for GSOC 2014. Project: Debugging tools for LINUX INDUSTRIAL I/O SUBSYSTEM What is this? I know that GSOC is google summer of code, but what is this helloworld.bin file? Why is it posted here? What does it do? Who might want it? How do you install and run this if you wanted to use it? Many questions, little information. -- 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] CPU speed and kernel builds
On Friday, March 21, 2014 8:32:48 AM UTC-6, RobertCNelson wrote: voodoo@am335x-boneblack-512mb-0:~$ cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpu...@vger.kernel.org javascript:, please. analyzing CPU 0: driver: generic_cpu0 CPUs which run at the same hardware frequency: 0 CPUs which need to have their frequency coordinated by software: 0 maximum transition latency: 300 us. hardware limits: 300 MHz - 1000 MHz available frequency steps: 300 MHz, 600 MHz, 800 MHz, 1000 MHz available cpufreq governors: conservative, ondemand, userspace, powersave, performance current policy: frequency should be within 300 MHz and 1000 MHz. The governor ondemand may decide which speed to use within this range. current CPU frequency is 300 MHz. cpufreq stats: 300 MHz:43.76%, 600 MHz:0.00%, 800 MHz:0.57%, 1000 MHz:55.67% (6) Robert, When using your Debian beta image, I always get 300 MHz as the current CPU frequency for the cpufreq-info command, both at idle and under load. I also get nan% for all the entries on the cpufreq stats line at the end. I see that you are getting real percentages there. As I noted earlier, I believe the speed is changing and cpufreq-info -w shows the correct values when idle and under load, 300 MHz and 1000 MHz. Any idea why I am seeing these strange values, in particular the nan% values? -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Thursday, March 20, 2014 8:49:22 AM UTC-6, RobertCNelson wrote: Okay, quick update on this as i have the same K120 keyboard. I'm seeing this same issue on 3.8/3.13/3.14 so I just blacklisted this device. Just run: cd /opt/scripts git pull to update the xinput script.. Robert, I did this update and then undid the workaround (i.e. I uncommented the display-setup-script line in /etc/lightdm/lightdm.conf). Now I no longer get the calibration screen on startup and logout of LXDE, however I lose my mouse pointer when I logout. The mouse pointer works on reboot, but if I logout of LXDE I have no visible pointer on the login screen or in LXDE after I log back in. The mouse does work and I can see where it is because some items like the LXDE menu icons highlight when I hover the mouse over them, but there is no onscreen pointer visible. Clicking the mouse buttons work as expected when I can figure out where it is pointing. Is there anything else I can do to help pinpoint the problem? -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Thursday, March 20, 2014 11:29:10 AM UTC-6, RobertCNelson wrote: However it works better if you add it via xset/xsetroot: root@beaglebone:~# cat /home/debian/.xsessionrc #!/bin/sh xset -dpms xset s off xsetroot -cursor_name left_ptr and just remove the [Option SWCursor true] line from /etc/X11/xorg.conf Robert, My .xsessionrc file looks identical to yours, and I did not have SWCursor anywhere in my xorg.conf file, so there was nothing to remove. My mouse pointer definitely becomes invisible when I logout. Any other ideas? -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Thursday, March 20, 2014 11:47:15 AM UTC-6, Dennis Cote wrote: My mouse pointer definitely becomes invisible when I logout. Any other ideas? Robert, I have done some more testing. I have discovered that I do have a mouse pointer on the login screen after the first logout after a reboot, and I have a mouse pointer when I log in again. If I log out again, I have no visible mouse pointer on the login screen, and no mouse pointer after I log back in. It remains the same on subsequent logout/logins until I reboot again. Then I can logout and back in one more time before I lose my mouse pointer. Any ideas? -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Thursday, March 20, 2014 11:57:11 AM UTC-6, RobertCNelson wrote: Might just have to go back to the xorg.conf workaround. Robert, More test results. I googled and found many references to adding 'Option HWCursor off' to the device section of xorg.conf as a fix for the disappearing mouse cursor issue in Debian/Ubuntu/Mint etc. These all seemed to be for PC based systems thought. I tried it and it did not work. I lost my mouse cursor on every logout. I added the line you suggested to remove earlier 'Option SWCursor true' to the device section of my xorg.conf. This appears to have fixed the problem. I can logout and back in many times in a row, and haven't lost my mouse cursor since. HTH Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Thursday, March 20, 2014 1:23:24 PM UTC-6, RobertCNelson wrote: OH Fun! ;) I've had reports that xorg.conf change was causing lockup's when moving icons around, hence we changed it to the .xsessonrc workaround in the last week. Robert, I have just noticed now that my BBB is no longer blanking the HDMI output after a period of inactivity. Prior to these changes the display would blank after some period of inactivity, and I would have to move my mouse to get it to start sending video again. It has been sitting unused for an hour or more now (there is an ssh session open), and it has not blanked the screen. I googled Debian screen blanking and discovered what I think your .xsessionrc commands are doing. xset s off # don't activate screensaver xset -dpms # disable DPMS (Energy Star) features. xset s noblank # don't blank the video device I suspect you have disabled the DPMS features that were shutting down the HDMI video output. I don't need a screen saver, but I would like the video to blank after a while. So I executed an xset +dpms command and then an xset q to check the current settings and verify that DPMS was enabled. With DPMS enabled I waited for 600 seconds (10 minutes), and my display blanked as I wanted. I see that many people are searching for a way to disable screen blanking, so I think this is one of those things that should be added to your FAQ for simple ways to accomplish basic setup changes. I think the display should blank by default out of the box both for the energy savings (135,000 BBB boards could be preventing their monitors from going to low power mode) and to provide a similar experience to what one gets using a Mac or PC. The FAQ should explain how to change it, both to blank or not blank. Is there any other reason you are disabling DPMS? -- 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: Playing sound using with my BBB using a piezo buzzer (beeper)
On Monday, March 17, 2014 9:11:53 PM UTC-6, Ramon Mendes wrote: I want play 'beeps' connecting a piezo buzzer to my Beaglebone Black. I am very new to eletronics, so I need some help here, don't know how to operate these sound devices. -Eletrical circuit: as for the circuit, I am referring to this book/chapterhttp://books.google.com.br/books?id=k6FMtlXOQ50Clpg=PA101ots=XwRSMXrq8edq=beaglebone%20black%20buzzerhl=pt-BRpg=PA101#v=onepageq=beaglebone%20black%20buzzerf=falsewhich shows it very well how I should proceed: using a transistor.. -What I don't know is, how do I control the buzzer (say from a C program) to emit sound? -I guess I should configure and use PWM feature of the processor, am I right? -And how do I pragmatically control PWM output? -How could I make it play an given sound file, like a .midi file? Hi Ramon, The piezo buzzer you are using is a digital device. It is either on or off. When it is on it beeps at a fixed frequency. When it is off it is silent. The circuit you have shown uses a transistor to control current through the buzzer. When the line from processor is high, or 3.3 V, the transistor turns on and draws current through the buzzer. The line from processor would normally be a GPIO (general purpose input/output) pin rather than a PWM output. You can use one of the Python or Bonescript libraries to turn a GPIO pin on or off to control the buzzer. This simple buzzer will not play a sound file or midi file. For that you would need a PWM output running at a high frequency with its duty cycle adjusted at the sample rate of your audio signal to produce an average analog voltage proportional to the audio signal. This would then need to be low pass filtered to remove the high frequency PWM carrier and amplified to drive a speaker. This will require much more learning, hardware, and software on your part. HTH Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Friday, March 14, 2014 8:54:08 AM UTC-6, RobertCNelson wrote: I've started an offical page at: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian Hi Robert, I'm sorry to nitpick, but this new official page is wrong right out of the gate. It says it is about running an ARM EABI Debian distribution. The Debian page at https://wiki.debian.org/ArmEabiPort says this is different than the newer armhf ABI which I believe is the basis for your images. Getting this kind of basic stuff correct is important. Also, the description of how to set the timezone to your local timezone so that the clock displays local wall clock time is terse to point of extreme. It is not at all clear what the listed commands do, or why you might want to use them. Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Friday, March 14, 2014 9:21:31 AM UTC-6, Mike Bell wrote: Is this shell running within X? If so .profile isn't sourced as it's not run as login shell. Ah ha... there is the nugget of truth I was looking for. Yes, this is the LXTerminal under LXDE. I checked and the .profile *is* executed for my serial console. So how does one get the same path for the LXTerminal as you get using a serial terminal? Also, is an ssh terminal a login shell, or is like the X terminal? I don't quite follow why you want to set the TZ variable from the user environment either. It's all handled at a system level by default. No need to set the variable then export it either, just do it all in one go. export TZ=Whatever I know that now, but yesterday when I was trying to get the timezone set correctly I ran the tzselect command (which seemed logical). This is the output of that command: The following information has been given: Canada Mountain Time - Alberta, east British Columbia west Saskatchewan Therefore TZ='America/Edmonton' will be used. Local time is now:Fri Mar 14 09:31:43 MDT 2014. Universal Time is now:Fri Mar 14 15:31:43 UTC 2014. Is the above information OK? 1) Yes 2) No #? 1 You can make this change permanent for yourself by appending the line TZ='America/Edmonton'; export TZ to the file '.profile' in your home directory; then log out and log in again. Here is that TZ value again, this time on standard output so that you can use the /usr/bin/tzselect command in shell scripts: America/Edmonton So I did as it suggested. I added this line to my .profile and logged out and in. This again seemed logical. I left it in as a simple test of whether or not my .profile was executed. I will remove it now. Also less typing to just echo variables echo $HOME $PATH Really no need for env and grep. Yes, thanks for the tip. I started by using env to dump my entire environment, and then just progressed to using grep to filter the dump, while looking into why the .profile wasn't being executed. Thanks again for the info. Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Friday, March 14, 2014 9:56:45 AM UTC-6, RobertCNelson wrote: It works if i add: # set PATH so it includes user's private bin if it exists if [ -d $HOME/bin ] ; then PATH=$HOME/bin:$PATH fi into .bashrc If there is no objections i'll probably set that up by default.. Will this add the user's bin directory to the path twice when using a serial console since .bashrc is sourced from the existing .profile? Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Friday, March 14, 2014 11:53:15 AM UTC-6, RobertCNelson wrote: Yeap it does.. debian@beaglebone:~$ echo $PATH /home/debian/bin:/home/debian/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/local/games:/usr/games What gets sourced first? i can patch it to check.. I moved that section from my .profile to .bashrc since .profile will source .bashrc if it exists. So a login shell will source .profile, which will source .bashrc and add the path. A non login shell will source .bashrc directly and add the path. This seems to work for me. I'm not sure what happens for script that use #!/bin/sh since that runs dash instead of bash. The dash docs say it sources .profile on login shells so that should be OK, but for non login shells it says it looks in the ENV environment variable for the name of a file to execute. There is no such variable defined currently so it does nothing. Perhaps these commands should be put in a .shinit file and then set ENV=$HOME/.shint in the .profile file to take card of setting it for login shells, and have the .bashrc source this .shinit file for non login shells. Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Friday, March 14, 2014 10:25:42 AM UTC-6, RobertCNelson wrote: btw, as a workaround till i can debug it with the same hardware, just run: sudo sed -i -e 's:display-setup-script=:#display-setup-script:g' /etc/lightdm/lightdm.conf And it'll stop displaying the calibrator on bootup. FYI, commenting out the display-setup-script line does not take effect until after you reboot. I no longer have the calibration screen on startup or logout. Thanks. Dennis Cote -- 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: BBB Analog Digital Convertion error on Ubuntu
On Thursday, March 13, 2014 8:48:40 AM UTC-6, cagri yilmaz wrote: I used for AIN1 (P9-40) connected a PTC with parallel 480 ohm resistor and P9-03 3.3V and P9_34 AGND. I did not used VADC P9-32 as reference. Is there anybody knows what I did wrong? Oh oh... The absolute maximum allowed input on ANIx is 2.1 V per the AM335x datasheet. You may have damaged your CPU by connecting to 3.3V. The PTC should be used to form a resistor divider between VADC (P9-32) and GND_ADC (P9-34). The voltage out of the divider will change as the value of the PTC resistor changes. See the crude schematic below. VADC \ Fixed Resistor / AIN1 \ PTC / GND_ADC AINx will always be less than VADC and greater than GND_ADC. HTH Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Friday, March 14, 2014 2:08:00 PM UTC-6, RobertCNelson wrote: Here is a better fix: sudo sed -i -e 's:Exec=lxterminal:Exec=lxterminal -l -e bash:g' /usr/share/applications/lxterminal.desktop As far as I can tell by using ps - p $$, lxterminal is already running bash, so adding -e bash shouldn't change anything. Adding the -l make it a login shell, so it sources /etc/profile and then .profile, which sources .bashrc if it exists. Without this change lxterminal runs bash as a non login shell so it sources /etc/bash.bashrc and then .bashrc instead. The /etc/bash.bashrc file setups the command prompt. What I don't understand is why an lxterminal command with no options starts a bash shell, but an lxterminal -l command starts a /bin/sh shell which is actually a dash shell. You end up with no command prompt because it doesn't run /etc/bash.bashrc. There are probably other differences. This is why you added the -e bash option. Anyway this does seem like a better fix, though anything that runs /bin/sh will still have a different PATH without the user bin directory. Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Friday, March 14, 2014 2:56:50 PM UTC-6, William Hermans wrote: Dennis, just so you know, you should be able to google debian + whatever keyword you need to know something about to find an answer. We're talking basic Linux / Debian stuff here. For example. google - howto change debian timezone, and you will very likely find what i asked about last night dpkg-reconfigure tzdata. I did that and ended up at http://www.debian-administration.org/article/213/Changing_the_timezone_of_your_Debian_system which suggested the tzselect command (which in turn suggested adding a TZ environment variable, which in turn led to me seeing that my .profile wasn't being executed, etc). I also saw the page at https://wiki.debian.org/TimeZoneChanges but the text at the top of that page and the titles of the other sections made it seem more about checking and adapting the system to changes in the dates of daylight saving etc. I just wanted to set my timezone. The section where dpkg-reconfigure tzdata is mentioned has the title Check Configured Timezone, and the text of the command itself didn't lead me to conclude it would change my timezone. Had I read in more detail I would have seem what it did, but I was skimming for something that said this is how to change your timezone as on the page above. Anyway, dont feel as though I am putting you down by saying this. quite the contrary actually. No problem, no offence taken. I just want to point out that not all google searches (or searchers) lead to the best answer. Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Wednesday, March 12, 2014 4:18:02 PM UTC-6, Dennis Cote wrote: Since you seem t think the problem is SD card specific, I will try again with a different card. Using a different 8GB SD card my BBB boots this new image as expected. Hopefully the bootlog from the problem card will help identify the issue. Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
Please take the time to give a detailed look over this image and report any issues to the bug tracker on elinux.org: http://bugs.elinux.org/projects/debian-image-releases On booting this new image I noticed a few issues immediately, but I'm not sure if one is by design. The ethernet interface is not setup in this image. Running ifconfig shows no IP address for the ethernet port. Looking at /etc/network/interfaces I see that the eth0 section is commented out. I tried adding the following to /etc/network/interfaces but I still have no IP address assigned (as if dhcp wasn't aquirring an address). Commenting out the allow-hotplug line makes no difference. auto eth0 allow-hotplug eth0 iface eth0 inet dhcp Shouldn't the ethernet interface be setup by default? How does one setup dhcp on Debian if not through the interfaces file? Also, how is one supposed to use the Root Terminal in the LXDE environment? It won't accept the admin password for the debian user, and I don't know if there is a different root password? Thanks. Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Thursday, March 13, 2014 9:56:05 AM UTC-6, RobertCNelson wrote: The wicd deamon should setup eth0 within 30 seconds on 2nd boot. (first boot there is a slight delay as the ssh key's are generated). I had rebooted many times. I hadn't paid any attention to the wicd program since it seemed to be for WIFI which I am not using. I had to open the preferences and check the option to always show wired interfaces (I also checked always switch to wired connection when available) before I saw the eth0 connection. I then clicked the connect button and waited until it finished. It still didn't connect, but after I rebooted again, it did connect using dhcp. Since then it has been connecting on each boot. If you uncomment out the eth0 interface in /etc/network/interfaces boot time falls from 15seconds to 35ish.. I'm not sure what you mean by this. unccomment out is ambiguous. Did you mean uncomment, or did you mean comment out. Is it faster to boot with the eth0 defined in /etc/network/interfaces, or is it faster with the eth0 section commented out? Why? Is it redundant to define eth0 here, and then have wicd also connect eth0; or does having defined in the interafces file cause wicd to skip its redundant setup later? On an unrelated issue, how do you setup the timezone for the time display on the LXDE desktop? I have set /etc/timezone. I have also used tzselect and added the TZ environment variable to my .profile as suggested in the output of tzselect. It does not appear that my .profile file is being executed though. I have a user bin directory in my /home/debian directory, and it is not being added to the path as it seems it should be by reading the .profile file. I checked and I don't have a .bash_profile or .bash_login file which would prevent .profile from executing. Any ideas? Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Thursday, March 13, 2014 12:49:52 PM UTC-6, RobertCNelson wrote: Which brings up a fun question. What default timezone do you guys want? Or is utc generic enough? I think UTC would be best, but there should be clear instructions for how to change it. Most users (like me) are not Linux experts and don't know how to do many of these basic things. I though /etc/timezone seemed like the perfect place to make this change, but it turns out that was wrong. Google led me to tzselect which also looked promising, but again it was wrong. Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Thursday, March 13, 2014 2:33:59 PM UTC-6, RobertCNelson wrote: So then, here's a question for you. Where do you want to see those type of faq's listed? I can pretty much dump them anywhere, but the hard question is where... I don't know where they should be stored, but there should definitely be links on the beagleboard.org main page. It seems to me that if Debian is going to replace Angstrom, then a link to the Debian release images and FAQs should be put there. Eventually, the Angstrom info could be deprecated, or rather archived and its visibility reduced. It seems to me that there are currently too many places to go to get the various linux distributions and kernels, and none of them seem to be officially sanctioned as the standard release. This leads to unnecessary confusion for new users. Some info on beagleboard.org, some info at circuitco.com, some info at elinux.org, some info at armhf.com, etc., not to mention all the other stuff at ti.com. The official wiki at http://www.elinux.org/Beagleboard:BeagleBoneBlack#Software_Resources doesn't even mention this Debian releases (and it should if you want people to test it). The community wiki at http://elinux.org/BeagleBone_Community#Debian does list a Debian release, but it is a different, and incompatible, arm EABI version from this new armhf release. I appreciate all the hard work that people have done to prepare all this information, but it's a little like the wild west when you first start looking around. Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Thursday, March 6, 2014 8:58:32 AM UTC-7, Jason Kridner wrote: If you have a BeagleBone Black and are able to try out this image, it might be good to propose fixing any short-falls you see in what is provided on the image. Every time I boot, or logout of LXDE, I get a touchscreen calibration program that runs. It says 'Touchscreen calibration for Logitech USB Keyboard' (I think it sometimes says Mouse, but I could be mistaken). I am running with a HDMI monitor and a USB keyboard and mouse connected to an external powered hub. I have no touchscreen to calibrate and this wastes about 15 seconds on each logout. What starts this program, and how do I disable it? Also, the .profile file in the /home/debian directory is not being executed. I don't have a .bash_profile or .bash_login file to prevent it from being loaded. I noticed the default shell is dash rather than bash, at least /bin/sh is linked to /bin/dash, but the dash man page says it should read commands from .profile as well. When I tried the chsh command it says the default login shell is /bin/bash which should definitely read from .profile. I can tell that .profile is not being executed because I have a personal bin directory at /home/debian/bin. This directory should be added to the PATH by the .profile, but that isn't happening. I have also set a new environment variable in my .profile and it does not appear in the output of the env command. Any ideas why my .profile is not executing? Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Monday, March 10, 2014 8:03:28 AM UTC-6, RobertCNelson wrote: Doesn't really make a difference for 3.8 thou, as you see.. Best to just switch to v3.13.x Robert, How do you propose that users switch to v3.13.x (by which I assume you mean the Linux kernel version)? My BBB panics like this on every boot using the Debian 2014-03-04 image. I can't even log in to the text console. Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Wednesday, March 12, 2014 1:02:55 PM UTC-6, RobertCNelson wrote: panics on every boot? Do you have any error log? I can't really help with that limited info. When I said panics like this I meant in the same way that as the user whose message you replied to. I have copied his log below. On my BBB it usually happens just after the 120 second mark, but I have also seen it happen at 180 seconds as below. The rest of the messages are identical (same addresses etc.). [ 180.537526] INFO: task mmcqd/0:74 blocked for more than 60 seconds. [ 180.544275] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 180.552668] Kernel panic - not syncing: hung_task: blocked tasks [ 180.559071] [c0010443] (unwind_backtrace+0x1/0x8a) from [c0455ced] (panic+0x51/0x148) [ 180.567727] [c0455ced] (panic+0x51/0x148) from [c006770b] (watchdog+0x14f/0x194) [ 180.575937] [c006770b] (watchdog+0x14f/0x194) from [c003fb8f] (kthread+0x67/0x74) [ 180.584234] [c003fb8f] (kthread+0x67/0x74) from [c000c0dd] (ret_from_fork+0x11/0x34) [ 180.592778] drm_kms_helper: panic occurred, switching back to text console Easitest thing to do is, grab the non-flasher: https://s3.amazonaws.com/beagle-debian/bone-debian-7.4-2014-03-04-2gb.img.xz flash it to a microSD card.. That is what I did, and what I am running. mount the first fat partition, edit uEnv.txt remove the quiet from optargs.. save unmount.. Next using a usb-serial convert log the full serial boot log for me. Will do. -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Wednesday, March 12, 2014 2:31:13 PM UTC-6, RobertCNelson wrote: Yeah this annoyance.. What brand of microSD cards are you using? I'm using a 4GB Kingston Technology cards. Note, I have not expanded the partition to fill the card yet, I just to boot with it after copying the image. I'll get you the complete boot log if that is still of use. Dennis Cote -- 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: Here is the BeagleBone Debian (beta) image you want to test
On Wednesday, March 12, 2014 1:02:55 PM UTC-6, RobertCNelson wrote:
mount the first fat partition, edit uEnv.txt remove the quiet from
optargs.. save unmount..
Next using a usb-serial convert log the full serial boot log for me.
Robert,
The uEnv.txt file from the FAT partition in this image (attached) does not
have optargs defined. Both sections where optargs appears are commented out.
There is a line that says:
systemd=quiet init=/lib/systemd/systemd
I'm not sure if you mean to remove the quiet from this line, or perhaps
something else.
Dennis Cote
--
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.
##Video: Uncomment to override:
##see:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/fb/modedb.txt
#kms_force_mode=video=HDMI-A-1:1024x768@60e
##Enable systemd
systemd=quiet init=/lib/systemd/systemd
##BeagleBone Cape Overrides
##BeagleBone Black:
##Disable HDMI/eMMC
#optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
##Disable HDMI
#optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN
##WIP: v3.13+ capes..
#cape=lcd4-01
#cape=
##note: the eMMC flasher script relies on the next line
mmcroot=/dev/mmcblk0p2 ro
mmcrootfstype=ext4 rootwait fixrtc
##These are needed to be compliant with Angstrom's 2013.06.20 u-boot.
console=ttyO0,115200n8
kernel_file=zImage
initrd_file=initrd.img
loadaddr=0x8030
initrd_addr=0x8160
fdtaddr=0x815f
initrd_high=0x
fdt_high=0x
loadkernel=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${kernel_file}
loadinitrd=load mmc ${mmcdev}:${mmcpart} ${initrd_addr} ${initrd_file}; setenv
initrd_size ${filesize}
loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdtaddr} /dtbs/${fdtfile}
loadfiles=run loadkernel; run loadinitrd; run loadfdt
mmcargs=setenv bootargs console=${console} ${optargs} ${kms_force_mode}
root=${mmcroot} rootfstype=${mmcrootfstype} ${systemd}
uenvcmd=run loadfiles; run mmcargs; bootz ${loadaddr}
${initrd_addr}:${initrd_size} ${fdtaddr}
#
Re: [beagleboard] Re: Here is the BeagleBone Debian (beta) image you want to test
On Wednesday, March 12, 2014 4:08:50 PM UTC-6, Dennis Cote wrote: There is a line that says: systemd=quiet init=/lib/systemd/systemd I'm not sure if you mean to remove the quiet from this line, or perhaps something else. OK, so I removed the quiet from the systemd definition and rebooted my BBB. It did log a lot more stuff. The complete boot log is attached. Since you seem t think the problem is SD card specific, I will try again with a different card. HTH Dennis Cote -- 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. U-Boot SPL 2013.04-dirty (Jul 10 2013 - 14:02:53) musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 OMAP SD/MMC: 0 mmc_send_cmd : timeout: No status update reading u-boot.img reading u-boot.img U-Boot 2013.04-dirty (Jul 10 2013 - 14:02:53) I2C: ready DRAM: 512 MiB WARNING: Caches not enabled NAND: No NAND device found!!! 0 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 *** Warning - readenv() failed, using default environment musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Peripheral mode controller at 47401000 using PIO, IRQ 0 musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn) musb-hdrc: MHDRC RTL version 2.0 musb-hdrc: setup fifo_mode 4 musb-hdrc: 28/31 max ep, 16384/16384 memory USB Host mode controller at 47401800 using PIO, IRQ 0 Net: ethaddr not set. Validating first E-fuse MAC cpsw, usb_ether Hit any key to stop autoboot: 1 0 gpio: pin 53 (gpio 53) value is 1 mmc0 is current device micro SD card found mmc0 is current device gpio: pin 54 (gpio 54) value is 1 SD/MMC found on device 0 reading uEnv.txt 1384 bytes read in 9 ms (149.4 KiB/s) Loaded environment from uEnv.txt Importing environment from mmc ... Running uenvcmd ... reading zImage 3711864 bytes read in 426 ms (8.3 MiB/s) reading initrd.img 2873068 bytes read in 331 ms (8.3 MiB/s) reading /dtbs/am335x-boneblack.dtb 24996 bytes read in 11 ms (2.2 MiB/s) ## Flattened Device Tree blob at 815f Booting using the fdt blob at 0x815f Using Device Tree in place at 815f, end 815f91a3 Starting kernel ... Uncompressing Linux... done, booting the kernel. [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.8.13-bone41 (root@imx6q-sabrelite-1gb-1) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Tue Mar 4 22:51:47 UTC 2014 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] AM335X ES1.0 (neon ) [0.00] PERCPU: Embedded 9 pages/cpu @c0c8b000 s14080 r8192 d14592 u36864 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 129792 [0.00] Kernel command line: console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc init=/lib/systemd/systemd [0.00] PID hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [0.00] __ex_table already sorted, skipping sort [0.00] allocated 1048576 bytes of page_cgroup [0.00] please try 'cgroup_disable=memory' option if you don't want memory cgroups [0.00] Memory: 511MB = 511MB total [0.00] Memory: 506112k/506112k available, 18176k reserved, 0K highmem [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xe080 - 0xff00 ( 488 MB) [0.00] lowmem : 0xc000 - 0xe000 ( 512 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf80 - 0xbfe0 ( 6 MB) [0.00] .text : 0xc0008000 - 0xc073fc90 (7392 kB) [0.00] .init
Re: [beagleboard] java on BBB
On Saturday, March 1, 2014 12:01:55 PM UTC-7, Ggnome wrote: Were you able to get Java running? I'm trying to access a Java applet on my website There are instructions for installing Java from Oracle on the BB.org website at http://www.beagleboard.org/project/java/ These instructions should work for Angstrom. If you want use Java with a Ubuntu or Debian distribution you will need to download the hard float version instead. HTH Dennis Cote -- 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/groups/opt_out.
[beagleboard] Re: I can't attach a file to a posting
On Tuesday, February 18, 2014 9:00:55 AM UTC-7, Dennis Cote wrote: Does anyone else have a problem attaching a file to a post? After an update to the latest Chrome (I have had Chrome windows open for many days prior) it started working. Problem has gone away. -- 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/groups/opt_out. attachment: buffer.PNG
[beagleboard] Re: Darlington Array Help
On Friday, February 14, 2014 3:51:08 PM UTC-7, Dennis Cote wrote: Is there a secret to attaching a file? File attaching started working after updating to latest Chrome (and therefore restarting Chrome). Schematic is attached. Dennis Cote -- 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/groups/opt_out. attachment: buffer.PNG
[beagleboard] Re: Darlington Array Help
My reading of the datasheet is that the trigger current is the load current required to trip the zero crossing detector logic in order to turn on the load. I think it is separate from the input voltage required to activate the zero crossing detection circuitry. In any case using a buffer like the ULN2003 to isolate the BBB GPIO pin from the SSR is a good idea. Also, the current measured by your Kill-a-Watt is the 120 VAC input current draw by the power supply. It should produce 5 VDC at up to 2A on its output which is used to power the BBB. I would connect the GPIO pin to the input of the ULN2003 channel you are using (and remember to connect the unused inputs and the ground pin (pin 8) to the BBB GND). When the GPIO pin goes high (3.3 V) the ULN2003 input will draw about 1 mA from the GPIO pin. In turn the ULN2003 will turn on and its output will go low (to about 1 V above GND). This output should be connected to pin 4 of the SSR (as shown in the Application Hints section of the datasheet). Pin 3 of the SSR should be connected to the 5 V supply pin on the BBB. The ULN2003 will draw current current through the SSR input and the SSR should turn on after the next zero crossing. When the GPIO pin goes low (0 V) the ULN2003 will turn off and the SSR should turn off after the next zero crossing. To unsure the SSR turns off when the ULN2003 turns off you should connect a 1K pull-up resistor between the SSR pins 3 and 4. This resistor will draw about 4 mA when the ULN2003 is on. Finally, to ensure the ULN2003 is not destroyed by any inductive flyback (unlikely here, but possible), you should connect the COM pin (pin 9) to the BBB 5 V supply. This will provide about 4 V on the input to turn it on (when the GPIO pin is high), and 0 V on the input to turn it off (when the GPIO pin is low). These values are greater than the min ON voltage (2.4 V) and less than the max off voltage (1 V) specified for the SSR. I hope that is clear, a simple schematic would be better. HTH Dennis Cote On Thursday, February 13, 2014 3:48:30 PM UTC-7, godsf...@gmail.com wrote: I am looking to control three SSR's (datasheethttp://www.fotek.com.tw/pdf/etc_34.pdf ). 1. For these SSRs' input voltage, I can't go over 32V. Does the input voltage on the ULN2003 match the output voltage? 2. If I were able to use the BB's 3.3V pin as the input voltage, would there be enough current to trigger the SSR? 3. How many channels on the ULN could I power if I used the 3.3V on the BB? As I understand, the GPIO are not for sourcing current. Another option (what makes the most sense to me) is using the BB's 5V power supply for both the BB and the ULN2003. I don't know where that puts the output voltage (question #1). The BBB docs suggest 2A supply if you are running a USB peripheral. I have a WiFi USB dongle being used. The supply is rated at 2A. According to my Kill-a-watt, I don't see a draw of over 100mA. It draws 70-80mA at idle/load. I'm not sure if you can use the kill-a-watt as the amperage draw though? 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/groups/opt_out.
Re: [beagleboard] BBB VS Radiation?
On Saturday, January 18, 2014 12:05:12 AM UTC-7, lisarden wrote: if fully industrial version of a BBB clone can help you to struggle radiation then I can donate you one :) Where did you obtain this industrial version of BBB? I would be interested in that board as well. Thanks Dennis Cote -- 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/groups/opt_out.
[beagleboard] Re: How to take backup image of updated image on sd card.
On Friday, January 17, 2014 4:27:58 AM UTC-7, Jai wrote: I am using beaglebone black with ubuntu precise available at http://www.armhf.com/index.php/boards/beaglebone-black/#precise booting from sd card. I have extended the partition on the sd card and have installed ubuntu-desktop. Now I want to use my memory card for other purpose. I would like to a backup of what is on my memory card now as a image file and format my memory card after that and use for a different purpose. And whenever I want I must be able to use win32 disk imager and write the backup image and use it with ubuntu-desktop and other files that I saved. Can this be done. If yes, how? You can use Win32DiskImager to make a backup of your SD card on your PC. Insert the SD card into your SD card reader, start Win32DiskImager, select the SD card in the device dropdown, select or type a file in the Image File area, and click on the Read button. This will copy the data from the SD card to an image file. You can use 7zip or something similar to compress the image file to save space. You can now format the SD card and use it for any other function. Decompress and use the write option in Win32DiskImager to restore the image back to the SD card. HTH Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] new beaglebone image-builder script fails when downloading Cloud9
On Wednesday, January 15, 2014 5:10:59 PM UTC-7, RobertCNelson wrote: how about just plain old: sudo dd if=./bone-debian-7.3-2014-01-14-4gb.img of=/dev/sdd I can try but I doubt if it will be any different than cp or xz -cd . dennis@dennis-VirtualBox:~$ cat /sys/block/sdd/size 7626752 I believe this is units of 512B blocks. This corresponds to 3.904 GB or 3.637 GiB. The image file size is: root@dennis-VirtualBox:/home/dennis/BBB/image-builder/deploy# ls -l bone-debian-7.3-2014-01-14-4gb.img -rw-r--r-- 1 dennis dennis 393216 Jan 15 12:26 bone-debian-7.3-2014-01-14-4gb.img This size is 3.932 GB or 3.662 GiB (i.e. the 3.7GB reported earlier). Other than the fact i HATE debugging VMware/VirtualBox with a passion.. What brand are these 4GB microSD cards? Kingston Technology. To rule out virtualbox's involvment I inserted the same SD card into my BBB and checked its size as reported by Angstrom linux. root@beaglebone:~# cat /sys/block/mmcblk1/size 7626752 As you can see it reports exactly the same size. The magic number I've been using is 3750, which is working on SanDisk/Kingston/Samsung 4GB https://github.com/RobertCNelson/omap-image-builder/blob/master/tools/setup_sdcard.sh#L1540 Yes, 3750*1024*1024 is 3.932 GB, the size of the image file. Reducing this to 3750 * 3.904/3.932 or 3723 would make it fit this SD card. I would suggest reducing it slightly more, to 3700 to allow for other smaller cards. I know that the armhf.com images are 2 GB. These can be copied to a larger SD card and then fdisk is used to resize the second partition to fill the SD card, and finally the filesystem is resized to match the new partition size. This seems like a better approach than arbitrarily reducing the image size to fit on undersized SD cards, though it is more complicated. If you want a 2Gb image, pass the --img option vs the img-4gb option to setup_sdcard.sh.. I think I'll do that. I will also look at creating a script to automate the expansion process so that the result automatically fills the SD card to its full capacity, regardless of its exact size. Thanks again. Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] new beaglebone image-builder script fails when downloading Cloud9
On Thursday, January 16, 2014 9:22:12 AM UTC-7, RobertCNelson wrote: Okay, just dropped it to 3700.. https://github.com/beagleboard/image-builder/commit/b6288e9ebbe3a688b4c9623ce3c94bfdb9e5e305 Success... finally. :-) It took a while to figure out ship.sh was using the setup_sdcard.sh inside the image file. I had pulled the new version into the image_builder dir, but I didn't rerun the entire build. I was just rerunning the ship.sh script. After editing the setup_sdcard.sh in the image it worked. I have booted my BBB using the new 4GB wheezy SD card. Everything seems to be working as expected. What i'd really like to see is a script that can be run on target to automatically re-size it, even on bootup... Because, if your already running linux, instead of resizing the *.img for your microSD, you can just already call --mmc /dev/sdX with setup_sdcard.sh and it'll auto partition your microSD using all the available space. Of course the --img option allows you to easily share a completed image that doesn't need network access to pull in the extra bits setup_sdcard.sh.. I was thinking more along the lines of always building a standard image the exact size needed for the BBB eMMC (i.e. 2 GB) since they are all the same size. Then using a minimal system and a compressed copy of this standard image to build the eMMC_flasher image which I think would also fit into 2 GB. The same compressed standard image could be distributed for use with a small script that would expand the image onto an SD card of any larger size (i.e. 4 GB, 8 GB, 16 GB, etc) and then expand the partition and filesystem to match the size of the SD card. This would work well for linux host systems, but perhaps not so well for Windows or OS X hosts. So perhaps the larger images will still be needed for these systems. I noticed that the ship.sh script seems to build each image from scratch rather than basing one image on the other (i.e. it calls setup_sdcard.sh once for each image). The only thing I saw that is done for the eMMC_flasher image is the creation of a file called flash-eMMC.txt. It wasn't obvious to me how that file is used. I assume the startup code looks for that file and runs the flashing commands if it's found as the system boots the flasher image. Are there other differences between a normal image (say the 4GB image) and a eMMC_flasher image as they are currently being built? Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] new beaglebone image-builder script fails when downloading Cloud9
On Tuesday, January 14, 2014 3:14:29 PM UTC-7, RobertCNelson wrote: I think this was the real issue.. https://github.com/beagleboard/image-builder/commit/95f61a4c3c050492c252152f7fff1379c4aa50b4 Running a full rerun right now and so far it looks good.. Hi Robert, I haven't had any luck yet. The native build on the BBB had a panic while building node.js. The cross build on my PC is still running (it was waiting for a password when I returned this morning). Putty wouldn't let me copy the text from the BBB console, so had to do a screen capture. See file attached. It looks like something went wrong with the SD card driver. I thought the root partition may have run out of space, but it had 1.9GB free after the reset. I am using an 8GB SD card with ubuntu 13.10. Do you know how much space is required to run the native image builder script? Also, is there a way to restart the script without redoing all the downloads etc again? Thanks again. Dennis Cote -- 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/groups/opt_out. attachment: panic.PNG
Re: [beagleboard] new beaglebone image-builder script fails when downloading Cloud9
On Wednesday, January 15, 2014 9:27:05 AM UTC-7, RobertCNelson wrote: Humm, i thought we fixed that.. what kernel version on your BBB? ubuntu@ubuntu-armhf:~$ uname -a Linux ubuntu-armhf 3.8.13-bone30 #1 SMP Thu Nov 14 06:23:24 UTC 2013 armv7l armv7l armv7l GNU/Linux ubuntu@ubuntu-armhf:~$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 13.10 Release: 13.10 Codename: saucy Humm, honestly I'm not sure on the minimum spec's. I really don't mess around with the script, using a quad A9 with 2GB of ram and a fast sata drive.. Just started a fresh run right now, so i'll get those numbers.. OK. I'll wait until then to try the native build again. The good news is the cross build on my PC completed successfully. So I can try using your Wheezy image next time. No on restarting.. But if you build alot, look at setting up apt-cacher-ng on a local server.. then just set the apt-proxy variable like: https://github.com/beagleboard/image-builder/blob/master/host/rcn-ee-host.sh#L12 Then on the 2nd run every is gotten from the local cache server... Again, thanks for the tips. Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] new beaglebone image-builder script fails when downloading Cloud9
On Wednesday, January 15, 2014 11:27:10 AM UTC-7, Dennis Cote wrote: When my PC was done I ran the ship.sh script in the deploy directory. When I look at the files I see the following: dennis@dennis-VirtualBox:~/BBB/image-builder/deploy$ ls -hl total 3.1G -rw-r--r-- 1 root root 1.2G Jan 15 09:02 armhf-rootfs-debian-wheezy-2014-01-14-src.tar -rw-r--r-- 1 root root 1.7G Jan 15 09:46 BBB-eMMC-flasher-debian-7.3-2014-01-14-2gb.img -rw-r--r-- 1 dennis dennis 254K Jan 15 09:38 BBB-eMMC-flasher-debian-7.3-2014-01-14-2gb.img.xz -rw-r--r-- 1 dennis dennis 362M Jan 15 09:48 bone-debian-7.3-2014-01-14-4gb.img.xz -rw-r--r-- 1 dennis dennis 300M Jan 15 09:05 debian-7.3-lxde-armhf-2014-01-14.tar.xz -rwxr-xr-x 1 dennis dennis 689 Jan 15 09:05 ship.sh I noticed that the timestamp of the compressed flasher image was before the timestamp of the uncompressed image. This file was probably created the first time I ran the ship.sh script. It did some operations and then told be I was missing some dependencies. I installed the missing tools and then reran the script. which produced they files above. It seems like I should be able to delete the output files and rerun the script, but it is not clear to me which files are the outputs at this point. Should I delete the two BBB... flasher image files and the *-4gb.img.xz file, and uncompress the debian...tar.xz file to get back to square one before running the ship.sh script again? Thanks Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] new beaglebone image-builder script fails when downloading Cloud9
On Wednesday, January 15, 2014 11:38:20 AM UTC-7, RobertCNelson wrote: It looks like xz just died, it should remove BBB-eMMC-flasher-debian-7.3-2014-01-14-2gb.img when done.. That explains what happened to the debian-7.3-lxde-armhf-2014-01-14.tar file that ship.sh is looking for to start with. I changed that this week, seemed kinda silly calling it console when obviously an 'lxde' image.. Good to know. That difference is explained away. Where does the armhf... file come from? I tried tracing through the build scripts, but I couldn't see where it was created. The armhf is the name of the debian port we are using.. https://wiki.debian.org/ArmHardFloatPort Yes, I understand what armhf means (after I looked it up a few days ago), but I was asking where does the file armhf-rootfs-debian-wheezy-2014-01-14-src.tar come from? I couldn't see where it was created in the scripts. Thanks again. Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] new beaglebone image-builder script fails when downloading Cloud9
On Wednesday, January 15, 2014 11:54:17 AM UTC-7, RobertCNelson wrote: This will work around that.. ;) https://github.com/beagleboard/image-builder/commit/d856d07c209f6af4022c95fd8fecf9d1f86514c6 Thanks, that did it (after a little copying and editing to update my existing ship.sh script without rebuilding everything). I now have what appear to be a complete set of image files. Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] new beaglebone image-builder script fails when downloading Cloud9
On Wednesday, January 15, 2014 12:15:51 PM UTC-7, RobertCNelson wrote: Oh that, it gets dumped out here: https://github.com/beagleboard/image-builder/blob/master/scripts/chroot.sh#L719 just un-comment the chroot_ENABLE_DEB_SRC=enable line.. Is it used for anything in this build, or is it simply an extraneous file that doesn't need to be produced? Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] new beaglebone image-builder script fails when downloading Cloud9
On Wednesday, January 15, 2014 1:06:28 PM UTC-7, RobertCNelson wrote: It serves only one purpose. If someone was to ask you. Do you have the source to package xyz which was installed in release_xyz? You'd be able to give it to them.. It's just a tar file with the source package for everything that was installed. I see, *-src.tar now its clear. :-) Thanks again for all your help. Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] new beaglebone image-builder script fails when downloading Cloud9
Still no joy. :-( I am getting an error when writing the 4GB image to a 4 GB SD card. root@dennis-VirtualBox:/home/dennis/BBB/image-builder/deploy# xz -cd bone-debian-7.3-2014-01-14-4gb.img.xz /dev/sdd xz: (stdout): Write error: No space left on device I expanded the image to check its size and it comes back as 3.7GB which should fit. So I then unmounted the two partitions and copied the image file to the SD card (/dev/sdd) again. This also failed root@dennis-VirtualBox:/home/dennis/BBB/image-builder/deploy# cp bone-debian-7.3-2014-01-14-4gb.img /dev/sdd cp: writing ‘/dev/sdd’: No space left on device cp: failed to extend ‘/dev/sdd’: No space left on device I then removed and reinserted the SD card. It mounted the BOOT partition on /dev/sdd1, but failed to mount the rootfs partition from /dev/sdd2 with the following error: Error mounting /dev/sdd2 at /media/dennis/rootfs: Command-line `mount -t ext4 -o uhelper=udisks2,nodev,nosuid /dev/sdd2 /media/dennis/rootfs' exited with non-zero exit status 32: mount: wrong fs type, bad option, bad superblock on /dev/sdd2 Next I checked the size of the SD card. dennis@dennis-VirtualBox:~$ cat /sys/block/sdd/size 7626752 I believe this is units of 512B blocks. This corresponds to 3.904 GB or 3.637 GiB. The image file size is: root@dennis-VirtualBox:/home/dennis/BBB/image-builder/deploy# ls -l bone-debian-7.3-2014-01-14-4gb.img -rw-r--r-- 1 dennis dennis 393216 Jan 15 12:26 bone-debian-7.3-2014-01-14-4gb.img This size is 3.932 GB or 3.662 GiB (i.e. the 3.7GB reported earlier). Therefore this image is slightly too large for my nominal 4GB SD card. Can this image be resized so that it is small enough to fit? I know that the armhf.com images are 2 GB. These can be copied to a larger SD card and then fdisk is used to resize the second partition to fill the SD card, and finally the filesystem is resized to match the new partition size. This seems like a better approach than arbitrarily reducing the image size to fit on undersized SD cards, though it is more complicated. Dennis Cote -- 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/groups/opt_out.
[beagleboard] new beaglebone image-builder script fails when downloading Cloud9
I tried to use the image builder linked at the end of http://www.beagleboard.org/blog/2014-01-04-happy-new-year/ to build a new Debian based image for a BBB. I used the following commands in my home directory to download and run the image builder script. mkdir BBB cd BBB git clone https://github.com/beagleboard/image-builder cd image-builder ./beagleboard.org_image.sh The script worked until it tried to clone the Cloud9 git repository. There were many subsequent errorsafter that as copied below. Cloning into '/opt/cloud9'... error: Problem with the SSL CA cert (path? access rights?) while accessing https://github.com/ajaxorg/cloud9.git/info/refs fatal: HTTP request failed /bin/chown: invalid user: `debian:debian' Cloning into '/var/www'... error: Problem with the SSL CA cert (path? access rights?) while accessing https://github.com/beagleboard/bone101/info/refs fatal: HTTP request failed Cloning into '/var/lib/cloud9'... error: Problem with the SSL CA cert (path? access rights?) while accessing https://github.com/beagleboard/bonescript/info/refs fatal: HTTP request failed /bin/chown: invalid user: `debian:debian' Cloning into '/opt/source/libsoc'... error: Problem with the SSL CA cert (path? access rights?) while accessing https://github.com/jackmitch/libsoc/info/refs fatal: HTTP request failed final.sh: 160: cd: can't cd to /opt/source/libsoc/ final.sh: 161: final.sh: ./autogen.sh: not found final.sh: 162: final.sh: ./configure: not found final.sh: 163: final.sh: make: not found final.sh: 164: final.sh: make: not found final.sh: 165: final.sh: make: not found Cloning into '/opt/source/Userspace-Arduino'... error: Problem with the SSL CA cert (path? access rights?) while accessing https://github.com/prpplague/Userspace-Arduino/info/refs fatal: HTTP request failed /bin/sed: can't read /etc/ssh/sshd_config: No such file or directory /bin/sed: can't read /etc/ssh/sshd_config: No such file or directory Does anyone know what went wrong, or more importantly, what I need to do to fix it? TIA Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] new beaglebone image-builder script fails when downloading Cloud9
On Tuesday, January 14, 2014 1:27:44 PM UTC-7, RobertCNelson wrote: I'm guessing this was on x86? So what OS and what version and Yes, you are correct. A Ubuntu 13.10 VM running on virtualbox. Linux dennis-VirtualBox 3.11.0-15-generic #23-Ubuntu SMP Mon Dec 9 18:17:04 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux what version of qemu-arm-static qemu-arm-static -version qemu-arm version 1.5.0 (Debian 1.5.0+dfsg-3ubuntu5.2), Copyright (c) 2003-2008 Fabrice Bellard I'm not 100% sure of this is qemu to blame or the network went down.. BTW: due to issues with qemu across the board, I only run this script on native arm hardware (Debian Jessie).. OK I can try to build with a Ubuntu 13.10 install I have running on an SD card on the BBB. Linux ubuntu-armhf 3.8.13-bone30 #1 SMP Thu Nov 14 06:23:24 UTC 2013 armv7l armv7l armv7l GNU/Linux How do you get the image off the SD card used to build it and onto another SD card to test booting? I guess I'll copy it up to another computer (like my Ubuntu PC) and write the image to an SD card there. Thanks. Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] new beaglebone image-builder script fails when downloading Cloud9
My build on the BBB itself just failed in *exactly* the same fashion. I got the same error after starting to clone Cloud9. Also, the same follow on errors since I hadn't fixed the script as you did in your patch. So this does not look like it is caused by qemu. Interestingly, I think this build completed slightly faster than the x86 build. I think it was mostly because the network speed for the downloads was better. I suspect the network translation slows down the virtual machine build enough to make a difference. On the other hand it could have been the time of day or something else. Ultimately the downloads were about twice the speed on the BBB as my VM, and both eventually lead to the same ISP. In any case, the native build is definitely not radically slower than the PC build (as I had expected). On Tuesday, January 14, 2014 2:09:03 PM UTC-7, RobertCNelson wrote: For me.. Sometimes this version works.. voodoo@work-e6400:~$ qemu-arm-static -version qemu-arm version 1.7.0 (Debian 1.7.0+dfsg-2), Copyright (c) 2003-2008 Fabrice Bellard depending on mode the git calls just fail.. I'm not 100% sure of this is qemu to blame or the network went down.. BTW: due to issues with qemu across the board, I only run this script on native arm hardware (Debian Jessie).. btw, this should help the script atleast complete on totaly failure qemu/git failure.. https://github.com/beagleboard/image-builder/commit/7e308e293e6d524e00406590a8cefc57d2173115 How do I use this link to update the script? I'm quite new to git. Just copy it via any means, rsync/apache/etc. When you run ./beagleboard.org_image.sh, your final image base image will be under the deploy directory. You'll also see a ship.sh script, this created the final 3 images i uploaded to here: http://rcn-ee.net/deb/testing/2014-01-10/ Normally i copy these 2 files (ship.sh/debian*-.tar) to an x86 and then run ./ship.sh as the xz compression takes a lot of resources before uploading.. Thanks for the tips. I'll do that when I can get the build to complete. Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] new beaglebone image-builder script fails when downloading Cloud9
On Tuesday, January 14, 2014 3:06:39 PM UTC-7, Dennis Cote wrote: How do I use this link to update the script? I'm quite new to git. Google answered that one I think. I did git pull in the directory I had cloned from github. It updated the correct file as expected. Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] BBB flasher fails to update eMMC
On Friday, September 27, 2013 7:27:21 AM UTC-6, Gerald wrote: I will add it to the top of the page for those that only read part of the page. I just hope they start at the top. Hi Gerald, Just to be clear, I think the new info should be added in the middle of http://beagleboard.org/Getting%20Started between the Update board with latest software and the Step #1: Download the latest software image. It should explain how to check the current version so the user can skip the download and update if they already have the current version (which is likely on a new board). I have downloaded the 2013.09.04 flasher image again and verified that I get the same MD5 hash as the original file I downloaded, so I'm sure the download was not corrupted. Do you have any idea when a new flasher image with a complete rootfs archive will be available? Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] BBB flasher fails to update eMMC
On Friday, September 27, 2013 8:37:54 AM UTC-6, Gerald wrote: I will pass that suggestion on to someone else to see if that can be updated. Thanks. We point people to the WIKI via the card that comes in the box as that is easier t update than the website.. The card is what led me to the circuit.co wiki page with the 2013.09.04 image. I had already downloaded the older 2013-06-20 image linked to from the Getting Started web page. Maybe the web page can be updated with a link to the wiki labeled for the latest info go to... rather than relying on just the cards. I will need to defer your question on the image to the rest of the team to answer. OK, hopefully someone can help. I don't see how anyone could have used this image successfully, but I may be wrong. Has anyone used the 2013.09.04 flasher image to install the latest Angstrom version on a BBB eMMC? Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] BBB flasher fails to update eMMC
On Friday, September 27, 2013 9:11:20 AM UTC-6, Gerald wrote: We use the 9_4 Flasher image in production to flash all the production boards. It is tested thousands of time a week. Can you verify that the file linked to from the wiki at https://s3.amazonaws.com/angstrom/demo/beaglebone/BBB-eMMC-flasher-2013.09.04.img.xz is **exactly** the same as the file used to build the production flasher SD cards? The file I downloaded is BBB-eMMC-flasher-2013.09.04.img.xz and it is 373,850,348 bytes long with MD5 hash 6b551bf357339e98377dfb6f6fdba016. It is expanded by 7zip into an image file BBB-eMMC-flasher-2013.09.04.img which is 3,657,433,088 bytes long and has MD5 hash b45fcc0da3d797f6dc0fed3dde19d311. This image is copied (using the Win32DiskImager) to a 4GB SD card which boots the BBB and runs the emmc.sh script as expected, but the script consistently fails after about 5 minutes as explained in my previous post. The board stops with all user LEDs off because of errors detected by the emmc.sh script. Those errors are caused by missing files and directories in the archived rootfs, Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone.rootfs.tar.gz, contained in the /build directory of the Angstrom linux installed on the flasher SD card. I just completed another pass through the entire update process starting with the freshly downloaded compressed flasher image. It failed in the same way. After the emmc.sh script stopped I logged in using the serial debug cable and tried to expand the archived rootfs manually. I got an error about an invalid tar header checksum. root@beaglebone:~# cd /build root@beaglebone:/build# mkdir rootfs root@beaglebone:/build# tar -zxf Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone.rootfs.tar.gz -C rootfs tar: invalid tar header checksum root@beaglebone:/build# ls rootfs binhome media mntsbin usr The directories created look the same as those listed in my previous post. I just repeated the tar listing again and go the same error. I must have missed it last time since I had redirected the output to a file, but the error message went to the console instead of the file. There is definitely a problem with the flasher image I downloaded. The archived rootfs is corrupt so it generates an incomplete rootfs in the eMMC. Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] BBB flasher fails to update eMMC
On Friday, September 27, 2013 12:14:05 PM UTC-6, Robert P. J. Day wrote: still chugging away so i'm confident it will finish. i did nothing different from all the other times: * download xz-ball * uncompress to get .img file * verified that my size and md5sum matched what original poster listed * dd to 4G uSD card * remove uSD card, then immediately reinsert to verify that filesystems are mounted by my linux box * put uSD card in BBB and ... go the fact that my size and md5sum matched suggests something gets corrupted in the flashing process or something. i've always downloaded my flasher images from koen's dominion site, never from amazon. Hi Robert, I agree that if your MD5 checksums matches mine the problem must be in the writing of the image to the SD card. I am using Win7 instead of linux to expand the image and write the SD card, but I don't think that should matter. I will try writing the SD card with a different SD card adapter on a different PC. BTW I can't get the http://dominion.thruhere.net/koen/angstrom/beaglebone/BBB-eMMC-flasher-2013.09.04.img.xz image since the domain is blocked by our untangle firewall for the following reason. This site was categorized in: Parked Domains I will have to talk to our network admin about this, but I believe we use the default blacklists for untangle. Since others may use this firewall ( http://www.untangle.com/store/firewall.html) you may want to see if they can correct their blacklist. Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] BBB flasher fails to update eMMC
On Friday, September 27, 2013 12:44:56 PM UTC-6, Robert P. J. Day wrote: i can't think of anything else ... if my size and md5sum matches yours after decompression, there's really no other possibility. I have reprogrammed the SD card using a different PC and SD card adapter. It has been happily blinking away for about 15 minutes. I expect it will complete as expected. So I'm pretty sure the problem is with the SC card adapter I was using. It was an older Spyker USB Hub and multiple format flash card adapter. I'm surprised that so much worked right but the rootfs was still corrupted. I also got no error messages from the Win32DiskImager utility using this adapter. Oh well, on to better things. At least I learned a lot about the boot and flashing process while chasing this down. Thanks for your suggestions and taking the time to check the MD5 checksums. Dennis Cote -- 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/groups/opt_out.
Re: [beagleboard] BBB flasher fails to update eMMC
On Friday, September 27, 2013 1:38:11 PM UTC-6, denni...@gmail.com wrote: I have reprogrammed the SD card using a different PC and SD card adapter. It has been happily blinking away for about 15 minutes. I expect it will complete as expected. FYI the flasher completed and worked as expected. Hooray! I have already bought a new SD card adapter. The problems with the incorrect test for the kpartx command in mkcard.sh and the missing blockdev command used in emmc.sh as noted in my original post are still present. Additionally there are several warnings about the use of depreciated paths and one error cannot register alternative run-parts... that may need to be looked at. Dennis Cote -- 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/groups/opt_out.
