If there is something you'd like to see in the software image for the
next-gen BeagleBone (and updated image for existing BeagleBone), *NOW*
is your last chance to get it into image before it ships. The image
will be frozen on Monday and you should submit your additions in with
sufficient time to get them accepted (time will vary depending on
complexity).
To contribute to Angstrom, see:
http://www.angstrom-distribution.org/contribution-angstrom-where-do-i-send-patches-buildsystem-related-issues
The 'cloud9-gnome-image' is the rootfs that ships with the board.
The kernel and bootloader are build out of the meta-beagleboard repo:
https://github.com/beagleboard/meta-beagleboard
To contribute to the kernel outside of Angstrom, see:
http://github.com/beagleboard/kernel/tree/3.8
Github pull requests are the most effective way to get patches into
this "vendor kernel". Sending your kernel patches to the upstream
maintainers in parallel and getting their feedback will help
tremendously with getting patches accepted into the vendor kernel. If
your patches look dead-end, they could easily be ignored.
Contribute now to make sure the out-of-box-experience is what you'd like to see!
Contribute now to make sure the out-of-box-experience is what you’d like to see!
I’;d like to see a more common and broadly supported OS such as debian supported out of the box.
I'm as much of a fan of Debian on bones as anyone but in what way is
Debian not supported as of today? RCN has a bunch of tools to build
net-installers for bones, beagles, pandas, etc. Is that not
satisfactory?
-Andrew
With regards to the kernel, I think he means to work better with
debian to make sure their kernel supports the hardware out of the
box.. For wheezy (v3.2.x) the delta for the bone would be impossible
for debian to take and support.. The only thing we can do is actively
push mainline, then debian can pick something up in wheezy+1 for the
BeagleBone..
Till then we, have scripts to merge in a mainline kernel into debian's
debian-installer infrastructure..
Regards,
So this is mostly a comment saying, "Get code into mainline," then?
If so, I'll hardily recommend that!
Jason, can we get that done by Monday? 
-Andrew
Laughs, this is debian remember.. 
Squeeze was released on Feb 2011, Wheezy should be in the next 4 weeks
(so April 2013)... So if nothing changes, we'd need to make sure the
BeagleBone support was in mainline kernel (and a stable version)
before: May 2015.
Regards,
Robert
Do you plan to support ubuntu-12.10 on this as well?
It would really help me understand why BeagleBone Texas Instruments
people choose to go with angstrom when there are well known systems
like ubuntu out there?
I dont have much background, so its a question i always haven been
wondering about.
regards
Robert
Do you plan to support ubuntu-12.10 on this as well?
Actually i have been:
http://elinux.org/BeagleBoardUbuntu#Quantal_12.10_armhf
Exact same kernel source, just built for quantal compiler.. As far as
image generations goes, there is really only 2-3 differences between
debian/ubuntu..
It would really help me understand why BeagleBone Texas Instruments
people choose to go with angstrom when there are well known systems
like ubuntu out there?
Simple, go back to 2010.. Angstrom was the ONLY game in town to get
the full speed out of these Cortex-A8 devices. I started hacking on
debian, i as enjoyed that system, even thou on that date it was
probally about 5 times slower then Angstrom.. 
Still today, if you want a small filesystem to be put in NAND, it's
still the only real game in town..
Regards,
If someone can do the work and get it such that this can be flashed into the eMMC, I would not be opposed to supporting it. Maybe not out of the box, but maybe shortly there after.
Gerald
If someone can do the work and get it such that this can be flashed into the
eMMC,
Bone Black would have an eMMC part and some reference code on how to use it.
I would guess it should not be that difficult to adapt it to any
environment including ubuntu.
Use it? dd works pretty well, assuming it fits.
Gerald
Robert
Do you plan to support ubuntu-12.10 on this as well?
It would really help me understand why BeagleBone Texas Instruments
people choose to go with angstrom when there are well known systems
like ubuntu out there?
By “Texas Instruments people”, you mean me. This isn’t a TI strategy, it is a Jason strategy. I’ll tell you my reasons:
-
OpenEmbedded gives a clear path to commercial support through the participants in the Yocto Project. That means that if you create something custom, you can find multiple commercial Linux vendors willing to compete with each other ready to help you scale your software resources to push something across the finish line.
-
Koen allows me to customize the out-of-box-experience with Angstrom on BeagleBone.
-
Angstrom focuses on optimizations targeting embedded devices, including boot time, lean desktops and more.
-
The distro works with cross-compilation for all the packages, making build times sane.
-
The history is I started with Gentoo, which I believe has the best cross-building infrastructure of the major desktop/server Linux distributions out there, but Koen was able to build and optimize packages using OpenEmbedded far faster than I could. No one else has even really stepped up to the plate. While Robert does an amazing job at supporting Ubuntu, Debian and Fedora using the upstream distro build tools and the kernel integration work where he collaborates with Koen, none of the upstream distro maintainers has taken it as an on-going effort to support Beagles out of the box in a clean fashion. Ubuntu had a start and I thought was going to get there, but I think the model is more one of commercial contributions to keep it going. Arch Linux is the closest I’ve seen so far outside of Angstrom.
-
CircuitCo employs Koen, so the primary maintainer of Angstrom is motivated to see the platform succeed.
If someone can do the work and get it such that this can be flashed into the
eMMC,
Bone Black would have an eMMC part and some reference code on how to use it.
I would guess it should not be that difficult to adapt it to any
environment including ubuntu.
We work in public as much as possible. Mainline u-boot and GitHub - beagleboard/kernel: Kernel for the beagleboard.org boards already have support for the eMMC and the next-gen board in general. eMMC simply works like an SD card.
I would not be opposed to supporting it. Maybe not out of the box, but
maybe shortly there after.
I don’t see why distributors couldn’t load other distros onto the boards to have them work out-of-the-box. Certainly some coordination would be required to avoid nasty support issues. CircuitCo uses Angstrom to validate the hardware, so end users would likely be expected to perform some kind of validation against a known-good Angstrom image before reporting any hardware problems.
I have early and basic script, that would copy the existing (and
running) sd card to the onboard eMMC. At the moment it only takes
care of the boot partition. Copying the live/running extX partition
will be a little interesting..
https://github.com/RobertCNelson/tools/blob/master/scripts/beaglebone-black-sync-nand.sh
Regards,
Contribute now to make sure the out-of-box-experience is what
you’d like to see!
I’;d like to see a more common and broadly supported OS such as
debian supported out of the box.
I’m as much of a fan of Debian on bones as anyone but in what way is
Debian not supported as of today? RCN has a bunch of tools to build
net-installers for bones, beagles, pandas, etc. Is that not
satisfactory?
With regards to the kernel, I think he means to work better with
debian to make sure their kernel supports the hardware out of the
box… For wheezy (v3.2.x) the delta for the bone would be impossible
for debian to take and support… The only thing we can do is actively
push mainline, then debian can pick something up in wheezy+1 for the
BeagleBone…
Till then we, have scripts to merge in a mainline kernel into debian’s
debian-installer infrastructure…
So this is mostly a comment saying, “Get code into mainline,” then?
If so, I’ll hardily recommend that!
Yes, that is always the recommendation. What is notable here is that there is opportunity to get some functionality in if you have a real plan to support the code all the way to mainline. At this point, those kernel contributions would need to be pretty simple and/or bug-fixes, but getting into GitHub - beagleboard/kernel: Kernel for the beagleboard.org boards on your way to mainline is a nice stepping stone with some short-term dividends in having that code provided out-of-the-box on 10s of thousands of boards being built in the next couple of weeks.
Further, we aren’t just talking about the kernel. I’m talking about the packages included on the distro to include things like ‘mpd’ and ‘scratch’ to name a couple that I know aren’t there today and for which I’ve heard recent interest. It means impacting Bonescript and the services run at start-up. Without a native serial connection, lots of users are going to be stuck using the services already running until they establish an ssh connection to the board. The issues with GateOne and Cloud9 IDE have me most concerned to get them back into some nice state.
Jason, can we get that done by Monday? 
Mainline, no, but merged into Angstrom… possibly. Support for the platform in mainline (u-boot/kernel) is still, by-far, the overriding priority, but having a nice first-impression is more than simply welcome.
If someone can do the work and get it such that this can be flashed into the
eMMC,
Bone Black would have an eMMC part and some reference code on how to use it.
I would guess it should not be that difficult to adapt it to any
environment including ubuntu.
I have early and basic script, that would copy the existing (and
running) sd card to the onboard eMMC. At the moment it only takes
care of the boot partition. Copying the live/running extX partition
will be a little interesting..
https://github.com/RobertCNelson/tools/blob/master/scripts/beaglebone-black-sync-nand.sh
Looks neat.
Assumption would be that kernel supports:
a) /dev/mmcblk1
b) and boot setting pins are such that at reboot mmc2 is taken as boot
device instead of mmc1 on AM35xx processor.
Any plans of supporting (a) on 3.8 kernel?
(b) would be a hw change, which i think black will come with anyways.
If someone can do the work and get it such that this can be flashed into the
eMMC,
Bone Black would have an eMMC part and some reference code on how to use it.
I would guess it should not be that difficult to adapt it to any
environment including ubuntu.
I have early and basic script, that would copy the existing (and
running) sd card to the onboard eMMC. At the moment it only takes
care of the boot partition. Copying the live/running extX partition
will be a little interesting..
https://github.com/RobertCNelson/tools/blob/master/scripts/beaglebone-black-sync-nand.sh
Looks neat.
Assumption would be that kernel supports:
a) /dev/mmcblk1
That's actually the 2nd mmc card or eMMC cape.
b) and boot setting pins are such that at reboot mmc2 is taken as boot
device instead of mmc1 on AM35xx processor.
I'm tempted to setup u-boot to just ignore any boot select pins...
Just have u-boot scan both 0:1 (mmc) 1:1 (eMMC), if both are present
then default to eMMC unless mmc has an 'uEnv.txt' file..
Any plans of supporting (a) on 3.8 kernel?
(b) would be a hw change, which i think black will come with anyways.
Regards,
Robert
Do you plan to support ubuntu-12.10 on this as well?
It would really help me understand why BeagleBone Texas Instruments
people choose to go with angstrom when there are well known systems
like ubuntu out there?
By "Texas Instruments people", you mean me. This isn't a TI strategy, it is
a Jason strategy. I'll tell you my reasons:
Thanks for all this insight.
I was pretty sure there was some history behind this.
Personally i don't like to spend time learning new distro intricacies -
i would rather spend that time to get my real work done.
Few observations :
a) Few months back my first take with Angstrom build system was
horrible, wrt Kernel and bootloader rebuilding.
It took almost a month to figure out how to let this build system not
delete the source codes.
b) Robert did a clean job in exactly addressing this concern about
recompiling kernel
(refer his script build_kernel.sh) - uboot used was upstream - so no
issues. For Angstrom i could not use upstream u-boot as u clearly know
it needs some boot-from-ext4 kernel patch etc etc.
c) I am not sure how i could customize Angstrom for a headless system.
Ubuntu minimal/consle fs was exactly that.
my need is to recompile kernel/bootloaders often - and i find ubuntu
setup by Robert best suited.
Maybe if u incorporate similar stuff for kernel/bootloader for
angstorm, i am more than happy to use it
Hi,
I would like to see the (USB) WiFi actually working including adhoc mode.
Jan
Jason, are you saying that 3.8 will be the kernel version for the new Image? If that is the case I have a few patches that I would like to submit! The patches have been developed on Robert Nelsons kernel 3.8 patchset, so I’m trying to determine what needs to be done to port them, hopefully very little.