doc/README.mips: Add MIPS notes
authorShinya Kuribayashi <skuribay@ruby.dti.ne.jp>
Tue, 22 Apr 2008 13:47:27 +0000 (22:47 +0900)
committerWolfgang Denk <wd@denx.de>
Thu, 24 Apr 2008 22:03:53 +0000 (00:03 +0200)
Signed-off-by: Shinya Kuribayashi <skuribay@ruby.dti.ne.jp>
doc/README.mips [new file with mode: 0644]

diff --git a/doc/README.mips b/doc/README.mips
new file mode 100644 (file)
index 0000000..85dea40
--- /dev/null
@@ -0,0 +1,57 @@
+
+Notes for the MIPS architecture port of U-Boot
+
+Toolchains
+----------
+
+  http://www.denx.de/wiki/DULG/ELDK
+  ELDK < DULG < DENX
+
+  http://www.emdebian.org/crosstools.html
+  Embedded Debian -- Cross-development toolchains
+
+  http://buildroot.uclibc.org/
+  Buildroot
+
+Known Issues
+------------
+
+  * Little endian build problem
+
+    If use non-ELDK toolchains, -EB will be set to CPPFLAGS. Therefore all
+    objects will be generated in big-endian format.
+
+  * Cache incoherency issue caused by do_bootelf_exec() at cmd_elf.c
+
+    Cache will be disabled before entering the loaded ELF image without
+    writing back and invalidating cache lines. This leads to cache
+    incoherency in most cases, unless the code gets loaded after U-Boot
+    re-initializes the cache. The more common uImage 'bootm' command does
+    not suffer this problem.
+
+    [workaround] To avoid this cache incoherency,
+    1) insert flush_cache(all) before calling dcache_disable(), or
+    2) fix dcache_disable() to do both flushing and disabling cache.
+
+  * Note that Linux users need to kill dcache_disable() in do_bootelf_exec()
+    or override do_bootelf_exec() not to disable I-/D-caches, because most
+    Linux/MIPS ports don't re-enable caches after entering kernel_entry.
+
+TODOs
+-----
+
+  * Probe CPU types, I-/D-cache and TLB size etc. automatically
+
+  * Secondary cache support missing
+
+  * Centralize the link directive files
+
+  * Initialize TLB entries redardless of their use
+
+  * R2000/R3000 class parts are not supported
+
+  * Limited testing across different MIPS variants
+
+  * Due to cache initialization issues, the DRAM on board must be
+    initialized in board specific assembler language before the cache init
+    code is run -- that is, initialize the DRAM in lowlevel_init().