- 08 4月, 2014 12 次提交
-
-
由 Mela Custodio 提交于
The conditional is using a variable that is not defined. Signed-off-by: NRommel G Custodio <sessyargc+u-boot@gmail.com>
-
由 Leo Yan 提交于
When flush the d$ with set/way instruction, it need calculate the way's offset = log2(Associativity); but in current uboot's code, it use below formula to calculate the offset: log2(Associativity * 2 - 1), so finally it cannot flush data cache properly. Signed-off-by: NLeo Yan <leoy@marvell.com>
-
由 York Sun 提交于
For ARMv8, U-boot has been running at EL3 with cache and MMU enabled. Without proper setup for EL2, cache and MMU are both disabled (out of reset). Before switching, we need to flush the dcache to make sure the data is in the main memory. Signed-off-by: NYork Sun <yorksun@freescale.com> Acked-by: NDavid.Feng <fenghua@phytium.com.cn>
-
由 Marcel Ziswiler 提交于
Get rid of double VF610_PAD_DDR_A15__DDR_A_15 iomux configuration. Signed-off-by: NMarcel Ziswiler <marcel@ziswiler.com>
-
由 Marcel Ziswiler 提交于
This patch contains several changes required for second Ethernet (enet1/RMII1) port on vf610 - ANADIG PLL5 control definitions required for Ethernet RMII1 clock - Secondary Ethernet (enet1) MAC RMII1 base address definition - RMII1 iomux definitions - VF610_PAD_PTA6__RMII0_CLKOUT iomux definition required for internal (e.g. crystal-less) Ethernet clocking. Signed-off-by: NMarcel Ziswiler <marcel@ziswiler.com> [stefan@agner.ch: regrouped patch] Signed-off-by: NStefan Agner <stefan@agner.ch>
-
由 Marcel Ziswiler 提交于
Add CCM_CCGR0_UART0_CTRL_MASK clock definition and add TX/RX iomux definitions for UART0 (aka. SCI0). Signed-off-by: NMarcel Ziswiler <marcel@ziswiler.com> [stefan@agner.ch: regrouped patch] Signed-off-by: NStefan Agner <stefan@agner.ch>
-
由 Marcel Ziswiler 提交于
The anadig_reg structure started at the wrong offset (fixed by adding reserved_0x000[4]), was missing some reserved field required for alignment purpose (reserved_0x094[3] between pll4_denom and pll6_ctrl) and further contained a too short reserved field causing further miss- alignment (reserved_0x0C4[7]). Also, rename all the reserved fields and using a memory offset based scheme for. Discovered and tested by temporarily putting the following debug instrumentation into board_init(): struct anadig_reg *anadig = (struct anadig_reg *)ANADIG_BASE_ADDR; printf("&anadig->pll3_ctrl=0x%p\n", &anadig->pll3_ctrl); printf("&anadig->pll5_ctrl=0x%p\n", &anadig->pll5_ctrl); Signed-off-by: NMarcel Ziswiler <marcel@ziswiler.com> [stefan@agner.ch: regrouped patch] Signed-off-by: NStefan Agner <stefan@agner.ch>
-
由 Łukasz Majewski 提交于
After Kbuild introduction, the CROSS_COMPILE environment variable has been set to some default value (prefix arm-linux-). This shall be removed since it breaks building u-boot for native arm target (like qemu ARM). Moreover not all compilers have arm-linux- prefix. Additionally the u-boot cross compiles with CROSS_COMPILE= set explicitly- e.g.: CROSS_COMPILE=/ .... /arm-v7a-linux-gnueabi- make Signed-off-by: NLukasz Majewski <l.majewski@samsung.com> Cc: Masahiro Yamada <yamada.m@jp.panasonic.com> Acked-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
-
由 Albert ARIBAUD 提交于
-
由 Nitin Garg 提交于
Since MX6 is Cortex-A9 r2p10, enable software workaround for errata 794072 and 761320. Signed-off-by: NNitin Garg <nitin.garg@freescale.com>
-
由 Nitin Garg 提交于
Full cache line writes to the same memory region from at least two processors might deadlock the processor. Exists on r1, r2, r3 revisions. Signed-off-by: NNitin Garg <nitin.garg@freescale.com> Acked-by: NFabio Estevam <fabio.estevam@freescale.com>
-
由 Nitin Garg 提交于
A short loop including a DMB instruction might cause a denial of service on another processor which executes a CP15 broadcast operation. Exists on r1, r2, r3, r4 revisions. Signed-off-by: NNitin Garg <nitin.garg@freescale.com> Acked-by: NDirk Behme <dirk.behme@de.bosch.com>
-
- 07 4月, 2014 5 次提交
-
-
由 York Sun 提交于
When SoC first boots up, we should invalidate the cache but not flush it. We can use the same function for invalid and flush mostly, with a wrapper. Invalidating large cache can ben slow on emulator, so we postpone doing so until I-cache is enabled, and before enabling D-cache. Signed-off-by: NYork Sun <yorksun@freescale.com> CC: David Feng <fenghua@phytium.com.cn>
-
由 York Sun 提交于
If D-cache is enabled, we need to flush it, and invalidate i-cache before jumping to the new location. This should be done right after relocation. Signed-off-by: NYork Sun <yorksun@freescale.com> CC: David Feng <fenghua@phytium.com.cn>
-
由 York Sun 提交于
Move setting for MAIR and TCR to cache_v8.c, to avoid conflict with sub-architecture. Signed-off-by: NYork Sun <yorksun@freescale.com> CC: David Feng <fenghua@phytium.com.cn>
-
由 Andreas Färber 提交于
Avoids "could not find output section .gnu.hash" ld.bfd errors on openSUSE. Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Tom Rini <trini@ti.com> Signed-off-by: NAndreas Färber <afaerber@suse.de> Acked-by: NSimon Glass <sjg@chromium.org> Tested-by: NSimon Glass <sjg@chromium.org>
-
由 Chin Liang See 提交于
Clock Manager driver will be called to reconfigure all the clocks setting based on user input. The input are passed to Preloader through handoff files Signed-off-by: NChin Liang See <clsee@altera.com> Cc: Albert Aribaud <albert.u.boot@aribaud.net> Cc: Tom Rini <trini@ti.com> Cc: Wolfgang Denk <wd@denx.de> CC: Pavel Machek <pavel@denx.de> Cc: Dinh Nguyen <dinguyen@altera.com> Acked-by: NPavel Machek <pavel@denx.de>
-
- 04 4月, 2014 3 次提交
-
-
由 Marek Vasut 提交于
This patch adds the groundwork for generating signed BootStream, which can be used by the HAB library in i.MX28. We are adding a new target, u-boot-signed.sb , since the process for generating regular non-signed BootStream is much easier. Moreover, the signed bootstream depends on external _proprietary_ _binary-only_ tool from Freescale called 'cst', which is available only under NDA. To make things even uglier, the CST or HAB mandates a kind-of circular dependency. The problem is, unlike the regular IVT, which is generated by mxsimage, the IVT for signed boot must be generated by hand here due to special demands of the CST. The U-Boot binary (or SPL binary) and IVT are then signed by the CST as a one block. But here is the problem. The size of the entire image (U-Boot, IVT, CST blocks) must be appended at the end of IVT. But the size of the entire image is not known until the CST has finished signing the U-Boot and IVT. We solve this by expecting the CST block to be always 3904B (which it is in case two files, U-Boot and the hand-made IVT, are signed in the CST block). Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
-
git://git.denx.de/u-boot-arm由 Stefano Babic 提交于
Conflicts: arch/arm/cpu/arm926ejs/mxs/mxsimage.mx23.cfg arch/arm/cpu/arm926ejs/mxs/mxsimage.mx28.cfg Signed-off-by: NStefano Babic <sbabic@denx.de>
-
由 Stefano Babic 提交于
This reverts commit 53e6b14e. Patch does not merge anymore with u-boot-arm and must be rebased. Signed-off-by: NStefano Babic <sbabic@denx.de>
-
- 02 4月, 2014 5 次提交
-
-
由 Łukasz Majewski 提交于
The u-boot's image TEXT_BASE needs to be changed to 0x43e00000 from 0x78100000. This change provides compatibility with other trats2 (RD_PQ) devices (http://download.tizen.org/releases/system/). Signed-off-by: NLukasz Majewski <l.majewski@samsung.com> Signed-off-by: NMinkyu Kang <mk7.kang@samsung.com>
-
由 Stefano Babic 提交于
Signed-off-by: NStefano Babic <sbabic@denx.de> CC: Fabio Estevam <fabio.estevam@freescale.com>
-
由 Stefano Babic 提交于
Signed-off-by: NStefano Babic <sbabic@denx.de>
-
由 Stefano Babic 提交于
Signed-off-by: NStefano Babic <sbabic@denx.de>
-
由 Albert ARIBAUD 提交于
-
- 01 4月, 2014 13 次提交
-
-
由 Marek Vasut 提交于
Add support for serial console into the i.MX23/i.MX28 SPL. A full, uncrippled serial console support comes very helpful when debugging various spectacular hardware bringup issues early in the process. Because we do not use SPL framework, but have our own minimalistic SPL, which is compatible with the i.MX23/i.MX28 BootROM, we do not use preloader_console_init(), but instead use a similar function to start the console. Nonetheless, to avoid blowing up the size of the SPL binary, this support is enabled only if CONFIG_SPL_SERIAL_SUPPORT is defined, which is disabled by default. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
-
由 Marek Vasut 提交于
Set the GD pointer in the SPL to a defined symbol so various functions from U-Boot can be used without adverse side effects. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
-
由 Marek Vasut 提交于
The DRAM size can be easily detected at runtime on i.MX53. Implement such detection on M53EVK and adjust the rest of the macros accordingly to use the detected values. An important thing to note here is that we had to override the function for trimming the effective DRAM address, get_effective_memsize(). That is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of the available DRAM and we don't have gd->bd->bi_dram[0].size set up at the time the function is called, thus we cannot put this into the macro CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the size of the first DRAM block which we just detected. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Wolfgang Denk <wd@denx.de>
-
由 Marek Vasut 提交于
Fix memory access slowness on i.MX53 M53EVK board. Let us inspect the issue: First of all, the i.MX53 CPU has two memory banks mapped at 0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of DRAM memory. Notice that the memory area is not continuous. On M53EVK, each of the banks contain 512MiB of DRAM, which makes a total of 1GiB of memory available to the system. The problem is how the relocation of U-Boot is treated on i.MX53 . The U-Boot is placed at the ((start of first DRAM partition) + (gd->ram_size)) . This in turn poses a problem, since in our case, the gd->ram_size is 1GiB, the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory. Thus, with this algorithm, U-Boot is placed at offset: 0x7000_0000 + 1GiB - sizeof(u-boot and some small margin) This is past the DRAM available in the first bank on M53EVK, but is still within the address range of the first DRAM bank. Because of the memory wrap-around, the data can still be read and written to this area, but the access is much slower. There were two ideas how to solve this problem, first was to map both of the available DRAM chunks next to one another by using MMU, second was to define CONFIG_VERY_BIG_RAM and CONFIG_MAX_MEM_MAPPED to size of the memory in the first DRAM bank. We choose the later because it turns out the former is not applicable afterall. The former cannot be used in case Linux kernel was loaded into the second DRAM bank area, which would be remapped and one would try booting the kernel, since at some point before the kernel is started, the MMU would be turned off, which would destroy the mapping and hang the system. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Wolfgang Denk <wd@denx.de>
-
由 Marek Vasut 提交于
The DRAM size can be easily detected at runtime on i.MX53. Implement such detection on MX53QSB and adjust the rest of the macros accordingly to use the detected values. An important thing to note here is that we had to override the function for trimming the effective DRAM address, get_effective_memsize(). That is because the function uses CONFIG_MAX_MEM_MAPPED as the upper bound of the available DRAM and we don't have gd->bd->bi_dram[0].size set up at the time the function is called, thus we cannot put this into the macro CONFIG_MAX_MEM_MAPPED . Instead, we use custom override where we use the size of the first DRAM block which we just detected. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Wolfgang Denk <wd@denx.de>
-
由 Marek Vasut 提交于
Fix memory access slowness on i.MX53 MX53QSB board. Let us inspect the issue: First of all, the i.MX53 CPU has two memory banks mapped at 0x7000_0000 and 0xb000_0000 and each of those can hold up to 1GiB of DRAM memory. Notice that the memory area is not continuous. On MX53QSB, each of the banks contain 512MiB of DRAM, which makes a total of 1GiB of memory available to the system. The problem is how the relocation of U-Boot is treated on i.MX53 . The U-Boot is placed at the ((start of first DRAM partition) + (gd->ram_size)) . This in turn poses a problem, since in our case, the gd->ram_size is 1GiB, the first DRAM bank starts at 0x7000_0000 and contains 512MiB of memory. Thus, with this algorithm, U-Boot is placed at offset: 0x7000_0000 + 1GiB - sizeof(u-boot and some small margin) This is past the DRAM available in the first bank on MX53QSB, but is still within the address range of the first DRAM bank. Because of the memory wrap-around, the data can still be read and written to this area, but the access is much slower. There were two ideas how to solve this problem, first was to map both of the available DRAM chunks next to one another by using MMU, second was to define CONFIG_VERY_BIG_RAM and CONFIG_MAX_MEM_MAPPED to size of the memory in the first DRAM bank. We choose the later because it turns out the former is not applicable afterall. The former cannot be used in case Linux kernel was loaded into the second DRAM bank area, which would be remapped and one would try booting the kernel, since at some point before the kernel is started, the MMU would be turned off, which would destroy the mapping and hang the system. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Wolfgang Denk <wd@denx.de>
-
由 Marek Vasut 提交于
Add support for PCIe on MX6 SabreSDP board and enable the support in the config file. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Liu Ying <Ying.Liu@freescale.com>
-
由 Marek Vasut 提交于
Implement a callback to toggle the slot power supply. The callback can be overriden in case some more complex power supply for the slot was implemented in hardware, yet for the usual case, one can define a GPIO which toggles the power to the slot. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de> Cc: Fabio Estevam <fabio.estevam@freescale.com> Cc: Liu Ying <Ying.Liu@freescale.com>
-
由 Eric Nelson 提交于
Use of PCIe on SABRE Lite and Nitrogen6x boards is atypical and requires the use of custom daughter boards. Use in U-Boot is even rarer, so this patch removes it from the standard configuration. Signed-off-by: NEric Nelson <eric.nelson@boundarydevices.com> Acked-by: NMarek Vasut <marex@denx.de>
-
由 Fabio Estevam 提交于
CONFIG_BOOT_INTERNAL is not used anywhere, so let's remove it. Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com> Acked-by: NStefano Babic <sbabic@denx.de>
-
由 Marek Vasut 提交于
Add yet another OCOTP driver for this i.MX family. This time, it's a driver for the OCOTP variant found in the i.MX23 and i.MX28. This version of OCOTP is too different from the i.MX6 one that I could not use the mxc_ocotp.c driver without making it into a big pile of #ifdef . This driver implements the regular fuse command interface, but due to the IP blocks' limitation, we support only READ and PROG functions. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
-
由 Marek Vasut 提交于
This patch adds the groundwork for generating signed BootStream, which can be used by the HAB library in i.MX28. We are adding a new target, u-boot-signed.sb , since the process for generating regular non-signed BootStream is much easier. Moreover, the signed bootstream depends on external _proprietary_ _binary-only_ tool from Freescale called 'cst', which is available only under NDA. To make things even uglier, the CST or HAB mandates a kind-of circular dependency. The problem is, unlike the regular IVT, which is generated by mxsimage, the IVT for signed boot must be generated by hand here due to special demands of the CST. The U-Boot binary (or SPL binary) and IVT are then signed by the CST as a one block. But here is the problem. The size of the entire image (U-Boot, IVT, CST blocks) must be appended at the end of IVT. But the size of the entire image is not known until the CST has finished signing the U-Boot and IVT. We solve this by expecting the CST block to be always 3904B (which it is in case two files, U-Boot and the hand-made IVT, are signed in the CST block). Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
-
由 Marek Vasut 提交于
When using HAB, there are additional special requirements on the placement of U-Boot and the U-Boot SPL in memory. To fullfill these, this patch moves the U-Boot binary a little further from the begining of the DRAM, so the HAB CST and IVT can be placed in front of the U-Boot binary. This is necessary, since both the U-Boot and the IVT must be contained in single CST signature. To make things worse, the IVT must be concatenated with one more entry at it's end, that is the length of the entire CST signature, IVT and U-Boot binary in memory. By placing the blocks in this order -- CST, IVT, U-Boot, we can easily align them all and then produce the length field as needed. As for the SPL, on i.MX23/i.MX28, the SPL size is limited to 32 KiB, thus we place the IVT at 0x8000 offset, CST right past IVT and claim the size is correct. The HAB library accepts this setup. Finally, to make sure the vectoring in SPL still works even after moving the SPL from 0x0 to 0x1000, we add a small function which copies the vectoring code and tables to 0x0. This is fine, since the vectoring code is position independent. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Stefano Babic <sbabic@denx.de>
-
- 31 3月, 2014 1 次提交
-
-
由 Hannes Petermaier 提交于
Since RTC-Clock is needed on all B&R boards, the OSC will be enabled wihtin SPL-stage. Signed-off-by: NHannes Petermaier <oe5hpm@oevsv.at>
-
- 27 3月, 2014 1 次提交
-
-
由 Stephen Warren 提交于
I2C protocol requires open-drain IOs. Fix the Dalmore and Venice2 pinmux tables to configure the IOs correctly. Without this, Tegra may actively drive the lines high while an external device is actively driving the lines low, which can only lead to bad things. Signed-off-by: NStephen Warren <swarren@nvidia.com> Acked-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NTom Warren <twarren@nvidia.com>
-