- 24 10月, 2018 1 次提交
-
-
- 23 10月, 2018 4 次提交
-
-
由 Tom Rini 提交于
- Split the AArch64 LS10xx and LS20xx builds into their own jobs, and then exclude only ls1/ls2 from the catch-all. This moves the S32V234 job (and future i.MX8*) to the catch-all. - Split spear out from arm926ejs and exclude freescale, not mx from that job. The older Freescale i.MX boards are caught by the catch-all job for Freescale but now we build the non-Freescale older i.MX platforms. Signed-off-by: NTom Rini <trini@konsulko.com>
-
由 Dirk Meul 提交于
Odroid HC2 board is based on Odroid XU4 board, like the Odroid HC1. The linux kernel does not provide a hc2 DTB so the hc1 DTB is also used for the Odroid HC2. Resend because MUA changed whitespace. Signed-off-by: NDirk Meul <dirk.meul@rwth-aachen.de> Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: NLukasz Majewski <lukma@denx.de> Signed-off-by: NMinkyu Kang <mk7.kang@samsung.com>
-
由 Simon Glass 提交于
Unfortunately the test was not included in the original implementation. Add one. Signed-off-by: NSimon Glass <sjg@chromium.org> Signed-off-by: NSimon Glass <sjg@chromium.org>
-
-
- 22 10月, 2018 35 次提交
-
-
由 Sam Protsenko 提交于
Remove "environment" partition and do not read it when booting Android from eMMC. We don't use this partition anymore, so this is just an unintentional leftover. Earlier we were reading dtb file from "environment" partition to feed it further to kernel. Now we are using dtb from FIT image ("boot" partition contains boot_fit.img image), which can be seen from this command: bootm ${loadaddr}#${fdtfile} where "#" character means we have FIT image in ${loadaddr} RAM address. Signed-off-by: NSam Protsenko <semen.protsenko@linaro.org> Acked-by: NPraneeth Bajjuri <praneeth@ti.com>
-
由 Cédric Le Goater 提交于
This is required for the current Linux kernel to reboot. It should also probably be fixed in Linux. Signed-off-by: NCédric Le Goater <clg@kaod.org> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Adam Ford 提交于
The DM37 and OMAP35 SOM-LV SOM-LV products both support a NOR flash part connected to CS2 in addition to the NAND part on CS0. This patch setups the GPMC timings for the MT28 NOR Flash and enables the CFI-Flash driver now that the CFI stuff is in Kconfig Signed-off-by: NAdam Ford <aford173@gmail.com>
-
由 Meul, Dirk 提交于
Instead of keeping a custom environment, use a more generic approach by switching to distro config. Signed-off-by: NDirk Meul <dirk.meul@rwth-aachen.de> Reviewed-by: NFabio Estevam <festevam@gmail.com>
-
由 Heinrich Schuchardt 提交于
Compiling the overlay unit test fails with odroid-c2_defconfig showing errors like: test/overlay/cmd_ut_overlay.c:29:8: error: unknown type name ‘fdt32_t’ Add the missing include. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Bin Meng 提交于
Currently in pmecc_get_sigma(), the code tries to clear the memory pointed by smu with wrong size 'sizeof(int16_t) * ARRAY_SIZE(smu)'. Since smu is actually a pointer, not an array, so ARRAY_SIZE(smu) does not generate correct size to be cleared. In fact, GCC 8.1.0 reports a warning against it: error: division 'sizeof (int16_t * {aka short int *}) / sizeof (int16_t {aka short int})' does not compute the number of array elements [-Werror=sizeof-pointer-div] Fix it by using the correct size. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
-
由 Eugen Hristev 提交于
Add default bootargs for the MMC defconfig to use SD-Card as rootfs Signed-off-by: NEugen Hristev <eugen.hristev@microchip.com>
-
由 Eugen Hristev 提交于
Add the default kernel bootargs according to our NAND flash demo layout: http://www.at91.com/linux4sam/bin/view/Linux4SAM/Sama5d2PtcEKMainPage#NAND_Flash_demo_Memory_mapSigned-off-by: NEugen Hristev <eugen.hristev@microchip.com>
-
由 Eugen Hristev 提交于
Enable onewire support and commands, fdt overlay for the emmc defconfig. Signed-off-by: NEugen Hristev <eugen.hristev@microchip.com>
-
由 Eugen Hristev 提交于
Enable onewire support and commands, fdt overlay for the mmc1 defconfig. Signed-off-by: NEugen Hristev <eugen.hristev@microchip.com>
-
由 Eugen Hristev 提交于
Enable iminfo command with CONFIG_CMD_IMI Signed-off-by: NEugen Hristev <eugen.hristev@microchip.com>
-
由 Eugen Hristev 提交于
Enabled FIT image support and iminfo command for FIT information. Signed-off-by: NEugen Hristev <eugen.hristev@microchip.com>
-
由 Eugen Hristev 提交于
When booting and CPU is detected from cpuid, we also need an environment variable that will be used in boot commands to load the proper devicetree. Signed-off-by: NEugen Hristev <eugen.hristev@microchip.com>
-
由 Adam Ford 提交于
In my haste to migrate SPL to DM, I copied the wrong name. While it really doesn't matter, I'd prefer the name to match the board, so am335x_mmc0 is now called omap3_logic_mmc0 Signed-off-by: NAdam Ford <aford173@gmail.com>
-
由 Adam Ford 提交于
With the new omap_serial driver, this patch uses this instead from the former ns16550_serial driver. Even though the omap_serial driver is essentially the same. Signed-off-by: NAdam Ford <aford173@gmail.com>
-
由 Adam Ford 提交于
With the DM_USB working for USB host features, encapsulate the USB gadget initialization in a precomiler check. If DM is enabled, we don't need to manually initialize the MUSB driver. Signed-off-by: NAdam Ford <aford173@gmail.com>
-
由 Adam Ford 提交于
The default timings are assumming an OMAP36 / AM37 / DM37, but the OMAP35 controller is a bit slower, so DDR may operate out of spec when under stress. This patch checks the processor type and sets the DDR timings according to processor type. Fixes: 5ad4212c ("ARM: DTS: Add Logic PD OMAP35/DM37 SOM-LV and OMAP35 Torpedo") Signed-off-by: NAdam Ford <aford173@gmail.com>
-
由 Adam Ford 提交于
The da850evm does not need this enabled, so this removes a notice that appears during compile time that says "Please remove" Signed-off-by: NAdam Ford <aford173@gmail.com>
-
由 Bin Meng 提交于
Add qemu-x86_64 to the list of targets we use for test.py runs. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Bin Meng 提交于
This updates travis-ci to use QEMU 3.0.0 for testing. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Bin Meng 提交于
grub_x86.efi is for 32-bit QEMU. Generate the 64-bit one. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Bin Meng 提交于
Specify X86_TSC_TIMER_EARLY_FREQ for Quark SoC so that TSC as the early timer can be supported. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Bin Meng 提交于
So far the TSC timer driver supports trying hardware calibration first and using device tree as last resort for its running frequency as the normal timer. However when it is used as the early timer, it only supports hardware calibration and if it fails, the driver just panics. This introduces a new config option to specify the early timer frequency in MHz and it should be equal to the value described in the device tree. Without this patch, the travis-ci testing on QEMU x86_64 target fails each time after it finishes the 'bootefi selftest' as the test.py see an error was emitted on the console like this: TSC frequency is ZERO resetting ... ### ERROR ### Please RESET the board ### It's strange that this error is consistently seen on the travis-ci machine, but only occasionally seen on my local machine (maybe 1 out of 10). Since QEMU x86_64 target enables BOOTSTAGE support which uses early timer, with this fix it should work without any failure. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Bin Meng 提交于
At present in arch_setup_gd() it calls printch(' ') at the end which has been a mystery for a long time as without such call the 64-bit U-Boot just does not boot at all. In fact this is due to the bug that board_init_f() was called with boot_flags not being set. Hence whatever value being there in the rdi register becomes the boot_flags if without such magic call. With a printch(' ') call the rdi register is initialized as 0x20 and this value seems to be sane enough for the whole boot process. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
-
由 Heinrich Schuchardt 提交于
On x86_64 the field global_data_ptr is assigned before relocation. As sections for uninitialized global data (.bss) overlap with the relocation sections (.rela) this destroys the relocation table and leads to spurious errors. Initialization forces the global_data_ptr into a section for initialized global data (.data) which cannot overlap any .rela section. Fixes: a160092a ("x86: Support global_data on x86_64") Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: NBin Meng <bmeng.cn@gmail.com> Tested-by: NBin Meng <bmeng.cn@gmail.com> Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Heinrich Schuchardt 提交于
Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE. We should be warned if other relocation types appear in the relocation sections. This type of message has helped to identify code overwriting a relocation section before relocation and incorrect parsing of relocation tables. Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: NBin Meng <bmeng.cn@gmail.com> Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Heinrich Schuchardt 提交于
Since commit 380d4f78 ("rtc: Allow use of RTC in SPL and TPL") qemu-x86_64_defconfig does not boot anymore. Fixes: 380d4f78 ("rtc: Allow use of RTC in SPL and TPL") Signed-off-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Bin Meng 提交于
There are some sections in current doc saying 64-bit is unsupported. This apparently is out of date. Remove it. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de>
-
由 Bin Meng 提交于
Currently only 32-bit U-Boot for QEMU x86 is documented. Mention the 64-bit support. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Bin Meng 提交于
With the '-march=core2' fix, it seems that we have some luck that the 64-bit U-Boot boots again. However if we examine the disassembly codes there are still SSE instructions elsewhere which means passing cpu type to GCC is not enough to prevent it from generating these instructions. A simple test case is doing a 'bootefi selftest' from the U-Boot shell and it leads to a reset too. The 'bootefi selftest' reset is even seen with the image created by the relative older GCC 5.4.0, the one shipped by Ubuntu 16.04. The reset actually originates from undefined instruction exception caused by these SSE instructions. To keep U-Boot as a bootloader as simple as possible, we don't want to handle such advanced SIMD stuff. To make sure no MMX/SSE instruction sets are generated, tell GCC not to do this. Note AVX is out of the question as CORE2 is old enough to support AVX yet. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Bin Meng 提交于
With newer kernel.org GCC (7.3.0 or 8.1.0), the u-boot.rom image built for qemu-x86_64 target does not boot. It keeps resetting soon after the 32-bit SPL jumps to 64-bit proper. Debugging shows that the reset happens inside env_callback_init(). 000000000113dd85 <env_callback_init>: 113dd85: 41 54 push %r12 113dd87: 55 push %rbp 113dd88: 31 c0 xor %eax,%eax 113dd8a: 53 push %rbx 113dd8b: 0f 57 c0 xorps %xmm0,%xmm0 Executing "xorps %xmm0,%xmm0" causes CPU to immediately reset. However older GCC like 5.4.0 (the one shipped by Ubuntu 16.04) does not generate such instructions that utilizes SSE for this function - env_callback_init() and U-Boot boots without any issue. Explicitly specifying -march=core2 for newer GCC allows U-Boot proper to boot again. Examine assembly codes of env_callback_init and there is no SSE instruction in that function hence U-Boot continues to boot. core2 seems to be the oldest arch in GCC that supports 64-bit. Like 32-bit U-Boot build we use -march=i386 which is the most conservative cpu type so that the image can run on any x86 processor, let's do the same for the 64-bit U-Boot build. Signed-off-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NHeinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Hannes Schmelzer 提交于
Once we get a zero pointer from load_zimage(...) we must bunch out instead of continue boot. Signed-off-by: NHannes Schmelzer <hannes.schmelzer@br-automation.com> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
In initr_bootstage() we call bootstage_mark_name() which ends up calling timer_get_us(). This call happens before initr_dm(), which inits driver model. On x86 we set gd->timer to NULL in the transition from board_init_f() to board_init_r(). See board_init_f_r() for this assignment. So U-Boot knows there is no timer available in the period immediately after relocation. On x86 the timer_get_us() call is implemented as calls to get_ticks() and get_tbclk(). Both of these call dm_timer_init() to set up the timer, if gd->timer is NULL and the early timer is not available. However dm_timer_init() cannot succeed before initr_dm() is called. So it seems that on x86 if we want to use CONFIG_BOOTSTAGE we must enable CONFIG_TIMER_EARLY. Update the Kconfig to handle this. Note: On most architectures we can rely on the pre-relocation memory still being available, so that gd->timer pointers to a valid timer device and everything works correctly. Admittedly this is not strictly correct since the timer device is set up by pre-relocation U-Boot, but normally this is fine. On x86 the 'CAR' (cache-as-RAM) memory used by pre-relocation U-Boot disappears in board_init_f_r() and any attempt to access it will hang. This is the reason why we must mark the timer as invalid when we get to board_init_f_r(). Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
Some platforms use this instead of FSP to set up the platform, including memory. Add support for this in binman. This is needed for chromebook_samus, for example. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
由 Simon Glass 提交于
With bootstage now allocating pre-relocation memory the current amount available is insufficient. Increase it a little. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-