summaryrefslogtreecommitdiff
path: root/common/hwconfig.c
Commit message (Collapse)AuthorAgeLines
* hwconfig: Fix handling of env_hwconfig, board_hwconfig, and cpu_hwconfigKumar Gala2010-12-09-6/+9
| | | | | | | | | | | | The handling of env_hwconfig, board_hwconfig, and cpu_hwconfig got broken when we removed the boards defining dummy board_hwconfig & cpu_hwconfig values. We fix this by handling the various strings in priority order. If hwconfig_parse returns NULL for a given string we check the next one in order (env_hwconfig, board_hwconfig, followed by cpu_hwconfig). Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
* hwconfig: Fix dummy initialization of {board, cpu}_hwconfigKumar Gala2010-11-30-8/+6
| | | | | | | | | | | | | | | | Since board_hwconfig & cpu_hwconfig are defined as weak and dont have a default value they will get put into the BSS if they aren't defined elsewhere. This is problematic as we try to utilize hwconfig before we've relocated and thus BSS isn't setup. Instead of giving dummy values in the board files that utilize this feature, we can just initialize the variables to an empty string and thus move them out of the BSS if they aren't defined elsewhere. Also made board_hwconfig & cpu_hwconfig arrays to reduce size associated with string pointers vs arrays. Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
* hwconfig: Utilize getenv_f before relocation to allow for larger bufferKumar Gala2010-10-23-1/+20
| | | | | | | | | | | | | | | | Since we use hwconfig in cases before relocation (like getting DDR params on FSL PPC systems), we can have strings that exceed the early small (32 byte) buffer size that getenv will handle. So we explicitly allocate our own buffer on the stack and use if to handle getting the hwconfig env string. We currently utilize a string length of 128 bytes. This allows us to get rid of boot messages like: env_buf too small [32] Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
* hwconfig: Add some unit testsAnton Vorontsov2010-06-29-0/+55
| | | | | | | I use this for testing, and I think this might be useful in the future. Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
* hwconfig: Fix stop characters parsing for subkeysAnton Vorontsov2010-06-29-9/+10
| | | | | | | | | | | | | | | | | | | | | | | | For the following hwconfig string: key1:subkey1=value1,subkey2=value2;key2:value3 The subkey2 cannot be extracted correctly. The parsing code looks for comma as a stopch, but there may be two kind of stop characters: a comma and a semicolon. Currently the code would return "value2;key2:value3", while just "value2" is the correct answer. This patch fixes the issue by making the code aware of multiple stop characters. For old U-Boots, the issue can be workarounded by placing a comma before a semicolon, i.e.: hwconfig=key1:subkey1=value1,subkey2=value2,;key2:value3 Reported-by: York Sun <yorksun@freescale.com> Signed-off-by: Anton Vorontsov <avorontsov@mvista.com>
* Add simple hwconfig infrastructureAnton Vorontsov2009-07-16-0/+210
This patch implements simple hwconfig infrastructure: an interface for software knobs to control a hardware. This is very simple implementation, i.e. it is implemented via `hwconfig' environment variable. Later we could write some "hwconfig <enable|disable|list>" commands, ncurses interface for Award BIOS-like interface, and frame-buffer interface for AMI GUI[1] BIOS-like interface with mouse support[2]. Current implementation details/limitations: 1. Doesn't support options dependencies and mutual exclusion. We can implement this by integrating apt-get[3] into the u-boot. But I didn't bother yet. 2. Since we don't implement hwconfig command, i.e. we're working with the environement directly, there is no way to tell that toggling a particular option will need a reboot to take an effect. So, for now it's advised to always reboot the target after modifying hwconfig variable. 3. We support hwconfig options with arguments. For example, set hwconfig dr_usb:mode=peripheral,phy_type=ulpi That means: - dr_usb - enable Dual-Role USB controller; - dr_usb:mode=peripheral - USB in Function mode; - dr_usb:phy_type=ulpi - USB should work with ULPI PHYs; The purpose of this simple implementation is to define some internal API and then we can continue improving user experience by adding more mature interface, like hwconfig command with bells and whistles. Or not adding, if we feel that current interface fits its needs. [1] http://en.wikipedia.org/wiki/American_Megatrends [2] Regarding ncurses and GUI with mouse support -- I'm just kidding. [3] The comment regarding apt-get is also a joke, meaning that dependency tracking could be non-trivial. For example, for enabling HW feature X we may need to disable Y, and turn Z into reduced mode (like RMII-only interface for ethernet, no MII). It's quite trivial to implement simple cases though. Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com> Acked-by: Kim Phillips <kim.phillips@freescale.com>