Hi All,
Here’s my latest update regarding building a 3.13.9-bone9 bootable image.
Again, I want to thank Robert Nelson, Jason Kridner and everyone that has contributed to the BBB/Debian effort. This was a big improvement for me.
I did get Debian 3.13.9 running last night. I am trying to integrate devices with the BBB and it was recommended that in order to complete the integration I should perform the build and upgrade. But first I needed to put together the cross compiler development platform. I didn’t didn’t have one other than Windows 7, Eclipse, GNU toolchain and Putty. I went the dual boot route by adding Ubuntu to may second SSD.
As mentioned above I tried to perform the steps outlined in this link http://eewiki.net/display/linuxonarm/BeagleBone . The difficulties I had are documented earlier in this thread. Those issues were part of my learning curve and having the correct packages loaded in the correct directory structure. I own those issues.
However, in those instructions there are patches applied to u-boot. After the patch, many environmental variables are set in AM335x_evm.h. Some of those variables are load addresses for zImage. Other variables are defined/set in uEnv.txt. This was important all day yesterday because u-boot wouldn’t load the zImage or fdtload. It can become confusing trying to understand the uImage/zImage concept when you go back and forth between the code and running uboot. BTW, none of this troubleshooting would have been possible without at least a serial → USB converter and Putty running a serial connection. Need to learn u-boot as part of the process as well. Using printenv and comparing the environmental variables to the values defined/set in the u-boot patch (AM335x_evm.h) was insightful.
So, to finish the build discussion, I ended up using ./build_kernel.sh and ./install_kernel.sh. I think ./install_kernel.sh is still a work in progress as can be determined by looking at the conditional code surrounding zImage. But it works and the pesky edits and cp -v of fstab, inittab et. al. found in the ‘//eewiki.net/’ are now included in the shell (build/install). Life is simpler for that. But…let’s go back to the patches referenced in the ‘//eewiki.net/’ link that are applied to u-boot and also to uEnv.txt.
In a nutshell, variables such as loadaddr are set in AM335x_emv.h if you apply the patch. Yet they appear to be changed in uboot when you compare the contents of the dump when you perform printenv. It was interesting because according to uboot quit with the unable to load zImage running from the uEnv.txt command file. Interesting because some of those variables aren’t defined or set in uEnv.txt and are different than what was defined in the u-boot patch. What was more curious was the skeletal uEnv.txt command file from the wiki link. At the end of the day, here’s how I got things to work. I booted my Win7 machine and copied the latest Debian build (v3.8) to one of my SD cards. I ran my BBB to check that it worked. Shutdown my BBB and removed the card. I rebooted my development platform out of Win7 and into Ubuntu. Placed the sdcard into a reader and compared the uEnv.txt file in the ~/linux-dev/deploy path against what was on the sdcard. Well, I almost fell out of my chair.
I had a “I wonder if” moment and copied the uEnv.txt file from the sdcard (w/Debian v3.8) to my desktop and then swapped sdcards (w/Debian v3.13.9) and copied the much different uEnv.txt file from my desktop to the sdcard. After placing the sdcard into the BBB I started the BBB. Now everything booted correctly (Debian v3.13.9).
I hope that someone benefits from my mistakes and my discoveries.
