- 14 6月, 2013 5 次提交
-
-
由 Andrew Gabbasov 提交于
After waiting for the command completion event, the interrupt status bits, that occured to be set by that time, are cleared by writing them back. It is supposed, that it should be command related bits (command complete and may be command errors). However, in some cases the DMA already completes by that time before the full transaction completes. The corresponding DINT bit gets set and then cleared before even entering the loop, waiting for data part completion. That waiting loop never gets this bit set, causing the operation to hang. This is reported to happen, for example, for write operation of 1 sector to upper area (block #7400000) of SanDisk Ultra II 8GB card. The solution could be to explicitly clear only command related interrupt status bits. However, since subsequent processing does not rely on any command bits state, it could be easier just to remove clearing of any bits at that point, leaving them all until all data processing completes. After that the whole register will be cleared at once. Also, on occasion, interrupts masking moved to before writing the command, just for the case there should be no chance of interrupt between the first command and interrupts masking. Reported-by: NDirk Behme <dirk.behme@de.bosch.com> Signed-off-by: NAndrew Gabbasov <andrew_gabbasov@mentor.com> Acked-by: NDirk Behme <dirk.behme@de.bosch.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 Fabio Estevam 提交于
Since commit 48e0b2bd (powerpc/esdhc: Correct judgement for DATA PIO mode) we see mx6 systems to hang after doing a 'save' command. Revert this commit since the original 'ifdef' logic from 7b43db92 (drivers/mmc/fsl_esdhc.c: fix compiler warnings) was the correct one. Reported-by: NTapani Utriainen <tapani@technexion.com> Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 Ruud Commandeur 提交于
This patch fixes a bug related to mmc writes. When doing fatwrites on an SD-Card, MMC bus problems can occur. Depending on the size of the file, "MMC0: Bus busy timeout!" is reported, resulting in an SD-Card that is no longer responding. It appears to be, that set_cluster can be called with a size being zero. That can be with a file that has a size being an exact multiple (including 0) of the clustersize, but also for files that are smaller than the size of one cluster. The same problem occurs if the "mmc write" command is given with a block count being 0. By adding a check for the block count being zero in mmc_write_blocks (drivers/mmc.c), this problem is solved. Signed-off-by: NRuud Commandeur <rcommandeur@clb.nl> Cc: Tom Rini <trini@ti.com> Cc: Benoît Thébaudeau <benoit.thebaudeau@advansee.com> Cc: Mats Karrman <Mats.Karrman@tritech.se> Cc: Andy Fleming <afleming@gmail.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
CAP register don't have any information for 8-bit buswidth support on 2.0 sdhci spec, only from 3.0 onwards bit[18] got this information. Due to this misassignment in sdhci, mmc is setting 8-bit buswidth using mmc_set_bus_width even if controller doesn't support. Below change has code information. "mmc: Properly determine maximum supported bus width" (sha1: 7798f6db) Bug log: <mmc plus and emmc cards) ------- zynq-uboot> mmcinfo Error detected in status(0x208100)! Device: zynq_sdhci Manufacturer ID: fe ..... So enable 8-bit support only for 3.0 spec using CAP and for below 3.0 assign mmc->host_caps = MMC_MODE_8BIT on respective platform driver if host have a support. Signed-off-by: NJagannadha Sutradharudu Teki <jaganna@xilinx.com> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
由 Bo Shen 提交于
The commit d196bd88 (env_mmc: add support for redundant environment) introduce the following compile error when enable redundant environment support with MMC ---8<--- env_mmc.c:149: error: 'env_t' has no member named 'flags' env_mmc.c:248: error: 'env_t' has no member named 'flags' env_mmc.c:248: error: 'env_t' has no member named 'flags' env_mmc.c:250: error: 'env_t' has no member named 'flags' env_mmc.c:250: error: 'env_t' has no member named 'flags' env_mmc.c:252: error: 'env_t' has no member named 'flags' env_mmc.c:252: error: 'env_t' has no member named 'flags' env_mmc.c:254: error: 'env_t' has no member named 'flags' env_mmc.c:254: error: 'env_t' has no member named 'flags' env_mmc.c:267: error: 'env_t' has no member named 'flags' make[1]: *** [env_mmc.o] Error 1 --->8--- Add this patch to fix it Signed-off-by: NBo Shen <voice.shen@atmel.com> Reviewed-by: NMichael Heimpold <mhei@heimpold.de> Signed-off-by: NAndy Fleming <afleming@freescale.com>
-
- 12 6月, 2013 3 次提交
-
-
-
由 Marek Vasut 提交于
The flash_info_t->start[] field is limited in size by CONFIG_SYS_MAX_FLASH_SECT macro, which is set to 19 for this board in the board config file. If we inspect the board/ppmc7xx/flash.c closely, especially the flash_get_size() function, we can notice the "switch ((long)flashtest)" at around line 80 having a few results which will set flash_info_t->sector_count to value higher than 19, for example "case AMD_ID_LV640U" will set it to 128. Notice that right underneath, iteration over flash_info_t->start[] happens and the upper bound for the interation is flash_info_t->sector_count. Now if the sector_count is 128 as it is for the AMD_ID_LV640U case, but the CONFIG_SYS_MAX_FLASH_SECT limiting the start[] is only 19, an access past the start[] array much happen. Moreover, during this iteration, the field is written to, so memory corruption is inevitable. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Wolfgang Denk <wd@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Richard Danter <richard.danter@windriver.com>
-
由 Scott Wood 提交于
C99's strict aliasing rules are insane to use in low-level code such as a bootloader, but as Wolfgang has rejected -fno-strict-aliasing in the past, add a union so that 16-bit accesses can be performed. Compile-tested only. Signed-off-by: NScott Wood <scottwood@freescale.com> Acked-by: NWolfgang Denk <wd@denx.de>
-
- 09 6月, 2013 2 次提交
-
-
由 Daniel Schwierzeck 提交于
This fixes several warnings like In file included from ./u-boot/include/linux/mtd/mtd.h:13:0, from env_onenand.c:37: ./u-boot/build/vct_platinumavc_onenand_small/include2/asm/errno.h:52:0: warning: "ENOMSG" redefined [enabled by default] Signed-off-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com>
-
由 Gabor Juhos 提交于
The purpose of the __raw* IO accessors is to provide IO access in native-endian order. However in the current MIPS implementation, the 16 and 32 bit variants of the __raw accessors are swapping the values on big-endian systems if the CONFIG_SWAP_IO_SPACE option is enabled. The patch changes the IO accessor macros to fix this broken behaviour. Signed-off-by: NGabor Juhos <juhosg@openwrt.org> Cc: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com>
-
- 08 6月, 2013 8 次提交
-
-
由 Gabor Juhos 提交于
The pci_indirect.c file is always compiled when CONFIG_PCI is defined although the indirect PCI bridge support is not needed by every board. Introduce a new CONFIG_PCI_INDIRECT_BRIDGE config option and only compile indirect PCI bridge support if this options is enabled. Also add the new option into the configuration files of the boards which needs that. Compile tested for powerpc, x86, arm and nds32. MAKEALL results: powerpc: --------------------- SUMMARY ---------------------------- Boards compiled: 641 Boards with warnings but no errors: 2 ( ELPPC MPC8323ERDB ) ---------------------------------------------------------- Note: the warnings for ELPPC and MPC8323ERDB are present even without the actual patch. x86: --------------------- SUMMARY ---------------------------- Boards compiled: 1 ---------------------------------------------------------- arm: --------------------- SUMMARY ---------------------------- Boards compiled: 311 ---------------------------------------------------------- nds32: --------------------- SUMMARY ---------------------------- Boards compiled: 3 ---------------------------------------------------------- Cc: Tom Rini <trini@ti.com> Cc: Daniel Schwierzeck <daniel.schwierzeck@googlemail.com> Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
-
由 Stephen Warren 提交于
Some ARM compilers may emit code that makes unaligned accesses when faced with constructs such as: char mac[16] = "ethaddr"; Replace this with a strcpy() call instead to avoid this. strcpy() is used here, rather than replacing all usage of the mac variable with the string itself, since the loop itself sprintf()s to the variable each iteration, so strcpy() is doing basically the same thing. Reported-by: Florian Meier Signed-off-by: NStephen Warren <swarren@wwwdotorg.org>
-
由 Masahiro Yamada 提交于
This commit refactors common/board_f.c and common/board_r.c in order to delete the dest_addr and dest_addr_sp from gd_t struct. As mentioned as follows in include/asm-generic/global_data.h, /* TODO: is this the same as relocaddr, or something else? */ unsigned long dest_addr; /* Post-relocation address of U-Boot */ dest_addr is the same as relocaddr. Likewise, dest_addr_sp is the same as start_addr_sp. It seemed dest_addr/dest_addr_sp was used only as a scratch variable to calculate relocaddr/start_addr_sp, respectively. With a little refactoring, we can delete dest_addr and dest_addr_sp. Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com> Cc: Simon Glass <sjg@chromium.org>
-
由 Peter Korsgaard 提交于
Jump into full u-boot mode if a 'c' character is received on the uart. We need to adjust the spl bss/malloc area to not overlap with the loadaddr of the kernel (sdram + 32k), so move it past u-boot instead. For raw mmc, we store the kernel parameter area in the free space after the MBR (if used). For nand, we use the last sector of the partition reserved for u-boot. This also enables the spl command in the full u-boot so the kernel parameter area snapshot can be created. Signed-off-by: NPeter Korsgaard <peter.korsgaard@barco.com>
-
由 Peter Korsgaard 提交于
If Falcon mode support is enabled (and the system isn't directed into booting u-boot), it will instead try to load kernel from sector CONFIG_SYS_MMCSD_RAW_MODE_KERNEL_SECTOR and CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTORS of kernel argument parameters starting from sector CONFIG_SYS_MMCSD_RAW_MODE_ARGS_SECTOR. Signed-off-by: NPeter Korsgaard <peter.korsgaard@barco.com>
-
由 Peter Korsgaard 提交于
So we can use it for falcon mode as well. Signed-off-by: NPeter Korsgaard <peter.korsgaard@barco.com>
-
由 Peter Korsgaard 提交于
If Falcon mode support is enabled (and the system isn't directed into booting u-boot), it will instead try to load kernel from CONFIG_SPL_FAT_LOAD_KERNEL_NAME file and kernel argument parameters from CONFIG_SPL_FAT_LOAD_ARGS_NAME, both from the same partition as u-boot. Signed-off-by: NPeter Korsgaard <peter.korsgaard@barco.com>
-
由 Tom Rini 提交于
Signed-off-by: NTom Rini <trini@ti.com>
-
- 07 6月, 2013 4 次提交
-
-
由 Peter Korsgaard 提交于
So we can use it for falcon mode as well. Signed-off-by: NPeter Korsgaard <peter.korsgaard@barco.com>
-
由 Peter Korsgaard 提交于
So we can instead fallback to doing something else on errors. Signed-off-by: NPeter Korsgaard <peter.korsgaard@barco.com>
-
-
-
- 06 6月, 2013 6 次提交
-
-
由 Stephen Warren 提交于
[trini: Applied v1 of the series rather than v2, this commit is the delta from v1 to v2] Signed-off-by: NStephen Warren <swarren@nvidia.com> Signed-off-by: NTom Rini <trini@ti.com>
-
由 Tom Rini 提交于
Signed-off-by: NTom Rini <trini@ti.com>
-
由 Tom Rini 提交于
The location of valid scratch space is dependent on SoC, so move that there. On OMAP4+ we continue to use SRAM_SCRATCH_SPACE_ADDR. On am33xx/ti814x we want to use what the ROM defines as "public stack" which is the area after our defined download image space. Correct the comment about and location of CONFIG_SPL_TEXT_BASE. Signed-off-by: NTom Rini <trini@ti.com>
-
由 Stephen Warren 提交于
Add a DT simple-framebuffer node to DT when booting the Linux kernel. This will allow the kernel to inherit the framebuffer configuration from U-Boot, and display a graphical boot console, and even run a full SW- rendered X server. Signed-off-by: NStephen Warren <swarren@wwwdotorg.org> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Stephen Warren 提交于
simple-framebuffer is a new device tree binding that describes a pre- configured frame-buffer memory region and its format. The Linux kernel contains a driver that supports this binding. Implement functions to create a DT node (or fill in an existing node) with parameters that describe the framebuffer format that U-Boot is using. This will be immediately used by the Raspberry Pi board in U-Boot, and likely will be used by the Samsung ARM ChromeBook support soon too. It could well be used by many other boards (e.g. Tegra boards with built-in LCD panels, which aren't yet supported by the Linux kernel). Signed-off-by: NStephen Warren <swarren@wwwdotorg.org> Acked-by: NSimon Glass <sjg@chromium.org>
-
-
- 05 6月, 2013 12 次提交
-
-
-
由 Tom Rini 提交于
We need to call the save_omap_boot_params function on am33xx/ti81xx and other newer TI SoCs, so move the function to boot-common. Only OMAP4+ has the omap_hw_init_context function so add ifdefs to not call it on am33xx/ti81xx. Call save_omap_boot_params from s_init on am33xx/ti81xx boards. Reviewed-by: NR Sricharan <r.sricharan@ti.com> Signed-off-by: NTom Rini <trini@ti.com>
-
由 Tom Rini 提交于
Prior to Sricharan's cleanup of the boot parameter saving code, we did not make use of NON_SECURE_SRAM_START on am33xx, so it wasn't a problem that the address was pointing to the middle of our running SPL. Correct to point to the base location of the download image area. Increase CONFIG_SPL_TEXT_BASE to account for this scratch area being used. As part of correcting these tests, make use of the fact that we've always been placing our stack outside of the download image area (which is fine, once the downloaded image is run, ROM is gone) so correct the max size test to be the ROM defined top of the download area to where we link/load at. Signed-off-by: NTom Rini <trini@ti.com> --- Changes in v2: - Fix typo noted by Peter Korsgaard
-
由 Tom Rini 提交于
Only called in this file, mark as static. Signed-off-by: NTom Rini <trini@ti.com>
-
由 Stephen Warren 提交于
This can be useful to force bootcmd to execute as soon as U-Boot has started. My use-case is: An SoC-specific tool pushes U-Boot into RAM, along with an image to be written to device boot flash, with the DT config property "bootcmd" set to contain a command to write that image to flash. In this scenario, we don't want to allow any stale bootdelay value taken from the current flash content to affect how long it takes before the flashing process starts. Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: NSimon Glass <sjg@chromium.org> Acked-by: NGerald Van Baren <vanbaren@cideas.com>
-
由 Stephen Warren 提交于
We know the exact property names that the code wants to process. Look these up directly with fdt_get_property(), rather than iterating over all properties within the node, and checking each property's name, in a convoluted fashion, against the expected name. Signed-off-by: NStephen Warren <swarren@nvidia.com>
-
由 Stephen Warren 提交于
Initialized character arrays on the stack can cause gcc to emit code that performs unaligned accessess. Make the data static to avoid this. Note that the unaligned accesses are made when copying data to prefix[] on the stack from .rodata. By making the data static, the copy is completely avoided. All explicitly written code treats the data as u8[], so will never cause any unaligned accesses. Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: NSimon Glass <sjg@chromium.org>
-
由 Masahiro Yamada 提交于
The generic-board board_init_f function called board_postclk_init twice. The first one came from arch/arm/lib/board.c, while the second one from arch/powerpc/lib/board.c. This commit deletes the first occurrence. In addition, the second get_clocks call is moved after board_postclk_init in order to keep the function call order both for ARM and PowerPC. ARM board calles get_clocks function after board_postclk_init. Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
-
由 Marek Vasut 提交于
Make sure to never access beyond bounds of either EFI partition name or DOS partition name. This situation is happening: part.h: disk_partition_t->name is 32-byte long part_efi.h: gpt_entry->partition_name is 36-bytes long The loop in part_efi.c copies over 36 bytes and thus accesses beyond the disk_partition_t->name . Fix this by picking the shortest of source and destination arrays and make sure the destination array is cleared so the trailing bytes are zeroed-out and don't cause issues with string manipulation. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Tom Rini <trini@ti.com> Cc: Simon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
The image code is fairly complex with various different options. It would be useful to have comprehensive tests for this. As a start, create a script which tries out loading a kernel/ramdisk/fdt from a FIT and checks that the images appear in the right place in memory. This uses sandbox which now supports bootm and related features. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Now that the code for loading these three images from a FIT is common, we don't need individual boostage IDs for each of them. Note: there are some minor changes in the bootstage numbering, particuarly for kernel loading. I don't believe this matters. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Use map_sysmem() to convert from address to pointer, so that sandbox can print FIT information without crashing. Signed-off-by: NSimon Glass <sjg@chromium.org>
-