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
