[beagleboard] Re: BBB in Cold Weather
I recently had one random selected BBB sourced from Embest in the clima chamber at -40°C and it started and operated flawlessly within these conditions. I was somehow surprised by myself a little bit. -- Günter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Bulk flashing of BBB eMMC
Hello Lee, my process is that I have a running Linux on a bootable SD card. As a autostart service, there is a scripted executed, which performs 1) partitioning of the eMMC card 2) copy u-boot.bin and MLO to the first sectors of the eMMC 3) format the 1st (and only) partition with ext4 file system 4) unzip/untar a master tar.gz from the boot media to the data partition 5) patch the extracted uEnv.txt with the actual UUID of the partition on eMMC 6) initiate regeneration of ssh host keys (touch /etc/ssh/ssh.regenerate) 7) sync 8) power off That takes about 1min to flash one Beaglebone. It takes somewhat longer if the BBB is not connected to a network, because then it needs a network timeout to proceed cheers, Günter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Boot MLO/U-Boote directly from USB?
Some time ago there was a similar discussion in this board: https://groups.google.com/forum/#!msg/beagleboard/bDRCI2J7msY/k_tvzXO9W88J Unfortunately I did not have time trying this. However, William knows the BB quite good, maybe you give a comment about the solution presented there? -- Günter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6
I'm sorry to say, but now I confirmed my assumption. In my application I am heavily using /dev/ttyO5 and moderatly using /dev/ttyO2. One of my BB-White is stable on 4.1.0-rc8-bone9 since 38 days now. I don't want to touch this. I was running a BB-White (bb589b) with 4.1.0-rc8-bone9 for 2 days without problems. I then updated bb589b to 4.1.5-ti-r10 and am getting a crash *unexpected IRQ trap at vector 00* after just a few hours, same happend with 4.1.4-ti-r9. I'll now look for some more BB-White in order to get more information. -- Günter -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6
I don't want to say that I am 100% sure with my findings, as I need some more testing done before, but it might be that they suffer from a problem on BB-White. Together with my application, which heavily uses the ttyO5 and moderately uses ttyO2, I have one BB-White up running 4.1.0-rc8-bone9 since 34 days now I have another BB-White with 4.1.2-ti-r4 also tried 4.1.4-ti-r9, and both times after a few hours of operation am getting on the console unexpected IRQ trap at vector 00 Before ringing any bells, I want to ensure that those boards showing this error are stable with the 4.1.0-rc8-bone9. -- Günter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6
This is what I can add for now, please note the uptime of the first, which is up since 8 days. These are 3 BB-Black from the very first production of Embest, probably there was a different PMIC? I should get 16 out of the April Embest production (which were stored at a different location) today and I will include them afterwards. # dmesg | grep phy mask [3.687140] davinci_mdio 4a101000.mdio: detected phy mask fffe # cat /proc/device-tree/model TI AM335x BeagleBone Black # uname -a Linux bb1cf1 4.1.2-ti-r4.6 #1 SMP PREEMPT Tue Jul 21 08:24:37 CDT 2015 armv7l GNU/Linux # uptime 07:15:08 up 8 days, 11:13, 1 user, load average: 0.00, 0.01, 0.05 # dmesg | grep phy mask [2.722583] davinci_mdio 4a101000.mdio: detected phy mask fffe # cat /proc/device-tree/model TI AM335x BeagleBone Black # uname -a Linux bbc1a1 4.0.4-bone4 #1 Mon May 18 05:59:35 UTC 2015 armv7l GNU/Linux # uptime 07:17:40 up 9:26, 1 user, load average: 0.00, 0.01, 0.04 # dmesg | grep phy mask [2.722541] davinci_mdio 4a101000.mdio: detected phy mask fffe # cat /proc/device-tree/model TI AM335x BeagleBone Black # uname -a Linux bbde39 4.0.4-bone4 #1 Mon May 18 05:59:35 UTC 2015 armv7l GNU/Linux # uptime 07:18:55 up 9:28, 1 user, load average: 0.00, 0.01, 0.05 for you all to enjoy, one of the BB-White: # dmesg | grep phy mask [3.676818] davinci_mdio 4a101000.mdio: detected phy mask fffe # cat /proc/device-tree/model TI AM335x BeagleBone # uname -a Linux rc22 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux # uptime 07:20:25 up 22 days, 2:36, 2 users, load average: 0.24, 0.20, 0.18 -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Image 2015-7-26, kernel 4.1.3-ti-r6
I can set up easily 24 boards, and with some additional work even 48, if that helps. Günter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Image 2015-07-19
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. Günter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BBB intermittently rebooting.
wget http://rcn-ee.homeip.net:81/farm/testing/linux-image-4.1.2-ti-r4.6_1cross_armhf.deb sudo dpkg -i linux-image-4.1.2-ti-r4.6_1cross_armhf.deb sudo reboot It improves the situation, but there are still some reboots. After 12h operation, 5 of my 14 BBB are still up since reboot, the others have seen reboots, one outstanding has had 4 oft them. -- 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.
Am Mittwoch, 22. Juli 2015 08:45:40 UTC+2 schrieb lisarden: You can disable in software Vac or Vusb, but not the battery source, that is why so much trouble What about adding a 1k resistor from the VBat+ input to ground, just for safety? -- 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: Debian 8.1 / kernel 4.1.x test releases are unstable
Since we now have two threads about the same problem... https://groups.google.com/forum/#!topic/beagleboard/2yOpE3XYJ1Y My 13 BB-Black under test are powered from external +5V with these power supplies: http://www.deutronic.com/products/power-supplies/ac-adapter/esc15g-15-watt.html Average reboot number of each BB-B was each about 3 per day. After reading this thread, I simply connected a USB cable from the front side Type-A to the back side Mini-USB and since then the number of reboots drastically decreased, within the last 12h I saw in total just two. Other systems under my control but not located in my lab are showing the same improvement. --- Günter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BBB intermittently rebooting.
Since we now have two threads about the same problem... https://groups.google.com/forum/#!topic/beagleboard/lF1X1XINjDo My 13 BB-Black under test are powered from external +5V with these power supplies: http://www.deutronic.com/products/power-supplies/ac-adapter/esc15g-15-watt.html Average reboot number of each BB-B was each about 3 per day. After reading this thread, I simply connected a USB cable from the front side Type-A to the back side Mini-USB and since then the number of reboots drastically decreased, within the last 12h I saw in total just two. Other systems under my control but not located in my lab are showing the same improvement. --- Günter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Debian 8.1 / kernel 4.1.x test releases are unstable
Just to let you know that my test of 13 BBB is still available Here my results of of 3 days + 12h testing: bba94e: 13 reboots bbf611: 9 reboots bb4f8e: 12 reboots bb5d63: 12 reboots bbea75: 14 reboots bb845a: 12 reboots bb93dc: 10 reboots bbde13: 6 reboots bb5a40: 13 reboots bb6c1f: 14 reboots bb151f: 7 reboots bb6548: 14 reboot bb8f34: 9 reboots The reboots are equally distributed over time. I have two BB-White running: root@bb22:~# cat /proc/device-tree/model TI AM335x BeagleBone root@bb22:~# uname -a Linux bb22 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux root@bb22:~# uptime 07:39:40 up 8 days, 2:55, 1 user, load average: 0.25, 0.21, 0.23 root@bb22:~# ssh root@bb110 root@bb110:~# cat /proc/device-tree/model TI AM335x BeagleBone root@bb110:~# uname -a Linux bb110 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux root@bb110:~# uptime 07:40:01 up 13 days, 20:07, 2 users, load average: 0.38, 0.36, 0.32 --- Günter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: Debian 8.1 / kernel 4.1.x test releases are unstable
I installed 4.1.2-ti-r3 on 13 devices. Without executing cpufreq-set -g performance. First impression is not good, as I had 3 reboots since then, but more info after the night about 8h. -- 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: Debian 8.1 / kernel 4.1.x test releases are unstable
Here my results of of 12h testing: bba94e: 4 reboots bbf611: no reboot bb4f8e: 2 reboots bb5d6e: 4 reboots bbea75: 1 reboot bb845a: no reboot bb93dc: 2 reboots bbde13: 2 reboots bb5a40: 2 reboots bb6c1f: 4 reboots bb151f: 1 reboot bb6548: 1 reboot bb8f34: 1 reboot In parallel, I have set up one system with 3.19-3-bone4. That was stable for 12h while simply idling. Now while running some software on it it seems it does not have the same problem of the 4.1.x but instead it shows an *unexpected IRQ trap at vector 00* error after around 6h of operation (several times). For me that looks like 3.19.3-bone4 did not have the problem we're looking for in 4.1.x now. -- Günter -- 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: Debian 8.1 / kernel 4.1.x test releases are unstable
Results after two days overnight test: (1) System bb1cf1 got installed with 3.19.3-bone4: *still no reboot* uptime 04:19:11 up 1 day, 13:51, 2 users, load average: 0.00, 0.01, 0.05 (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots to a total of 4* Jul 13 00:55:17 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 01:51:02 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 21:46:08 rc6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 14 04:02:45 rc6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *rebooted 15:50* after around 20h uptime, before it had 6 reboots within 24h (4) some other systems ran with cpufreq-set -g performance, feeling is that the number of reboots decreased My conclusion: - cpufreq-set -g performane seems to improve the situation, but does not solve it. - 3.19.3-bone4 is stable --- Guenter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
Results from overnight test: I used the worst rebooters for some tests: (1) System bb1cf1 got installed with 3.19.3-bone4: *no more reboot* uptime 03:23:37 up 14:50, 1 user, load average: 0.00, 0.01, 0.05 (2) System bb6c1f: installed with 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux: *2 reboots* Jul 13 00:55:17 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 Jul 13 01:51:02 bb6c1f kernel: [0.00] Booting Linux on physical CPU 0x0 (3) System bb4f8e still has 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux: but cpufreq-set -g performance: *no more reboot* uptime 03:29:57 up 9:01, 1 user, load average: 0.02, 0.06, 0.05 As I have to leave for the day, I will let all my systems run for at least 12h without changes. If then still like this, I will do (1) and (3) on some more devices. @RobertCNelson: If you have further suggestions which image to test, let me know. --- Guenter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
W: Failed to fetch http://repos.rcn-ee.com/debian/dists/jessie/main/binary-armhf/Packages Hash Sum mismatch Solution: http://askubuntu.com/questions/41605/trouble-downloading-packages-list-due-to-a-hash-sum-mismatch-error Simply: rm -rf /var/lib/apt/lists/* -- 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] Debian 8.1 / kernel 4.1.x test releases are unstable
I now have one of the worst case rebooters running on 3.19.3-bone4 (already installed 8h ago) root@bb1cf1:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 8.1 (jessie) Release:8.1 Codename: jessie root@bb1cf1:~# uname -a Linux rc1cf1 3.19.3-bone4 #1 Fri Mar 27 16:05:22 UTC 2015 armv7l GNU/Linux root@bb1cf1:~# uptime 19:47:17 up 7:49, 1 user, load average: 0.47, 0.17, 0.09 and one on Robert's suggestion 4.1.1-ti-r2 root@rc6c1f:~# uname -a Linux rc6c1f 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux root@rc6c1f:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux 8.1 (jessie) Release:8.1 Codename: jessie root@rc6c1f:~# uname -a Linux rc6c1f 4.1.1-ti-r2 #1 SMP PREEMPT Wed Jul 8 17:03:29 UTC 2015 armv7l GNU/Linux root@rc6c1f:~# uptime 19:49:39 up 22 min, 1 user, load average: 1.09, 0.69, 0.31 -- 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 8.1 / kernel 4.1.x test releases are unstable
I absolutely agree with Graham's report. I also saw plenty of unexplainable resets of the Beaglebone, same as Graham says when just having them on the table, naked, no cape, just flashed with fresh image. My power supplies are 5V/2A from a german quality vendor and I'm using them in hundreds, the power supply is not the reason. There is no information in journalctl -f, no information on the RS232 console, the board just resets without any indication. I made a test with a bigger number of Beaglebone (white) and Beaglebone-Black, and these are the results within 24h. All but two of them are operating this release: uname -a Linux bb151f 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux These are my test results: MACBBCommentNumber of Resets / uptime 00:18:31:e0:54:35Whitestable since power on (1day) -bc:6a:29:cc:a5:aeWhitestable since power on (7 days) -00:18:31:8b:59:4eWhitestable- d4:94:a1:85:c2:3dWhitestable running 4.1.1-bone9 - 78:a5:04:cd:cf:b3Blackstable- 78:a5:04:ce:13:21Blackstable since power on (12days) -d0:5f:b8:d7:53:ecBlackunstablereboots every 4-6h6c:ec:eb:5d:26:09Blackunstable, even with 4.2.0-rc1-bone13d0:39:72:45:1c:f1Blackinstable, got 1x stuck in U-Boot 678:a5:04:ca:a9:4eBlack 378:a5:04:fe:f6:11Black 378:a5:04:cf:4f:8eBlack 678:a5:04:db:5d:63Black 354:4a:16:c5:ea:75Black 278:a5:04:cf:84:5aBlack 378:a5:04:fd:93:dcBlack 278:a5:04:fe:de:13Black 578:a5:04:cf:5a:40Black 478:a5:04:cf:6c:1fBlack 66c:ec:eb:a5:15:1fBlack 278:a5:04:cf:65:48Black 478:a5:04:ca:8f:34Black 3 I'm sampling uptime of all boards every 30min, and sometimes the simple script that collects that data gets stuck, so the true number is definitly higher. All my Beaglebone (white) under test are rock-solid, and so are also two BB-Black. Those two BB-Black are elder devices from the first BB-Black on the market, while those that are unstable are mostly latest production from Embest. As Graham reports, all the boards are stable when running something before 4.x.x, in my case this is the very old 3.8 Angstrom: # uname -a Linux beaglebone 3.8.13 #1 SMP Tue Jul 30 11:56:13 CEST 2013 armv7l GNU/Linux # lsb_release -a Distributor ID: Angstrom Description:Angstrom GNU/Linux v2012.12 (Core edition) Release:v2012.12 Codename: Core edition I am now changing my worst candidates back to uname -a Linux bb1cf1 3.19.3-bone4 #1 Fri Mar 27 16:05:22 UTC 2015 armv7l GNU/Linux Any comment or help would be greatly appreciated. If I can add some testing, let me know. --- Guenter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
Instabilities have been found by just flashing elinux.org images from, for example, http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_console, in special *Flasher: (console) (BeagleBone Black eMMC)* and letting the board idle with network + serial console connected Also, is 4.1.x stable if you don't mess with the image? -- 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] Debian 8.1 / kernel 4.1.x test releases are unstable
Instabilities have been found by just flashing elinux.org images from, for example, http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_console, in special *Flasher: (console) (BeagleBone Black eMMC)* and letting the board idle with network + serial console connected Also, is 4.1.x stable if you don't mess with the image I am willing to try with serveral images, as I have 15 boards suffering from this under supervision But I don't understand which sequence to go for. There are so many, if I look for them in apt-cache search linux-image --- Guenter (dl4mea) -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Debian 8.1 / kernel 4.1.x test releases are unstable
If I look on one - but not the target worst case Beaglebone, I see only one package matching Robert's suggestion apt-cache search linux-image | grep ti | grep 4.1 linux-image-4.1.1-ti-r2 - Linux kernel, version 4.1.1-ti-r2 However, if I want to apt-get update on the two current worst case targets, I am getting Get:10 http://ftp.us.debian.org jessie-updates/non-free armhf Packages [20 B] Fetched 9247 kB in 20s (457 kB/s) W: Failed to fetch http://repos.rcn-ee.com/debian/dists/jessie/main/binary-armhf/Packages Hash Sum mismatch E: Some index files failed to download. They have been ignored, or old ones used instead. This system has installed uname -a Linux bb6c1f 4.1.0-rc8-bone9 #1 Wed Jun 17 00:05:43 UTC 2015 armv7l GNU/Linux Is this a temporary hickup or any other idea? -- 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: flashing eMMC over serial (or uart or ttl serial)
Hi, can you describe how you did achive that? It would be a great help so. Thanks a lot in advance! Günter Am Montag, 8. Juni 2015 02:06:16 UTC+2 schrieb rh_: On Sat, 6 Jun 2015 10:45:26 -0700 rh_ richard...@lavabit.com javascript: wrote: I got this working. -- 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: beaglebone automatically boots from sd
The u-boot programming (see uEnv.txt or stop during boot and say printenv) will show you that it first probes if there is a bootable SD card inserted and in such a case it boots from SD card. If you don't want this, you need to change settings in uEnv.txt Am Freitag, 29. Mai 2015 12:37:08 UTC+2 schrieb BBBUser: I have installed Ubuntu in the eMMC of the BeagleBone Black and Debian bone-debian-7.8-lxde-4gb-armhf-2015-03-01-4gb.img on the SD (non flasher). If I remove the SD card *only *I am able to boot from the eMMC. If I boot while the SD is plugged with *no *switched pressed the BBB boots by default the SD image. Also if I boot (connect power cable) while holding the boot switch *still *BBB boots from the SD card. Why does this happen? Has anyone else had this experience? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] How to avoid vi and nano editors resetting Putty number of lines?
Hello Charles, yes, this helped. I did not know that the two values must fit to each other. Good to know. Thanks a lot, Günter -- 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: Cloning Beaglebone eMMC
Hello,
I quite often have to clone a Beaglebone and dd is far too much time
consuming for me. For that, I process that way:
- make a reference installation on an eMMC (currently the single
partition image from Robert Nelson)
- use a separate SD card image and boot from this.
- create a mount point on the SD card and mount eMMC to the mount point
- tar cvfz archive.tgz -C mount point
On the target system:
- Boot from SD card
- MLO and uImage are copied to eMMC from the ones on the SD card (this
is a weak point but working for me)
- fdisk eMMC for one partition and mkfs.ext4
- mount eMMC partition and untar tgz to it.
- !!! remove ssh keys and generate new ones !!!
- !!! edit uuid of the eMMC partition in uEnv.txt !!!
I am starting this skript automatically after boot using a systemd process,
when ready the board goes into powerdown. Whole flashing procedure takes
about 2min. It is safe, if not working it can be re-done several times.
Like to say from my experience that this is production grade.
That is done with a skript:
#!/bin/sh
# reference:
https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SetupmicroSD/SDcard
# precondition: make a tgz of an existing eMMC installation
# boot from a SD card
# mount the eMMC into a mounting point and then compress it with tar cvfz
-C mountpoint/
set -x -e
#umount mmc1
ntpdate -bv ptbtime2.ptb.de
export DISK=/dev/mmcblk1
dd if=/dev/zero of=${DISK} bs=1M count=10
dd if=/opt/backup/uboot/MLO of=${DISK} count=1 seek=1 conv=notrunc bs=128k
dd if=/opt/backup/uboot/u-boot.img of=${DISK} count=2 seek=1 conv=notrunc
bs=384k
sudo sfdisk --in-order --Linux --unit M ${DISK} -__EOF__
1,,0x83,*
__EOF__
mkfs.ext4 ${DISK}p1 -L rootfs
sync
mount ${DISK}p1 mmc1
tar xfm previouly_archived_root_file_system -C mmc1
BLKID=`blkid -o export /dev/mmcblk1p1 | grep -i uuid`
UUID=$(echo $BLKID | tr '[:upper:]' '[:lower:]')
sed -i s/uuid=.*/$UUID/I mmc1/boot/uEnv.txt
rm -fv mmc1/etc/ssh/*key*
ssh-keygen -t dsa -b 1024 -f mmc1/etc/ssh/ssh_host_dsa_key -q -N
ssh-keygen -t rsa -b 1024 -f mmc1/etc/ssh/ssh_host_rsa_key -q -N
ssh-keygen -t ecdsa -b 256 -f mmc1/etc/ssh/ssh_host_ecdsa_key -q -N
umount mmc1
poweroff
--
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] 625 MHz leak?
In a similar problem it helped for me to replace the 0.1R that connectes Ethernet shield to the frame of the Beaglebone by a simple solder bridge. This resistor is located on the solder side of the Beaglebone, just below the network connector. I have a spectrum analyzer and a 3GHz active probe and was astonished about the amount of infuence. Sounds crazy but prooven many times meanwhile. Regards, Günter -- 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] How to avoid vi and nano editors resetting Putty number of lines?
Hello, I am most of the time accessing the Beaglebone through the serial console using Putty. Every time I open a vi or nano editor, the number of lines that is actually used is set to 25, even if the window is much larger. Worse than that, after leaving the editors, that size stays permanent and requires a Reset Terminal. I've also tested several of the disabling functions but none of them helped. While working over a ssh console, it is not a problem, even with Putty. Anyone who knows how to get rid of this problem. Not answer use Teraterm or others please, the question is only for Putty. Thanks, Günter -- 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] CE and ESD, BBB is failing 4kV contact discharge ESD testing
If we are just at this theme, what about the ethernet lines? Looking at the schematic, sheet 9, the 4 active lines are directly connected to the LAN8710 chip. Or is there anything not visible inside the RJ45 connector? Regards, Günter -- 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] Enabling ttyO4 with DTR/DSR/RTS without the capemgr
Make sure the ttyO4 driver is loaded via the device-tree (use the dtb-rebuilder if needed), and setup the pin multiplexing with the installed-by-default universal overlay. The intent is to provide user-mode control of pin multiplexing so you should be able to enable just the Rx/Tx pins or whatever combination of data and handshake pins are needed for your application. Hello Charles, I am about in the same situation. As far as I have understood the installed-by-default 'universal' overlay is bound into the Kernel. Am I right? In that case, I see that the one bound into Robert's latest builds is intended for BB-Black, and exports all pins that are not HDMI and not eMMC. Also right? However, I want to run the 3.14 on BB-White, and am in special need for P8.03 P8.04 and P8.05, which are not exported as they are eMMC on the BB-Black. What is your recommendation for this situation? Cheers, Guenter -- 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.
