Re: [U-Boot] AT91SAM926x Nor Boot
Jens Scharsig wrote: I'm start with a port for a new customer board with NOR-flash only. Our customer don't like use AT91Bootstrap. I look at the source, but don't found any initialization code for AT91SAM926x. My question: Are there any plans or patches which support to use u-boot without AT91Bootstrap? or Should I do this by myself? I have tested a solution based on U-Boot-1.1.5 as modified by Atmel. The adaptation to booting via NOR flash itself was written by Alessandro Rubini: http://www.gnudd.com/pub/patches/at91sam9263ek-nor/at91sam9263ek-nor.pdf Although it is based on old code, the documentation of the problem of booting from NOR flash on the AT91SAM9263 is worth reading. Sincerely, Ken Fuchs ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Starting WindowsCE
Andreas Geisreiter wrote: I use U-Boot with a Marvell PXA270 CPU. And now I will start WindowsCE with it. I have loaded the nk.bin image via TFTP to the RAM but I need the entry point of the image. And I don't know anything about starting WinCE at the moment. Has anybody experience with starting WinCE or has anybody done this with U-Boot? It is quite easy to use U-Boot to chainload Eboot which boots the CE kernel NK. The easiest way to do this (prior to the patch that supports the NK.bin image) is using nb0 (raw executable) images, namely Eboot.nb0 and NK.nb0. Use U-Boot to download these images into SDRAM and modify Eboot to use the NK.nb0 image previously loaded into SDRAM by U-Boot. An extra bonus for booting CE via both U-Boot and Eboot is using U-Boot's image (bootm with the boot feature disabled) decompression features. For large CE kernels, booting a gz compressed NK.nb0 could be significantly faster than booting an NK.bin image, because the gz image can be about 1/3 the size of the NK.bin image. Trivially changes to the Eboot and even NK sources may be required to make this work. Look also into the U-Boot patches that support NK.bin directly. These patches may be faster than the approach I described above. The 2008-Aug-22 06:43 UTC patch by Ryan Chen has already been mentioned. There is also a much earlier patch by RD4 dated 2008-Feb-02 16:57 UTC. (Not sure whether or not the patch by Chen is based on the patch by RD4.) Sincerely, Ken Fuchs ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] [RFC] Add support for early serial debugconsole
It's weekend, and not many people are active now. Let's wait for a few more days if anybody shows up with arguments to support your patches. In my opinion, the serial device should be the first device initialized and utilized before all other devices where that is possible. For example, it would be very useful to have serial output while debugging RAM initialization. An early serial port prior to U-Boot relocating itself would be very useful for porting U-Boot to new boards. An early debug serial port would be a good candidate for mainline U-Boot: CONFIG_DEBUG_EARLY_SERIAL has been implemented in a few forks of U-Boot. I also favor an early serial debug console as advocated by this patch, but perhaps its code should be self contained. I'm not sure it is a good idea to modify some commands so they can be run before RAM relocation. If such a thing can be done simply, it should be done for all commands. Is the patch submitted clean enough? No, the implementation could be improved with some effort; a few #if - #else - #endif clauses could be eliminated for example. Would an easier to maintain implementation even be feasible? I agree that a JTAG debugger is extremely useful for board bring-up, but they are very expensive. I'm strongly in favor of having some early serial functionality whether in the form of simply being able to send output to the serial port or having a semi-functional to fully functional shell prior to RAM relocation. Sincerely, Ken Fuchs ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
