Well I feel like an idiot. I'd thought that the resulting UBI image was essentially an initramfs image; kernel and filesystem combined in one image. From looking at the address mapping and the commands I've been issuing to flash the new UBI, I now see that I've been building the kernel but not burning it to flash.
I guess what tricked me was issuing the set of three commands below would do a clean rebuild of the kernel and the filesystem, but it wasn't obvious to me from the instructions on Atmel's website that the kernel wasn't included in the UBI image. I'd issued a 'bitbake -c cleanall virtual/kernel' and that's still in the middle of rebuilding. If I find out that I still have something else wrong I'll post back here. Otherwise, assume that my only mistake was not actually burning the kernel to flash. -Bryan -----Original Message----- From: angstrom-distro-devel-boun...@linuxtogo.org [mailto:angstrom-distro-devel-boun...@linuxtogo.org] On Behalf Of Jack Mitchell Sent: Tuesday, April 24, 2012 4:03 PM To: angstrom-distro-devel@linuxtogo.org Subject: Re: [Angstrom-devel] Trouble getting peripheral changes to filter to filesystem On 24/04/2012 20:42, Bryan Evenson wrote: > I have a SAM9G25-EK board and I am having issues with my Angstrom image > incorporating some kernel configuration changes I've made. This chip has 4 > USARTs with USART0 and USART3 populated on the development board. The > default image has USART3 disabled and I am trying to enable it. With a > Buildroot setup, all I needed to do was register USART3 in the board > configuration file in the kernel by adding: > > at91_register_uart(AT91SAM9X5_ID_USART3, 4, 0); > > to board-sam9x5ek.c. I've done this with my Angstrom image (using a patch > and verifying that the patch was correctly applied) and then executed: > > bitbake -c clean virtual/kernel > bitbake -c clean net-at91sam9-image > bitbake net-at91sam9-image > > where net-at91sam9-image console-based image recipe that was created by > Atmel. I burned the new image to my dev board and rebooted. After booting > the new image, USART3 is still not operable and a search of dmesg showed that > no attempt was made to register USART3. > > I then tried removing the registration of USART0 and USART3, rebuilding > everything and loading the new image. With this image there was still no > change; USART0 was still operational and USART3 was not. So there is a step > that I must be missing in getting my updates to the kernel to filter down. > I've also tried cleaning and rebuilding udev, but that didn't help either. > Any ideas what steps I may be missing? > > Thanks, > Bryan > > > > > > _______________________________________________ > Angstrom-distro-devel mailing list > Angstrom-distro-devel@linuxtogo.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel Hi Bryan, There is a suggested guide for kernel development[1], and one I recently wrote myself[2] - have a look at the workflow. I am guessing that when you perform the bitbake -c clean you are removing the changes you made to your Angstrom kernel source. [1] http://www.slimlogic.co.uk/2011/05/openembeddedangstrom-kernel-workflow/ [2] http://communistcode.co.uk/blog/blogPost.php?blogPostID=3 _______________________________________________ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel _______________________________________________ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
