]> git.kernelconcepts.de Git - karo-tx-uboot.git/blobdiff - doc/feature-removal-schedule.txt
Merge branch 'u-boot-ti/master' into 'u-boot-arm/master'
[karo-tx-uboot.git] / doc / feature-removal-schedule.txt
index ffe261513c86867b3b6a0c53191ad868e02b4532..ce728612e393e6769362b1d5b1aa5aaace13137f 100644 (file)
@@ -6,50 +6,48 @@ from U-Boot, its corresponding entry should also be removed from this
 file.
 
 ---------------------------
-What:  CONFIG_SYS_ARM_WITHOUT_RELOC option
-When:  After Release 2011.03
 
-Why:   The implementation of U-Boot for the ARM architecture has
-       been reworked to support relocation. This allows to
-       efficiently use the same U-Boot binary image on systems with
-       different RAM sizes, and brings the implementation much more
-       in line with the code used for example on Power Architecture
-       systems (eventually allowing to merge into common code). This
-       seems especailly interesting now that ARM is getting Device
-       Tree support as well.
+What:  Remove CONFIG_CMD_MEMTEST from default list
+When:  Release v2013.07
 
-       All ARM boards need to be adapted to this new code, which
-       requires testing on the actual hardware, so this is a task
-       for the respective board maintainers or other users.
+Why:   The "mtest" command is of little practical use (if any), and
+       experience has shown that a large number of board configu-
+       rations define useless or even dangerous start and end
+       addresses.  If not even the board maintainers are able to
+       figure out which memory range can be reliably tested, how can
+       we expect such from the end users?  As this problem comes up
+       repeatedly, we rather do not enable this command by default,
+       so only people who know what they are doing will be confronted
+       with it.
 
-       Please see the commit message of commit f1d2b31 for details:
+Who:   Wolfgang Denk <wd@denx.de>
 
-       http://git.denx.de/?p=u-boot.git;a=commit;h=f1d2b31
+---------------------------
 
-       Support for CONFIG_SYS_ARM_WITHOUT_RELOC will be removed
-       after release v2011.03; all boards that have not been
-       converted by then, i. e. that are still broken then, are
-       considered unmaintained and without interest for the
-       community and will be removed as well.
+What:  Remove CONFIG_SYS_ENABLE_PADS_ALL and CONFIG_SYS_CLOCKS_ENABLE_ALL
+When:  Release v2013.07
 
----------------------------
+Why:   When set these options enable "all" of the pads and clocks found
+       on OMAP4/5 platforms, so that the Linux Kernel does not have to.
+       It has been agreed that this goes against the U-Boot design
+       philosophy and since f3f98bb0 we have not enabled more than is
+       used in U-Boot.  The kernel has been updating drivers to enable
+       rather than assume pads/clocks have been enabled already.  Our
+       expectation is that by v2013.07 a suitable kernel shall exist that
+       does not need these options set for a reasonable I/O set to function.
 
-What:  CONFIG_NET_MULTI option
-When:  Release 2009-11
+Who:   Tom Rini <trini@ti.com> and Sricharan R <r.sricharan@ti.com>
+
+---------------------------
 
-Why:   U-boot currently implements two network driver APIs.  New drivers with
-       the older-style implementation have not been accepted for a while, and
-       this parallel system makes the code confusing and hard to augment.
+What:  Users of the legacy miiphy_* code
+When:  undetermined
 
-       All existing in-tree boards will be converted to use CONFIG_NET_MULTI
-       over the span of two releases (2009-07 and 2009-09).
-       In the 2009-11 release, all code that is compiled when CONFIG_NET_MULTI
-       is not set will be removed, and all references to CONFIG_NET_MULTI
-       will be removed, effectively making it the only API.  This should
-       provide ample time for out-of-tree users to adjust, and for tools on
-       all architectures to be made to work with weak functions.
+Why:   We now have a PHY library, which allows everyone to share PHY
+       drivers. All new drivers should use this infrastructure, and
+       all old drivers should get converted to use it.
 
-Who:   Ben Warren <biggerbadderben@gmail.com>
+Who:   Andy Fleming <afleming@freescale.com> and driver maintainers
 
 ---------------------------