summaryrefslogtreecommitdiff
path: root/include
AgeCommit message (Collapse)Author
2011-08-24Fix compiler warning of include/lcd.hChe-Liang Chiou
include/lcd.h:240: warning: function declaration isn't a prototype BUG=none TEST=build without above compiler warning Review URL: http://codereview.chromium.org/6648027 Change-Id: I0dbfd8ebce4e71e28c073fd4f074d438211060ec
2011-08-24Make lcd_clear as non-static such that other parts can call it.Tom Wai-Hong Tam
BUG=chromium-os:1305 TEST=emerge-tegra2_seaboard chromeos-u-boot-next successfully Change-Id: Ia1382a4545c2209e830b14909af635753ad40472 Review URL: http://codereview.chromium.org/6651016
2011-08-24Add skeleton of normal firmwareChe-Liang Chiou
BUG=chromium-os:1304 TEST=MAKEALL successfully Review URL: http://codereview.chromium.org/6628008 Change-Id: I71f6ab5afbc8e9c3a569f11c4f2184a1a15c56b1
2011-08-24Rename caller_internal_t to firmware_storage_tChe-Liang Chiou
Renaming the caller_internal_t for better reflecting its purpose. BUG=chromium-os:1302 TEST=MAKEALL successfully Review URL: http://codereview.chromium.org/6594066 Change-Id: I0e28c5934fdbd198ab4fdb278a33d4707767b3c6
2011-08-24Rename cros_rofw to cros_bootstubChe-Liang Chiou
Because read-only firmware may refer to boot stub and recovery firmware. BUG=chromium-os:1302 TEST=MAKEALL successfully Review URL: http://codereview.chromium.org/6591037 Change-Id: I40b0b4f458675b1d129fd09dc1ac7504053883c3
2011-08-24Add statically allocated buffer for GetFirmwareBodyChe-Liang Chiou
These buffers will cache loaded firmware so that boot stub does not have to load them again. This CL also factors out the code that initialize struct fields used by GetFirmwareBody(). BUG=chromium-os:1302 TEST=MAKEALL successfully Review URL: http://codereview.chromium.org/6598032 Change-Id: I64d1e6f1e06edaa53bbf1e723bc0ea3aa88b6b6c
2011-08-24Pass firmware data offsets to GetFirmwareBodyChe-Liang Chiou
Caller to LoadFirmware is required to specify which firmware section to be verified first. BUG=chromium-os:1302 TEST=MAKEALL successfully Review URL: http://codereview.chromium.org/6598031 Change-Id: I7fee789f3e8f7d2aa9d2e768c1cd1cb77fbb0e2e
2011-08-24Fix copyright statementChe-Liang Chiou
BUG=None TEST=None Review URL: http://codereview.chromium.org/6602003 Change-Id: I6dd474c1d111499db8940a8aea43045b6e4e00a6
2011-08-24Move tpm lite API to common include pathRong Chang
In order to run test cases in both Linux user mode and u-boot command mode. The API header tlcl.h must be accessed by both ebuilds. Change-Id: Ic027dc118f26666b88bf54c511e2455a55e4eb8f BUG=chromium-os:10497 TEST=emerge vboot_reference-firmware successfully Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=baa3bbe Review URL: http://codereview.chromium.org/6469089
2011-08-24Display the screens which are stored in GBB BMP block.Tom Wai-Hong Tam
BUG=chromium-os:11368 TEST=manual $ emerge-tegra2_seaboard chromeos-u-boot-next $ emerge-tegra2_seaboard chromeos-bios $ write_tegra_bios --board tegra2 --variant seaboard --bios /build/tegra2_seaboard/u-boot/image.bin $ grep -m1 -E "^[0-9a-fA-F]{8} T _start$" /build/tegra2_seaboard/u-boot/System.map | cut -d " " -f 1 00e08000 $ grep -m1 CONFIG_OFFSET_GBB /build/tegra2_seaboard/u-boot/autoconf.mk | tr -d "\"" | cut -d = -f 2 0x000f0400 $ python -c 'print "0x%x" % (0xe08000 + 0xf0400)' 0xef8400 CrOS> cros bmpblk info 0xef8400 0 screens[0] info: - BMP (1366 x 768) showed on (0, 0) CrOS> cros bmpblk info 0xef8400 1 screens[1] info: - BMP (1366 x 768) showed on (0, 0) CrOS> cros bmpblk display 0xef8400 0 // The developer mode BMP is showing on LCD. CrOS> cros bmpblk display 0xef8400 1 // The recovery mode BMP is showing on LCD. Change-Id: I8bee7b74a3ca3006376838bd7de6a327bb253704 Review URL: http://codereview.chromium.org/6543008
2011-08-24Factor out verified boot required hardware interfaceChe-Liang Chiou
BUG=none TEST=emerge-tegra2_seaboard chromeos-u-boot-next Review URL: http://codereview.chromium.org/6543034 Change-Id: I88dfd38aedd81281415ecb8156181a6cc4d46495
2011-08-24Change GetFirmwareBody to use static firmware layoutChe-Liang Chiou
It is unnecessary to scan the whole flashrom to look for the flashmap because the flashmap is stored in read-only part of flashrom. Furthermore, boot stub should use static firmware layout rather than fmap; this is faster and easier. BUG=chromium-os:1302 TEST=Run following u-boot commands successfully CrOS> cros load_fw 0x10000000 0x00400000 0x10500000 do_load_fw: params.firmware_root_key_blob: 10160180 do_load_fw: params.verification_block_0: 10200000 do_load_fw: params.verification_size_0: 00001128 do_load_fw: params.verification_block_1: 102e0000 do_load_fw: params.verification_size_1: 00001128 do_load_fw: params.kernel_sign_key_blob: 10500000 do_load_fw: params.kernel_sign_key_size: 00000838 DEBUG: LoadFirmware started... DEBUG: TPM: Startup DEBUG: TPM: command 0x99 send/receive failed: 0x800 DEBUG: TPM: Continue self test DEBUG: TPM: command 0x53 send/receive failed: 0x800 DEBUG: Checking key block signature... DEBUG: Firmware 0 is valid. DEBUG: Checking key block signature... DEBUG: Will boot firmware index 0 LoadFirmware returns: LOAD_FIRMWARE_SUCCESS firmware_index: 0 CrOS> mw.b 0x10210100 0x33 0x100 CrOS> cros load_fw 0x10000000 0x00400000 0x10500000 do_load_fw: params.firmware_root_key_blob: 10160180 do_load_fw: params.verification_block_0: 10200000 do_load_fw: params.verification_size_0: 00001128 do_load_fw: params.verification_block_1: 102e0000 do_load_fw: params.verification_size_1: 00001128 do_load_fw: params.kernel_sign_key_blob: 10500000 do_load_fw: params.kernel_sign_key_size: 00000838 DEBUG: LoadFirmware started... DEBUG: TPM: Startup DEBUG: TPM: command 0x99 send/receive failed: 0x800 DEBUG: TPM: Continue self test DEBUG: TPM: command 0x53 send/receive failed: 0x800 DEBUG: Checking key block signature... DEBUG: In RSAVerify(): Hash check failed! DEBUG: Firmware body verification failed. DEBUG: Checking key block signature... DEBUG: Firmware 1 is valid. DEBUG: Will boot firmware index 1 LoadFirmware returns: LOAD_FIRMWARE_SUCCESS firmware_index: 1 CrOS> mw.b 0x102f0100 0x33 0x100 CrOS> cros load_fw 0x10000000 0x00400000 0x10500000 do_load_fw: params.firmware_root_key_blob: 10160180 do_load_fw: params.verification_block_0: 10200000 do_load_fw: params.verification_size_0: 00001128 do_load_fw: params.verification_block_1: 102e0000 do_load_fw: params.verification_size_1: 00001128 do_load_fw: params.kernel_sign_key_blob: 10500000 do_load_fw: params.kernel_sign_key_size: 00000838 DEBUG: LoadFirmware started... DEBUG: TPM: Startup DEBUG: TPM: command 0x99 send/receive failed: 0x800 DEBUG: TPM: Continue self test DEBUG: TPM: command 0x53 send/receive failed: 0x800 DEBUG: Checking key block signature... DEBUG: In RSAVerify(): Hash check failed! DEBUG: Firmware body verification failed. DEBUG: Checking key block signature... DEBUG: In RSAVerify(): Hash check failed! DEBUG: Firmware body verification failed. DEBUG: Alas, no good firmware. LoadFirmware returns: LOAD_FIRMWARE_RECOVERY Review URL: http://codereview.chromium.org/6258021 Change-Id: I6a2ca31e9f5e1295ce4e04c4097f087cee56b135
2011-08-24Add boot stub template of verify boot firmware.Che-Liang Chiou
This CL is intended for parallelizing development and is not the final implementation of the boot stub. BUG=chromium-os:1302 TEST=build successfully Review URL: http://codereview.chromium.org/6048006 Change-Id: I99ddbaae3e07581e9e2a024ba30dab2e2853f74e
2011-08-24Add a dummy LoadKernel driverChe-Liang Chiou
Load kernel with BOOT_FLAG_DEVELOPER and BOOT_FLAG_SKIP_ADDR_CHECK flags on. This CL depends on a previous CL implementing __aeabi_uldivmod. BUG=None TEST=Run u-boot command below with expected output Note: Although the kernel is loaded successfully, the LoadKernel() still fails because TPM stub functions are not implemented yet. CrOS> usb start CrOS> cros bootdev set usb 0 CrOS> cros load_k 0x10000000 0x01000000 DEBUG: GptNextKernelEntry looking at new prio partition 1 DEBUG: GptNextKernelEntry s1 t15 p15 DEBUG: GptNextKernelEntry looking at new prio partition 3 DEBUG: GptNextKernelEntry s0 t15 p0 DEBUG: GptNextKernelEntry looking at new prio partition 5 DEBUG: GptNextKernelEntry s0 t15 p0 DEBUG: GptNextKernelEntry likes that one DEBUG: Found kernel entry at % size % DEBUG: Checking key block hash only... DEBUG: Kernel preamble is good. DEBUG: Partiton is good. DEBUG: Boot_flags = !is_normal DEBUG: Updating GPT header 2 DEBUG: Updating GPT entries 2 DEBUG: Good_partition >= 0 DEBUG: TPM: Lock physical presence DEBUG: TPM: command 0x4000000a send/receive failed: 0x800 DEBUG: Error locking kernel versions. Internal error; reboot to recovery mode Note: tegra2_seaboard build's kernel partition was invalid. You will see "Only invalid kernels found on device" on outputs when you are trying to load a tegra2_seaboard image. Please test with x86-generic image just for now. Review URL: http://codereview.chromium.org/5273008 Change-Id: Id129bb9423d8580e88fe75dd511dfdd61187f275
2011-08-24Add GetFirmwareBody implementationChe-Liang Chiou
The GetFirmwareBody is a part of the interface between bootloader and vboot reference library. The test driver of loading firmware is in a separating CL. See also CL:5278007 Change-Id: Id484f84f3f3e8492c4778f4030ac954d5beecd46 BUG=None TEST=Build successfully Review URL: http://codereview.chromium.org/5311005
2011-08-24Add flashmap to u-bootChe-Liang Chiou
BUG=None TEST=See below 1. Run 'VBOOT_DEBUG=1 make all' successfully 2. On u-boot command prompt run the following: (Assume you load a flashmap/bin/example.bin on address 0x02000000) CrOS> cros fmap 0x02000000 0x0400 fmap_signature: 0x5f5f50414d465f5f fmap_ver_major: 1 fmap_ver_minor: 0 fmap_base: 0x0000000000000000 fmap_size: 0x0400 fmap_name: "example" fmap_nareas: 4 area_offset: 0x00000000 area_size: 0x00000080 area_name: "bootblock" area_flags_raw: 0x01 area_flags: static area_offset: 0x00000080 area_size: 0x00000080 area_name: "normal" area_flags_raw: 0x03 area_flags: static compressed area_offset: 0x00000100 area_size: 0x00000100 area_name: "fallback" area_flags_raw: 0x03 area_flags: static compressed area_offset: 0x00000200 area_size: 0x00000200 area_name: "data" area_flags_raw: 0x00 Review URL: http://codereview.chromium.org/4446003 Change-Id: I90bdcd9e325c5287e16f61ae71dd0f0479f304a6
2011-08-24Implement boot device r/w functions for vbootChe-Liang Chiou
BUG=None TEST=Manual Test procedure: 1. Compile with VBOOT_DEBUG flag on successfully 2. Run u-boot on dev board as follows: (Assume you have mmc device on dev board) CrOS> mmc init CrOS> cros bootdev set mmc 1 CrOS> cros bootdev (info of mmc1) CrOS> read mmc 1 0x20000000 1 2 CrOS> md.b 0x20000000 (mmc1 content) CrOS> cros bootdev read 0x20001000 1 2 CrOS> md.b 0x20001000 (mmc1 content) CrOS> cmp.b 0x20000000 0x20001000 0x400 (compare the blocks, should be identical) Review URL: http://codereview.chromium.org/4001006 Change-Id: I339f9fb63862993f8b9ced80d4c27d6bef0c1bc6
2011-08-24Implement utility functions used by vbootChe-Liang Chiou
BUG=None TEST=Build and run u-boot successfully Change-Id: I3f7643b7d4c193cd6ef6b982ebfb790d56c4d7ab Review URL: http://codereview.chromium.org/3793012
2011-08-24CHROMIUMOS: config: Move to zero delay for U-Boot bootSimon Glass
Now that SPI/UART is fixed pretty well, we can move to a zero boot delay. Hold down a key (e.g. space) before reset to interrupt boot, or use: setenv bootdelay 2 to increase the boot delay to 2 seconds for development. This speeds up the normal boot by 2 seconds. BUG=chromium-os:13228 TEST=Try U-Boot on Seaboard, check it doesn't wait for a boot, but it can be interrupted by holding down a key before reset. Change-Id: I8c433761bd977f750cecd844976574f340c54988 Reviewed-on: http://gerrit.chromium.org/gerrit/400 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-24No retry for USB storage to speed up the resume time.Tom Wai-Hong Tam
In the scenario, a user inserts a USB storage and boots to recovery mode, we required the user to plug the USB out first. However, in the meantime that the system is scanning the USB, the user plugs it out. It may need ~50sec to resume because there are many retry there. This change makes it no retry such that it only takes <1sec to resume. R=clchiou@chromium.org,sjg@chromium.org BUG=chromium-os:10500 TEST=emerge-tegra2_seaboard chromeos-u-boot-next successfully. When the system is scanning the USB storage, plug the USB out. It takes <1sec to resume. Review URL: http://codereview.chromium.org/6685083 Change-Id: I7d002a879bc8f93ccc354b5fc4a28b55a88276d1 Reviewed-on: http://gerrit.chromium.org/gerrit/397 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-24Add tftp speed indicationSimon Glass
This prints a tftp speed indication after the download completes. This is the 3.6 MiB/s indicator below. Tegra2 (SeaBoard) # tftp ... Using asx0 device TFTP from server 172.22.72.144; our IP address is 172.22.73.81 Filename '/tftpboot/uImage-user-seaboard-1'. Load address: 0x408000 Loading: ################################################# 3.6 MiB/s done BUG=chromium-os:13228 TEST=Boot on Seaboard, make sure message appears. Use 'time tftp ...' to make sure that speed reported is approximately right. Change-Id: I5e96e2ef6aa196a6fd8486f2dae0fe11f7464f20 Reviewed-on: http://gerrit.chromium.org/gerrit/225 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-24Add time measurement command to u-bootChe-Liang Chiou
The command "time" takes a command as its argument, executes the command, and reports how much time the command has used. Example usage: ------------------------------------------------------------ CrOS> time sleep 1 time: 1.000 seconds, 1000 ticks CrOS> time sleep 10 time: 10.000 seconds, 10000 ticks ------------------------------------------------------------ R=robotboy@chromium.org,sjg@chromium.org BUG=none TEST=see above Review URL: http://codereview.chromium.org/6670118 Change-Id: I97cb234c68f29e5db1f5a66abbe32ec6e575b847 Reviewed-on: http://gerrit.chromium.org/gerrit/201 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-24Enable time commandSimon Glass
BUG=chromium-os:13228 TEST=time usb start see that timing is produced Tegra2 (SeaBoard) # time usb start (Re)start USB... USB: Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 3 USB Device(s) found scanning bus for storage devices... 0 Storage Device(s) found scanning bus for ethernet devices... 1 Ethernet Device(s) found time: 2.708 seconds, 2708 ticks Tegra2 (SeaBoard) # Change-Id: I93c53d4291ae4e6a97bdccb8250fb171bdb52cbf Reviewed-on: http://gerrit.chromium.org/gerrit/218 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-24usbeth: asix: Do a fast init if link already establishedSimon Glass
The Asix driver takes the link down during init() and then brings it back up. This commit changes this so that if a link has already been established successfully we simply check that the link is still good. This reduces the delay between successive network commands. TEST=bootp; tftp ... - see that delay is now shorter than before. Change-Id: I044e6d12f6c175a87ee3c93bf874b497f9379c3e BUG=chromium-os:14082 TEST=run U-boot; usb start; bootp; bootp See that second bootp happens quickly and link stays up. Change-Id: I79fdf4f099041ed0a077e8a833d66076c1b28402 Reviewed-on: http://gerrit.chromium.org/gerrit/200 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Warren <twarren@nvidia.com>
2011-08-24Add microsecond boot time measurementSimon Glass
This defines the basics of a new boot time measurement feature. This allows logging of very accurate time measurements as the boot proceeds, by using an available microsecond counter. To enable the feature, define CONFIG_BOOTSTAGE in your board config file. Also available is CONFIG_BOOTSTAGE_REPORT which will cause a report to be printed just before handing off to the OS. BUG=chromium-os:13875 TEST=build and boot, check that progress is reported before running Linux: Timer summary in microseconds: Mark Elapsed Stage 0 0 awake 2,181,078 2,181,078 usb_start 11,861,817 9,680,739 bootp_start 11,884,610 22,793 bootp_stop 11,884,689 79 tftp start 15,271,536 3,386,847 tftp done 15,271,568 32 bootm_start 15,406,551 134,983 start_kernel Change-Id: I71b89c8402dc5dec75e68333bd24a6bab7500a1b Reviewed-on: http://gerrit.chromium.org/gerrit/197 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-24Enable SPI environment on SeaboardSimon Glass
This uses the SPI flash on Seaboard to store a 4KB environment. Change-Id: I9378cbe14b4b87ec31cab2f8d96868f371ef2a2d Reviewed-on: http://gerrit.chromium.org/gerrit/192 Tested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Warren <twarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-24Fix Seaboard UART corruption on SPI activityTom Warren
On Seaboard the UART and SPI interfere with each other. This causes the UART to receive spurious zero bytes after SPI transactions and also means that SPI can corrupt a few output characters when it starts up if they are still in the UART buffer. This hack corrects this by making SPI record that it may have corrupted the UART, and making the UART take evasive action. BUG=chromium-os:13228 TEST=Try developer U-Boot on Seaboard, make sure it auto-boots OK now Review URL: http://codereview.chromium.org/6715017 Change-Id: If2281357f177eeb3a19a170ddea22adbcf5942e9 Reviewed-on: http://gerrit.chromium.org/gerrit/191 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-24spi: Tegra2: Add SPI driver for SPIFLASH on SeaboardTom Warren
Change-Id: I306129ca7b8851639d7a062d877933e7c520c7ca Signed-off-by: Tom Warren <twarren@nvidia.com> Reviewed-on: http://gerrit.chromium.org/gerrit/190 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
2011-08-24NS16550: buffer readsScott Wood
This improves the performance of U-Boot when accepting rapid input, such as pasting a sequence of commands. Without this patch, on P4080DS I see a maximum of around 5 mw.l lines can be pasted. With this patch, it handles around 70 lines before lossage, long enough for most things you'd paste. Change-Id: Ic17bce2fe04a3526c2605ad6d58a0d1f172e728f Signed-off-by: Scott Wood <scottwood@freescale.com> Tested-by: Simon Glass <sjg@chromium.org> Reviewed-on: http://gerrit.chromium.org/gerrit/404 Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-24Tegra2: Enable data cacheSimon Glass
This plumbs in support for the Cortex A9's data cache. Since armv7 instructions are used we need to ensure that none of these appear in the instruction stream executed by the ARM7TDMI. BUG=chromium-os:12253 TEST=build and boot U-Boot on Seaboard, check that it makes it to Linux Tegra2 (SeaBoard) # dcache Data (writethrough) Cache is ON Tegra2 (SeaBoard) # Change-Id: I91e6ef847abcb821dcaf482faa31d82b98ba93b8 Reviewed-on: http://gerrit.chromium.org/gerrit/198 Tested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Warren <twarren@nvidia.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2011-08-24armv7: replace CONFIG_L2_OFF with CONFIG_SYS_NO_L2CACHEAneesh V
replace all occurences of CONFIG_L2_OFF with a more appropriate CONFIG_SYS_NO_L2CACHE CONFIG_SYS_NO_L2CACHE has been chosen to be in line with CONFIG_SYS_NO_ICACHE and CONFIG_SYS_NO_DCACHE Signed-off-by: Aneesh V <aneesh@ti.com>
2011-08-24armv7: cache maintenance operations for armv7Aneesh V
- Add a framework for layered cache maintenance - separate out SOC specific outer cache maintenance from maintenance of caches known to CPU - Add generic ARMv7 cache maintenance operations that affect all caches known to ARMv7 CPUs. For instance in Cortex-A8 these opertions will affect both L1 and L2 caches. In Cortex-A9 these will affect only L1 cache - D-cache operations supported: - Invalidate entire D-cache - Invalidate D-cache range - Flush(clean & invalidate) entire D-cache - Flush D-cache range - I-cache operations supported: - Invalidate entire I-cache - Add maintenance functions for TLB, branch predictor array etc. - Enable -march=armv7-a so that armv7 assembly instructions can be used Signed-off-by: Aneesh V <aneesh@ti.com>
2011-08-24Tegra2: config: enable network bootingSimon Glass
This enables networking booting using a USB dongle plugged into the side seaboard port. BUG=chromium-os:13875 TEST=build and boot, check that network boot completes Change-Id: I673bbed5a58ce7981590e49157cbf570129ca1a0 Review URL: http://codereview.chromium.org/6880194
2011-08-24Tegra2: Add USB supportSimon Glass
This adds basic USB support for port 0. The other port is not supported by this CL. BUG=chromium-os:13875 TEST=Put USB stick in side port. Then: Tegra2 (SeaBoard) # ext2load usb 0:3 10000000 /boot/vmlinuz Loading file "/boot/vmlinuz" from usb device 0:3 (gpt3) 2745808 bytes read Tegra2 (SeaBoard) # Change-Id: I10f9228377ee7ed7817bb30bf665d69c5e74f239 Review URL: http://codereview.chromium.org/6896012
2011-08-24GPIO: Tegra2: add GPIO driver for Seaboard and HarmonyTom Warren
Change-Id: Id28ef0061004aa0f6a1d2948557642e27738a06f Signed-off-by: Tom Warren <twarren@nvidia.com>
2011-06-27Minor coding style fixes.Wolfgang Denk
Signed-off-by: Wolfgang Denk <wd@denx.de>
2011-06-23Merge branch 'master' of git://git.denx.de/u-boot-armWolfgang Denk
* 'master' of git://git.denx.de/u-boot-arm: run arm_pci_init after relocation IXP42x PCI rewrite update/fix PDNB3 board update/fix IXDP425 / IXDPG425 boards add dvlhost (dLAN 200 AV Wireless G) board IXP NPE: add support for fixed-speed MII ports update/fix AcTux4 board update/fix AcTux3 board update/fix AcTux2 board update/fix AcTux1 board use -ffunction-sections / --gc-sections on IXP42x support CONFIG_SYS_LDSCRIPT on ARM fix "depend" target in npe directory Fix IXP code to work after relocation was added trigger hardware watchdog in IXP42x serial driver add support for IXP42x Rev. B1 and newer add XScale sub architecture (IXP/PXA) to maintainer list Conflicts: arch/arm/lib/board.c Signed-off-by: Wolfgang Denk <wd@denx.de>
2011-06-23update/fix PDNB3 boardMichael Schwingen
Signed-off-by: Michael Schwingen <michael@schwingen.org>
2011-06-23update/fix IXDP425 / IXDPG425 boardsMichael Schwingen
Signed-off-by: Michael Schwingen <michael@schwingen.org>
2011-06-23add dvlhost (dLAN 200 AV Wireless G) boardMichael Schwingen
Signed-off-by: Michael Schwingen <michael@schwingen.org>
2011-06-23update/fix AcTux4 boardMichael Schwingen
Signed-off-by: Michael Schwingen <michael@schwingen.org>
2011-06-23update/fix AcTux3 boardMichael Schwingen
Signed-off-by: Michael Schwingen <michael@schwingen.org>
2011-06-23update/fix AcTux2 boardMichael Schwingen
Signed-off-by: Michael Schwingen <michael@schwingen.org>
2011-06-23update/fix AcTux1 boardMichael Schwingen
Signed-off-by: Michael Schwingen <michael@schwingen.org>
2011-06-22ARM: drop unsupported 'trab' boardWolfgang Denk
The 'trab' board configuration is broken, and there is nobody who is interested and willing to fix it. Drop it. This includes support for VFD displays which have always been used by this board only. Signed-off-by: Wolfgang Denk <wd@denx.de>
2011-06-21Build fix/update of AFEB9260Sergey Lapin
Make AFEB9260 build again. Based on fix for AT91SAM9260EK. Signed-off-by: Sergey Lapin <slapin@ossfans.org>
2011-06-21cpu9260/9G20: fix board supportEric Benard
Signed-off-by: Eric Bénard <eric@eukrea.com>
2011-06-21AT91 rework: fix TOP9000 files to build againReinhard Meyer
Fix EMK TOP9000 board to build again: - changes required due to ATMEL rework Signed-off-by: Reinhard Meyer <u-boot@emk-elektronik.de>
2011-06-21AT91 rework: fix at91sam(9260/9g20/9xe)ek board port to build again:Reinhard Meyer
Make ATMEL's at91sam9260/9g20/9xe-ek boards build again Signed-off-by: Reinhard Meyer <u-boot@emk-elektronik.de>
2011-06-21Add support for Bluewater Systems Snapper 9260/9G20 modulesRyan Mallon
Add support for Bluewater Systems AT91 based Snapper 9260 and 9G20 single board computer modules. Includes NAND flash and Ethernet support. Signed-off-by: Ryan Mallon <ryan@bluewatersys.com>
generated by cgit v1.2.3 (git 2.0.4) at 2024-09-13 04:29:35 +0000