Re: [beagleboard] Re: RS485 support for BBB
p.s. - I'm currently running a patched version of kernel version 4.4.110... for the BB-X15, but I believe the underlying principles are the same between the BBB and BB-X15 with respect to UART (except for the pinmux which is more straight forward to configure in BBB world). On Monday, March 5, 2018 at 9:12:06 AM UTC-6, Jeff Andich wrote: > > Hi, > > There have been a number of posts on here on how to switch between the > 8250 and OMAP drivers. Above in this same thread, Robert showed which > defines within the kernel defconfig file to change, and I experimented with > this and was able to see and use /dev/ttyO* instead of /dev/ttyS*. I had > to search for and swtich additional defines, as initially, I ended-up > losing my console and still had /dev/ttyS*.. If you look through the > following post, you can see how I switched from the 8250 to the OMAP > driver. Someone else on here proposed a way to have a mixture of OMAP and > 8250 serial drivers, but I haven't been brave enough to try that yet. > > https://groups.google.com/forum/#!topic/beagleboard/JGIm0Ej6jDI > > I never attempted to get full-blown hardware flow control up and running, > since our hardware board has RS485 chips which only have the DE pin > connected. RTS and CTS lines don't interconnect the different parties on > the MODBUS network in our case, only the RS485 differential signals (e.g. > TXp, TXn). > > Initially we connected GPIO lines to the DE pins, but then more recently, > our hardware engineer swapped out GPIO lines for the "dedicated RTS" line > for a given UART. > > One thing that's really interesting, IMO, is if you use a dedicated RTS > line (e.g. UART5 RTSn), you can still toggle RTS from the application layer > **using the 8250 driver**. Whereas when I attempted to use a GPIO line > and couple that to the UART through the UART device tree fragment (refer to > the above thread for an example), I was not able to toggle the RTS line > with the 8250 serial driver, but only the OMAP serial driver. So as a test > I installed python-serial on my beagleBoard-X15. When I issued > serial_object.setRTS(False/True) which was connected to DE on the 485 chip, > I would see the chip transmit and not transmit using the 8250 driver. But > when using the GPIO line for RTS, I could only switch between transmit and > receive on the 485 chip when I compiled in and used the OMAP drivers. > > On Monday, March 5, 2018 at 7:12:50 AM UTC-6, erc...@gmail.com wrote: >> >> Hi Micka, >> >> We are having lots of trouble with RS485 with Kernel 4.4.x or kernel >> 3.8.13. >> >> Is there any guideline about how to use OMAP rather than 8250 or can you >> please explain the steps how can we do that? >> >> On Tuesday, April 26, 2016 at 10:00:19 AM UTC+3, Micka wrote: >>> >>> I dont know about 8250, but omap work well. I'm more confident about >>> omap handling the gpio than the driver 8250. >>> >>> I've been using omap for rs485 since the driver 3.8 and I've nothing to >>> complain about. >>> >>> I will also switch to the driver 8250 when it will be ready ( a lot of >>> test need to be done ) >>> >>> >>> Micka, >>> >>> >>> >>> Le mar. 26 avr. 2016 08:05, 'Artur Festyn' via BeagleBoard < >>> beagl...@googlegroups.com> a écrit : >>> Hi Micka. no ttyO, its 8250 driver. shouldn't 4.5 kernel work after these patches are applied or is it still too early? -rw-r--r-- 1 root root 1440 Apr 21 12:26 0001-tty-serial-8250-fix-RS485-half-duplex-RX.patch -rw-r--r-- 1 root root 8243 Apr 21 12:26 0002-tty-serial-8250-make-UART_MCR-register-access-consis.patch -rw-r--r-- 1 root root 2743 Apr 21 12:26 0003-serial-mctrl_gpio-add-modem-control-read-routine.patch -rw-r--r-- 1 root root 1347 Apr 21 12:26 0004-serial-mctrl_gpio-add-IRQ-locking.patch -rw-r--r-- 1 root root 7924 Apr 21 12:26 0005-tty-serial-8250-use-mctrl_gpio-helpers.patch the last one clearly states that use of any gpio as rts should be possible 2016-04-26 6:54 GMT+01:00 Micka : > Can you show me what this command show : > > dmesg|grep ttyO* > > I repeat only omap driver work for rs485 > > Le mar. 26 avr. 2016 00:40, 'Artur Festyn' via BeagleBoard < > beagl...@googlegroups.com> a écrit : > >> It is easy and already disabled. >> My question is about RS485 and custom gpio to drive DE pin of RS485 >> chip. >> >> >> 2016-04-25 23:22 GMT+01:00 evilwulfie : >> >>> read this. disabling I2C2 is not as easy as using an overlay >>> if you are not using capes sure but IMHO is always best to leave the >>> default things enabled and just work with overlays >>> >>> >>> http://www.embedded-things.com/bbb/enable-canbus-on-the-beaglebone-black/ >>> >>> >>> >>> >>> >>> On 4/25/2016 2:09 PM, 'Artur Festyn' via BeagleBoard wrote: >>> >>> Honestly I do
[beagleboard] Re: Bluetooth Low Energy Beacon performance
Hi, Do you have wifi enabled and are you using it? The most likely explanation is that the antenna is shared between the Wifi and BLE radios. So when it is busy doing wifi it cannot be listening on BLE for advertisements. As the WL18xx does not know when advertisements will be taking place it cannot schedule the BLE Rx windows for scanning. As soon as you are in a BLE connection the BLE RF activity is following a known schedule and so all BLE activity can be scheduled. In conclusion the best way to get BLE scanning performance is to have Wi-Fi disabled. Iain On Tuesday, 6 March 2018 03:53:42 UTC, jeffr...@gmail.com wrote: > > I am attempting to use the beaglebone black wireless to receive Bluetooth > Low Energy (BLE) advertisements. I am utilizing a mobile device to > transmit BLE advertisements at a 10 Hz frequency. I am comparing the > performance of the beaglebone black wireless to other comparable boards and > receive unexpectedly terrible results. The beagleboard was only able to > capture between 20%-30% of the advertised beacons. With the superior > hardware on the beaglebone black wireless, I would expect the performance > to be as good or better than the raspberry pi 3. I have tried several > versions of the Debian OS with no change in performance. I have also tried > changing the cpu frequncy to ondemand without any performance > enhancements. Is there anything that someone would suggest doing. I have a > strong feeling that it has to do with the the wireless card driver not > being fully developed. If there are any suggestions please feel free to > respond. > Thank You > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/57a9b4ea-fcb6-4780-8191-dcd0a4d03ceb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can BBB Wireless update image in a bare metal device like ARM M0+(has a bootloader)
On Mon, Mar 5, 2018 at 2:29 PM, wrote: > > I have a FRDM-KV11Z (dev board for NXP ARM M0+ MCU) and a Beaglebone > black Wireless (ARM Cortex A8). I am trying to get a bootloader up and > running in FRDM-KV11Z device so that we could program it using > Beaglebone(BBB). The connection between BBB and KV11Z is using a RJ45 > cable. The communication protocol used is UART with RTS-only. > > My idea is to get the KV11Z device change its application whenever BBB > gets a updated version of app code( from the cloud). Can you guide me > through the development process I will need to follow to get this working? > I appreciate if you could share any document related to this. > It's not clear what level of help you're asking for. Do you know how to update firmware on your Freedom board from your desktop computer? I don't remember the NXP bootloader details myself, but I don't think it's very complicated, and probably uses a USB port, right? Basically, you'd do the same thing from the BBB as you are doing when working on your desktop. The BBB has USB host ports so you should be able to talk to FRDM's bootloader as well as serial emulation over this USB. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAC%3D1GgEY1_y4XdFF_Zus0W7VMsqiqqC%3DiFis1YHm3H4-Gqmdvw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: RS485 support for BBB
Hi there. Got your PM..
Regarding the defconfig changes to enable the OMAP.
I THINK your prescribed changes to the defconfig file are correct, just
please refer to the above thread,
https://groups.google.com/forum/#!topic/beagleboard/JGIm0Ej6jDI.
You're going to need to tune the defconfig, and the re-build and deploy the
kernel until you see /dev/ttyO*. And then you'll need to check that the
serial device of interest is enabled. You can go into /sys/class/tty/ttyO*
directory and start looking at things like irq #'s to make sure they're
non-0. Not sure how this changes if DMA is enabled.
One interesting thing. If you want to enable UARTs (beyond #6), I found
that with the OMAP driver, all you need to do is enable it in the device
tree fragement. But with the 8250 driver, you need to change another
defconfig define to increase the total # of UARTs..
Regarding updating/building the kernel on the BBB (??
/opt/scripts/tools/update_kernel.sh??), I'm afraid I still haven't done
this or used Robert's image Builder on target. I hope to get some practice
with that next-week. Then I can hopefully speak more intelligently on that.
To build/re-build the kernel, I follow the instructions on how to fetch and
build the kernel,
here, https://eewiki.net/display/linuxonarm/BeagleBoard-X15.
And then, inintially I call root_kernel_build_dir/build_kernel.sh,
allow makemenuconfig to run.
Set the defconfig options I need.
Then every subsequent build, I think you can call
root_kernel_build_dir/tools/rebuild.sh which will leave your
defconfig/.config file in tact.
I promise I won't tell anyone if you modify, KERNEL/.config directly, but I
think this is not the recommended procedure.
Regarding and updated OS for 485, I'm not aware of any. If you compile in
the OMAP serial driver, then the driver has a 485 interface, so you can add
lines to the respective UART's fragment such as the following and the
referenced gpio line in the fragement below will toggle when you do
setRTS(True/False) in python-serial.
This won't work with the 8250 serial driver. However, what will work with
the 8250 driver is if you allocate a dedicated uart5_rtsn line and then tie
that to your DE input on a 485 chip, you will be able to call
setRTS(True/False) from Python (and I assume C/C++/C#), and the line will
actually change state. But I don't think the 8250 driver will handle the
automatic flow control with intercharacter timeouts needed for full
hardware flow control. I haven't tried this.
Also another question you need to ask is for 485, are you using 2-wire or
4-wire RS485 chips. If 4-wire, then, depending on your application, you
maybe able to tie the DE signal high and allow the 485 chip to operate in
full-duplex mode. If 2 wire, then presumably, someone will need to toggle
the DE line to multiplex internally the BBB UART's Rxd vs Txd onto the
differential signal end of the 485 chip. For our purposes, since our
application knows when its transmitting vs receiving, the application can
toggle the RTS line around transmit and receive sentences/packets.
Another thing I don't yet know. Say that your application program refuses
to add toggling of the RTS line between transmit and receive packets and
s/he wants you to handle this at the driver level (which is understandable
given application software portability requirements). What all do you need
to implement for the OMAP serial driver and the UART to handle automatic
toggling of the RTS line so that the driver "senses" when the transmitter
is done transmitting and can then toggle RTS/CTS to allow the other party
to speak on the half-duplex line? Do you need to wire up DE to UARTn_RTS
and DE_INV to UARTn_CTS or can you leave CTS floating (or tie it to a known
state if your mux mode permits)? If someone has tried this (granted
hardware flow control is probably an anachronism), please chime in. But
the test data probably exists somewhere in this thread or a related thread
on this forum.
&uart5 {
pinctrl-names = "default";
pinctrl-0 = <&uart5_pins>;
status = "okay";
rts-gpio = <&gpio5 8 GPIO_ACTIVE_HIGH>;
rs485-rts-active-high;
rs485-rts-delay = <0 0>;
linux,rs485-enabled-at-boot-time;
};
On Tuesday, March 6, 2018 at 8:12:41 AM UTC-6, Jeff Andich wrote:
>
> p.s. - I'm currently running a patched version of kernel version
> 4.4.110... for the BB-X15, but I believe the underlying principles are the
> same between the BBB and BB-X15 with respect to UART (except for the pinmux
> which is more straight forward to configure in BBB world).
>
> On Monday, March 5, 2018 at 9:12:06 AM UTC-6, Jeff Andich wrote:
>>
>> Hi,
>>
>> There have been a number of posts on here on how to switch between the
>> 8250 and OMAP drivers. Above in this same thread, Robert showed which
>> defines within the kernel defconfig file to change, and I experimented with
>> this and was able to see a
[beagleboard] create sd card to flash eMMC and affect /etc/fstab
I have a project running on eMMC with a custom entry in the /etc/fstab (intended to mount a blank SD card on boot). So I use the */opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh *script to create an sd flasher. Then I turn around and flash the eMMC with it, ssh login, and find that /etc/fstab no longer has my custom entry in it. How can I resolve this? Or do I just have to flash every card and ssh in to add that custom fstab entry for every eMMC I flash? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/5fc2364a-883a-47dc-9f9e-4a25d0a88c3c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] create sd card to flash eMMC and affect /etc/fstab
On Tue, Mar 6, 2018 at 3:42 PM, Troy Weber wrote:
> I have a project running on eMMC with a custom entry in the /etc/fstab
> (intended to mount a blank SD card on boot).
>
> So I use the
> /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh
> script to create an sd flasher. Then I turn around and flash the eMMC with
> it, ssh login, and find that /etc/fstab no longer has my custom entry in it.
>
> How can I resolve this? Or do I just have to flash every card and ssh in to
> add that custom fstab entry for every eMMC I flash?
'today' add your custom entries right after this line:
echo "debugfs /sys/kernel/debug debugfs defaults 0 0" >>
${tmp_rootfs_dir}/etc/fstab
https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/functions.sh#L972
Regards,
--
Robert Nelson
https://rcn-ee.com/
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/CAOCHtYgf2HjDzmqTYNFJ_N-bu472bRsaApb%2B88JDgy5%2BwJW%3D9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Weird behaviour: input/output error and no commands after few minutes
Same problems on new Beagle Bone Blue. Unpacked, powered up, worked like 5 minutes until IO errors. Kind regards, Bm On Wednesday, August 23, 2017 at 11:49:22 PM UTC+2, Jeffrey Obadal wrote: > > I don't have my logs with me, but I believe mine looked pretty much just > like that. Unfortunately both of mine spits out errors just trying to > update Debian. Using an SD Card delays the error a little longer, but > eventually it gets some disk access errors and goes into read only mode. I > wonder if there is a way to slow down read/write and if that would fix it. > I mean, besides updating it I don't really care about writing much after > that. > > I contacted the RMA email on the beagleboard site, and Arrow. Never heard > back from beagleboard. Arrow said they would have the RMA people contact > me, been a week already. I bought this for testing until their new X15 > comes out, but at this rate I think I'll wait a major revision of X15 after > it first comes out. > > Jeff > > On Tue, Aug 22, 2017 at 7:34 PM, > wrote: > >> I also am having the same issue. I thought it was broken hardware so I >> bought a new one and the same thing happened again. I found that I can >> usually induce the errors by transferring a large amount of files using >> scp. >> >> I'm going to check UART0 for additional information once I get the >> cabling set up. I really hope this gets patched soon, it's a very >> irritating bug. >> >> One time I was able to get some debug information before the I/O errors >> consumed everything, not sure if it's helpful in any way. >> >> Here's the last few lines given from dmesg >> >> [14188.582576] wlan0: RX AssocResp from 06:18:d6:57:8c:90 (capab=0x431 >> status=0 aid=2) >> [14188.593611] wlan0: associated >> [14188.641133] wlcore: Association completed. >> [25043.096569] hrtimer: interrupt took 136276 ns >> [30864.563462] mmcblk1: error -110 sending status command, retrying >> [30864.597101] mmcblk1: error -110 sending status command, retrying >> [30864.638167] mmcblk1: error -110 sending status command, aborting >> [30864.644451] blk_update_request: I/O error, dev mmcblk1, sector 3487760 >> [30864.651172] blk_update_request: I/O error, dev mmcblk1, sector 3487768 >> [30864.657840] blk_update_request: I/O error, dev mmcblk1, sector 3487776 >> [30864.664510] blk_update_request: I/O error, dev mmcblk1, sector 3487784 >> [30864.671146] blk_update_request: I/O error, dev mmcblk1, sector 3487792 >> [30864.677767] blk_update_request: I/O error, dev mmcblk1, sector 3487800 >> [30864.684382] blk_update_request: I/O error, dev mmcblk1, sector 3487808 >> [30864.690996] blk_update_request: I/O error, dev mmcblk1, sector 3487816 >> [30864.697652] blk_update_request: I/O error, dev mmcblk1, sector 3487824 >> [30864.708291] Aborting journal on device mmcblk1p1-8. >> [30864.769510] mmcblk1: error -110 sending status command, retrying >> [30864.817684] mmcblk1: error -110 sending status command, retrying >> [30864.865245] mmcblk1: error -110 sending status command, aborting >> [30864.871498] blk_update_request: I/O error, dev mmcblk1, sector 8192 >> [30864.877900] Buffer I/O error on dev mmcblk1p1, logical block 0, lost >> sync page write >> [30864.886607] EXT4-fs error (device mmcblk1p1): >> ext4_journal_check_start:56: Detected aborted journal >> [30864.895940] EXT4-fs (mmcblk1p1): Remounting filesystem read-only >> [30864.902042] EXT4-fs (mmcblk1p1): previous I/O error to superblock >> detected >> [30865.101035] mmcblk1: error -110 sending status command, retrying >> [30865.115710] mmcblk1: error -110 sending status command, retrying >> >> >> And here are the last few lines of /var/log/syslog >> >> >> Aug 4 20:37:33 beaglebone connmand[794]: ntp: time slew -0.003904 s >> Aug 4 20:37:33 beaglebone rsyslogd-2007: action 'action 17' suspended, >> next retry is Fri Aug 4 20:39:03 2017 [try http://www.rsyslog.com/e/2007 >> ] >> Aug 4 20:39:04 beaglebone rsyslogd-2007: action 'action 17' suspended, >> next retry is Fri Aug 4 20:40:34 2017 [try http://www.rsyslog.com/e/2007 >> ] >> Aug 4 20:40:35 beaglebone rsyslogd-2007: action 'action 17' suspended, >> next retry is Fri Aug 4 20:42:05 2017 [try http://www.rsyslog.com/e/2007 >> ] >> Aug 4 20:42:14 beaglebone rsyslogd-2007: action 'action 17' suspended, >> next retry is Fri Aug 4 20:43:44 2017 [try http://www.rsyslog.com/e/2007 >> ] >> Aug 4 20:43:56 beaglebone rsyslogd-2007: action 'action 17' suspended, >> next retry is Fri Aug 4 20:45:26 2017 [try http://www.rsyslog.com/e/2007 >> ] >> Aug 4 20:45:27 beaglebone rsyslogd-2007: action 'action 17' suspended, >> next retry is Fri Aug 4 20:46:57 2017 [try http://www.rsyslog.com/e/2007 >> ] >> Aug 4 20:46:57 beaglebone rsyslogd-2007: action 'action 17' suspended, >> next retry is Fri Aug 4 20:48:27 2017 [try http://www.rsyslog.com/e/2007 >> ] >> Aug 4 20:48:32 beaglebone rsyslogd-2007: action 'action 17' suspended, >> next retry is Fri Aug 4 20:50:02 2017 [try http:
[beagleboard] Re: interfacing the Sterling LWB module to the BeagleBone Black
Hey Mike did you ever solve your problem? We are trying to do similar to you except using a raspberry pi CM3. Currently confused by their linux integration guide. Specifically the way they set up their cross compiling environment and use the KLIB_BUILD env variable. Is that where you got stuck as well? Anyway, I hope you met some success in your work. Have a good one, - Cory On Saturday, February 3, 2018 at 7:04:23 AM UTC-8, Mike Wood wrote: > > We are developing a new product around the BeagleBone Black that uses the > Sterling LWB Wi-Fi/Bluetooth module. LSR supplies some rather convoluted > information on their website to build the drivers for this product in a > Linux environment. Following their steps yields results completely > different from their guidance. Has anyone ever attempted to integrate this > radio into a BeagleBone Black project? If so did you get it to work and how > did you accomplish it? > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e1dcf755-6811-4a52-a751-2da66d232b81%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] create sd card to flash eMMC and affect /etc/fstab
Thank you!
On Tuesday, March 6, 2018 at 1:46:01 PM UTC-8, RobertCNelson wrote:
>
> On Tue, Mar 6, 2018 at 3:42 PM, Troy Weber > wrote:
> > I have a project running on eMMC with a custom entry in the /etc/fstab
> > (intended to mount a blank SD card on boot).
> >
> > So I use the
> >
> /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh
> > script to create an sd flasher. Then I turn around and flash the eMMC
> with
> > it, ssh login, and find that /etc/fstab no longer has my custom entry in
> it.
> >
> > How can I resolve this? Or do I just have to flash every card and ssh in
> to
> > add that custom fstab entry for every eMMC I flash?
>
> 'today' add your custom entries right after this line:
>
> echo "debugfs /sys/kernel/debug debugfs defaults 0 0" >>
> ${tmp_rootfs_dir}/etc/fstab
>
>
> https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/functions.sh#L972
>
>
> Regards,
>
> --
> Robert Nelson
> https://rcn-ee.com/
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/58eb0e89-203a-4a6b-b913-e032ce37b2b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Is it possible to save an image created on the SD card to the PC?
So I'm relatively comfortable using *dd* on a linux system to copy the contents of an sd card to an image file. Previously I had run the command... sudo dd status=progress bs=512 count=$((8192+6955008)) if=/dev/disk4 of= /path/to/image/storage/`date +%Y-%m-%d`_image_name.img ... and that usually does the trick. However, I'm a bit confused because the count value isn't lining up with the current card specs. I just created a flasher on a 16GB card using the aforementioned script. But when I insert that sd card to my development laptop and I run... sudo fdisk -l /dev/sdb ... I get the following output: $ sudo fdisk -l /dev/sdb [sudo] password for troyw: Disk /dev/sdb: 14.9 GiB, 15931539456 bytes, 31116288 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x55866915 Device Boot Start End Sectors Size Id Type /dev/sdb1 * 8192 31116287 31108096 14.9G 83 Linux My confusion is that I recall the card should be 8192+6955008 sectors long, not 31116287 sectors long... So what happened? Did something change recently in the aforementioned flasher-making script? Does it now automatically expand to the sd card size? Do I need to re-partition the */dev/sdb* device and *then* use the *dd* command? How would I determine how much I can shrink the partition without losing the data on the image? Any help would be greatly appreciated. On Monday, February 5, 2018 at 7:17:17 AM UTC-8, Dennis Lee Bieber wrote: > > On Mon, 5 Feb 2018 04:41:12 -0800 (PST), > 82am...@gmail.com declaimed the following: > > > > > >My problem is that I would like to save the images that were created in > the > >SD card in the PC, in order to have several releases saved. When I insert > >the SD card into the PC, I try to open it to make a copy of the image, I > >get a message saying that it can not be opened and also asks if I want to > >format the SD card. > > > > M$ Windows OS? > > >Someone could help me to know how I can copy those images to my PC to > save > >them. > > > > The (apparently deprecated) Win32DiskImager program appears to > have the > ability to move in both directions -- so can generate an image file by > reading an SD card (Etcher appears to only support writing an image file > TO > SD card). > > However, as I recall, it was rather sensitive to the card used -- > I'd > tried to duplicate a card (both nominally 8GB) but the target card > (another > brand) was just different enough that the image could not be written (I > think the target card reserved more blocks for overhead, with the result > the original image was now too large for the target). > -- > Wulfraed Dennis Lee Bieber AF6VN > wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/ > > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1f3c92e7-48ab-49c5-b1ab-fc9f2382228e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Networking on Pocket with USB, WTF?
First the basics. I have a beagle pocket. It's connected to a Macbook Pro, running Sierra (10.12.6). I connect using a USB cable and after a short delay I get two entries in my networking pane. BeagleBone (192.168.7.1) and BeagleBone 2(192.168.6.1). I have internet sharing turned off. At this point I am able to successfully ssh to my board and login. I use: $ssh debian@beaglebone.local *debian@beaglebone*:*~*$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.6.0 0.0.0.0 255.255.255.252 U 0 00 usb1 192.168.7.0 0.0.0.0 255.255.255.252 U 0 00 usb0 *debian@beaglebone*:*~*$ ifconfig lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 1 (Local Loopback) RX packets 480 bytes 34400 (33.5 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 480 bytes 34400 (33.5 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 usb0: flags=4163 mtu 1500 inet 192.168.7.2 netmask 255.255.255.252 broadcast 192.168.7.3 inet6 fe80::6264:5ff:fe45:1b63 prefixlen 64 scopeid 0x20 ether 60:64:05:45:1b:63 txqueuelen 1000 (Ethernet) RX packets 392 bytes 83626 (81.6 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 305 bytes 78511 (76.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 usb1: flags=4163 mtu 1500 inet 192.168.6.2 netmask 255.255.255.252 broadcast 192.168.6.3 inet6 fe80::6264:5ff:fe45:1b66 prefixlen 64 scopeid 0x20 ether 60:64:05:45:1b:66 txqueuelen 1000 (Ethernet) RX packets 146 bytes 38517 (37.6 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 111 bytes 24192 (23.6 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Any attempt to turn the mac's internet sharing on, causes the two networking entries BeagleBone (192.168.7.1) and BeagleBone 2(192.168.6.1) to stop woking. BeagleBone goes red and reports not connected, BeagleBone 2 stays green but the SSH connection freezes. Communications with the board dies. The only solution at this point is to disconnect the board from the USB cable and turn off internet sharing and then reconnect the board on USB. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/133ecde8-4eda-4150-b553-35e215b58147%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] BeagleBone Blue: No SSH, so trying to get WiFi up via serial link (w/ console image)
Can't use SSH, so I'm trying to get the BeagleBone's WiFi up via serial link (w/ console image). My failing method: Create /etc/network/interfaces: iface wlan0 inet dhcp wpa-ssid "My_WiFi_SSID" wpa-psk "My_WiFi_Password" Enter commands: sudo ip link set wlan0 up sudo ifup wlan0 Resulting output: Internet Systems Consortium DHCP Client 4.3.5 Copyright 2004-2016 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Listening on LPF/wlan0/f4:5e:ab:3b:e4:72 Sending on LPF/wlan0/f4:5e:ab:3b:e4:72 Sending on Socket/fallback DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 18 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 18 No DHCPOFFERS received. No working leases in persistent database - sleeping. I notice that `sudo ip link set wlan0 up` isn't working (`ip link` shows that wlan0 status is still DOWN). I'm stuck. Please help! 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/305ee4ea-1d16-4491-8184-0c708ea523ce%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Micro sd card in BBB
Hello, I am a newbie to Beaglebone black. Successfully completed the steps of booting BBB with the latest debian images, installing the drivers in windows and establishing network connectivity to BBB through usb. But, actually I want to launch debian from the eMMC, but which is now launching from the micro SD card. How can this be fixed? i.e., launching debian from the eMMC and not from the micro SD card. BBB should read micro SD as external storage only .It should not boot from it. Regards, Rakesh -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a43b00d2-68eb-4f33-a057-ed6198b4347c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
