Hi,
The A6 revision of the beaglebone is coming up, which only has a few fixes to the PCB, but no new features. The current kernel situation is unworkable and needs to changes. Here's my suggestion:
A6 release (4 weeks from now):
* kernel base: v3.2-staging from TI PSP - http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=09e9651bcf2ee8d86685f2a8075bc6557b1d3b91
* 3.2.x stable updates from Greg KH - http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=shortlog;h=refs/heads/linux-3.2.y
* beaglebone patches
A6 sw update (8 weeks from now):
* kernel base: 'master' from Vaibhav - https://github.com/hvaibhav/am335x-linux
* beaglebone patches
To be able to ship the A6 update with the VH kernel we need to address at least:
* ADC sysfs support
* Cape EEPROM readout
* Cape support
* PRU
* subsystem powerup withput changing pinmux (e.g. PWM)
* PWM (Bill or Sacha PWM?)
* devicetree changes for capes in u-boot
* update bonescript to work with new kernel
I would recommend going the non-DT path first and then slowly convert over to DT since that needs coordination between kernel and u-boot again (deja-vu of beagleboard expansion board support).
Non critical bits to address:
* expand GPIO api to report GPIOs that are already taken (e.g. w1-gpio) so we have a usefull error message in bonescript
* devicetree support in bonescript
* make st7735fb DMA safe
All the new releases will of course support revision A3 and up.
regards,
Koen
Koen,
For those of us that might not be in the know, can you provide a short paragraph as to why the current kernel is unworkable, and why the change from TI PSP to Vaibhav base? When I see the word "unworkable" it starts to raise red flags for future projects using the bone. At least you do have a roadmap which helps a bit with the old nerves. 
Thanks for you time,
Mark
Hi,
The A6 revision of the beaglebone is coming up, which only has a few fixes to the PCB, but no new features. The current kernel situation is unworkable and needs to changes. Here's my suggestion:
A6 release (4 weeks from now):
* kernel base: v3.2-staging from TI PSP - http://arago-project.org/git/projects/?p=linux-am33x.git;a=commitdiff;h=09e9651bcf2ee8d86685f2a8075bc6557b1d3b91
* 3.2.x stable updates from Greg KH - kernel/git/stable/linux.git - Linux kernel stable tree
* beaglebone patches
A6 sw update (8 weeks from now):
* kernel base: 'master' from Vaibhav - GitHub - hvaibhav/am335x-linux: Linux development (Baseport + Driver) for TI's AM335x family of devices, especially targetted for BeagleBone and daughterboards around it.
* beaglebone patches
To be able to ship the A6 update with the VH kernel we need to address at least:
* ADC sysfs support
* Cape EEPROM readout
* Cape support
* PRU
* subsystem powerup withput changing pinmux (e.g. PWM)
* PWM (Bill or Sacha PWM?)
* devicetree changes for capes in u-boot
* update bonescript to work with new kernel
I would recommend going the non-DT path first and then slowly convert over to DT since that needs coordination between kernel and u-boot again (deja-vu of beagleboard expansion board support).
Non critical bits to address:
* expand GPIO api to report GPIOs that are already taken (e.g. w1-gpio) so we have a usefull error message in bonescript
* devicetree support in bonescript
* make st7735fb DMA safe
All the new releases will of course support revision A3 and up.
regards,
Koen
Koen,
For those of us that might not be in the know, can you provide a short paragraph as to why the current kernel is unworkable, and why the change from TI PSP to Vaibhav base?
The problems are partially self inflicted, like our current ADC readout using sysfs, that won't work anymore with the most recent TI 3.2 kernel. The not self inflicted problems include not being able to get any of our patches back into the TI kernel. Vaibhav is doing an awesome job looking at the beagle list and commenting on patches for his tree.
But the biggest problem is that the current kernel is completely different from what will be in the mainline (Linus) kernel eventually e.g. the competing PWM framework seems to be gaining traction again[1], not the one TI picked.
It boils down to: beagleboard.org doesn't want to maintain their own kernel, but use mainline with a small number of patches if needed. Vaibhavs tree is the best way to accomplish that.
When I see the word "unworkable" it starts to raise red flags for future projects using the bone. At least you do have a roadmap which helps a bit with the old nerves. 
If you look back at the announcements we did around the launch of beaglebone you'll see phrases like "software needs another 6 months", which seems like an accurate assesment looking back. What we want to accomplish with this roadmap is have one "big bang" change in the near future for the kernel so people can be assured we'll only break things once this year[2]. For 'hobby' projects we'll try to use bonescript to abstract the changes away and most kernel interfaces won't change (USB, SPI, I2c, etc).
regards,
Koen
[1] Which was completely unexpected, but someone used the magic 'devicetree bindings' phrase in a recent mail.
[2] Fingers crossed!
Thanks Robert. I did remember seeing the post but failed to put 2 and 2 together.
Mark
<snip>
For those of us that might not be in the know, can you provide a short paragraph as to why the current kernel is unworkable, and why the change from TI PSP to Vaibhav base?
The problems are partially self inflicted, like our current ADC readout using sysfs, that won't work anymore with the most recent TI 3.2 kernel. The not self inflicted problems include not being able to get any of our patches back into the TI kernel. Vaibhav is doing an awesome job looking at the beagle list and commenting on patches for his tree.
But the biggest problem is that the current kernel is completely different from what will be in the mainline (Linus) kernel eventually e.g. the competing PWM framework seems to be gaining traction again[1], not the one TI picked.
It boils down to: beagleboard.org doesn't want to maintain their own kernel, but use mainline with a small number of patches if needed. Vaibhavs tree is the best way to accomplish that.
When I see the word "unworkable" it starts to raise red flags for future projects using the bone. At least you do have a roadmap which helps a bit with the old nerves.
If you look back at the announcements we did around the launch of beaglebone you'll see phrases like "software needs another 6 months", which seems like an accurate assesment looking back. What we want to accomplish with this roadmap is have one "big bang" change in the near future for the kernel so people can be assured we'll only break things once this year[2]. For 'hobby' projects we'll try to use bonescript to abstract the changes away and most kernel interfaces won't change (USB, SPI, I2c, etc).
regards,
Koen
[1] Which was completely unexpected, but someone used the magic 'devicetree bindings' phrase in a recent mail.
[2] Fingers crossed!
Excellent explanation Koen,
Thanks
Mark