summaryrefslogtreecommitdiff
path: root/include/vxworks.h
AgeCommit message (Collapse)Author
2018-05-07SPDX: Convert all of our single license tags to Linux Kernel styleTom Rini
When U-Boot started using SPDX tags we were among the early adopters and there weren't a lot of other examples to borrow from. So we picked the area of the file that usually had a full license text and replaced it with an appropriate SPDX-License-Identifier: entry. Since then, the Linux Kernel has adopted SPDX tags and they place it as the very first line in a file (except where shebangs are used, then it's second line) and with slightly different comment styles than us. In part due to community overlap, in part due to better tag visibility and in part for other minor reasons, switch over to that style. This commit changes all instances where we have a single declared license in the tag as both the before and after are identical in tag contents. There's also a few places where I found we did not have a tag and have introduced one. Signed-off-by: Tom Rini <trini@konsulko.com>
2018-04-16bootvx: x86: Assign bootaddr based on kernel memory baseBin Meng
On VxWorks x86 its bootline address is at a pre-defined offset @ 0x1200. If 'bootaddr' is not passed via environment variable, we assign its value based on the kernel memory base address. Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
2018-04-16bootvx: x86: Make VxWorks EFI console driver happyBin Meng
When booting from EFI BIOS, VxWorks bootloader stores the EFI GOP framebuffer info at a pre-defined offset @ 0x6100. When VxWorks kernel boots up, its EFI console driver tries to find such a block and if the signature matches, the framebuffer information will be used to initialize the driver. However it is not necessary to prepare an EFI environment for VxWorks's EFI console driver to function (eg: EFI loader in U-Boot). If U-Boot has already initialized the graphics card and set it to a VESA mode that is compatible with EFI GOP, we can simply prepare such a block for VxWorks. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-04-16vxworks: x86: Rename e820info to e820_infoBin Meng
This changes 'struct e820info' to 'struct e820_info' to conform with the coding style. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2018-04-16bootvx: x86: Explicitly clear the bootloader image sizeBin Meng
VxWorks bootloader stores its size at a pre-defined offset @ 0x5004. Later when VxWorks kernel boots up and system memory information is retrieved from the E820 table, the bootloader size will be subtracted from the total system memory size to calculate the size of available memory for the OS. Explicitly clear the bootloader image size otherwise if memory at this offset happens to contain some garbage data, the final available memory size for the kernel is insane. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
2018-04-16bootvx: x86: Prepare e820 related stuff from the given kernel memory base ↵Bin Meng
address At present two environment variables 'e820data'/'e820info' are required to boot a VxWorks x86 kernel, but this is superfluous. The offset of these two tables are actually at a fixed offset from the kernel memory base address and we can provide the kernel memory base address to U-Boot via only one variable 'vx_phys_mem_base'. Note as it name indicates, the physical address should be provided. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2015-10-21cmd: bootvx: Pass E820 information to an x86 VxWorks kernelBin Meng
E820 is critical to the kernel as it provides system memory map information. Pass it to an x86 VxWorks kernel. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Acked-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Jian Luo <jian.luo4@boschrexroth.de>
2015-10-21cmd: bootvx: Always get VxWorks bootline from envBin Meng
So far VxWorks bootline can be contructed from various environment variables, but when these variables do not exist we get these from corresponding config macros. This is not helpful as it requires rebuilding U-Boot, and to make sure these config macros take effect we should not have these environment variables. This is a little bit complex and confusing. Now we change the logic to always contruct the bootline from environments (the only single source), by adding two new variables "bootdev" and "othbootargs", and adding some comments about network related settings mentioning they are optional. The doc about the bootline handling is also updated. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Tom Rini <trini@konsulko.com> Tested-by: Hannes Schmelzer <oe5hpm@oevsv.at>
2013-12-16common/cmd_bootm: extend do_bootm_vxworks to support the new VxWorks boot ↵Miao Yan
interface. The next version VxWorks adopts device tree (for PowerPC and ARM) as its hardware description mechanism. For PowerPC, the boot interface conforms to the ePAPR standard, which is: void (*kernel_entry)(ulong fdt_addr, ulong r4 /* 0 */, ulong r5 /* 0 */, ulong r6 /* EPAPR_MAGIC */, ulong r7 /* IMA size */, ulong r8 /* 0 */, ulong r9 /* 0 */) For ARM, the boot interface is: void (*kernel_entry)(void *fdt_addr) Signed-off-by: Miao Yan <miao.yan@windriver.com> [trini: Fix build error when !CONFIG_OF_FDT is set, typo on PowerPC, missing extern ft_fixup_num_cores] Signed-off-by: Tom Rini <trini@ti.com>
2013-07-24Add GPL-2.0+ SPDX-License-Identifier to source filesWolfgang Denk
Signed-off-by: Wolfgang Denk <wd@denx.de> [trini: Fixup common/cmd_io.c] Signed-off-by: Tom Rini <trini@ti.com>
2012-10-15ppc4xx: Remove IOP480 supportStefan Roese
Since the IOP480 (PPC401/3 variant from PLX) is only used on 2 boards that are not actively maintained, lets remove support for it completely. This way the ppc4xx code will get a bit cleaner. Signed-off-by: Stefan Roese <sr@denx.de> Acked-by: Matthias Fuchs <matthias.fuchs@esd.eu> Acked-by: Marek Vasut <marex@denx.de>
2010-07-04Make sure that argv[] argument pointers are not modified.Wolfgang Denk
The hush shell dynamically allocates (and re-allocates) memory for the argument strings in the "char *argv[]" argument vector passed to commands. Any code that modifies these pointers will cause serious corruption of the malloc data structures and crash U-Boot, so make sure the compiler can check that no such modifications are being done by changing the code into "char * const argv[]". This modification is the result of debugging a strange crash caused after adding a new command, which used the following argument processing code which has been working perfectly fine in all Unix systems since version 6 - but not so in U-Boot: int main (int argc, char **argv) { while (--argc > 0 && **++argv == '-') { /* ====> */ while (*++*argv) { switch (**argv) { case 'd': debug++; break; ... default: usage (); } } } ... } The line marked "====>" will corrupt the malloc data structures and usually cause U-Boot to crash when the next command gets executed by the shell. With the modification, the compiler will prevent this with an error: increment of read-only location '*argv' N.B.: The code above can be trivially rewritten like this: while (--argc > 0 && **++argv == '-') { char *arg = *argv; while (*++arg) { switch (*arg) { ... Signed-off-by: Wolfgang Denk <wd@denx.de> Acked-by: Mike Frysinger <vapier@gentoo.org>
2008-12-09vxworks.h: Fix build problem introduced by commits 29a4c24d/e9084b23Wolfgang Denk
Signed-off-by: Wolfgang Denk <wd@denx.de>
2008-12-07Add vxworks.h to handle CONFIG_SYS_VXWORKS parametersNiklaus Giger
Signed-off-by: Niklaus Giger <niklaus.giger@member.fsf.org>