xiangfu at openmoko.org
Sun Aug 3 06:58:24 CEST 2008
this week i make the serial console work.
and learn something about GPIO, S3C2442B data sheet CLOCK,
there is a question:
the same program, i run twice times, it's give me different output
sometimes it is can output "hellod work"
sometimes just "?" and sometimes it's output nothing, i really don't
i doubt is there something wrong with my debug broad.
the PLAN Werner Almesberger wrote:
> 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)
i spent a lot of time about loads a file form NAND to DRAM(and serial
so i want do something about "Next"
--"add the initialization that is currently done in u-boot and not
--in the kernel." even now i don't know how to do it, but i want try.
> ****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
> 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
More information about the openmoko-kernel