[U-Boot-Users] OMAP1510 Innovator kit booting questions

Hi!
I am using U-Boot 1.0 on my OMAP 1510 Innovator kit. Could someone give me answer on my 2 questions?
1. My platform is ARM9 and I am using separate Linux kernel and RAMdisk images. I am booting from RAW flash. In file ./lib_arm/armlinux.c there is function do_bootm_linux() that works with initrd. But at least for separate images initrd is not copied anywhere. Why? And this means that for any ARM platform initrd won't be copied if user will use separate images?
So I solved this by putting memory copying call - and it now is working well.
2. Next - I am using autoboot mode with 3-5 seconds of bootdelay. But 1 u-boot seconds is approximately 15-20 of real seconds. Yes - this is board specific - maybe some clock setup missed - (by me?) or PLL settings - so could someone help me with it?
Only that I have changed - I've switched to use UART2 for serial communication - it is working well - I don't think that it has got any influence to board speed.
Thanks for answers.

Dear Grigory,
in message 15377154875.20031227100615@tut.by you wrote:
I am using U-Boot 1.0 on my OMAP 1510 Innovator kit. Could someone give me answer on my 2 questions?
I'll try.
- My platform is ARM9 and I am using separate Linux kernel and RAMdisk images. I am booting from RAW flash. In file ./lib_arm/armlinux.c there is function do_bootm_linux() that works with initrd.
...it also works without initrd.
But at least for separate images initrd is not copied anywhere.
Correct.
Why? And this means that for any ARM platform initrd won't be copied if user will use separate images?
Why should we copy the initrd image? You already have it in flash, so copying it to RAM is just a waste of time and memory.
So I solved this by putting memory copying call - and it now is working well.
No such copy is needed. It is trivial to patch the LInux kernel to avoid this. See the Linux kernel tree on opur CVS server; IIRC this is the core of the mods:
--- arch/arm/mm/init.c 25 Oct 2002 19:59:31 -0000 1.3 +++ arch/arm/mm/init.c 26 Oct 2002 09:27:17 -0000 1.4 @@ -64,6 +66,10 @@ */ struct page *empty_zero_page;
+#ifdef CONFIG_BLK_DEV_INITRD +int initrd_in_ram; +#endif + #ifndef CONFIG_NO_PGT_CACHE struct pgtable_cache_struct quicklists;
@@ -426,6 +435,9 @@ bootmap_pages = find_memend_and_nodes(mi, np); bootmap_pfn = find_bootmap_pfn(0, mi, bootmap_pages); initrd_node = check_initrd(mi); +#ifdef CONFIG_BLK_DEV_INITRD + initrd_in_ram = initrd_node >= 0; +#endif
map_pg = bootmap_pfn;
@@ -674,8 +689,17 @@
void free_initrd_mem(unsigned long start, unsigned long end) { - if (!keep_initrd) - free_area(start, end, "initrd"); + if (!keep_initrd) { + if (initrd_in_ram) + free_area(start, end, "initrd"); + else { + if (start == initrd_start && end == initrd_end) { + iounmap((void *)start); + initrd_start = initrd_end = 0; + } else + printk(KERN_ERR "Cannot unmap initrd !\n"); + } + } }
static int __init keepinitrd_setup(char *__unused) --- arch/arm/mm/mm-armv.c 6 Sep 2002 20:32:24 -0000 1.2 +++ arch/arm/mm/mm-armv.c 26 Oct 2002 09:27:17 -0000 1.3 @@ -22,6 +22,15 @@
#include <asm/mach/map.h>
+#ifdef CONFIG_BLK_DEV_INITRD +#include <linux/blk.h> +#include <asm/io.h> + +extern unsigned long initrd_phys; +extern unsigned long initrd_size; +extern int initrd_in_ram; +#endif + /* * These are useful for identifing cache coherency * problems by allowing the cache or the cache and @@ -495,4 +504,15 @@ pte_cache_ctor, NULL); if (!pte_cache) BUG(); + +#ifdef CONFIG_BLK_DEV_INITRD + if (initrd_phys != -1 && ! initrd_in_ram) { + initrd_start = (unsigned long)__ioremap(initrd_phys, + initrd_size, L_PTE_CACHEABLE | L_PTE_BUFFERABLE); + if (initrd_start == 0) + printk(KERN_ERR "Cannot map initrd !\n"); + else + initrd_end = initrd_start + initrd_size; + } +#endif }
- Next - I am using autoboot mode with 3-5 seconds of bootdelay. But 1 u-boot seconds is approximately 15-20 of real seconds. Yes - this is board specific - maybe some clock setup missed - (by me?) or PLL settings - so could someone help me with it?
I don't know your hardware. But it is obvious that your clock settings are wrong.
Only that I have changed - I've switched to use UART2 for serial communication - it is working well - I don't think that it has got any influence to board speed.
No, it does not.
Best regards,
Wolfgang Denk
participants (2)
-
Grigory A.
-
Wolfgang Denk