Hi Xiangfu, I would like to follow along with the steps Werner suggested. I want to mirror what you are doing. If possible, I would like to do this using QEMU, as I do not yet have a Freerunner.
Werner, et. al. -- please forgive my ignorance. Can you give me a pointer to help me bootstrap (pardon the pun) this effort? I'm not sure how to obtain "start.S and friends", or where to look for register/memory mappings for the Freerunner. Perhaps as Xiangfu makes progress along the lines you recommended, I could follow along in his footsteps. Is there a good way for me to see snapshots of his progress? ---------- Forwarded message ---------- > From: Werner Almesberger <[EMAIL PROTECTED]> > To: xiangfu <[EMAIL PROTECTED]> > Date: Tue, 3 Jun 2008 20:31:25 -0300 > Subject: Re: my work about KBOOT > xiangfu wrote: > > UBOOT very complicated for me. > > Yes, u-boot is complex and a lot of the code isn't nice. > > I'm not entirely sure where you are with your work at the moment, and > I also don't know how familiar you're already with the tools we use, > but this is what I'd suggest as the general course of action: > > I think it may be easier if you start with as little code as possible > and then add what you need. That way, you don't have to worry about > all the other things u-boot does. Also, you can progress in small > steps and can check your success after each step. > > I would start with a tiny program that just blinks a LED. You boot > this program from NAND (through Steppingstone), instead of u-boot. > This will give you > > - a Makefile that you can understand completely > > - a good understanding of linking and compiler flags > > - knowledge how to access registers > > - experience with using u-boot (from NOR) to place your code into NAND > > Then you can add full CPU initialization (start.S and friends) and > gradually change this into the NAND loader, which loads a file from > NAND to DRAM. I wouldn't try to use it to boot the kernel, but just a > very simple program, such as that LED blinker (now running at a > different address). This will give you > > - a good understanding of the CPU and DRAM bringup process > > - many opportunities to learn to use OpenOCD for debugging > (you'll need this experience later to bring up the kernel) > > Next, you can try to bring up the kernel. This is a big item, but after > having mastered the previous steps, you'll have the skills to debug it > step by step. You should treat the kernel just as one big binary. Don't > worry about user interaction and such yet. > > In order to make the kernel work, you have to: > > - add the initialization that is currently done in u-boot and not > in the kernel. I think you should be able to get the kernel to > issue printks over the serial port even without this, so you may > want to try this first. > > - provide the descriptors that tell it what hardware it runs on, etc. > This is a structure called "Arm TAG" or "ATAG". > > - pass a boot parameter line that tells the kernel where the console > is. > > Once you get the kernel to do anything at all, you can complete the > initialization code, add an initramfs, and then you'll have a fully > functional system. (Which doesn't to much yet, but that's the next > phase then.) > > The importance here is that you make sure you understand what happens > at each step. That's why I'm recommending to build that boot loader > from scratch, and not try to just trim down u-boot. > > If something "just works" but you don't know why, you will have an > incredibly hard time fixing it if it stops working in the future. > > Also, for building the kernel, don't worry about kboot yet. Just make > a regular Openmoko kernel and use that one. kboot's build process > involves the kernel in order to obtain configuration data, but that's > an issue to worry about much later. > > - Werner >
