Hi. Was the issue with the loading of Device Tree Overlays sorted out? The patchset was disabled in the 3.8 kernels which prevented DTBS from being loaded from eMMC on startup.
BR
Robert
Well considering the 3.12 doesn't contain "any" overlays at this
point... Sure... 
Regards,
Thanks Robert. Now I am getting further. As I am outside the Angstrom setup-scripts environment, what toolchain should I use?
So am I..
I just grab any linaro.. this one will work:
http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-ARMCrossCompiler:GCC
Regards,
OK I got the kernel, modules and firmware to buid eventually (forgot uboot-mkimage).
Commands used were:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOADADDR=0x80008000 uImage dtbs
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- LOADADDR=0x80008000 modules
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- INSTALL_MOD_PATH=./tempmod LOADADDR=0x80008000 modules_install
Now I am stuck at boot, see screenlog attached.
Any ideas?
Regards,
Dave.
screenlog.0.3.12 (2.36 KB)
Has anyone managed to get this kernel to work on the BBB?
Regards,
Dave.
I've booted it on Buildroot. Was going to try taking the same kernel
and booting it on Angstrom as well, but haven't gotten there yet.
Build output: https://s3.amazonaws.com/beagle/buildroot/2013-10-13-21%3A15%3A27/index.html
Source: https://github.com/jadonk/buildroot/commit/5bcbc31f31a9f0b6941c522a3a50877326cb96d2
Planning on automating this as I have time.
Robert, I completely missed this on your first post.
"Other thoughts…
Some users will build/install these from src, however anyone
interested in a quick “test-me.sh*” script which will install the new
kernel on a daily/weekly basis?
"
Yes please ! Does one exist yet ? I’ll test every new version that comes out when I am made aware of it if such a script exists. I’ve noticed that rc5 is here already which partially has me balking at using a lot of internet bandwidth to pull tons of sources in.
Also if you have a specific list of things you’d like tested I may be able to do this. Also what would be a good load test ? I’ve written my own very simple load test ( timed while(0){i++;} sort of deal, but yeah. Also I will be testing Nodejs following previously used steps( by me personally) to get the latest Nodejs sources compiled and running on 3.8.x.
I should be more active in this mater after this weekend . . .
Hi Robert,
I too had missed it earlier. I would be glad to do the quick “test-me.sh” script.
George
Well the server side is setup and running good with jenkins..
http://rcn-ee.homeip.net:81/dl/jenkins/beagleboard.org/
I just need to factory re-flash a few bbb's and finish the install
script changes early tomorrow..
Regards,
Nice progress! We will test this shortly. It appears the PRU patches are not in yet - is this on the list?
thx -c
I’ll be gone this weekend anyhow, so I am in no hurry.
Okay it's now active, just download:
wget http://rcn-ee.homeip.net:81/dl/jenkins/beagleboard.org/test-me.sh
chmod +x test-me.sh
run via: ./test-me.sh
(it does an abi check with the server, so if I ever change anything,
it'll tell you what to do to update test-me.sh..)
So far it's only been tested against Angstrom (2013-06-20) from here:
http://beagleboard.org/Getting%20Started#update via the eMMC.. So
microSD should work fine too..
PS: remember no "external" capes work.. For the BBB, hdmi, ethernet,
usb, etc is tested..
Regards,
I'll be gone this weekend anyhow, so I am in no hurry.
Okay it's now active, just download:
wget http://rcn-ee.homeip.net:81/dl/jenkins/beagleboard.org/test-me.sh
chmod +x test-me.shrun via: ./test-me.sh
(it does an abi check with the server, so if I ever change anything,
it'll tell you what to do to update test-me.sh..)
Oh and to save Cable Modem bandwidth, it'll warn if the "latest" is
already installed. 
It's only about 10Mb worth of data...
So far it's only been tested against Angstrom (2013-06-20) from here:
Getting Started - BeagleBoard | How do I start using my board? via the eMMC.. So
microSD should work fine too..PS: remember no "external" capes work.. For the BBB, hdmi, ethernet,
usb, etc is tested..
Regards,
On a BB white that was on debian 7.1, it booted into 3.12.0-rc5-bone6 #1
as expected. I noticed immediately that my byobu status bar says the CPU
speed is now "infGHz". 
debian@arm:~$ uname -a
Linux arm 3.12.0-rc5-bone6 #1 SMP Mon Oct 14 10:57:12 UTC 2013 armv7l
GNU/Linux
debian@arm:~$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
no or unknown cpufreq driver is active on this CPU
maximum transition latency: 0.00 ms.
On BBB that was on debian 7.1, kernel 3.8.13-bone28, after I ran test.sh
and rebooted I still have 3.8.13-bone28. There is a 3.8.13-bone28.bak
directory, and there are newly written *.dtb files in /boot but there are
no files from 3.12.x. This BBB is booting off uSD, Could that be the issue?
wget http://rcn-ee.homeip.net:81/dl/jenkins/beagleboard.org/test-me.sh
chmod +x test-me.shrun via: ./test-me.sh
(it does an abi check with the server, so if I ever change anything,
it'll tell you what to do to update test-me.sh..)So far it's only been tested against Angstrom (2013-06-20) from here:
Getting Started - BeagleBoard | How do I start using my board? via the eMMC.. So
microSD should work fine too..PS: remember no "external" capes work.. For the BBB, hdmi, ethernet,
usb, etc is tested..On a BB white that was on debian 7.1, it booted into 3.12.0-rc5-bone6 #1 as
expected. I noticed immediately that my byobu status bar says the CPU speed
is now "infGHz".
debian@arm:~$ uname -a
Linux arm 3.12.0-rc5-bone6 #1 SMP Mon Oct 14 10:57:12 UTC 2013 armv7l
GNU/Linux
debian@arm:~$ cpufreq-info
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
no or unknown cpufreq driver is active on this CPU
maximum transition latency: 0.00 ms.
Correct, cpufreq is broken at the moment..
I have this listed under: Status:
It looks like i can cherry pick a few things from 3.13 to get to work..
On BBB that was on debian 7.1, kernel 3.8.13-bone28, after I ran test.sh and
rebooted I still have 3.8.13-bone28. There is a 3.8.13-bone28.bak directory,
and there are newly written *.dtb files in /boot but there are no files from
3.12.x. This BBB is booting off uSD, Could that be the issue?
Laughs! It figures the first "bug" in the test-me.sh script would be a
user trying to update an debian/ubuntu system... Which I haven't
written support for yet... For now just use the install-me.sh and my
linux-dev build scripts..
So here's the deal, we no longer have an "active" Angstrom kernel
maintainer for the beagleboard.org, so i'm filling in till that
changes. Right now the goal/testing should be limited to usb and
video output and if we are missing any config's from the 3.8 kernel.
For capes, well that's going to take a little bit of work from you
guys too.
Regards,
> On BBB that was on debian 7.1, kernel 3.8.13-bone28, after I ran
test.sh and
> rebooted I still have 3.8.13-bone28. There is a 3.8.13-bone28.bak
directory,
> and there are newly written *.dtb files in /boot but there are no files
from
> 3.12.x. This BBB is booting off uSD, Could that be the issue?Laughs! It figures the first "bug" in the test-me.sh script would be a
user trying to update an debian/ubuntu system... Which I haven't
written support for yet... For now just use the install-me.sh and my
linux-dev build scripts..
Understand. I have this BBB updated using wget
http://rcn-ee.net/deb/wheezy-armhf/v3.12.0-rc5-bone6/install-me.sh.
So here's the deal, we no longer have an "active" Angstrom kernel
maintainer for the beagleboard.org, so i'm filling in till that
changes.
Appreciate your filling in this role.
Right now the goal/testing should be limited to usb and
video output and if we are missing any config's from the 3.8 kernel.
For capes, well that's going to take a little bit of work from you
guys too.
My ar9271 based wifi dongle seems to work fine.
I don't see UART listed among Status items. Is that categorized under
Capes? There is only /dev/ttyO0 at the moment. Besides telling you
something does not work, how do we help?
Just one data point to add;
Seems there is still a throughput issue with isochronous USB transfers. This is with DMA enabled (from looking at the defconfig), so not sure if this should still be expected?
But other than that has been working fine here… (Jessie & 3.12-rc5)
Regards,
Jon
I’m having some trouble getting this running. It just stops at
Starting kernel …
Cross compile the kernel (I an fairly confident it works, I am using the same compiler I use for armhf wandboard)
Follow the directions in the file included in the README.md file (copy over zImage – don’t appear to need uImage – and the dtbs and reboot).
make ARCH=arm CROSS_COMPILE=${CC} LOADADDR=0x80008000 uImage dtbs
root@yoda:~/kernel/kernel# echo $CC
/root/gcc-linaro-arm-linux-gnueabihf-4.8-2013.07-1_linux/bin/arm-linux-gnueabihf-
Here is my uEnv.txt (it is clean “out of the box” from the flasher image).
kernel_file=zImage
initrd_file=uInitrd
initrd_high=0xffffffff
fdt_high=0xffffffff
#Video: Uncomment to override:
#kms_force_mode=video=HDMI-A-1:1024x768@60
##BeagleBone Cape Overrides
##Note: On the BeagleBone Black, there is also an uEnv.txt in the eMMC, so if th
ese changes do not seem to be makeing a difference…
##BeagleBone Black:
##Disable HDMI/eMMC
#optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G
console=ttyO0,115200n8
mmcroot=UUID=731c488d-ddc0-47b9-807f-056742dd5bc9 ro
mmcrootfstype=ext4 rootwait fixrtc
loadkernel=load mmc ${mmcdev}:${mmcpart} 0x80200000 ${kernel_file}
loadinitrd=load mmc ${mmcdev}:${mmcpart} 0x81000000 ${initrd_file}; setenv initr
d_size ${filesize}
loadfdt=load mmc ${mmcdev}:${mmcpart} 0x815f0000 /dtbs/${fdtfile}
boot_classic=run loadkernel; run loadinitrd
boot_ftd=run loadkernel; run loadinitrd; run loadfdt
device_args=run expansion_args; run mmcargs
mmcargs=setenv bootargs console=${console} ${optargs} ${kms_force_mode} root=${m
mcroot} rootfstype=${mmcrootfstype} ${expansion}
expansion_args=setenv expansion ip=${ip_method}
#Classic Board File Boot:
#uenvcmd=run boot_classic; run device_args; bootz 0x80200000 0x81000000:${initrd
_size}
#New Device Tree Boot:
uenvcmd=run boot_ftd; run device_args; bootz 0x80200000 0x81000000:${initrd_size
} 0x815f0000