[beagleboard] Re: WiFi data rates on Beaglebone Blue

[Karthik Veeramalai]

Hi Juliusz,

I have both the antennas plugged in and will try it out with the changes 
you mentioned. I'll post the results soon. 

Thanks and Regards,
Karthik 

On Friday, 7 April 2017 07:30:45 UTC+5:30, Juliusz Chroboczek wrote:
>
> > My speeds over scp have been consistently below 2MB/s. Is this normal? 
>
> That's 20Mbit/s, which is perfectly respectable for a 1x1 interface in 
> a 20MHz channel. 
>
> If you've plugged both antennas in, you can switch the chip to 2x2 mode 
> by creating a file /etc/modprobe.d/wl18xx.conf with the following: 
>
>   options wl18xx ht_mode=default 
>
> This should roughly double the throughput, but only if both antennas are 
> plugged in. 
>
> -- Juliusz 
>
>

-- 
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/ee8d2fc8-b355-4607-8c41-16da105f3286%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: SSH with internet through USB not working for minimal image of BBB

[sajeevan k]

Hi Dennis Lee,

Q: Did you build the added modules has kernal built-in objects, or as 
loadable objects ?

A: I was building the added modules as loadable objects.
Also I am working on systemctrl and initd systems.

Initially I included all the loadable modules(g_mass_storage, 
usb_f_mass_storage and g_multi) in
/etc/modules-load.d/modules.conf

Then after reboot it is showing the following message:

[FAILED] Failed to start Load Kernel Modules
see 'systemctl status systemd-modules-load.service'   for details.

systemctl status systemd-modules-load.service shows the following errors

debian@arm:~$ systemctl status systemd-modules-load.service
● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; 
static; ven
   Active: failed (Result: exit-code) since Sat 2016-05-21 22:31:30 UTC; 10 
mont
 Docs: man:systemd-modules-load.service(8)
   man:modules-load.d(5)
 Main PID: 103 (code=exited, status=1/FAILURE)

Warning: Journal has been rotated since unit was started. Log output is 
incomple
lines 1-8/8 (END)...skipping...
● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; 
static; ven
   Active: failed (Result: exit-code) since Sat 2016-05-21 22:31:30 UTC; 10 
mont
 Docs: man:systemd-modules-load.service(8)
   man:modules-load.d(5)
 Main PID: 103 (code=exited, status=1/FAILURE)

Warning: Journal has been rotated since unit was started. Log output is 
incomple
~



Q: Did you recreate the, uhm from memory, initramfs (or whatever the files 
loaded by u-boot are called) containing your added modules?

I didn't understand what is meant by uhm. Googling also didn't provide me 
the results.
Please explain it.

After I added the modules, the added modules were available in 
/proc/modules, which  indicates they are active.
But after reboot it is not availble in /proc/modules 

Also 

find /lib/modules/$(uname -r) -type f -name \*.ko  gives all the modules 
including 
g_mass_storage, usb_f_mass_storage and g_multi. I think this is the list of all 
modules built.

I am trying with systemctrl and initd systems. Please inform if I am missing 
something.
Thanks in advance for the help.


Thanks & Regards,
Sajeevan.K


On Tuesday, April 18, 2017 at 7:00:54 PM UTC+5:30, Dennis Lee Bieber wrote:
>
> On Mon, 17 Apr 2017 23:30:50 -0700 (PDT), sajeevan k 
>  declaimed the 
> following: 
>
>
> > 
> >So I reboot and checked. But after rebooting, all this newly added 
> modules 
> >disappears.   
> > 
> > 
> >How can I include the modules in such a way that, it is available even 
> >after reboot? 
> > 
>
> Again, we are beyond my actual experience -- this is just an 
> hypothesis... 
>
> Did you recreate the, uhm from memory, initramfs (or whatever the 
> files 
> loaded by u-boot are called) containing your added modules? Did you build 
> the added modules has kernal built-in objects, or as loadable objects -- 
> the latter would require running some command during start-up (systemctrl? 
> my experience is still the initd system)? 
>
> >I feel, if the Beaglebone drive appears, in Ubuntu Host, if BBB connect 
> to 
> >it through USB cable, then ssh deb...@192.168.7.2  also 
> will work. But so 
> >far  Beaglebone drive does not appear. 
> > 
>
> Even having the file system is no guarantee... file system and 
> network 
> interfaces are separate enumerations on the USB bus. 
> -- 
> 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/e8a60d85-4935-4b16-b394-0bb5f5e3ca3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] As much as possible GPIO Outs . What should I do ?

[Immo]

Hi, I need the maximum possible GPIOs out of the BBB.
I'll direct connect a optocopler to decouple the bbb form the external 
devices.
But my first tries with P8 Pin 3-46 wher enot successful may be my overlay 
file is a bit to big. Or do somebody the same.? How about the boot pins ? 
If I use them as output do I have to pull them down anyway ?

Immo

-- 
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/7633f0b2-aa5c-4750-82b5-93695f2a9bec%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

[Robert Nelson]

On Wed, Apr 19, 2017 at 2:38 PM, Mark A. Yoder  wrote:
> The big picture is:  I'd like to use these in a workshop and the the
> participants play all they want.  Once we are done I want to run one command
> to reset everything.
>
> I can't count on having internet, so a local git repo sounds like a good
> idea.

Okay give the bone101 package update a shot:

sudo apt update ; sudo apt upgrade

1: backup old example folder:

https://github.com/rcn-ee/repos/blob/master/debian-9-bone101/suite/stretch/debian/preinst#L3-L9

2: init example folder as a git repo, so it's initial state is always set:

https://github.com/rcn-ee/repos/blob/master/debian-9-bone101/suite/stretch/debian/postinst#L51-L58

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/CAOCHtYjt8rX%2Bjvqr6iQ%3D5CwFurcT1oHrG77JG4Bov6Oty%2BeFzA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Newbie Question Using BBB for Telemetry

[William Hermans]

There is another way to go about this bit is slightly more complex, and
would require an additional "server" somewhere. This server could be
another embedded Linux system if you so wished. Such as a beaglebone.

But basically how this works if you have an MQTT broker running locally,
with the MQTT subscriber( the remote beaglebone ) out in the wild
somewhere. The MQTT protocol while technically not very secure. Can be made
very secure if some serious thought is put into how you architect your
complete system. MQTT works by using a publish, and subscribe model. So one
can pretty much bullet proof how a publisher, and subscriber interact with
one another.

E.G. The Broker acts as a Publisher and Subscriber as well as does the
remote system. So the local, and remote system each have their respective
Published, and subscribed values. Which makes it very hard for "The man in
the middle" attacks, and probably impossible for input injection.

Here's a pretty good hackaday article on MQTT:
http://hackaday.com/2016/05/09/minimal-mqtt-building-a-broker/

So this is actually a part of a set of articles by the same person I
believe. But this first article gives a pretty good overview of MQTT, and
the utilities available to Linux( debian ). Technically, you could even
write a set of shell scripts to accomplish what you want. But personally
I'd probably rather at least wrap these utilities from within another high
level language. Maybe even just use their API, and write my own code in C .
. . YMMV.

After saying all of the above however. You'd probably want to completely
lock your remote and lcoal system down completely, and avoid using wireless
or bluetooth on either end. To be the most secure.

-- 
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/CALHSORo0Q6ygt%3D8VTu6scmcEUx7iT6yEXWTpkcAHE1%2B34y0cEQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Newbie Question Using BBB for Telemetry

[William Hermans]

I am a programmer, and have hands on with doing a few projects that fall
into this category. What you're attempting to do does not sound very hard
at all. But it could turn out to be fairly complex in nature. Tacking a few
ADC values, GPI value as well as "toggling" a few GPO's is not that hard.
Where it gets complex is in doing this smartly over a web app. By "smartly"
I mean securely.

There is NodeRED, which I've heard is designed for engineers who have
limited or even no programming experience. But, being a programmer, I'm not
really keen on these types of hardware / software abstraction. So I know
very little about it. It may be something for you to look into though.


On Wed, Apr 19, 2017 at 3:17 PM, Ian Tulley  wrote:

> Hi all, first off, I'm not a programmer so the reason for this question. I
> want to see if there is already a BBB application to allow it to be used
> for telemetry and or could be modified for what I need.
>
> I am able to supply an interface board that can go from the headers of the
> BBB to do all the necessary level changes so as not to "destroy" the board
> by over voltage inputs etc.
> This is what I need to do.
>
> Analogue
> DC Voltage measurements in the ranges of 9-15V and 44-55V (multiple inputs)
> DC Amperage measurements in the ranges of 2-20A and 40-60A (multiple
> inputs)
> Temperature input (multiple)
>
> Digital In
> Again multiple inputs for an On or Off state
>
> Digital Out
> Multiple out for switching relays, depending on both Analogue and Digital
> input levels.
>
> Be able to display the measurements and some control of outputs etc via a
> Web Page.
>
> Hoping someone can help
>
> Regards
> Ian
>
> --
> 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/31a143f5-6625-4eb3-b70a-2bbbd0c8d883%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrt_KhNyGqCgG5BFkLjnv%2BZ%3D_KZh1LHR--%2B6OZM2_t64g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Newbie Question Using BBB for Telemetry

[Ian Tulley]

Hi all, first off, I'm not a programmer so the reason for this question. I 
want to see if there is already a BBB application to allow it to be used 
for telemetry and or could be modified for what I need.

I am able to supply an interface board that can go from the headers of the 
BBB to do all the necessary level changes so as not to "destroy" the board 
by over voltage inputs etc. 
This is what I need to do.

Analogue
DC Voltage measurements in the ranges of 9-15V and 44-55V (multiple inputs)
DC Amperage measurements in the ranges of 2-20A and 40-60A (multiple inputs)
Temperature input (multiple)

Digital In
Again multiple inputs for an On or Off state

Digital Out
Multiple out for switching relays, depending on both Analogue and Digital 
input levels.

Be able to display the measurements and some control of outputs etc via a 
Web Page.

Hoping someone can help

Regards
Ian 

-- 
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/31a143f5-6625-4eb3-b70a-2bbbd0c8d883%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

[William Hermans]

Sorry, I get into thinking about some things, and forget the minor details
of other things. So, dd will not work directly on a directory per se.
Technically dd can be used on single files, but that's a rather difficult
way of going about things. To clarify: Using dd on a single directory, that
directory would have to be on it's own block device. e.g. You'd need to
mount the cloud9 directory form it's own /dev/sdX device. However, you
could also use tar( whcih might be easier ) with I think it's the -P flag
option to preserve permissions. Double check that, I'm going form pure
memory.

On Wed, Apr 19, 2017 at 2:29 PM, William Hermans  wrote:

> Just a quick worklog to give an idea of how you set this up and how it
> works. Of course, you may want todo things a little differently. It depends
> on if you want to keep the cloud9 directory "updated" Meaning over time
> maybe updates have updated the files, so perhaps one could make a fresh img
> file very time the cloud9 directory is mounted for use. Perhaps that part
> could be done in memory, but keep in mind once the board loses power, that
> stored "data" will also be lost. Which is why I think the best way to go
> about things would be to store the directory structure we don't care about
> in memory.
>
> Also keep in mind that this is just an example, and the files I'm
> demonstrating with have nothing to do with cloud9. The overall concept
> however should be solid. As such, you may need to double check permissions
> etc. But if you use dd to create your image, directory structure along with
> file permissions should remain intact.
>
> *Load the zram kernel module:*
> root@wgd:~# *modprobe zram zram_num_devices=1*
>
> *Test to make sure driver module loaded:*
> root@wgd:~# *lsmod |grep zram*
> zram   25049  0
> zsmalloc   13745  1 zram
> lz4_compress3334  1 zram
>
> Notice here that zram is using the lz4 compression algorithm. This can be
> changed.
>
> *Set the zram memory constraints:*
> root@wgd:~# *echo '256M' > /sys/block/zram0/disksize*
> root@wgd:~# *echo '128M' > /sys/block/zram0/mem_limit*
>
> *Make a file system on our ramdisk:*
> root@wgd:~# *mkfs.ext4 /dev/zram0*
> mke2fs 1.43 (17-May-2016)
> Discarding device blocks: done
> Creating filesystem with 65536 4k blocks and 65536 inodes
> Filesystem UUID: 2a08c7dd-234f-497a-a89b-fe4ecbb78c3f
> Superblock backups stored on blocks:
> 32768
>
> Allocating group tables: done
> Writing inode tables: done
> Creating journal (4096 blocks): done
> Writing superblocks and filesystem accounting information: done
>
> *List directory contents( note" 'testfile' is empty ):*
> root@wgd:~# *ls*
> git  testfile
>
> *Get our current working directory:*
> root@wgd:~# *pwd*
> /root
>
> *Find our ramdisk device:*
> root@wgd:~# *ls /dev |grep zram**
> zram0
>
> *Mount our ramdisk at /root/ ( root's home directory ):*
> root@wgd:~# *mount /dev/zram0 /root*
>
> *The interesting part here is that we're still seeing our original file
> structure:*
> root@wgd:~# *ls*
> git  testfile
>
> *But once we change directory . . . The new structure shows up:*
> root@wgd:~# *cd /root/*
> root@wgd:~# *ls*
> lost+found
>
> *Create a new test file, and test:*
> root@wgd:~# *touch testfile*
> root@wgd:~# *ls*
> lost+found  testfile
> root@wgd:~# *echo "Hello World" > testfile*
> root@wgd:~# *cat testfile*
> Hello World
>
> *Unmount the ramdisk( note: one must change out of the mountpoint before
> unmounting ):*
> root@wgd:~# *cd ..*
> root@wgd:/# *umount /root/*
>
> *Change back into our root home directory and retest:*
> root@wgd:/# *cd ~*
> root@wgd:~# *ls*
> git  testfile
> root@wgd:~# *cat testfile*
> 
>
> On Wed, Apr 19, 2017 at 1:10 PM, William Hermans 
> wrote:
>
>> By the way Mark my last comment was directed at you. But one thing I
>> forgot to mention is that once you unmount the tmpfs directory I mention
>> above, the original directory would be there still. So you'd want to take
>> steps to keep from overwriting files there. I mean you could technically
>> just revert the directory from the img file I suppose, but that would be a
>> minor hassle at best. Also, using the zram tmpfs method i mentioned above
>> would not require chroot at all.
>>
>> On Wed, Apr 19, 2017 at 1:06 PM, William Hermans 
>> wrote:
>>
>>> How about using a chroot ? Basically you keep a chroot image where ever
>>> you want, mount it where ever you want, and just wipe it out for a fresh
>>> start when you need to get back to pristine. I am trying to think what
>>> would be the smartest way to do this as you wouldn't necessarily want to
>>> spend a long time trying to get all this done. Then it may also make better
>>> sense to run this chroot from a tmpfs. So perhaps you copy the content of
>>> the cloud9 directory, into an img file. make a zram tmpfs, then just mount
>>> it over the top of the original cloud9 directory, and extract the img
>>> 

Re: [beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

[William Hermans]

Just a quick worklog to give an idea of how you set this up and how it
works. Of course, you may want todo things a little differently. It depends
on if you want to keep the cloud9 directory "updated" Meaning over time
maybe updates have updated the files, so perhaps one could make a fresh img
file very time the cloud9 directory is mounted for use. Perhaps that part
could be done in memory, but keep in mind once the board loses power, that
stored "data" will also be lost. Which is why I think the best way to go
about things would be to store the directory structure we don't care about
in memory.

Also keep in mind that this is just an example, and the files I'm
demonstrating with have nothing to do with cloud9. The overall concept
however should be solid. As such, you may need to double check permissions
etc. But if you use dd to create your image, directory structure along with
file permissions should remain intact.

*Load the zram kernel module:*
root@wgd:~# *modprobe zram zram_num_devices=1*

*Test to make sure driver module loaded:*
root@wgd:~# *lsmod |grep zram*
zram   25049  0
zsmalloc   13745  1 zram
lz4_compress3334  1 zram

Notice here that zram is using the lz4 compression algorithm. This can be
changed.

*Set the zram memory constraints:*
root@wgd:~# *echo '256M' > /sys/block/zram0/disksize*
root@wgd:~# *echo '128M' > /sys/block/zram0/mem_limit*

*Make a file system on our ramdisk:*
root@wgd:~# *mkfs.ext4 /dev/zram0*
mke2fs 1.43 (17-May-2016)
Discarding device blocks: done
Creating filesystem with 65536 4k blocks and 65536 inodes
Filesystem UUID: 2a08c7dd-234f-497a-a89b-fe4ecbb78c3f
Superblock backups stored on blocks:
32768

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

*List directory contents( note" 'testfile' is empty ):*
root@wgd:~# *ls*
git  testfile

*Get our current working directory:*
root@wgd:~# *pwd*
/root

*Find our ramdisk device:*
root@wgd:~# *ls /dev |grep zram**
zram0

*Mount our ramdisk at /root/ ( root's home directory ):*
root@wgd:~# *mount /dev/zram0 /root*

*The interesting part here is that we're still seeing our original file
structure:*
root@wgd:~# *ls*
git  testfile

*But once we change directory . . . The new structure shows up:*
root@wgd:~# *cd /root/*
root@wgd:~# *ls*
lost+found

*Create a new test file, and test:*
root@wgd:~# *touch testfile*
root@wgd:~# *ls*
lost+found  testfile
root@wgd:~# *echo "Hello World" > testfile*
root@wgd:~# *cat testfile*
Hello World

*Unmount the ramdisk( note: one must change out of the mountpoint before
unmounting ):*
root@wgd:~# *cd ..*
root@wgd:/# *umount /root/*

*Change back into our root home directory and retest:*
root@wgd:/# *cd ~*
root@wgd:~# *ls*
git  testfile
root@wgd:~# *cat testfile*


On Wed, Apr 19, 2017 at 1:10 PM, William Hermans  wrote:

> By the way Mark my last comment was directed at you. But one thing I
> forgot to mention is that once you unmount the tmpfs directory I mention
> above, the original directory would be there still. So you'd want to take
> steps to keep from overwriting files there. I mean you could technically
> just revert the directory from the img file I suppose, but that would be a
> minor hassle at best. Also, using the zram tmpfs method i mentioned above
> would not require chroot at all.
>
> On Wed, Apr 19, 2017 at 1:06 PM, William Hermans 
> wrote:
>
>> How about using a chroot ? Basically you keep a chroot image where ever
>> you want, mount it where ever you want, and just wipe it out for a fresh
>> start when you need to get back to pristine. I am trying to think what
>> would be the smartest way to do this as you wouldn't necessarily want to
>> spend a long time trying to get all this done. Then it may also make better
>> sense to run this chroot from a tmpfs. So perhaps you copy the content of
>> the cloud9 directory, into an img file. make a zram tmpfs, then just mount
>> it over the top of the original cloud9 directory, and extract the img
>> contents into that ramdisk ?
>>
>> On Wed, Apr 19, 2017 at 12:38 PM, Mark A. Yoder 
>> wrote:
>>
>>> The big picture is:  I'd like to use these in a workshop and the the
>>> participants play all they want.  Once we are done I want to run one
>>> command to reset everything.
>>>
>>> I can't count on having internet, so a local git repo sounds like a good
>>> idea.
>>>
>>> --Mark
>>>
>>> On Wednesday, April 19, 2017 at 3:33:01 PM UTC-4, RobertCNelson wrote:

 On Wed, Apr 19, 2017 at 2:26 PM, Robert Nelson 
 wrote:
 > On Wed, Apr 19, 2017 at 1:34 PM, Mark A. Yoder 
 wrote:
 >> Robert:
 >>   It looks like all the files in /var/lib/cloud9/examples are owned
 by
 >> root:cloud9ide and are mode 664. They need to be mode 665, or maybe
 667.
 >>
 

[beagleboard] A question on automatically rebooting if BBB hangs

[Eric Berg]

I'm looking at using a BBB in an embedded system. I have a 555 that I'm 
using as a watchdog which the BBB would reset every so many seconds. If a 
minute goes by and the 555 hasn't received a reset from the BBB then it 
would time out and send a signal (either high or low) to the BBB forcing it 
to reboot itself. Is there a pin on the GPIOs that will allow me to reboot 
the BBB? I noticed there is a sys_reset pin on the BBB. Would driving this 
pin low force a reboot? I've searched on Google for answers to this 
question but I'll be darned if I can find anything other than "push the 
power button".


-- 
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/12b183b5-fb78-46ac-8c97-2b9a5c6b4b14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

[William Hermans]

By the way Mark my last comment was directed at you. But one thing I forgot
to mention is that once you unmount the tmpfs directory I mention above,
the original directory would be there still. So you'd want to take steps to
keep from overwriting files there. I mean you could technically just revert
the directory from the img file I suppose, but that would be a minor hassle
at best. Also, using the zram tmpfs method i mentioned above would not
require chroot at all.

On Wed, Apr 19, 2017 at 1:06 PM, William Hermans  wrote:

> How about using a chroot ? Basically you keep a chroot image where ever
> you want, mount it where ever you want, and just wipe it out for a fresh
> start when you need to get back to pristine. I am trying to think what
> would be the smartest way to do this as you wouldn't necessarily want to
> spend a long time trying to get all this done. Then it may also make better
> sense to run this chroot from a tmpfs. So perhaps you copy the content of
> the cloud9 directory, into an img file. make a zram tmpfs, then just mount
> it over the top of the original cloud9 directory, and extract the img
> contents into that ramdisk ?
>
> On Wed, Apr 19, 2017 at 12:38 PM, Mark A. Yoder 
> wrote:
>
>> The big picture is:  I'd like to use these in a workshop and the the
>> participants play all they want.  Once we are done I want to run one
>> command to reset everything.
>>
>> I can't count on having internet, so a local git repo sounds like a good
>> idea.
>>
>> --Mark
>>
>> On Wednesday, April 19, 2017 at 3:33:01 PM UTC-4, RobertCNelson wrote:
>>>
>>> On Wed, Apr 19, 2017 at 2:26 PM, Robert Nelson 
>>> wrote:
>>> > On Wed, Apr 19, 2017 at 1:34 PM, Mark A. Yoder 
>>> wrote:
>>> >> Robert:
>>> >>   It looks like all the files in /var/lib/cloud9/examples are owned
>>> by
>>> >> root:cloud9ide and are mode 664. They need to be mode 665, or maybe
>>> 667.
>>> >>
>>> >> Mode 667 would let people easily edit the files and experiment.
>>> Though it
>>> >> would also let people mess up the files.
>>> >>
>>> >> How about we have a parallel directory to examples that serves as a
>>> backup.
>>> >> They could all me mode 665 and the examples files would be 667.
>>> >
>>> > The debian user is part of the cloud9ide group, so the 664 should
>>> > work, or do you think it should be 674? so the cloud9ide group can
>>> > execute the file..
>>>
>>> The other issue, that whole directory get's extracted from the bone101
>>> package, so any changes to the package will wipe out that dir.
>>>
>>> Unless we move the examples to github and just create a local git clone?
>>>
>>> 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/ms
>> gid/beagleboard/eaa04298-81a4-4af0-a033-fe369e458cc7%40googlegroups.com
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpDdDFgs8Wj03XW1-RFsc9JOPPNVvcjw_LCe5dEZQT%3D6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

[William Hermans]

How about using a chroot ? Basically you keep a chroot image where ever you
want, mount it where ever you want, and just wipe it out for a fresh start
when you need to get back to pristine. I am trying to think what would be
the smartest way to do this as you wouldn't necessarily want to spend a
long time trying to get all this done. Then it may also make better sense
to run this chroot from a tmpfs. So perhaps you copy the content of the
cloud9 directory, into an img file. make a zram tmpfs, then just mount it
over the top of the original cloud9 directory, and extract the img contents
into that ramdisk ?

On Wed, Apr 19, 2017 at 12:38 PM, Mark A. Yoder 
wrote:

> The big picture is:  I'd like to use these in a workshop and the the
> participants play all they want.  Once we are done I want to run one
> command to reset everything.
>
> I can't count on having internet, so a local git repo sounds like a good
> idea.
>
> --Mark
>
> On Wednesday, April 19, 2017 at 3:33:01 PM UTC-4, RobertCNelson wrote:
>>
>> On Wed, Apr 19, 2017 at 2:26 PM, Robert Nelson 
>> wrote:
>> > On Wed, Apr 19, 2017 at 1:34 PM, Mark A. Yoder 
>> wrote:
>> >> Robert:
>> >>   It looks like all the files in /var/lib/cloud9/examples are owned by
>> >> root:cloud9ide and are mode 664. They need to be mode 665, or maybe
>> 667.
>> >>
>> >> Mode 667 would let people easily edit the files and experiment.
>> Though it
>> >> would also let people mess up the files.
>> >>
>> >> How about we have a parallel directory to examples that serves as a
>> backup.
>> >> They could all me mode 665 and the examples files would be 667.
>> >
>> > The debian user is part of the cloud9ide group, so the 664 should
>> > work, or do you think it should be 674? so the cloud9ide group can
>> > execute the file..
>>
>> The other issue, that whole directory get's extracted from the bone101
>> package, so any changes to the package will wipe out that dir.
>>
>> Unless we move the examples to github and just create a local git clone?
>>
>> 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/eaa04298-81a4-4af0-a033-fe369e458cc7%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrOw85WVnM0OWBg1A-a9xN2aYdt0pb86NXUBSrvnG%2BP2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

[Mark A. Yoder]

The big picture is:  I'd like to use these in a workshop and the the 
participants play all they want.  Once we are done I want to run one 
command to reset everything.

I can't count on having internet, so a local git repo sounds like a good 
idea.

--Mark

On Wednesday, April 19, 2017 at 3:33:01 PM UTC-4, RobertCNelson wrote:
>
> On Wed, Apr 19, 2017 at 2:26 PM, Robert Nelson  > wrote: 
> > On Wed, Apr 19, 2017 at 1:34 PM, Mark A. Yoder  > wrote: 
> >> Robert: 
> >>   It looks like all the files in /var/lib/cloud9/examples are owned by 
> >> root:cloud9ide and are mode 664. They need to be mode 665, or maybe 
> 667. 
> >> 
> >> Mode 667 would let people easily edit the files and experiment.  Though 
> it 
> >> would also let people mess up the files. 
> >> 
> >> How about we have a parallel directory to examples that serves as a 
> backup. 
> >> They could all me mode 665 and the examples files would be 667. 
> > 
> > The debian user is part of the cloud9ide group, so the 664 should 
> > work, or do you think it should be 674? so the cloud9ide group can 
> > execute the file.. 
>
> The other issue, that whole directory get's extracted from the bone101 
> package, so any changes to the package will wipe out that dir. 
>
> Unless we move the examples to github and just create a local git clone? 
>
> 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/eaa04298-81a4-4af0-a033-fe369e458cc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

[Mark A. Yoder]

Yup, mode 674 works.

--Mark

On Wednesday, April 19, 2017 at 3:27:18 PM UTC-4, RobertCNelson wrote:
>
> On Wed, Apr 19, 2017 at 1:34 PM, Mark A. Yoder  > wrote: 
> > Robert: 
> >   It looks like all the files in /var/lib/cloud9/examples are owned by 
> > root:cloud9ide and are mode 664. They need to be mode 665, or maybe 667. 
> > 
> > Mode 667 would let people easily edit the files and experiment.  Though 
> it 
> > would also let people mess up the files. 
> > 
> > How about we have a parallel directory to examples that serves as a 
> backup. 
> > They could all me mode 665 and the examples files would be 667. 
>
> The debian user is part of the cloud9ide group, so the 664 should 
> work, or do you think it should be 674? so the cloud9ide group can 
> execute the file.. 
>
> 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/136d878a-2af8-4b8f-a6db-ac6a4f594597%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

[Robert Nelson]

On Wed, Apr 19, 2017 at 2:26 PM, Robert Nelson  wrote:
> On Wed, Apr 19, 2017 at 1:34 PM, Mark A. Yoder  wrote:
>> Robert:
>>   It looks like all the files in /var/lib/cloud9/examples are owned by
>> root:cloud9ide and are mode 664. They need to be mode 665, or maybe 667.
>>
>> Mode 667 would let people easily edit the files and experiment.  Though it
>> would also let people mess up the files.
>>
>> How about we have a parallel directory to examples that serves as a backup.
>> They could all me mode 665 and the examples files would be 667.
>
> The debian user is part of the cloud9ide group, so the 664 should
> work, or do you think it should be 674? so the cloud9ide group can
> execute the file..

The other issue, that whole directory get's extracted from the bone101
package, so any changes to the package will wipe out that dir.

Unless we move the examples to github and just create a local git clone?

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/CAOCHtYhMoWp9ZfAr27bp1_D8PFokSK6Vc_u4XkNyv1nzcUbmkw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

[Robert Nelson]

On Wed, Apr 19, 2017 at 1:34 PM, Mark A. Yoder  wrote:
> Robert:
>   It looks like all the files in /var/lib/cloud9/examples are owned by
> root:cloud9ide and are mode 664. They need to be mode 665, or maybe 667.
>
> Mode 667 would let people easily edit the files and experiment.  Though it
> would also let people mess up the files.
>
> How about we have a parallel directory to examples that serves as a backup.
> They could all me mode 665 and the examples files would be 667.

The debian user is part of the cloud9ide group, so the 664 should
work, or do you think it should be 674? so the cloud9ide group can
execute the file..

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/CAOCHtYgVb4m-p3qBfAhwAxPU3FFQ_oaxZLL6XF1z%3DK37BUcsGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Debian Testing, un-root athon!!! (2017-04-18)

[Mark A. Yoder]

Robert:
  It looks like all the files in */var/lib/cloud9/examples* are owned by 
*root:cloud9ide* and are mode 664. They need to be mode 665, or maybe 667.

Mode 667 would let people easily edit the files and experiment.  Though it 
would also let people mess up the files.  

How about we have a parallel directory to *examples *that serves as a 
backup.  They could all me mode 665 and the examples files would be 667.

--Mark 

On Tuesday, April 18, 2017 at 9:50:20 PM UTC-4, RobertCNelson wrote:
>
> Hey everyone, 
>
> As we try to move more things from "root" -> "debian"  please give 
> this image a shot: 
>
> https://rcn-ee.net/rootfs/bb.org/testing/2017-04-18/stretch-iot/ 
>
> BBB-blank = eMMC flasher 
> bone- = run from microSD (Please have v2017.05-rc1 or later in eMMC 
> thou: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays 
> ) 
>
> Cloud9 to run as debian: 
>
> add 'User=debian' to the end of /lib/systemd/system/cloud9.service 
>
> and reboot.. 
>
> bonescript, config-pin, adafruit_bbio all "should" work as "debian" 
> user.. export/unexport gpio, pwm's.. (led needs a udev rule) 
>
> Please test and find the corner cases so we can add them to the 
> current udev rule list. 
>
> 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/52405c33-4cc2-4026-ace2-8a21f9a7122c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Explanation of PRU Programming in C

[Greg]

Excellent!  I did a couple of projects with PRU and C code, and this type 
of tutorial is sorely needed.

I would add a link to this:

https://training.ti.com/pru-compiler-tips-tricks

So I wonder how common it is to use a C union and bit selector?
When I first encountered this in the PRU header files, I didn't even think 
it was C code!
In fact, in the information provided by TI in the video and slides, they 
say it is really warped C code.

Regards,
Greg

-- 
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/bb0d76a6-0108-4f8c-a027-5a461c73ec68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Explanation of PRU Programming in C

[Joseph Heller]

Hi guys, after a deep dive, I've found how to program to PRU in C (instead 
of Assembly). Here's my contribution:

http://catch22.eu/omnirobot/beaglebone-pru-c/

Feel free to comment on this forum!

-- 
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/d177d3ae-06c9-471b-9620-f95f81842232%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Bonescript support for Blue?

[Chad Baker]

Drew,
I think that this spreadsheet might have the information that you are 
looking for.

https://github.com/StrawsonDesign/Robotics_Cape_Documentation/blob/master/Revision%20C%20Archive/SD-101C%20Robotics%20Cape%20Header%20Pin%20Table.pdf
Chad


On 4/18/17 8:55 PM, Drew Fustini wrote:

Is there support in Bonescript for the BeagleBone Blue?

For example, would GPIO1_25 map to something in the P8/P9 format?


thanks,
drew



--
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/833ba6ed-d2c9-9c23-0735-2b3bb708a15d%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Understanding boot process of beaglebone black.

[Madhu K]

In the beaglebone, If the eMMC and sd_card do not have bootable media, the
boot proces will go to UART device number 0 to look for a bootable medium
and then to USB0.

Meaning the device( some bootable device) which is connected to UART0 if
UART0 is also not available then it will look for the device which is
connected at USB0 am i right?

On Wed, Apr 19, 2017 at 5:13 PM, arun kumar  wrote:

> UART0 and USB0 are the peripheral communication.
> The number 0 attached to the end is the peripheral number, In modern day
> MPUs there will be multiple communication so we have multiple UART and USB.
> UART-0 and USB-0 are the first  devices with the same protocol. UART-0 and
> USB-0 are the first in the series adn are numbered as 0 accordingly.
>
> In the beaglebone, If the eMMC and sd_card do not have bootable media, the
> boot proces will go to UART device number 0 to look for a bootable medium
> and then to USB0.
> for more details visit the TI wiki  : http://processors.wiki.ti.com/
> index.php/Main_Page
>
> On Monday, February 6, 2017 at 5:39:54 PM UTC+5:30, Madhu K wrote::  All,
>>
>>
>> I want to understand the boot process of beaglebone black. I googled and
>> got an article in "Beyond logic" there is explained boot sequence as
>> follows.
>>
>> By default, the ROM in the Sitara AM3359 will boot from the MMC1
>> interface first (the onboard eMMC), followed by MMC0 (MicroSD), UART0 and
>> USB0.
>>
>> what does UART0 and USB0 meanig here?
>>
>> Regards,
>> Madhu
>>
> --
> 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/3d00b302-bda6-4297-87d7-ba83e8c038b2%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAA2oCOnqUcUSh9gGip433qQKZjhVusB86mH9hhyPZLMqwcGjXg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Understanding boot process of beaglebone black.

[arun kumar]

UART0 and USB0 are the peripheral communication. 
The number 0 attached to the end is the peripheral number, In modern day 
MPUs there will be multiple communication so we have multiple UART and USB.
UART-0 and USB-0 are the first  devices with the same protocol. UART-0 and 
USB-0 are the first in the series adn are numbered as 0 accordingly. 

In the beaglebone, If the eMMC and sd_card do not have bootable media, the 
boot proces will go to UART device number 0 to look for a bootable medium 
and then to USB0.
for more details visit the TI wiki  : 
http://processors.wiki.ti.com/index.php/Main_Page

On Monday, February 6, 2017 at 5:39:54 PM UTC+5:30, Madhu K wrote::  All,
>
>
> I want to understand the boot process of beaglebone black. I googled and 
> got an article in "Beyond logic" there is explained boot sequence as 
> follows.
>
> By default, the ROM in the Sitara AM3359 will boot from the MMC1 interface 
> first (the onboard eMMC), followed by MMC0 (MicroSD), UART0 and USB0.
>
> what does UART0 and USB0 meanig here?
>
> Regards,
> Madhu
>

-- 
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/3d00b302-bda6-4297-87d7-ba83e8c038b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] apt-show-versions

[ivanlmj]

Hi dude!

Thanks for your post. Saved my life :)!

I made a post at ServerFault 

 in 
order to spread the solution.

Thanks once again.

Best Regards,
Ivan Leon

On Wednesday, June 22, 2016 at 9:04:13 AM UTC-5, bucks...@gmail.com wrote:
>
> Removing /etc/apt/apt.conf.d/02compress-indexes didn't work for me (not 
> sure why). But I got webmin 1.801 installed on Jessie by doing:
> apt-get purge apt-show-versions
> rm /var/lib/apt/lists/*gz
> apt-get -o Acquire::GzipIndexes=false update
> apt-get install apt-show-versions
> dpkg -i webmin_1.801_all.deb
>
> Hope this helps any other poor souls out there.
>
>

-- 
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/b92f212a-886f-427f-b8f1-8cc2d78ed288%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: u-boot v2017.03 cross compilation failed

[arun kumar]

Hi, 
  I am using the same toolchain as you. But I could not recreate the 
problem that you faced.
I will list down my steps..

1. Clone the mainline u-boot . ( git clone git://git.denx.de/u-boot.git) 
I have faced issues too with the ee-wiki sources, but the steps 
more or less work with mainline sources too, just avoid the patches.)
2. make clean
3. make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- 
omap3_beagle_defconfig
4. make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- 

This did it for me, no issues faced.. have the MLO and u-boot.img 
generated. 

On Thursday, March 30, 2017 at 6:08:48 PM UTC+5:30, malkowki wrote:
>
> Hi,
>
> I have tried to compile the u-boot as described from Robert Nelson eewiki 
> but I have ended up with the following compilation error after executing 
> the following steps:
>
> make ARCH=arm CROSS_COMPILE=${CC} distclean
> make ARCH=arm CROSS_COMPILE=${CC} omap3_beagle_defconfig
> make ARCH=arm CROSS_COMPILE=${CC}
>
>
>
>
>   LD  spl/fs/built-in.o
>   LDS spl/u-boot-spl.lds
>   LD  spl/u-boot-spl
> /home/mppdev/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-
> linux-gnueabihf-ld.bfd: u-boot-spl section `.rodata' will not fit in 
> region `.sram'
> /home/mppdev/gcc-linaro-5.4.1-2017.01-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-ld.bfd:
>  
> region `.sram' overflowed by 3448 bytes
> make[1]: *** [spl/u-boot-spl] Error 1
> make: *** [spl/u-boot-spl] Error 2
>
> I am using VM running on Windows.
>
> Thanks for your help!
>

-- 
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/c1ff82c9-752a-46aa-8905-bbb090cdd2b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.