Re: [U-Boot] No console output once kernel starts loading.
Hi David, On 05/03/15 09:46, DaveKucharczyk wrote: I'm currently working on the kernel dtb for our MX53 board. U-boot loads the dtb and kernel and then gets stuck at starting kernel I've triple checked the uart pad setup in imx53.dtsi This is probably a long shot, but I had the same issue when I did the original x86 port. It turned out that I had not routed the UART interrupt signal correctly in U-Boot - I think the Linux kernel may have been waiting on some kind of interrupt from the UART (probably buffer empty) before it sent anything to it. Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Let's bury CONFIG_NEEDS_MANUAL_RELOC
Hi Guys, Since I did the initial 'full relocation' for x86 way back when (http://git.denx.de/?p=u-boot.git;a=commit;h=1c409bc7101a24ecd47a13a4e851845d66dc23ce), there has been a lot of chatter about the ongoing need for CONFIG_NEEDS_MANUAL_RELOC. I think it's about time we looked really hard at this define and come to a definitive conclusion as to IF and HOW we can get rid of it for the remaining architectures that use it (being avr32, m68k, nds32, and sparc). First, a bit of a primer on why and how I finally killed off CONFIG_NEEDS_MANUAL_RELOC for x86... Despite the best intentions of the 'manual' relocation performed by U-Boot, there were still instances where the U-Boot binary referenced the 'unrelocated' image which typically resides in flash (NOR flash in the case of the x86 board I was using). I only finally tracked this down through some arduous debugging of random crashes during the writing of a new U-Boot image to the NOR flash. After a lot of digging around, I managed to get a good understanding of the ELF binary format for x86 and compiler/linker flags needed in order to generate a binary image that could be relocated. It turns out that for x86, it was the -pic and --emit-relocs ld flags (Oddly, I cannot find the -pic flag in the gnu ld documentation maybe it's depricated?) The --emit-relocs flags leaves the relocation sections (for x86 the section of interest is .rela.dyn) in the final image. These sections list all the locations in the final binary that need to be adjusted if the image is loaded at a different address than the one it is compiled for. You can see the processing in do_elf_reloc_fixups() in arch/x86/lib/relocate.c Keep in mind that the relocation sections are NOT copied to RAM - they are only used once after U-Boot is copied to RAM to locate the memory locations that need to be adjusted. So the crux of generic relocation is to generate a stripped binary with all necessary ELF relocation information located AFTER the text and data sections which are copied to RAM So the first question that we need to answer is: Do the avr32, m68k, nds32, and sparc toolchains support the generation of the relevant sections needed to perform relocation in a manner similar to x86 (i.e generation of relocation references into sections of the final U-Boot binary)? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC
Hi Simon, Maybe I asked this before, but when can we remove CONFIG_NEEDS_MANUAL_RELOC? What platforms need it? A quick grep yields a global define of CONFIG_NEEDS_MANUAL_RELOC for avr32, m68k, nds32, and sparc Next question is - which of these platforms have toolchains which lack the ability to generate the relocation tables that we need? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH] dm: Add support for all targets which requires MANUAL_RELOC
Hi Albert, If we use SPL, we do not have to relocate code, I think. SPL doesn't have relocation that's why this code is not used there. It is not what I meant. If SPL can directly load the main u-boot image to the DRAM address where it is linked, we do not relocate the code in the main image. Current behavior is that SPL is reading u-boot.img entry point which can be in any location and jump to it and u-boot self relocate to the end of memory. If SPL adds u-boot directly to the location where it should run after relocation then relocation is not needed. To ensure this capability (based on my poor GOT/REL/RELA) experience it means that SPL loads u-boot to that location and patch REL/RELA section based on this location and internal relocation should be skipped. I've always thought the logical approach would be for SPL to calculate where U-Boot would end up in RAM, copy it from wherever (NAND, NOR, MMC, whatever) to the final location, perform the relocation fixups, then jump straight into U-Boot. It's pretty much what the Dynamic Loader does (particularly with address space layout randomization) IOW, that SPL perform the work of relocate_code() in U-Boot -- at least, on ARM, where REL/RELA is used. This is definitely doable for REL/RELA case and it can also speedup boot process Not sure about the speed-up, but never mind. It will save a RAM to RAM copy of u-boot's text and data sections. However, running the relocation code in SPL may be even slower (depending on configuration of caches). (I don't think there is easy way how to solve this with just GOT relocation because of that MANUAL_RELOC code which is patching arrays with function pointers). Even without importing SPL in the equation, switching from GOT to REL/RELA has enourmous advantages. I must admit, I'm really rusty with GOT vs REL/RELA - anyone care to give me a refresher? But yes, only having to deal with REL/RELA sections will make the relocation procedures much simpler Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Let's bury CONFIG_NEEDS_MANUAL_RELOC
Hi Albert, On 04/02/15 21:29, Albert ARIBAUD wrote: Hello Graeme, On Wed, 04 Feb 2015 18:14:22 +1100, Graeme Russ gr...@tss-engineering.com wrote: So the first question that we need to answer is: Do the avr32, m68k, nds32, and sparc toolchains support the generation of the relevant sections needed to perform relocation in a manner similar to x86 (i.e generation of relocation references into sections of the final U-Boot binary)? Those arches which use GCC should be able to use -pie / -pic-executable and possibly --emit-relocs, as none of these is arch-specific. That was my understanding too - it's a function of ELF, not the architecture. Then, each arch might have to look into what GCC options are needed. For the record, on ARM, I did not need any gcc option, but actually had one -fPIC option /removed/. Yes, I vaguely remember this. The difference is that -fPIC is used for relocatable LIBRARIES whereas -fPIE is used for relocatable EXECUTABLES. Since U-Boot is a monolithic executable, -fPIC makes no sense Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH v2] Add support for ReachTech G2C1 board
This patch adds U-Boot support for the Reachtech G2C1 board. G2C1 U-Boot images created with this patch will perform the following: - Initialise the MX28 for 'No Battery' mode - Configure all IOMUXs - Configure GPIO directions for all IOMUXs designed for GPIO use - Inilialise the MMC sub-system - Initialise the Ethernet sub-system NOTE: The 'arm: mxs: Enable booting of mx28 without battery' patch MUST be applied prior to building G2C1 images using this patch Refer to the README file for detailed documentation Signed-off-by: Graeme Russ gr...@tss-engineering.com Cc: Albert Aribaud albert.u.b...@aribaud.net Cc: Stefano Babic sba...@denx.de Cc: Marek Vasut ma...@denx.de Cc: u-boot@lists.denx.de Cc: Brent Larson blar...@reachtech.com Cc: Jonathan More jm...@reachtech.com Cc: Jeff Horn jh...@reachtech.com Cc: Wolfgang Denk w...@denx.de --- Changes in v2 - Moved IOMUX documenations into README file - Expanded README file to cover considerably more information - Setup all GPIO pins in g2c1.c - Created two configurations - g2c1_mmc_defconfig for building for MMC image and g2c1_nand_defconfig for building NAND image - Fixed up Ethernet initialisation arch/arm/Kconfig | 13 ++ board/reachtech/g2c1/Kconfig | 15 ++ board/reachtech/g2c1/MAINTAINERS | 7 + board/reachtech/g2c1/Makefile| 12 ++ board/reachtech/g2c1/README | 438 +++ board/reachtech/g2c1/g2c1.c | 142 + board/reachtech/g2c1/spl_boot.c | 236 + configs/g2c1_mmc_defconfig | 4 + configs/g2c1_nand_defconfig | 4 + include/configs/g2c1.h | 307 +++ 10 files changed, 1178 insertions(+) create mode 100644 board/reachtech/g2c1/Kconfig create mode 100644 board/reachtech/g2c1/MAINTAINERS create mode 100644 board/reachtech/g2c1/Makefile create mode 100644 board/reachtech/g2c1/README create mode 100644 board/reachtech/g2c1/g2c1.c create mode 100644 board/reachtech/g2c1/spl_boot.c create mode 100644 configs/g2c1_mmc_defconfig create mode 100644 configs/g2c1_nand_defconfig create mode 100644 include/configs/g2c1.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 5eb1d03..320041e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -278,6 +278,18 @@ config TARGET_XFI3 select CPU_ARM926EJS select SUPPORT_SPL +config TARGET_G2C1 + bool Support ReachTech G2C1 + select CPU_ARM926EJS + select SUPPORT_SPL + help + This is the Reachtech G2C1 development board. It contains a + Freescale MX28 SoC, 128MB DDR2 SDRAM, 128MB SLC NAND, 1x Ethernet + port, 2x USB Host ports, 1x USB OTG port, 1x RS-232 Debug port, + 1x RS-232 User port, 2x RS485 ports, Onboard audio, LCD Touch + screen interface, SD Card slot, I2C and SPI (with 2x slave select + lines) interfaces, CAN interface, and 8 GPIO (I2C slave interface) + config TARGET_M28EVK bool Support m28evk select CPU_ARM926EJS @@ -940,6 +952,7 @@ source board/phytec/pcm051/Kconfig source board/ppcag/bg0900/Kconfig source board/pxa255_idp/Kconfig source board/raspberrypi/rpi/Kconfig +source board/reachtech/g2c1/Kconfig source board/ronetix/pm9261/Kconfig source board/ronetix/pm9263/Kconfig source board/ronetix/pm9g45/Kconfig diff --git a/board/reachtech/g2c1/Kconfig b/board/reachtech/g2c1/Kconfig new file mode 100644 index 000..5ef821f --- /dev/null +++ b/board/reachtech/g2c1/Kconfig @@ -0,0 +1,15 @@ +if TARGET_G2C1 + +config SYS_BOARD + default g2c1 + +config SYS_VENDOR + default reachtech + +config SYS_SOC + default mxs + +config SYS_CONFIG_NAME + default g2c1 + +endif diff --git a/board/reachtech/g2c1/MAINTAINERS b/board/reachtech/g2c1/MAINTAINERS new file mode 100644 index 000..257888b --- /dev/null +++ b/board/reachtech/g2c1/MAINTAINERS @@ -0,0 +1,7 @@ +G2C1 BOARD +M: Graeme Russ gr...@tss-engineering.com +S: Maintained +F: board/reachtech/g2c1/ +F: include/configs/mx28evk.h +F: configs/g2c1_mmcconfig +F: configs/g2c1_nandconfig diff --git a/board/reachtech/g2c1/Makefile b/board/reachtech/g2c1/Makefile new file mode 100644 index 000..9bb55e8 --- /dev/null +++ b/board/reachtech/g2c1/Makefile @@ -0,0 +1,12 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +ifndef CONFIG_SPL_BUILD +obj-y := g2c1.o +else +obj-y := spl_boot.o +endif diff --git a/board/reachtech/g2c1/README b/board/reachtech/g2c1/README new file mode 100644 index 000..745bcdc --- /dev/null +++ b/board/reachtech/g2c1/README @@ -0,0 +1,438 @@ +ReachTech G2C1 +== + +Supported hardware: ReachTech G2C1 + +Reference Documentation +--- +doc/README.mxs + +Files of the G2C1 port +-- +arch/arm/cpu/arm926ejs/mxs/- The CPU support code for the Freescale i.MX28
[U-Boot] [v3 PATCH 1/3] arm: mxs: Add debug outputs and comments to mxs SPL source files
It is difficult to track down fail to boot issues in the mxs SPL.
Implement the following to make it easier:
- Add debug outputs to allow tracing of SPL progress in order to track
where failure to boot occurs. DEUBUG and CONFIG_SPL_SERIAL_SUPPORT must
be defined to enable debug output in SPL
- Add TODO comments where it is not clear if the code is doing what it
is meant to be doing, even tough the board boots properly (these comments
refer to existing code, not to any code added by this patch)
Signed-off-by: Graeme Russ gr...@tss-engineering.com
---
Changes in v2
- Add missing newlines
- Add commit message
Changed in v3
- None
---
arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 1 +
arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c | 13 +++-
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 18 +
arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 100 +++-
4 files changed, 127 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index d29b9aa..2a5f817 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -147,6 +147,7 @@ void mxs_common_spl_init(const uint32_t arg, const uint32_t
*resptr,
mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size);
mxs_spl_console_init();
+ debug(SPL: Serial Console Initialised\n);
mxs_power_init();
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
index cdfcddd..96bd32f 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
@@ -18,6 +18,8 @@ void mxs_lradc_init(void)
{
struct mxs_lradc_regs *regs = (struct mxs_lradc_regs *)MXS_LRADC_BASE;
+ debug(SPL: Initialisating LRADC\n);
+
writel(LRADC_CTRL0_SFTRST, regs-hw_lradc_ctrl0_clr);
writel(LRADC_CTRL0_CLKGATE, regs-hw_lradc_ctrl0_clr);
writel(LRADC_CTRL0_ONCHIP_GROUNDREF, regs-hw_lradc_ctrl0_clr);
@@ -37,9 +39,15 @@ void mxs_lradc_enable_batt_measurement(void)
{
struct mxs_lradc_regs *regs = (struct mxs_lradc_regs *)MXS_LRADC_BASE;
+ debug(SPL: Enabling LRADC battery measurement\n);
+
/* Check if the channel is present at all. */
- if (!(readl(regs-hw_lradc_status) LRADC_STATUS_CHANNEL7_PRESENT))
+ if (!(readl(regs-hw_lradc_status) LRADC_STATUS_CHANNEL7_PRESENT)) {
+ debug(SPL: LRADC channel 7 is not present - aborting\n);
return;
+ }
+
+ debug(SPL: LRADC channel 7 is present - configuring\n);
writel(LRADC_CTRL1_LRADC7_IRQ_EN, regs-hw_lradc_ctrl1_clr);
writel(LRADC_CTRL1_LRADC7_IRQ, regs-hw_lradc_ctrl1_clr);
@@ -65,6 +73,7 @@ void mxs_lradc_enable_batt_measurement(void)
100, regs-hw_lradc_delay3);
writel(0x, regs-hw_lradc_ch7_clr);
-
writel(LRADC_DELAY_KICK, regs-hw_lradc_delay3_set);
+
+ debug(SPL: LRADC channel 7 configuration complete\n);
}
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index 97ef67d..a744e5d 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -92,6 +92,7 @@ static uint32_t dram_vals[] = {
__weak void mxs_adjust_memory_params(uint32_t *dram_vals)
{
+ debug(SPL: Using default SDRAM parameters\n);
}
#ifdef CONFIG_MX28
@@ -99,8 +100,10 @@ static void initialize_dram_values(void)
{
int i;
+ debug(SPL: Setting mx28 board specific SDRAM parameters\n);
mxs_adjust_memory_params(dram_vals);
+ debug(SPL: Applying SDRAM parameters\n);
for (i = 0; i ARRAY_SIZE(dram_vals); i++)
writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
}
@@ -109,6 +112,7 @@ static void initialize_dram_values(void)
{
int i;
+ debug(SPL: Setting mx23 board specific SDRAM parameters\n);
mxs_adjust_memory_params(dram_vals);
/*
@@ -120,6 +124,7 @@ static void initialize_dram_values(void)
* HW_DRAM_CTL8 is setup as the last element.
* So skip the initialization of these HW_DRAM_CTL registers.
*/
+ debug(SPL: Applying SDRAM parameters\n);
for (i = 0; i ARRAY_SIZE(dram_vals); i++) {
if (i == 8 || i == 27 || i == 28 || i == 35)
continue;
@@ -146,6 +151,8 @@ static void mxs_mem_init_clock(void)
const unsigned char divider = 21;
#endif
+ debug(SPL: Initialising FRAC0\n);
+
/* Gate EMI clock */
writeb(CLKCTRL_FRAC_CLKGATE,
clkctrl_regs-hw_clkctrl_frac0_set[CLKCTRL_FRAC0_EMI]);
@@ -170,6 +177,7 @@ static void mxs_mem_init_clock(void)
clkctrl_regs-hw_clkctrl_clkseq_clr);
early_delay(1);
+ debug(SPL: FRAC0 Initialised\n);
}
static void mxs_mem_setup_cpu_and_hbus(void)
@@ -177,6 +185,8 @@ static void
[U-Boot] [v3 PATCH 2/3] arm: mxs: Enable booting of mx28 without battery
Section 4.1.2 of Freescale Application Note AN4199 describes the configuration required to operate the mx28 from a 5V source without a battery. This patch changes the behaviour of the dropout control of the DC-DC converter (refer to section 11.12.9 of the mx28 Application Processor Reference Manual - Document Number: MCIMX28RM, Rev 2, 08/2013) to the following: - Always use 4P2 Linear Regulator if CONFIG_SYS_MXS_VDD5V_ONLY is defined - Switch between 4P2 Linear Regulator and Battery, using whichever has the highest voltage if CONFIG_SYS_MXS_VDD5V_ONLY isnot set (this is the same as the pre-patch behaviour) Signed-off-by: Graeme Russ gr...@tss-engineering.com Signed-off-by: Damien Gotfroi dgotf...@greenwatch.be --- Changes in v2 - Implemented Damien Gotfroi's simplified version Changes in v3 - Updated commit message - Explicitly use POWER_DCDC4P2_DROPOUT_CTRL_SRC_4P2 for the DCDC4P2_DROPOUT_CONFIG define (it is 0x0 so it make no functional difference) --- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c index 7fb734e..c342217 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c @@ -14,6 +14,13 @@ #include mxs_init.h +#ifdef CONFIG_SYS_MXS_VDD5V_ONLY +#define DCDC4P2_DROPOUT_CONFIG POWER_DCDC4P2_DROPOUT_CTRL_100MV | \ + POWER_DCDC4P2_DROPOUT_CTRL_SRC_4P2 +#else +#define DCDC4P2_DROPOUT_CONFIG POWER_DCDC4P2_DROPOUT_CTRL_100MV | \ + POWER_DCDC4P2_DROPOUT_CTRL_SRC_SEL +#endif /** * mxs_power_clock2xtal() - Switch CPU core clock source to 24MHz XTAL * @@ -303,8 +310,7 @@ static void mxs_power_init_4p2_params(void) clrsetbits_le32(power_regs-hw_power_dcdc4p2, POWER_DCDC4P2_DROPOUT_CTRL_MASK, - POWER_DCDC4P2_DROPOUT_CTRL_100MV | - POWER_DCDC4P2_DROPOUT_CTRL_SRC_SEL); + DCDC4P2_DROPOUT_CONFIG); clrsetbits_le32(power_regs-hw_power_5vctrl, POWER_5VCTRL_CHARGE_4P2_ILIMIT_MASK, -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v3 PATCH 3/3] arm: mxs: Add 'Wait for JTAG user' if booted in JTAG mode
When booting in JTAG mode, there is no way to use soft break-points, and
no way of knowing when SPL has finished executing (so the user can issue
a 'halt' command to load u-boot.bin for example)
Add a debug output and simple loop to stop execution at the completion of
the SPL initialisation as a pseudo break-point when booting in JTAG mode
Signed-off-by: Graeme Russ gr...@tss-engineering.com
---
Changes in v2
- Added and used boot mode #defines
Changes in v3
- Removed extra new-line
---
arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 5 +
arch/arm/include/asm/arch-mxs/sys_proto.h | 17 +
2 files changed, 22 insertions(+)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index 2a5f817..d7956e5 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -157,6 +157,11 @@ void mxs_common_spl_init(const uint32_t arg, const
uint32_t *resptr,
data-boot_mode_idx = bootmode;
mxs_power_wait_pswitch();
+
+ if (mxs_boot_modes[data-boot_mode_idx].boot_pads == MXS_BM_JTAG) {
+ debug(SPL: Waiting for JTAG user\n);
+ asm volatile (x: b x);
+ }
}
/* Support aparatus */
diff --git a/arch/arm/include/asm/arch-mxs/sys_proto.h
b/arch/arm/include/asm/arch-mxs/sys_proto.h
index 062f3de..4678723 100644
--- a/arch/arm/include/asm/arch-mxs/sys_proto.h
+++ b/arch/arm/include/asm/arch-mxs/sys_proto.h
@@ -74,6 +74,23 @@ static const struct mxs_pair mxs_boot_modes[] = {
#endif
};
+#define MXS_BM_USB 0x00
+#define MXS_BM_I2C_MASTER_3V3 0x01
+#define MXS_BM_I2C_MASTER_1V8 0x11
+#define MXS_BM_SPI2_MASTER_3V3_NOR 0x02
+#define MXS_BM_SPI2_MASTER_1V8_NOR 0x12
+#define MXS_BM_SPI3_MASTER_3V3_NOR 0x03
+#define MXS_BM_SPI3_MASTER_1V8_NOR 0x13
+#define MXS_BM_NAND_3V30x04
+#define MXS_BM_NAND_1V80x14
+#define MXS_BM_JTAG0x06
+#define MXS_BM_SPI3_MASTER_3V3_EEPROM 0x08
+#define MXS_BM_SPI3_MASTER_1V8_EEPROM 0x18
+#define MXS_BM_SDMMC0_3V3 0x09
+#define MXS_BM_SDMMC0_1V8 0x19
+#define MXS_BM_SDMMC1_3V3 0x0a
+#define MXS_BM_SDMMC1_1V8 0x1a
+
struct mxs_spl_data {
uint8_t boot_mode_idx;
uint32_tmem_dram_size;
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v3 PATCH 0/3] Add support for booting mx28 boards without a battery
This series adds support for booting mx28 based boards which do not include a battery as per Freescale application note AN4199 Patch 1 adds SPL debug output to help track down where early init of the power block and SDRAM fails (define DEBUG and CONFIG_SPL_SERIAL_SUPPORT in order to enable) Patch 2 (which implements booting without a battery) is based on a patch submitted to the Freescale community forums by Damien Gotfroi (define CONFIG_SYS_MXS_VDD5V_ONLY to enable) Patch 3 adds a useful halt upon completion of SPL in the case that the board is booted in JTAG mode. If SPL debug is enabled, 'Waiting for JTAG user' will be printed to the console when SPL has completed Changes in v2 - Dropped patch which adds Reachtech G2C1 board in order to allow the 'no battery' functionality to be mainlined as soon as possible - Removed the patch which moved the PLL power up from spl_power_init.c to spl_mem_init.c - This patch will be considered in future rework of the power block and SDRAM initialisation code Changes in v3 - Clarified commit message for patch 2 - Used explicit define in patch 2 (define == 0x00, so no functional change) - Removed extra blank line from patch #3 Graeme Russ (3): arm: mxs: Add debug outputs and comments to mxs SPL source files arm: mxs: Enable booting of mx28 without battery arm: mxs: Add 'Wait for JTAG user' if booted in JTAG mode arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 6 ++ arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c | 13 +++- arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 18 + arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 110 ++-- arch/arm/include/asm/arch-mxs/sys_proto.h | 17 + 5 files changed, 157 insertions(+), 7 deletions(-) -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [v2 PATCH 3/3] arm: mxs: Add 'Wait for JTAG user' if booted in JTAG mode
On 24/01/15 14:32, Graeme Russ wrote:
When booting in JTAG mode, there is no way to use soft break-points, and
no way of knowing when SPL has finished executing (so the user can issue
a 'halt' command to load u-boot.bin for example)
Add a debug output and simple loop to stop execution at the completion of
the SPL initialisation as a pseudo break-point when booting in JTAG mode
Signed-off-by: Graeme Russ gr...@tss-engineering.com
---
Changes in v2
- Added and used boot mode #defines
---
arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 6 ++
arch/arm/include/asm/arch-mxs/sys_proto.h | 17 +
2 files changed, 23 insertions(+)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index 2a5f817..d1457e0 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -157,6 +157,12 @@ void mxs_common_spl_init(const uint32_t arg, const
uint32_t *resptr,
data-boot_mode_idx = bootmode;
mxs_power_wait_pswitch();
+
+
My bad - I missed this. I'll post a v3
+ if (mxs_boot_modes[data-boot_mode_idx].boot_pads == MXS_BM_JTAG) {
+ debug(SPL: Waiting for JTAG user\n);
+ asm volatile (x: b x);
+ }
}
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v2 PATCH 2/3] arm: mxs: Enable booting of mx28 without battery
Section 4.1.2 of Freescale Application Note AN4199 describes the configuration required to operate the mx28 from a 5V source without a battery. This patch implements the changes to the Freescale bootlets which allow this configuration to properly boot the mx28 processor Signed-off-by: Graeme Russ gr...@tss-engineering.com Signed-off-by: Damien Gotfroi dgotf...@greenwatch.be --- Changes in v2 - Implemented Damien Gotfroi's simplified version --- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c index 7fb734e..0634c81 100644 --- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c +++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c @@ -14,6 +14,12 @@ #include mxs_init.h +#ifdef CONFIG_SYS_MXS_VDD5V_ONLY +#define DCDC4P2_DROPOUT_CONFIG POWER_DCDC4P2_DROPOUT_CTRL_100MV +#else +#define DCDC4P2_DROPOUT_CONFIG POWER_DCDC4P2_DROPOUT_CTRL_100MV | \ + POWER_DCDC4P2_DROPOUT_CTRL_SRC_SEL +#endif /** * mxs_power_clock2xtal() - Switch CPU core clock source to 24MHz XTAL * @@ -303,8 +309,7 @@ static void mxs_power_init_4p2_params(void) clrsetbits_le32(power_regs-hw_power_dcdc4p2, POWER_DCDC4P2_DROPOUT_CTRL_MASK, - POWER_DCDC4P2_DROPOUT_CTRL_100MV | - POWER_DCDC4P2_DROPOUT_CTRL_SRC_SEL); + DCDC4P2_DROPOUT_CONFIG); clrsetbits_le32(power_regs-hw_power_5vctrl, POWER_5VCTRL_CHARGE_4P2_ILIMIT_MASK, -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v2 PATCH 1/3] arm: mxs: Add debug outputs and comments to mxs SPL source files
It is difficult to track down fail to boot issues in the mxs SPL.
Implement the following to make it easier:
- Add debug outputs to allow tracing of SPL progress in order to track
where failure to boot occurs. DEUBUG and CONFIG_SPL_SERIAL_SUPPORT must
be defined to enable debug output in SPL
- Add TODO comments where it is not clear if the code is doing what it
is meant to be doing, even tough the board boots properly (these comments
refer to existing code, not to any code added by this patch)
Signed-off-by: Graeme Russ gr...@tss-engineering.com
---
Changes in v2
- Add missing newlines
- Add commit message
---
arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 1 +
arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c | 13 +++-
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 18 +
arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 100 +++-
4 files changed, 127 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index d29b9aa..2a5f817 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -147,6 +147,7 @@ void mxs_common_spl_init(const uint32_t arg, const uint32_t
*resptr,
mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size);
mxs_spl_console_init();
+ debug(SPL: Serial Console Initialised\n);
mxs_power_init();
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
index cdfcddd..96bd32f 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
@@ -18,6 +18,8 @@ void mxs_lradc_init(void)
{
struct mxs_lradc_regs *regs = (struct mxs_lradc_regs *)MXS_LRADC_BASE;
+ debug(SPL: Initialisating LRADC\n);
+
writel(LRADC_CTRL0_SFTRST, regs-hw_lradc_ctrl0_clr);
writel(LRADC_CTRL0_CLKGATE, regs-hw_lradc_ctrl0_clr);
writel(LRADC_CTRL0_ONCHIP_GROUNDREF, regs-hw_lradc_ctrl0_clr);
@@ -37,9 +39,15 @@ void mxs_lradc_enable_batt_measurement(void)
{
struct mxs_lradc_regs *regs = (struct mxs_lradc_regs *)MXS_LRADC_BASE;
+ debug(SPL: Enabling LRADC battery measurement\n);
+
/* Check if the channel is present at all. */
- if (!(readl(regs-hw_lradc_status) LRADC_STATUS_CHANNEL7_PRESENT))
+ if (!(readl(regs-hw_lradc_status) LRADC_STATUS_CHANNEL7_PRESENT)) {
+ debug(SPL: LRADC channel 7 is not present - aborting\n);
return;
+ }
+
+ debug(SPL: LRADC channel 7 is present - configuring\n);
writel(LRADC_CTRL1_LRADC7_IRQ_EN, regs-hw_lradc_ctrl1_clr);
writel(LRADC_CTRL1_LRADC7_IRQ, regs-hw_lradc_ctrl1_clr);
@@ -65,6 +73,7 @@ void mxs_lradc_enable_batt_measurement(void)
100, regs-hw_lradc_delay3);
writel(0x, regs-hw_lradc_ch7_clr);
-
writel(LRADC_DELAY_KICK, regs-hw_lradc_delay3_set);
+
+ debug(SPL: LRADC channel 7 configuration complete\n);
}
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index 97ef67d..a744e5d 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -92,6 +92,7 @@ static uint32_t dram_vals[] = {
__weak void mxs_adjust_memory_params(uint32_t *dram_vals)
{
+ debug(SPL: Using default SDRAM parameters\n);
}
#ifdef CONFIG_MX28
@@ -99,8 +100,10 @@ static void initialize_dram_values(void)
{
int i;
+ debug(SPL: Setting mx28 board specific SDRAM parameters\n);
mxs_adjust_memory_params(dram_vals);
+ debug(SPL: Applying SDRAM parameters\n);
for (i = 0; i ARRAY_SIZE(dram_vals); i++)
writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
}
@@ -109,6 +112,7 @@ static void initialize_dram_values(void)
{
int i;
+ debug(SPL: Setting mx23 board specific SDRAM parameters\n);
mxs_adjust_memory_params(dram_vals);
/*
@@ -120,6 +124,7 @@ static void initialize_dram_values(void)
* HW_DRAM_CTL8 is setup as the last element.
* So skip the initialization of these HW_DRAM_CTL registers.
*/
+ debug(SPL: Applying SDRAM parameters\n);
for (i = 0; i ARRAY_SIZE(dram_vals); i++) {
if (i == 8 || i == 27 || i == 28 || i == 35)
continue;
@@ -146,6 +151,8 @@ static void mxs_mem_init_clock(void)
const unsigned char divider = 21;
#endif
+ debug(SPL: Initialising FRAC0\n);
+
/* Gate EMI clock */
writeb(CLKCTRL_FRAC_CLKGATE,
clkctrl_regs-hw_clkctrl_frac0_set[CLKCTRL_FRAC0_EMI]);
@@ -170,6 +177,7 @@ static void mxs_mem_init_clock(void)
clkctrl_regs-hw_clkctrl_clkseq_clr);
early_delay(1);
+ debug(SPL: FRAC0 Initialised\n);
}
static void mxs_mem_setup_cpu_and_hbus(void)
@@ -177,6 +185,8 @@ static void mxs_mem_setup_cpu_and_hbus(void)
struct
[U-Boot] [v2 PATCH 0/3] Add support for booting mx28 boards without a battery
This series adds support for booting mx28 based boards which do not include a battery as per Freescale application note AN4199 Patch 1 adds SPL debug output to help track down where early init of the power block and SDRAM fails (define DEBUG and CONFIG_SPL_SERIAL_SUPPORT in order to enable) Patch 2 (which implements booting without a battery) is based on a patch submitted to the Freescale community forums by Damien Gotfroi (define CONFIG_SYS_MXS_VDD5V_ONLY to enable) Patch 3 adds a useful halt upon completion of SPL in the case that the board is booted in JTAG mode. If SPL debug is enabled, 'Waiting for JTAG user' will be printed to the console when SPL has completed Changes in v2 - Dropped patch which adds Reachtech G2C1 board in order to allow the 'no battery' functionality to be mainlined as soon as possible - Removed the patch which moved the PLL power up from spl_power_init.c to spl_mem_init.c - This patch will be considered in future rework of the power block and SDRAM initialisation code Graeme Russ (3): arm: mxs: Add debug outputs and comments to mxs SPL source files arm: mxs: Enable booting of mx28 without battery arm: mxs: Add 'Wait for JTAG user' if booted in JTAG mode arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 7 ++ arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c | 13 +++- arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 18 + arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 109 ++-- arch/arm/include/asm/arch-mxs/sys_proto.h | 17 + 5 files changed, 157 insertions(+), 7 deletions(-) -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v2 PATCH 3/3] arm: mxs: Add 'Wait for JTAG user' if booted in JTAG mode
When booting in JTAG mode, there is no way to use soft break-points, and
no way of knowing when SPL has finished executing (so the user can issue
a 'halt' command to load u-boot.bin for example)
Add a debug output and simple loop to stop execution at the completion of
the SPL initialisation as a pseudo break-point when booting in JTAG mode
Signed-off-by: Graeme Russ gr...@tss-engineering.com
---
Changes in v2
- Added and used boot mode #defines
---
arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 6 ++
arch/arm/include/asm/arch-mxs/sys_proto.h | 17 +
2 files changed, 23 insertions(+)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index 2a5f817..d1457e0 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -157,6 +157,12 @@ void mxs_common_spl_init(const uint32_t arg, const
uint32_t *resptr,
data-boot_mode_idx = bootmode;
mxs_power_wait_pswitch();
+
+
+ if (mxs_boot_modes[data-boot_mode_idx].boot_pads == MXS_BM_JTAG) {
+ debug(SPL: Waiting for JTAG user\n);
+ asm volatile (x: b x);
+ }
}
/* Support aparatus */
diff --git a/arch/arm/include/asm/arch-mxs/sys_proto.h
b/arch/arm/include/asm/arch-mxs/sys_proto.h
index 062f3de..4678723 100644
--- a/arch/arm/include/asm/arch-mxs/sys_proto.h
+++ b/arch/arm/include/asm/arch-mxs/sys_proto.h
@@ -74,6 +74,23 @@ static const struct mxs_pair mxs_boot_modes[] = {
#endif
};
+#define MXS_BM_USB 0x00
+#define MXS_BM_I2C_MASTER_3V3 0x01
+#define MXS_BM_I2C_MASTER_1V8 0x11
+#define MXS_BM_SPI2_MASTER_3V3_NOR 0x02
+#define MXS_BM_SPI2_MASTER_1V8_NOR 0x12
+#define MXS_BM_SPI3_MASTER_3V3_NOR 0x03
+#define MXS_BM_SPI3_MASTER_1V8_NOR 0x13
+#define MXS_BM_NAND_3V30x04
+#define MXS_BM_NAND_1V80x14
+#define MXS_BM_JTAG0x06
+#define MXS_BM_SPI3_MASTER_3V3_EEPROM 0x08
+#define MXS_BM_SPI3_MASTER_1V8_EEPROM 0x18
+#define MXS_BM_SDMMC0_3V3 0x09
+#define MXS_BM_SDMMC0_1V8 0x19
+#define MXS_BM_SDMMC1_3V3 0x0a
+#define MXS_BM_SDMMC1_1V8 0x1a
+
struct mxs_spl_data {
uint8_t boot_mode_idx;
uint32_tmem_dram_size;
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Enable booting of mx28 without battery
Hi Damien, On 23/01/15 19:03, Damien GOTFROI wrote: Hi, I confirm, my first patch for spl_power_init.c generated DDR errors. And my new (small) patch for spl_power_init.c fixes these errors, it is not my DDR patch. An I can confirm that your smaller patch allows me to boot the G2C1 board. I'll just implement the smaller patch - we can tackle the rest later Thanks for your very helpful experimentation Regards, Graeme Many thanks and best regards, Damien Gotfroi Electronics Engineer GreenWatch S.A. Avenue Lavoisier, 18A B-1300 Wavre Tel. + 32 (0) 10 471 367 dgotf...@greenwatch.be www.greenwatch.be BCE: 0820 144 205 Retrouvez l’actu des thématiques énergétiques sur notre blog Please consider the environment before printing this mail note. « Ce message électronique et ses éventuels fichiers attachés est(sont) destiné(s) à l’usage exclusif de la (les) personne(s) mentionnée(s) comme destinataire. Si vous recevez ce message électronique par erreur, vous n’êtes pas autorisé à utiliser ; dévoiler ; distribuer ; imprimer ou copier tout ou partie de ce message si vous n’en êtes pas le destinataire. GreenWatch décline toute responsabilité pour tout dommage direct ou indirect lié à l’utilisation inappropriée ou frauduleuse de ce message électronique par des personnes non autorisées. En outre, les informations contenues dans ce message électronique sont à caractère exclusivement informatif et GreenWatch ne saurait en garantir l’exactitude ou l’ exhaustivité .Les préjudices occasionnés par l’utilisation d’une information erronée ou incomplète n’entraînent en aucun cas la responsabilité de GreenWatch » -Original Message- From: Graeme Russ [mailto:gr...@tss-engineering.com] Sent: vendredi 23 janvier 2015 05:15 To: Fabio Estevam Cc: U-Boot-Denx; Fabio Estevam; Mårten Wikman; Damien GOTFROI; Stefano Babic; Marek Vašut Subject: Re: [U-Boot] [PATCH 2/5] Enable booting of mx28 without battery Hi Fabio, On 23/01/15 14:49, Fabio Estevam wrote: On Fri, Jan 23, 2015 at 1:27 AM, Graeme Russ gr...@tss-engineering.com wrote: I thought the DDR errors were fixed with Damien's DDR patch. Damien, can you please confirm? His response in the forum was: About the patch posted on January, 6th, you can simply delete it, and empty your recycle bin . It generate DDR errors (I searched a long time in spl_mem_init to find why my DDR was not stable, but it was not a DDR configuration mistake, but a power mistake caused by my patch). Ah - I missed that - my bad. I'll check if his newer patch works. If it does, I'll implement it instead. Best to make these kind of changes one small step at a time :) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Enable booting of mx28 without battery
Hi Fabio, On 22/01/15 23:42, Fabio Estevam wrote: Hi Graeme, On Wed, Jan 21, 2015 at 9:55 AM, Graeme Russ gr...@tss-engineering.com wrote: Section 4.1.2 of Freescale Application Note AN4199 describes the configuration required to operate the mx28 from a 5V source without a battery. This patch implements the changes to the Freescale bootlets which allow this configuration to properly boot the mx28 processor Signed-off-by: Graeme Russ gr...@tss-engineering.com --- arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 190 +++- doc/README.mxs | 10 ++ Damien posted today a new version of this patch in the imx community, which is a lot simpler. Could you please try it? I've taken a look at it, but decided to leave this patch as-is. Here is what I wrote on the Freescale forum: I'm going to keep my U-Boot patch mostly as-is for a few reasons: - The patch disables battery voltage measurement when there is no battery - The patch disables all code paths relating to booting from battery - The power block configuration is based primarily on the Fressscale bootlets which I think should be retained unless we can come up with some pretty clear and convincing arguments as to why an alternative approach is better I think there is scope for some refactoring of the power block setup code in U-Boot, but for now I think it best to leave it as close to the bootlet code sequence as practical Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Using __func__ and __LINE__ in debug outputs
Hi All, What is the general consensus on using __func__ and __LINE__ in debug outputs? My personal opinion is that distinct statements that can be grep'd are better for a couple of reasons: - It keeps the debug statements shorter - If your running a slightly older version of U-Boot, the line numbers (and possibly even the function names) may not match the current version of the source code Regardless of whether we should use __func__ and __LINE__, greping for __func__ yields 1,837 hits with inconsistent usage. Should we not simply have a #define which tells debug() to output the function and line number in a consistent manner? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Enable booting of mx28 without battery
Hi Fabio, On 23/01/15 14:49, Fabio Estevam wrote: On Fri, Jan 23, 2015 at 1:27 AM, Graeme Russ gr...@tss-engineering.com wrote: I thought the DDR errors were fixed with Damien's DDR patch. Damien, can you please confirm? His response in the forum was: About the patch posted on January, 6th, you can simply delete it, and empty your recycle bin . It generate DDR errors (I searched a long time in spl_mem_init to find why my DDR was not stable, but it was not a DDR configuration mistake, but a power mistake caused by my patch). Ah - I missed that - my bad. I'll check if his newer patch works. If it does, I'll implement it instead. Best to make these kind of changes one small step at a time :) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Enable booting of mx28 without battery
Hi Fabio, On 23/01/15 14:01, Fabio Estevam wrote: On Fri, Jan 23, 2015 at 12:58 AM, Graeme Russ gr...@tss-engineering.com wrote: I've taken a look at it, but decided to leave this patch as-is. Here is what I wrote on the Freescale forum: Still curious: does the updated patch from Damien allow your system to boot or not? It is on today's todo list I'm going to keep my U-Boot patch mostly as-is for a few reasons: - The patch disables battery voltage measurement when there is no battery - The patch disables all code paths relating to booting from battery - The power block configuration is based primarily on the Fressscale bootlets which I think should be retained unless we can come up with some pretty clear and convincing arguments as to why an alternative approach is better ,but my understanding is that the original patch does not work on Damien's board as it gives DDR errors. I thought the DDR errors were fixed with Damien's DDR patch. Damien, can you please confirm? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Enable booting of mx28 without battery
Hi Marek, On 22/01/15 10:27, Marek Vasut wrote: On Wednesday, January 21, 2015 at 12:55:15 PM, Graeme Russ wrote: Section 4.1.2 of Freescale Application Note AN4199 describes the configuration required to operate the mx28 from a 5V source without a battery. This patch implements the changes to the Freescale bootlets which allow this configuration to properly boot the mx28 processor Signed-off-by: Graeme Russ gr...@tss-engineering.com I have to admit I don't really like this boatload of new ifdeffery. Isn't it possible to detect if the battery is or isn't connected at runtime ? I doubt it. If you look at the circuit in AN4199, the BATTERY and DCDC_BATT pins are hooked up to VDD4P2 via 1k resistors. What the mx28 does internally is measure the voltages on the VDD5V and either BATTERY/DCDC_BATT pins and decides which to use (preferencing the battery unless it goes below a threshold). Without this patch, the mx28 sees a good battery voltage and switches to battery mode which is drawn of DCDC4P2 which is now trying to be driven by the battery input which, of course, will not work. So the only way to figure it out at runtime would be to have the battery inputs at 0v so you could see there is no battery. The only other option would be to use a GPIO pin Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] Add support for ReachTech G2C1 board
On 22/01/15 10:03, Marek Vasut wrote: On Wednesday, January 21, 2015 at 09:53:30 PM, Fabio Estevam wrote: On Wed, Jan 21, 2015 at 9:55 AM, Graeme Russ gr...@tss-engineering.com wrote: Signed-off-by: Graeme Russ gr...@tss-engineering.com It would be nice to have a commit log with the text you put in the help section that describes the board. Also, the subject should contain proper tags (arm: mxs: blah blah ...) I know - I had them in, but patman complained :( ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Add debug output to mx29 SPL source files
On 22/01/15 10:24, Marek Vasut wrote: On Wednesday, January 21, 2015 at 12:55:14 PM, Graeme Russ wrote: Signed-off-by: Graeme Russ gr...@tss-engineering.com Hi! - Commit message is missing. - Some of the debug outputs are missing newline (\n) character - You can use __func__ and __LINE__ in the debug output to better specify where the debug spit happened. I saw something earlier on the list about this - I thought the feeling was to use descriptive strings that are easy to grep rather than __func__ and __LINE__, or maybe I misread Oh, and the CC list looks pretty random. You can just add Cc: tag into the patches so that git handles it correctly. Cc list was generated by patman (I added Damien as his patch is what mine are based on) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] Add support for ReachTech G2C1 board
Signed-off-by: Graeme Russ gr...@tss-engineering.com --- arch/arm/Kconfig | 13 ++ board/reachtech/g2c1/Kconfig | 15 ++ board/reachtech/g2c1/MAINTAINERS | 9 + board/reachtech/g2c1/Makefile| 12 ++ board/reachtech/g2c1/README | 58 + board/reachtech/g2c1/g2c1.c | 79 +++ board/reachtech/g2c1/spl_boot.c | 452 +++ configs/g2c1_defconfig | 3 + include/configs/g2c1.h | 303 ++ 9 files changed, 944 insertions(+) create mode 100644 board/reachtech/g2c1/Kconfig create mode 100644 board/reachtech/g2c1/MAINTAINERS create mode 100644 board/reachtech/g2c1/Makefile create mode 100644 board/reachtech/g2c1/README create mode 100644 board/reachtech/g2c1/g2c1.c create mode 100644 board/reachtech/g2c1/spl_boot.c create mode 100644 configs/g2c1_defconfig create mode 100644 include/configs/g2c1.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 5eb1d03..320041e 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -278,6 +278,18 @@ config TARGET_XFI3 select CPU_ARM926EJS select SUPPORT_SPL +config TARGET_G2C1 + bool Support ReachTech G2C1 + select CPU_ARM926EJS + select SUPPORT_SPL + help + This is the Reachtech G2C1 development board. It contains a + Freescale MX28 SoC, 128MB DDR2 SDRAM, 128MB SLC NAND, 1x Ethernet + port, 2x USB Host ports, 1x USB OTG port, 1x RS-232 Debug port, + 1x RS-232 User port, 2x RS485 ports, Onboard audio, LCD Touch + screen interface, SD Card slot, I2C and SPI (with 2x slave select + lines) interfaces, CAN interface, and 8 GPIO (I2C slave interface) + config TARGET_M28EVK bool Support m28evk select CPU_ARM926EJS @@ -940,6 +952,7 @@ source board/phytec/pcm051/Kconfig source board/ppcag/bg0900/Kconfig source board/pxa255_idp/Kconfig source board/raspberrypi/rpi/Kconfig +source board/reachtech/g2c1/Kconfig source board/ronetix/pm9261/Kconfig source board/ronetix/pm9263/Kconfig source board/ronetix/pm9g45/Kconfig diff --git a/board/reachtech/g2c1/Kconfig b/board/reachtech/g2c1/Kconfig new file mode 100644 index 000..5ef821f --- /dev/null +++ b/board/reachtech/g2c1/Kconfig @@ -0,0 +1,15 @@ +if TARGET_G2C1 + +config SYS_BOARD + default g2c1 + +config SYS_VENDOR + default reachtech + +config SYS_SOC + default mxs + +config SYS_CONFIG_NAME + default g2c1 + +endif diff --git a/board/reachtech/g2c1/MAINTAINERS b/board/reachtech/g2c1/MAINTAINERS new file mode 100644 index 000..e4e948d --- /dev/null +++ b/board/reachtech/g2c1/MAINTAINERS @@ -0,0 +1,9 @@ +G2C1 BOARD +M: Graeme Russ gr...@tss-engineering.com +S: Maintained +F: board/reachtech/g2c1/ +F: include/configs/mx28evk.h +F: configs/g2c1_defconfig +F: configs/g2c1_auart_console_defconfig +F: configs/g2c1_nand_defconfig +F: configs/g2c1_spi_defconfig diff --git a/board/reachtech/g2c1/Makefile b/board/reachtech/g2c1/Makefile new file mode 100644 index 000..9bb55e8 --- /dev/null +++ b/board/reachtech/g2c1/Makefile @@ -0,0 +1,12 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +ifndef CONFIG_SPL_BUILD +obj-y := g2c1.o +else +obj-y := spl_boot.o +endif diff --git a/board/reachtech/g2c1/README b/board/reachtech/g2c1/README new file mode 100644 index 000..41c7984 --- /dev/null +++ b/board/reachtech/g2c1/README @@ -0,0 +1,58 @@ +ReachTech G2C1 +== + +Supported hardware: ReachTech G2C1 is supported in U-boot. + +Files of the MX28EVK port +-- + +arch/arm/cpu/arm926ejs/mxs/- The CPU support code for the Freescale i.MX28 +arch/arm/include/asm/arch-mxs/ - Header files for the Freescale i.MX28 +board/reachtech/g2c1/ - G2C1 board specific files +include/configs/g2c1.h - G2C1 configuration file + +Jumper configuration +- + +To boot G2C1 from an SD card, set the boot mode DIP switches as: + + * Boot Mode Select: 1 0 0 1 (Boot from SD card Slot 0 - U42) + * JTAG PSWITCH RESET: To the right (reset disabled) + * Battery Source: Down + * Wall 5V: Up + * VDD 5V: To the left (off) + * Hold Button: Down (off) + +To boot MX28EVK from SPI NOR flash, set the boot mode DIP switches as: + + * Boot Mode Select: 0 0 1 0 (Boot from SSP2) + * JTAG PSWITCH RESET: To the right (reset disabled) + * Battery Source: Down + * Wall 5V: Up + * VDD 5V: To the left (off) + * Hold Button: Down (off) + +Environment Storage +--- + +There are three targets for mx28evk: + +make mx28evk_config - store environment variables into MMC + +or + +make mx28evk_nand_config - store environment variables into NAND flash + +or + +make mx28evk_spi_config - store enviroment variables into SPI NOR flash + +Choose the target accordingly. + +mx28evk does
[U-Boot] [PATCH 2/5] Enable booting of mx28 without battery
Section 4.1.2 of Freescale Application Note AN4199 describes the
configuration required to operate the mx28 from a 5V source without a
battery. This patch implements the changes to the Freescale bootlets
which allow this configuration to properly boot the mx28 processor
Signed-off-by: Graeme Russ gr...@tss-engineering.com
---
arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 190 +++-
doc/README.mxs | 10 ++
2 files changed, 197 insertions(+), 3 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index 7fb734e..e469381 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -14,6 +14,22 @@
#include mxs_init.h
+#if defined(CONFIG_MX28)
+/*
+ * The minimum DCDC operating voltage for i.MX28 with loading is 3.3V.
+ * we will set the BRWNOUT_LVL bitfield the 3.2V value for 0.1V margin.
+ */
+#define BATTERY_BRWNOUT_BITFIELD_VALUE 20 /* 20 = 3.2V */
+#else
+/*
+ * At the time of this writing, 3V is greater than the minimum DCDC
+ * operating voltage for i.MX233 as listed in by the Battery / DCDC Input
+ * Voltage parameter listed in the reference manual so we will set the
+ * BRWNOUT_LVL bitfield to 3V value.
+ */
+#define BATTERY_BRWNOUT_BITFIELD_VALUE 15 /* 15 = 3.0V */
+#endif
+
/**
* mxs_power_clock2xtal() - Switch CPU core clock source to 24MHz XTAL
*
@@ -88,6 +104,7 @@ static void mxs_power_set_auto_restart(void)
while (readl(rtc_regs-hw_rtc_ctrl) RTC_CTRL_CLKGATE)
;
+#ifdef CONFIG_SYS_MXS_VDD5V_ONLY
/* Do nothing if flag already set */
if (readl(rtc_regs-hw_rtc_persistent0) RTC_PERSISTENT0_AUTO_RESTART)
return;
@@ -103,6 +120,7 @@ static void mxs_power_set_auto_restart(void)
;
while (readl(rtc_regs-hw_rtc_stat) RTC_STAT_STALE_REGS_MASK)
;
+#endif
}
/**
@@ -135,6 +153,7 @@ static void mxs_power_set_linreg(void)
POWER_VDDIOCTRL_LINREG_OFFSET_1STEPS_BELOW);
}
+#ifndef CONFIG_SYS_MXS_VDD5V_ONLY
/**
* mxs_get_batt_volt() - Measure battery input voltage
*
@@ -217,6 +236,7 @@ static int mxs_is_batt_good(void)
debug(SPL: Battery Voltage too low\n);
return 0;
}
+#endif
/**
* mxs_power_setup_5v_detect() - Start the 5V input detection comparator
@@ -301,10 +321,19 @@ static void mxs_power_init_4p2_params(void)
POWER_5VCTRL_HEADROOM_ADJ_MASK,
0x4 POWER_5VCTRL_HEADROOM_ADJ_OFFSET);
+#ifdef CONFIG_SYS_MXS_VDD5V_ONLY
+ debug(SPL: Configuring 4P2 VDD5V only regulator params\n);
+ clrsetbits_le32(power_regs-hw_power_dcdc4p2,
+ POWER_DCDC4P2_DROPOUT_CTRL_MASK,
+ POWER_DCDC4P2_DROPOUT_CTRL_100MV |
+ POWER_DCDC4P2_DROPOUT_CTRL_SRC_4P2);
+#else
+ debug(SPL: Configuring VDD5V + Battery 4P2 regulator params\n);
clrsetbits_le32(power_regs-hw_power_dcdc4p2,
POWER_DCDC4P2_DROPOUT_CTRL_MASK,
POWER_DCDC4P2_DROPOUT_CTRL_100MV |
POWER_DCDC4P2_DROPOUT_CTRL_SRC_SEL);
+#endif
clrsetbits_le32(power_regs-hw_power_5vctrl,
POWER_5VCTRL_CHARGE_4P2_ILIMIT_MASK,
@@ -387,9 +416,11 @@ static void mxs_enable_4p2_dcdc_input(int xfer)
if (!pwd_bo)
clrbits_le32(power_regs-hw_power_minpwr, POWER_MINPWR_PWD_BO);
- while (readl(power_regs-hw_power_ctrl) POWER_CTRL_VBUS_VALID_IRQ)
- writel(POWER_CTRL_VBUS_VALID_IRQ,
- power_regs-hw_power_ctrl_clr);
+ if (xfer)
+ while (readl(power_regs-hw_power_ctrl)
+ POWER_CTRL_VBUS_VALID_IRQ)
+ writel(POWER_CTRL_VBUS_VALID_IRQ,
+ power_regs-hw_power_ctrl_clr);
if (prev_5v_brnout) {
writel(POWER_5VCTRL_PWDN_5VBRNOUT,
@@ -480,6 +511,23 @@ static void mxs_power_init_4p2_regulator(void)
POWER_DCDC4P2_BO_MASK,
22 POWER_DCDC4P2_BO_OFFSET); /* 4.15V */
+#ifdef CONFIG_SYS_MXS_VDD5V_ONLY
+ debug(SPL: Ramping up current limit (VDD5V only)\n);
+
+ tmp = (readl(power_regs-hw_power_5vctrl)
+ POWER_5VCTRL_CHARGE_4P2_ILIMIT_MASK)
+ POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET;
+ while (tmp 0x3f) {
+ tmp++;
+ tmp2 = readl(power_regs-hw_power_5vctrl);
+ tmp2 = ~POWER_5VCTRL_CHARGE_4P2_ILIMIT_MASK;
+ tmp2 |= tmp
+ POWER_5VCTRL_CHARGE_4P2_ILIMIT_OFFSET;
+ writel(tmp2, power_regs-hw_power_5vctrl);
+ early_delay(100);
+ }
+#else
+ debug(SPL: Ramping up current limit (VDD5V + Battery)\n);
if (!(readl(power_regs-hw_power_sts) POWER_STS_DCDC_4P2_BO)) {
setbits_le32(power_regs
[U-Boot] [PATCH 3/5] Add 'Wait for JTAG user' if booted in JTAG mode
When booting in JTAG mode, there is no way to use soft break-points, and
no way of knowing when SPL has finished executing (so the user can issue
a 'halt' command to load u-boot.bin for example)
Add a debug output and simple loop to stop execution at the completion of
the SPL initialisation as a pseudo break-point when booting in JTAG mode
Signed-off-by: Graeme Russ gr...@tss-engineering.com
---
arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index 2a5f817..7bfc623 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -157,6 +157,12 @@ void mxs_common_spl_init(const uint32_t arg, const
uint32_t *resptr,
data-boot_mode_idx = bootmode;
mxs_power_wait_pswitch();
+
+
+ if (mxs_boot_modes[data-boot_mode_idx].boot_pads == 0x06) {
+ debug(SPL: Waiting for JTAG user\n);
+ asm volatile (x: b x);
+ }
}
/* Support aparatus */
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] Move PLL power-up from power init to memory init
mxs_power_clock2pll() does not actually switch the CPU clock to the PLL.
All it does is power-up the PLL and set the CLKCTRL_CLKSEQ_BYPASS_CPU bit
(which was already set by mxs_power_clock2xtal() anyway)
spl_mem_init.c sets up the fractional divisor (which is required to run
the CPU from the PLL) and clears the CLKCTRL_CLKSEQ_BYPASS_CPU bit (which
switches the CPU clock to the PLL)
It makes more sense to power-up the PLL in spl_mem_init.c. While moving
the PLL power-up, we may as well properly configure how the PLL lock is
started and confirmed
Signed-off-by: Graeme Russ gr...@tss-engineering.com
---
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 31
arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 45 -
2 files changed, 31 insertions(+), 45 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index a744e5d..af4ed8c 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -340,10 +340,41 @@ static void mx28_mem_init(void)
}
#endif
+/**
+ * mxs_mem_powerup_pll() - Powerup PLL0
+ *
+ * This function turns on power to PLL0. The CPU clock will be switched to
+ * PLL0 after the fractional divider and SDRAM have been configured.
+ */
+static void mxs_mem_powerup_pll(void)
+{
+ struct mxs_clkctrl_regs *clkctrl_regs =
+ (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
+
+ /* Power up PLL0 */
+ debug(SPL: Powering up PLL0\n);
+ setbits_le32(clkctrl_regs-hw_clkctrl_pll0ctrl0,
+CLKCTRL_PLL0CTRL0_POWER);
+
+ /* Toggle FORCE_LOCK to initiate the PLL lock procedure */
+ setbits_le32(clkctrl_regs-hw_clkctrl_pll0ctrl1,
+CLKCTRL_PLL0CTRL1_FORCE_LOCK);
+
+ clrbits_le32(clkctrl_regs-hw_clkctrl_pll0ctrl1,
+CLKCTRL_PLL0CTRL1_FORCE_LOCK);
+
+ /* Wait until the PLL has a stable lock - takes ~50us */
+ while (!(readl(clkctrl_regs-hw_clkctrl_pll0ctrl1)
+CLKCTRL_PLL0CTRL1_LOCK))
+ ;
+}
+
void mxs_mem_init(void)
{
early_delay(11000);
+ mxs_mem_powerup_pll();
+
mxs_mem_init_clock();
mxs_mem_setup_vdda();
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
index e469381..7267fd5 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_power_init.c
@@ -50,39 +50,6 @@ static void mxs_power_clock2xtal(void)
}
/**
- * mxs_power_clock2pll() - Switch CPU core clock source to PLL
- *
- * This function switches the CPU core clock from 24MHz XTAL oscilator
- * to PLL. This can only be called once the PLL has re-locked and once
- * the PLL is stable after reconfiguration.
- */
-static void mxs_power_clock2pll(void)
-{
- struct mxs_clkctrl_regs *clkctrl_regs =
- (struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
-
- debug(SPL: Switching CPU core clock source to PLL\n);
-
- /*
-* TODO: Are we really? It looks like we turn on PLL0, but we then
-* set the CLKCTRL_CLKSEQ_BYPASS_CPU bit of the (which was already
-* set by mxs_power_clock2xtal()). Clearing this bit here seems to
-* introduce some instability (causing the CPU core to hang). Maybe
-* we aren't giving PLL0 enough time to stabilise?
-*/
- setbits_le32(clkctrl_regs-hw_clkctrl_pll0ctrl0,
- CLKCTRL_PLL0CTRL0_POWER);
- early_delay(100);
-
- /*
-* TODO: Should the PLL0 FORCE_LOCK bit be set here followed be a
-* wait on the PLL0 LOCK bit?
-*/
- setbits_le32(clkctrl_regs-hw_clkctrl_clkseq,
- CLKCTRL_CLKSEQ_BYPASS_CPU);
-}
-
-/**
* mxs_power_set_auto_restart() - Set the auto-restart bit
*
* This function ungates the RTC block and sets the AUTO_RESTART
@@ -993,12 +960,6 @@ static void mxs_power_configure_power_source(void)
BATTERY_BRWNOUT_BITFIELD_VALUE
POWER_BATTMONITOR_BRWNOUT_LVL_OFFSET);
mxs_5v_boot();
-
- /*
-* TODO: Do not switch CPU clock to PLL if we are VDD5V is sourced
-* from USB VBUS
-*/
- mxs_power_clock2pll();
#else
if (readl(power_regs-hw_power_sts) POWER_STS_VDD5V_GT_VDDIO) {
batt_ready = mxs_is_batt_ready();
@@ -1021,12 +982,6 @@ static void mxs_power_configure_power_source(void)
mxs_batt_boot();
}
- /*
-* TODO: Do not switch CPU clock to PLL if we are VDD5V is sourced
-* from USB VBUS
-*/
- mxs_power_clock2pll();
-
mxs_init_batt_bo();
#endif
--
1.9.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/5] Add debug output to mx29 SPL source files
Signed-off-by: Graeme Russ gr...@tss-engineering.com
---
arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 1 +
arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c | 13 +++-
arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 18 +
arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 100 +++-
4 files changed, 127 insertions(+), 5 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
index d29b9aa..2a5f817 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_boot.c
@@ -147,6 +147,7 @@ void mxs_common_spl_init(const uint32_t arg, const uint32_t
*resptr,
mxs_iomux_setup_multiple_pads(iomux_setup, iomux_size);
mxs_spl_console_init();
+ debug(SPL: Serial Console Initialised\n);
mxs_power_init();
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
index cdfcddd..9e6f24a 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c
@@ -18,6 +18,8 @@ void mxs_lradc_init(void)
{
struct mxs_lradc_regs *regs = (struct mxs_lradc_regs *)MXS_LRADC_BASE;
+ debug(SPL: Initialisating LRADC);
+
writel(LRADC_CTRL0_SFTRST, regs-hw_lradc_ctrl0_clr);
writel(LRADC_CTRL0_CLKGATE, regs-hw_lradc_ctrl0_clr);
writel(LRADC_CTRL0_ONCHIP_GROUNDREF, regs-hw_lradc_ctrl0_clr);
@@ -37,9 +39,15 @@ void mxs_lradc_enable_batt_measurement(void)
{
struct mxs_lradc_regs *regs = (struct mxs_lradc_regs *)MXS_LRADC_BASE;
+ debug(SPL: Enabling LRADC battery measurement\n);
+
/* Check if the channel is present at all. */
- if (!(readl(regs-hw_lradc_status) LRADC_STATUS_CHANNEL7_PRESENT))
+ if (!(readl(regs-hw_lradc_status) LRADC_STATUS_CHANNEL7_PRESENT)) {
+ debug(SPL: LRADC channel 7 is not present - aborting\n);
return;
+ }
+
+ debug(SPL: LRADC channel 7 is present - configuring\n);
writel(LRADC_CTRL1_LRADC7_IRQ_EN, regs-hw_lradc_ctrl1_clr);
writel(LRADC_CTRL1_LRADC7_IRQ, regs-hw_lradc_ctrl1_clr);
@@ -65,6 +73,7 @@ void mxs_lradc_enable_batt_measurement(void)
100, regs-hw_lradc_delay3);
writel(0x, regs-hw_lradc_ch7_clr);
-
writel(LRADC_DELAY_KICK, regs-hw_lradc_delay3_set);
+
+ debug(SPL: LRADC channel 7 configuration complete\n);
}
diff --git a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
index 97ef67d..a744e5d 100644
--- a/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c
@@ -92,6 +92,7 @@ static uint32_t dram_vals[] = {
__weak void mxs_adjust_memory_params(uint32_t *dram_vals)
{
+ debug(SPL: Using default SDRAM parameters\n);
}
#ifdef CONFIG_MX28
@@ -99,8 +100,10 @@ static void initialize_dram_values(void)
{
int i;
+ debug(SPL: Setting mx28 board specific SDRAM parameters\n);
mxs_adjust_memory_params(dram_vals);
+ debug(SPL: Applying SDRAM parameters\n);
for (i = 0; i ARRAY_SIZE(dram_vals); i++)
writel(dram_vals[i], MXS_DRAM_BASE + (4 * i));
}
@@ -109,6 +112,7 @@ static void initialize_dram_values(void)
{
int i;
+ debug(SPL: Setting mx23 board specific SDRAM parameters\n);
mxs_adjust_memory_params(dram_vals);
/*
@@ -120,6 +124,7 @@ static void initialize_dram_values(void)
* HW_DRAM_CTL8 is setup as the last element.
* So skip the initialization of these HW_DRAM_CTL registers.
*/
+ debug(SPL: Applying SDRAM parameters\n);
for (i = 0; i ARRAY_SIZE(dram_vals); i++) {
if (i == 8 || i == 27 || i == 28 || i == 35)
continue;
@@ -146,6 +151,8 @@ static void mxs_mem_init_clock(void)
const unsigned char divider = 21;
#endif
+ debug(SPL: Initialising FRAC0\n);
+
/* Gate EMI clock */
writeb(CLKCTRL_FRAC_CLKGATE,
clkctrl_regs-hw_clkctrl_frac0_set[CLKCTRL_FRAC0_EMI]);
@@ -170,6 +177,7 @@ static void mxs_mem_init_clock(void)
clkctrl_regs-hw_clkctrl_clkseq_clr);
early_delay(1);
+ debug(SPL: FRAC0 Initialised\n);
}
static void mxs_mem_setup_cpu_and_hbus(void)
@@ -177,6 +185,8 @@ static void mxs_mem_setup_cpu_and_hbus(void)
struct mxs_clkctrl_regs *clkctrl_regs =
(struct mxs_clkctrl_regs *)MXS_CLKCTRL_BASE;
+ debug(SPL: Setting CPU and HBUS clock frequencies\n);
+
/* Set fractional divider for ref_cpu to 480 * 18 / 19 = 454MHz
* and ungate CPU clock */
writeb(19 CLKCTRL_FRAC_FRAC_MASK,
@@ -209,6 +219,8 @@ static void mxs_mem_setup_vdda(void)
struct mxs_power_regs *power_regs =
(struct mxs_power_regs *)MXS_POWER_BASE;
+ debug(SPL: Configuring VDDA\n);
+
writel((0xc POWER_VDDACTRL_TRG_OFFSET
[U-Boot] [PATCH 0/5] Add support for G2C1 mx28 board (which has no battery)
This series adds support for booting mx28 based boards which do not include a battery as per Freescale application note AN4199 Patch 2 (which implements booting without a battery) is based on a patch submitted to the Freescale community forums by Damien Gotfroi (Cc'd) The patch series adds the following functionality (in oreder of implementation) - Debug output for mxs SPL (define DEBUG and CONFIG_SPL_SERIAL_SUPPORT in order to enable) - Ability to boot mx28 boards without a battery as per AN4199 (define CONFIG_SYS_MXS_VDD5V_ONLY to enable) - A tight loop (with 'Waiting for JTAG user') at the completion of SPL init if booting with the bootmode jumpers set to JTAG - Move the PLL power-up to a more logical location and properly initialise and check for PLL lock - Finally, add the G2C1 board Graeme Russ (5): Add debug output to mx29 SPL source files Enable booting of mx28 without battery Add 'Wait for JTAG user' if booted in JTAG mode Move PLL power-up from power init to memory init Add support for ReachTech G2C1 board arch/arm/Kconfig| 13 + arch/arm/cpu/arm926ejs/mxs/spl_boot.c | 7 + arch/arm/cpu/arm926ejs/mxs/spl_lradc_init.c | 13 +- arch/arm/cpu/arm926ejs/mxs/spl_mem_init.c | 49 +++ arch/arm/cpu/arm926ejs/mxs/spl_power_init.c | 287 -- board/reachtech/g2c1/Kconfig| 15 + board/reachtech/g2c1/MAINTAINERS| 9 + board/reachtech/g2c1/Makefile | 12 + board/reachtech/g2c1/README | 58 board/reachtech/g2c1/g2c1.c | 79 + board/reachtech/g2c1/spl_boot.c | 452 configs/g2c1_defconfig | 3 + doc/README.mxs | 10 + include/configs/g2c1.h | 303 +++ 14 files changed, 1281 insertions(+), 29 deletions(-) create mode 100644 board/reachtech/g2c1/Kconfig create mode 100644 board/reachtech/g2c1/MAINTAINERS create mode 100644 board/reachtech/g2c1/Makefile create mode 100644 board/reachtech/g2c1/README create mode 100644 board/reachtech/g2c1/g2c1.c create mode 100644 board/reachtech/g2c1/spl_boot.c create mode 100644 configs/g2c1_defconfig create mode 100644 include/configs/g2c1.h -- 1.9.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] Enable booting of mx28 without battery
Hi Guys, @@ -868,6 +962,44 @@ static void mxs_power_configure_power_source(void) mxs_src_power_init(); +#ifdef CONFIG_SYS_MXS_VDD5V_ONLY + /* +* device configured for no source to DCDC_BATT input (5V only power +* source). This boot option doesn't waste time looking for a good +* battery. Battery powered operation and automatic voltage +* measurements are disabled. +*/ + + /* TODO: Find out what the purpose of these two lines is */ + setbits_le32(rtc_regs-hw_rtc_persistent1, +TC_PERSISTENT1_GENERAL_USB_BOOT_PLAYER); Never make simple, last minute changes without testing them... This should be RTC_PERSISTENT1_GENERAL_USB_BOOT_PLAYER I'll fix it in the next version + clrbits_le32(rtc_regs-hw_rtc_persistent1, +RTC_PERSISTENT1_GENERAL_ENUM_500MA_2X); + Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Suggestions for ARM dev board and debugger
Hi Guys, I'm looking at getting a dev board and JTAG debugger for ARM development work. Does anyone have any suggestions on what are good options? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/22] x86: board_f: Adjust x86 boot order for performance
Hi Simon,
On 06/01/15 04:33, Simon Glass wrote:
Nice to hear from you again!
Thanks - Good to be back in the game
I don't understand. Isn't the init_cache_f_r() which turns on the
cache?
Yes it turns on the cache, but turns off the ROM cache (they are
different things). So this ordering is much faster. I think I might
have more tuning to do though.
Got it. Since we moved these 3 routines from init_sequence_f_r[] to
init_sequence_f[], how about we remove the whole init_sequence_f_r[]
completely? If not possible, the comment block above
init_sequence_f_r[] needs to be fixed?
I'll remove the comment.
I think init_sequence_f_r can go... but I need to have a better look at the
code
If turning off the ROM cache by init_cache_f_r is the problem, then perhaps
the following order would be better:
copy_uboot_to_ram,
init_cache_f_r,
clear_bss,
do_elf_reloc_fixups,
Without enabling the CPU's cache, clear_bss and do_elf_reloc_fixups will
suffer.
Better would be to have init_cache_f_r after all this I think.
Why so? After copying the U-Boot code from ROM to RAM, we would want RAM
based operations to be as fast as possible. By this point, we have
passed most of the XIP code, so XIP performance _should_ be a non-issue.
This board_init_f_r() code is part of one attempt to do this - the
premise was that turning the cache on before relocating U-Boot will
save time. That's true, but it would be even better to turn the cache
on much earlier. With pit (Chromebook 2) we turn on the cache in SPL.
So I think turning it on here is too late if we are trying to save
time. Still it is a good start and if we could make it happen
generally it would be nice.
And now you have me thinking board_init_f_r is not needed at all...
If we can setup the stack, clear BSS, copy U-Boot to RAM and perform
relocation fixups while running from ROM, what is left for board_init_f_r to
do?
The only thing I can think of is the caveats mentioned in the comment
('static' variables are read-only / Global Data (gd-xxx) is read/write).
But aren't these true when running from ROM?
Looking at non-x86 arches, relocate_code() looks to do what
copy_uboot_to_ram and clear_bss does in x86 land (not sure about
do_elf_reloc_fixups - seems to be arch specific as to whether
relocate_code() does this or it is done later (hence the
CONFIG_NEEDS_MANUAL_RELOC #define?)
Yes this can be unified. There is still something in there though for
board_init_f_r(), at least as things are now. It just so happens on
x86 that we are running from ROM and CAR so as I understand it we
sort-of have the cache on before relocation. That doesn't apply for
coreboot though, so there is probably an optimisation to be made
somewhere.
U-Boot runs from RAM right from the start in coreboot correct? In which
case, coreboot builds can probably do away with all the relocation code
I assume coreboot can relocate U-Boot to any place in memory. Last time
I looked, coreboot had some ELF processing code.
See here for my original attempt, which was tied up with generic
board. In the end I untied them and we got one but not the other.
http://lists.denx.de/pipermail/u-boot/2012-February/118409.html
Ah, generic relocation... I really wish my life hadn't taken a hard-left
turn when it did. We got so close.
From where I'm looking (fresh eyes - I might be missing something big) we
should be able to do the ROM-RAM copy, BSS clearing, and relocation fixups
in board_init_f.
When we return from board_init_f it should be a fairly simple matter of:
- Copying the contents of the Global Data structure from CAR to RAM (or
from RAM to RAM if your on a platform which initialises RAM before U-Boot)
- Set the gd pointer (reserved register) to point to the new copy
- Figure out where board_init_r is and jump to it
board_init_r should be able to do any remaining cache tweaks. If cache
tweaks cannot be done while executing from RAM then they need to be done in
board_init_f
I just cannot see the point of board_init_f_r any more
Yes, it's hard to see, I'm not sure either.
Anyway I'm going to apply this patch while we figure out what further
work can be done.
Sounds good to me.
The pity is that I don't have ANY hardware to test any of this any more,
and it looks like any development I do in the foreseeable future will be
on ARM. So hacking and testing x86 might be a bit of a problem
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/22] x86: board_f: Adjust x86 boot order for performance
Hi Simon Bin,
On Tue, Jan 6, 2015 at 12:40 AM, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Mon, Jan 5, 2015 at 9:44 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 3 January 2015 at 20:26, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Fri, Jan 2, 2015 at 6:23 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 30 December 2014 at 22:51, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Sun, Dec 28, 2014 at 10:20 AM, Simon Glass s...@chromium.org
wrote:
For bare platforms we turn off ROM-caching before calling
board_init_f_r()
It is then very slow to copy U-Boot from ROM to RAM. So adjust the
order so
that the copying happens before we turn off ROM-caching.
Signed-off-by: Simon Glass s...@chromium.org
---
common/board_f.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/common/board_f.c b/common/board_f.c
index 98c9c72..1b65575 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -983,6 +983,11 @@ static init_fnc_t init_sequence_f[] = {
INIT_FUNC_WATCHDOG_RESET
reloc_fdt,
setup_reloc,
+#ifdef CONFIG_X86
+ copy_uboot_to_ram,
+ clear_bss,
+ do_elf_reloc_fixups,
+#endif
#if !defined(CONFIG_ARM) !defined(CONFIG_SANDBOX)
jump_to_copy,
#endif
@@ -1042,9 +1047,6 @@ void board_init_f(ulong boot_flags)
*/
static init_fnc_t init_sequence_f_r[] = {
init_cache_f_r,
- copy_uboot_to_ram,
- clear_bss,
- do_elf_reloc_fixups,
NULL,
};
--
Wow, doesn't this bring back some memories. I've had a look over this code
as it is now and it took a while to sink in. Things have moved on in the
past 2 years :)
I don't understand. Isn't the init_cache_f_r() which turns on the
cache?
Yes it turns on the cache, but turns off the ROM cache (they are
different things). So this ordering is much faster. I think I might
have more tuning to do though.
Got it. Since we moved these 3 routines from init_sequence_f_r[] to
init_sequence_f[], how about we remove the whole init_sequence_f_r[]
completely? If not possible, the comment block above
init_sequence_f_r[] needs to be fixed?
I'll remove the comment.
I think init_sequence_f_r can go... but I need to have a better look at the
code
If turning off the ROM cache by init_cache_f_r is the problem, then perhaps
the following order would be better:
copy_uboot_to_ram,
init_cache_f_r,
clear_bss,
do_elf_reloc_fixups,
Without enabling the CPU's cache, clear_bss and do_elf_reloc_fixups will
suffer.
*
* The '_f_r' sequence must, as a minimum, copy U-Boot to RAM (if
* supported). It _should_, if possible, copy global data to RAM and
* initialise the CPU caches (to speed up the relocation process)
*
* NOTE: At present only x86 uses this route, but it is intended that
* all archs will move to this when generic relocation is implemented.
*/
So looks that we should either drop this _f_r stage, or make other
arch use this _f_r?
I think we should move to generic relocation, meaning that all archs
do relocation the same way with the same code. Then only arch-specific
stuff is the then ELF fixup function, which adjusts a relocation site,
and the code to actually change the stack pointer.
This was always my plan - have arch specific do_reloc_fixups and the rest
would be generic
This board_init_f_r() code is part of one attempt to do this - the
premise was that turning the cache on before relocating U-Boot will
save time. That's true, but it would be even better to turn the cache
on much earlier. With pit (Chromebook 2) we turn on the cache in SPL.
So I think turning it on here is too late if we are trying to save
time. Still it is a good start and if we could make it happen
generally it would be nice.
And now you have me thinking board_init_f_r is not needed at all...
If we can setup the stack, clear BSS, copy U-Boot to RAM and perform
relocation fixups while running from ROM, what is left for board_init_f_r
to do?
The only thing I can think of is the caveats mentioned in the comment
('static' variables are read-only / Global Data (gd-xxx) is read/write).
But aren't these true when running from ROM?
Looking at non-x86 arches, relocate_code() looks to do what
copy_uboot_to_ram and clear_bss does in x86 land (not sure about
do_elf_reloc_fixups - seems to be arch specific as to whether
relocate_code() does this or it is done later (hence
the CONFIG_NEEDS_MANUAL_RELOC #define?)
See here for my original attempt, which was tied up with generic
board. In the end I untied them and we got one but not the other.
http://lists.denx.de/pipermail/u-boot/2012-February/118409.html
Ah, generic relocation... I really wish my life hadn't taken a hard-left
turn when it did. We got so close.
From where I'm looking (fresh eyes - I might
Re: [U-Boot] [PATCH v2 4/9] Add a simple malloc() implementation for pre-relocation
Hi Simon,
Nice to see this being tackled after all the DM discussions I got
involved
in a long time ago (in a galaxy far far away...)
I think we can save a few bytes and simplify the code if we define only
the
base address and current pointer in global_data.h
#ifdef CONFIG_SYS_MALLOC_F_LEN
unsigned long malloc_base; /* limit address */
unsigned long malloc_ptr; /* current address */
#endif
On 2014-07-08 09:19, Simon Glass wrote:
+static int initf_malloc(void)
+{
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+ assert(gd-malloc_base); /* Set up by crt0.S */
+ gd-malloc_limit = gd-malloc_base + CONFIG_SYS_MALLOC_F_LEN;
+ gd-malloc_ptr = 0;
+#endif
#ifdef CONFIG_SYS_MALLOC_F_LEN
assert(gd-malloc_base); /* Set up by crt0.S */
gd-malloc_ptr= gd-malloc_base;
#endif
+
+ return 0;
+}
+
diff --git a/common/board_r.c b/common/board_r.c
index 602a239..86424a0 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -259,6 +259,10 @@ static int initr_malloc(void)
{
ulong malloc_start;
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+ debug(Pre-reloc malloc() used %#lx bytes (%ld KB)\n,
gd-malloc_ptr,
+ gd-malloc_ptr / 1024);
+#endif
Use (gd-malloc_ptr - gd-malloc_base) to calculate the size
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+ if (!(gd-flags GD_FLG_RELOC)) {
+ ulong new_ptr;
+ void *ptr;
+
+ new_ptr = gd-malloc_ptr + bytes;
+ if (new_ptr gd-malloc_limit)
+ panic(Out of pre-reloc memory);
+ ptr = map_sysmem(gd-malloc_base + gd-malloc_ptr, bytes);
+ gd-malloc_ptr = ALIGN(new_ptr, sizeof(new_ptr));
+ return ptr;
+ }
+#endif
+
#ifdef CONFIG_SYS_MALLOC_F_LEN
if (!(gd-flags GD_FLG_RELOC)) {
ulong curr_ptr;
curr_ptr = gd-malloc_ptr;
gd-malloc_ptr = ALIGN(gd-malloc_ptr + bytes,
sizeof(gd-malloc_ptr));
if (gd-malloc_ptr = (gd-malloc_base +
CONFIG_SYS_MALLOC_F_LEN))
panic(Out of pre-reloc memory);
return map_sysmem(curr_ptr, bytes);
#endif
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] why u-boot relocate it self to RAM from flash?
Hi, On Tue, Dec 3, 2013 at 1:18 AM, FengHua feng...@phytium.com.cn wrote: Hi, I can not understand why u-boot relocate it self to RAM from flash? Why is it not executing from flash? Can anybody explain. First, flash is slow. Second, there are many data structures or variables which should be writable. So, we should copy u-boot to RAM and relocate it. I'll expand a bit... In theory the writeable could be relocated into RAM, but this would require the relocation address to be hard-coded. Optimally, U-Boot places itself in a memory location to provide the maximum contiguous memory space to load the operating system kernel and supporting data (RAM disks, FDTs, etc). On most systems now, relocation is done by calculating the delta between the ROM address (TEXT_BASE) and the relocated address in RAM. The relocation code first copies the entire U-Boot image to RAM (apart from a few structures that are used only during the relocation calculation). It then scans the relocation entries (*.rel sections) to find where in the U-Boot executable all the references into the data sections. At each reference point in the executable, the relocation code modifies the reference by the relocation offset. None of this can happen if the U-Boot executable is in Flash. The other advantage of relocating U-Boot to RAM is that it makes it possible to flash a new U-Boot image from U-Boot. If you try to do this while U-Boot is running from flash, it will crash as you are overwriting the executable code while it's executing. Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] examples: add again x86 standalone example
Hi Guys, On Thu, Nov 28, 2013 at 2:44 PM, Masahiro Yamada yamad...@jp.panasonic.comwrote: Hello Tom, Simon. On Mon, Nov 11, 2013 at 12:47:53PM +0900, Masahiro Yamada wrote: Commit fea25720 renamed arch/i386 to arch/x86. But it missed to modify examples/standalone/Makefile. Oops - my bad :) This commit revives examples/standalone/82559_eeprom. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Simon Glass s...@chromium.org --- Hello, Simon. I think examples/standalone/82559_eeprom should have been originally implemented for i386(x86) architecture but it has never compiled more than two years. (And I am probably the first one to notice this.) I chosed to add it again rather than delete it in this patch. If you do not need it any more, I am glad to re-post v2 to delete it. Note that now that we build this I see: i586-angstrom-linux-ld: warning: cannot find entry symbol 82559_eeprom; defaulting to 0004 So a new warning on coreboot-x86. I'm giving this patch to Simon in patchwork and he can either follow-up with a patch fixing the warning or nak and delete the example. http://lists.denx.de/mailman/listinfo/u-boot To be honest, I don't think this will ever be used. 'Hello World' provides a perfect example of a standalone application on the x86 as it stands already. The 82559 is the EEPROM for the Intel Fast Ethernet controller, and as such, I think any interface to it should be done via a proper driver and not by a standalone application. Besides, I really doubt that there are any systems using an 82559 and U-Boot in the wild, and probably never will be. I vote for deletion Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot gerrit server
Hi Vadim, On Wed, Nov 20, 2013 at 4:21 AM, Vadim Bendebury (вб) vben...@google.comwrote: e On Sun, Nov 17, 2013 at 11:31 AM, Wolfgang Denk w...@denx.de wrote: Dear Wolfgang, [snip..] Maybe I'm wrong, but my understanding was that we were not primarily interested in introducing better project management tools, but in reducing the work load on the maintainers, making our work more efficient. Having worked with email based reviews and with gerrit, I would say that gerrit has overwhelming advantage when it comes to reviewing complex changes, especially when multiple patch versions are required due to review comments. These are the major advantages IMO: - the side-by side display of the changes makes it easier to understand what is going on - the entire source file is at the reviewer's disposal if he wants to see a larger context - it is very easy to see what changed between patch versions - it is easy to pull entire patch series into a local tree if one wants to try a change Emphasising the pros and cons of this tool versus that tool is the wrong way to go about this. This is how salespeople convince you to buy things you don't need - 'Let me show you how good it is at doing xyx'. Before you know it, you've bought a fancy do-da that does a million things, but you only end up using it for the things you _need_ to do anyway, and your come to the realisation that your old do-da did a perfectly fine job already and you end up using it instead because it's smaller and faster. gerrit is a great tool. I've seen it in action and I like it a lot. BUT - what is it we NEED. Where are the bottlenecks in the existing U-Boot workflow? Where do things fall over? What REALLY annoys you about how we do things now? Don't look at features of existing tools. The biggest trap you will fall into is selecting a tool that does a whole heap of nifty stuff you never even thought of, and you'll forget the one thing that troubles you the most. Maybe we could put the discussion on the Wiki. Or we could add a 'Wishlist' document to the git repo - that way we can discuss each wish on the ML individually, add it when it's sufficiently fleshed out, and remove it when it's implemented. Figure out the problem first, then look for a solution. Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] include: define bool type in a more portable way
Hi Masahiro Yamada, Why would hacking /include/linux/stddef.h and /include/linux/types.h be preferable? Regards, Graeme On Tue, Nov 19, 2013 at 3:37 PM, Masahiro Yamada yamad...@jp.panasonic.comwrote: Hi. I posted v2 of this patch http://patchwork.ozlabs.org/patch/292258/ I think both of two solutions work. (1) include stdbool.h in common/cmd_test.c but undef true and false. http://patchwork.ozlabs.org/patch/292247/ (2) Do not include stdbool.h and define true and false with enum. http://patchwork.ozlabs.org/patch/292258/ Personally, I prefer (2) to (1) because - we don't need to tweak common/cmd_test.c any more - we can reduce the conflict if we have a plan to update Linux-originated header files. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] include: define bool type in a more portable way
Hi Masahiro Yamada, On Tue, Nov 19, 2013 at 4:59 PM, Masahiro Yamada yamad...@jp.panasonic.comwrote: Hello Graeme Why would hacking /include/linux/stddef.h and /include/linux/types.h be preferable? The reason is this: Personally, I prefer (2) to (1) because - we don't need to tweak common/cmd_test.c any more - we can reduce the conflict if we have a plan to update Linux-originated header files. Some Linux header files are very old. Accoding to git log, for example, include/linux/types.h was added at 2000 and include/linux/stddef.h at 2002. I figured that might be the case after I hit send :) We imported Linux headers and generally add an item to them every time we find some necessary feature is missing. For example, this patch: http://patchwork.ozlabs.org/patch/291435/ Adjusting little by little is one strategy. But we might think of synchronizing Linux-related headers with new ones in future. Would be interesting to see what kinds of chaos would ensue if we did... We have lots of files imported from Linux Kernel. So, basiclly, there is more or less advantage to mimic Linux's way. Agreed - we use the Linux coding standards and probably 90% of our build probably happen on Linux machines. Anyway, this is my personal option. Opinions about this item may differ among people. I also think it would be better to have all headers under /include/linux/ synchronised with Linux. But I've been out of the game so long now, I don't know if I've inadvertently started a flame war... Regards, Graeme P.S. Apologies for my previous top-post - please don't hurt me ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot gerrit server
Hi All, You do all realise that we are going about this, to use some British vernacular, arse-about-tit Everyone agrees that the current U-Boot review workflow 'has issues' (and has had issues for quite some time). The first attempt at overcoming these issues was Patchwork. I personally think that that ended up being far less successful than we hoped Then Simon Glass wrote some truly excellent 'developer side' tools (patman and buildman) which I think we can all agree has help lighten the load be improving the quality of the patch submissions (not the patch code necessarily, but the submission process) And now we are looking at gerrit and, to be honest, we have one side of the fence trying to bang a square peg into a round hole, and on the other, the hole keeps changing shape. Implementing gerrit will force a significant change to the workflow of everyone involved in U-Boot (developers and maintainers). Question is - is the _workflow_ so broken that it needs such a drastic change, or does it just need a few more tools to 'grease the axle' so to speak. Or has U-Boot outgrown the current workflow model to such an extent that we need to change it? If the workflow is really that broken, then, unfortunately for some, there will be a rather painful transition to a new one. We've identified that there is a problem, but nobody has yet to qualify and quantify exactly what the problem is. You can't fix a rattle with a screwdriver if the problem is a loose nut :) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [IMPORTANT NOTE] License handling
Hi Masahiro On Tue, Jul 30, 2013 at 8:50 PM, Masahiro Yamada yamad...@jp.panasonic.comwrote: Hello, Wolfgang. - New files being added to U-Boot should no longer include a multi-line license header; instead, they shall contain a single line Unique Lincense Identifier, i. e. a line like this: SPDX-License-Identifier:GPL-2.0+ I have a question about this. Does this rule apply to files imported from other projects? For example, when adding files that originate from the Linux Kernel with modification for U-Boot, should we replace the legacy license block with SPDX-License-Identifer? Or can we keep the license block untouched I kind of raised this before - SPDX is not only a way of simplifying the license text, but also to provide a 'chain of authenticity'. The idea would be to reduce the license text in U-Boot to just the SPDX-License-Identifier, but we should also provide details on where the original file came from. I guess this is the next (harder) step. Wolfgang: How do you think this should be best handled? I still haven't found a definitive reference for the use of SPDX-License-Identifier - are there other identifiers which can be used to specify the original source of the file? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/5] Introducing SPDX-License-Identifiers
Hi Wolfgang, On Wed, Jul 10, 2013 at 5:37 PM, Wolfgang Denk w...@denx.de wrote: Like many other projects, U-Boot has a tradition of including big blocks of License headers in all files. This not only blows up the source code with mostly redundant information, but also makes it very difficult to generate License Clearing Reports. An additional problem is that even the same lincenses are referred to by a number of slightly varying text blocks (full, abbreviated, different indentation, line wrapping and/or white space, with obsolete address information, ...) which makes automatic processing a nightmare. To make this easier, such license headers in the source files will be replaced with a single line reference to Unique Lincense Identifiers as defined by the Linux Foundation's SPDX project [1]. For example, in a source file the full GPL v2.0 or later header text will be replaced by a single line: SPDX-License-Identifier:GPL-2.0+ Hi Wolfgang, This will certainly make compliance checking a lot easier. I remember going through and checking what licenses were used some time ago - what a mess! I've been reading Version 1.1 of the Software Package Data Exchange (SPDX®) Specification and I can't find any reference to using the term 'SPDX -License-Identifier'. What I have found, and I think would be beneficial, is details on creation of a central SPDX file which lists all files in the package, the license applicable for that file, and (I think most importantly) an Artifact of Project Name which provides information on the original source project of each file. So if we have source code taken from the Linux kernel and modified for U-Boot, the Linux kernel would be the Artifact Project. In theory, if the file was sources by the Linux kernel developers from somewhere else, then the Linux kernel SPDX file would provide the next hop in the chain. The idea being that the ancestry of the file can be traced back to the original author and license. The spec also calls for each source file to be SHA-1 checksummed - this allows for very rapid verification that all source files are indeed what have been published by the project maintainers. Would it be worthwhile machine generating an SPDX file for the project upon each release and publishing it on the U-Boot home page? This would also allow us to highlight and track files with dubious license assignments with a view to sanitising U-Boot once and for all :) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] decompile u-boot.bin file
Hi there ShinSham, Best bet is to contact the device manufacturer and ask for the U-Boot source code. As it is GPL, they are legally obliged to provide it to you. They are actually required to provide you with either the source when you obtained the device, or a reliable means of obtaining the source (typically a URL to a source archive). Check out the device packaging, any help screens the device has or the website. Failing that, email them. If they fob you off, remind them of their GPL obligations. Regards, Graeme On Wed, Jul 10, 2013 at 10:46 AM, Heer Lorcan heer.lor...@gmail.com wrote: Hey, have this iriver cover story. would like to hack the damn thing, since it's linux based and could do some work. add some options, delete others. have gotten the firmware decompressed from a EB05.HEX file to a very nice extended directory. the rootfs.cramfs is also decompressed. just leaves me the few files, *.feb - unknown format the zImage and the u-boot.bin could any of you here help me out with the u-boot.bin? kind regards, -- ShinSham DTL Heer Lorcan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] GPL v3 only code in U-Boot
Hi Dirk, No as there is still GPLv2 only code U-Boot. Regards Graeme On Wed, Jul 3, 2013 at 7:22 PM, Dirk Behme dirk.be...@de.bosch.com wrote: Hi, hopefully ;) a short question: We found that the commit http://git.denx.de/?p=u-boot.**git;a=commitdiff;h=** 3c945542dad99b1ec4a324ad6b69b8**de8829827bhttp://git.denx.de/?p=u-boot.git;a=commitdiff;h=3c945542dad99b1ec4a324ad6b69b8de8829827b contains two files board/qi/qi_lb60/qi_lb60.c include/configs/qi_lb60.h which seem to be GPL v3 *only*. Is this ok for U-Boot? Many thanks and best regards Dirk __**_ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/**listinfo/u-boothttp://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] I'm coming back :)
Excellent - I'm familiar with Henrik's work and it is top-notch. I'm thinking of focusing on the SPL component - Adding a file system so the DRAM parameters and U-Boot can be read from a standard file system rather than fixed blocks I'll purchase an A10 and A31 device soon Regards, Graeme On Wed, Jul 3, 2013 at 11:44 PM, Tom Rini tr...@ti.com wrote: On Mon, Jul 01, 2013 at 01:54:45PM +1000, Graeme Russ wrote: Hi Guys, Due to personal circumstances I left the U-Boot community back in late October 2012. Now I find my circumstances have been completely flipped upside down (long story) and I will soon have much more time on my hands. Unfortunately, I do not have a dev machine yet (that may take a couple of months) but at least I can start by reading the list again and get up to speed with what is going on. I want to send out a huge Thank You to Simon Glass for taking over the custodianship of the x86 repo. It's been really great to see my little baby grow up. Not only that, but he has taken over the campaign of architecture unification. I think I'm going to really like the new look U-Boot :) And another big Thanks toTom Rini, without whom U-Boot would have been at great risk of stumbling right when it was getting the greatest amount of momentum it ever had. Looking forward to being part of the team again. This time I will be focusing on ARM based devices, particularly the AllWinner A10 and A31. So Simon, I won't be taking x86 from you (I hope you don't mind) Welcome back! I've got one of the AllWinner A10 boards around here too, and am eagerly awaiting Henrik's next submission as I think things are close to mergable. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] compiled failed when turned off gcc optimazition
Hi Mike, On Wed, Jul 3, 2013 at 5:40 AM, Mike Dunn miked...@newsguy.com wrote: On 07/01/2013 12:51 PM, Wolfgang Denk wrote: Dear Mike Dunn, In message 51d1c455.9010...@newsguy.com you wrote: But there's a good motivation for wanting to turn off optimization. I disagree here. If you are hunting down a problem, you want to be as close at the original code as possible. Disabling optimization is such a dramatic change to the generated code that you actually debug a different program. I guess it depends on what problem being debugged... I think your point is valid for things like tracking down race conditions or misbehaving hardware. But for more mundane problems like logical errors in the code, optimizations get in the way. It would be nice to be able to experiment with optimizations off. Just knowing that a particular problem still exists when unoptimized code is run will provide some clues. Do be honest, I have never used an online debugger I have always found that a combination of hardware LEDs and printf's has been more than sufficient, particularly for mundane issues. I'll freely admit that an online debugger might been faster for me, but I just wanted to point out that there is more than one way to skin a cat. I also believe that the more onerous the debugging tool is (and it doesn't get more so than using the hardware LEDs) the more attention you pay to the code rather than the output ;) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] I'm coming back :)
Hi Guys, Due to personal circumstances I left the U-Boot community back in late October 2012. Now I find my circumstances have been completely flipped upside down (long story) and I will soon have much more time on my hands. Unfortunately, I do not have a dev machine yet (that may take a couple of months) but at least I can start by reading the list again and get up to speed with what is going on. I want to send out a huge Thank You to Simon Glass for taking over the custodianship of the x86 repo. It's been really great to see my little baby grow up. Not only that, but he has taken over the campaign of architecture unification. I think I'm going to really like the new look U-Boot :) And another big Thanks toTom Rini, without whom U-Boot would have been at great risk of stumbling right when it was getting the greatest amount of momentum it ever had. Looking forward to being part of the team again. This time I will be focusing on ARM based devices, particularly the AllWinner A10 and A31. So Simon, I won't be taking x86 from you (I hope you don't mind) Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/19] x86: Remove ISR timer
Hi Simon,
On Thu, Apr 18, 2013 at 12:13 PM, Simon Glass s...@chromium.org wrote:
This is no longer used since we prefer the more accurate TSC timer, so
remove the dead code.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/lib/Makefile | 1 -
arch/x86/lib/timer.c | 118
--
2 files changed, 119 deletions(-)
delete mode 100644 arch/x86/lib/timer.c
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 0bc8c2f..c614479 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -36,7 +36,6 @@ COBJS-$(CONFIG_PCI) += pci_type1.o
COBJS-y+= relocate.o
COBJS-y += physmem.o
COBJS-y+= string.o
-COBJS-$(CONFIG_SYS_X86_ISR_TIMER) += timer.o
COBJS-$(CONFIG_SYS_X86_TSC_TIMER) += tsc_timer.o
COBJS-$(CONFIG_VIDEO_VGA) += video.o
COBJS-$(CONFIG_CMD_ZBOOT) += zimage.o
diff --git a/arch/x86/lib/timer.c b/arch/x86/lib/timer.c
deleted file mode 100644
index fb11bfe..000
--- a/arch/x86/lib/timer.c
+++ /dev/null
@@ -1,118 +0,0 @@
-/*
- * (C) Copyright 2008,2009
- * Graeme Russ, graeme.r...@gmail.com
- *
- * (C) Copyright 2002
- * Daniel Engström, Omicron Ceti AB, dan...@omicron.se
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-
-#include common.h
-#include malloc.h
-#include asm/io.h
-#include asm/i8254.h
-#include asm/ibmpc.h
-
-DECLARE_GLOBAL_DATA_PTR;
-
-struct timer_isr_function {
- struct timer_isr_function *next;
- timer_fnc_t *isr_func;
-};
-
-static struct timer_isr_function *first_timer_isr;
-static unsigned long system_ticks;
-
-/*
- * register_timer_isr() allows multiple architecture and board specific
- * functions to be called every millisecond. Keep the execution time of
- * each function as low as possible
- */
-int register_timer_isr(timer_fnc_t *isr_func)
-{
- struct timer_isr_function *new_func;
- struct timer_isr_function *temp;
- int flag;
-
- new_func = malloc(sizeof(struct timer_isr_function));
-
- if (new_func == NULL)
- return 1;
-
- new_func-isr_func = isr_func;
- new_func-next = NULL;
-
- /*
-* Don't allow timer interrupts while the
-* linked list is being modified
-*/
- flag = disable_interrupts();
-
- if (first_timer_isr == NULL) {
- first_timer_isr = new_func;
- } else {
- temp = first_timer_isr;
- while (temp-next != NULL)
- temp = temp-next;
- temp-next = new_func;
- }
-
- if (flag)
- enable_interrupts();
-
- return 0;
-}
-
-/*
- * timer_isr() MUST be the registered interrupt handler for
- */
-void timer_isr(void *unused)
-{
- struct timer_isr_function *temp = first_timer_isr;
-
- system_ticks++;
-
- /* Execute each registered function */
- while (temp != NULL) {
- temp-isr_func();
- temp = temp-next;
- }
-}
-
-ulong get_timer(ulong base)
-{
- return system_ticks - base;
-}
-
-void timer_set_tsc_base(uint64_t new_base)
-{
- gd-arch.tsc_base = new_base;
-}
-
-uint64_t timer_get_tsc(void)
-{
- uint64_t time_now;
-
- time_now = rdtsc();
- if (!gd-arch.tsc_base)
- gd-arch.tsc_base = time_now;
-
- return time_now - gd-arch.tsc_base;
-}
--
1.8.2.1
Acked-by: Graeme Russ graeme.r...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 02/19] x86: Remove unused portion of link script
Hi Simon,
On Thu, Apr 18, 2013 at 12:13 PM, Simon Glass s...@chromium.org wrote:
Since we don't have real-mode code now, we can remove this chunk of the
link
script.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/u-boot.lds | 12
1 file changed, 12 deletions(-)
diff --git a/arch/x86/cpu/u-boot.lds b/arch/x86/cpu/u-boot.lds
index 2d6911a..b4ecd4b 100644
--- a/arch/x86/cpu/u-boot.lds
+++ b/arch/x86/cpu/u-boot.lds
@@ -79,18 +79,6 @@ SECTIONS
/DISCARD/ : { *(.interp*) }
/DISCARD/ : { *(.gnu*) }
- /* 16bit realmode trampoline code */
- .realmode REALMODE_BASE : AT ( LOADADDR(.rel.dyn) +
SIZEOF(.rel.dyn) ) { KEEP(*(.realmode)) }
-
- __realmode_start = LOADADDR(.realmode);
- __realmode_size = SIZEOF(.realmode);
-
- /* 16bit BIOS emulation code (just enough to boot Linux) */
- .bios 0 : AT ( LOADADDR(.realmode) + SIZEOF(.realmode) ) {
KEEP(*(.bios)) }
-
- __bios_start = LOADADDR(.bios);
- __bios_size = SIZEOF(.bios);
-
#ifdef CONFIG_X86_RESET_VECTOR
/*
--
1.8.2.1
Acked-by: Graeme Russ graeme.r...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 01/19] x86: Remove unused bios/pci code
Hi Simon, On Thu, Apr 18, 2013 at 12:13 PM, Simon Glass s...@chromium.org wrote: Graeme Russ pointed out that this code is no longer used. Remove it. Signed-off-by: Simon Glass s...@chromium.org --- arch/x86/include/asm/pci.h | 4 - arch/x86/lib/Makefile | 1 - arch/x86/lib/bios.h| 170 arch/x86/lib/pci.c | 188 - 4 files changed, 363 deletions(-) delete mode 100644 arch/x86/lib/bios.h delete mode 100644 arch/x86/lib/pci.c [snip] Acked-by: Graeme Russ graeme.r...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/19] x86: Remove old broken timer implementation
Hi Simon,
On Thu, Apr 18, 2013 at 12:13 PM, Simon Glass s...@chromium.org wrote:
Tidy up some old broken and unneeded implementations. These are not used
by coreboot or anything else now.
Signed-off-by: Simon Glass s...@chromium.org
Reviewed-by: Gabe Black gabebl...@chromium.org
Reviewed-by: Michael Spang sp...@chromium.org
Reviewed-by: Vadim Bendebury vben...@chromium.org
---
arch/x86/cpu/Makefile | 2 +-
arch/x86/cpu/timer.c | 20
2 files changed, 1 insertion(+), 21 deletions(-)
delete mode 100644 arch/x86/cpu/timer.c
diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile
index 7b520f8..cddf0dd 100644
--- a/arch/x86/cpu/Makefile
+++ b/arch/x86/cpu/Makefile
@@ -30,7 +30,7 @@ LIB = $(obj)lib$(CPU).o
START-y= start.o
START-$(CONFIG_X86_RESET_VECTOR) += resetvec.o start16.o
-COBJS = interrupts.o cpu.o timer.o
+COBJS = interrupts.o cpu.o
SRCS := $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
diff --git a/arch/x86/cpu/timer.c b/arch/x86/cpu/timer.c
deleted file mode 100644
index f95fce5..000
--- a/arch/x86/cpu/timer.c
+++ /dev/null
@@ -1,20 +0,0 @@
-/*
- * Copyright (c) 2011 The Chromium OS Authors. All rights reserved.
- * Use of this source code is governed by a BSD-style license that can be
- * found in the LICENSE file.
- *
- * Alternatively, this software may be distributed under the terms of the
- * GNU General Public License (GPL) version 2 as published by the Free
- * Software Foundation.
- */
-
-#include common.h
-
-/* Temporary patch to maintain bisectability, removed in next commit */
-#ifndef CONFIG_SYS_X86_TSC_TIMER
-unsigned long timer_get_us(void)
-{
- printf(timer_get_us used but not implemented.\n);
- return 0;
-}
-#endif
--
1.8.2.1
Acked-by: Graeme Russ graeme.r...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/19] x86: Re-enable PCAT timer 2 for beeping
Hi Simon,
On Thu, Apr 18, 2013 at 12:13 PM, Simon Glass s...@chromium.org wrote:
While we don't want PCAT timers for timing, we want timer 2 so that we can
still make a beep. Re-purpose the PCAT driver for this, and enable it in
coreboot.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/include/asm/u-boot-x86.h | 1 +
arch/x86/lib/Makefile | 2 +-
arch/x86/lib/pcat_timer.c | 69
++-
arch/x86/lib/tsc_timer.c | 6 +++-
include/configs/coreboot.h| 1 +
5 files changed, 11 insertions(+), 68 deletions(-)
[snip]
-/* this is not very exact */
-void __udelay(unsigned long usec)
-{
- int counter;
- int wraps;
-
- if (timer_init_done) {
- counter = read_pit();
- wraps = usec / 1000;
- usec = usec % 1000;
-
- usec *= 1194;
- usec /= 1000;
- usec += counter;
-
- while (usec 1194) {
- usec -= 1194;
- wraps++;
- }
-
- while (1) {
- int new_count = read_pit();
-
- if (((new_count usec) !wraps) || wraps 0)
- break;
-
- if (new_count counter)
- wraps--;
-
- counter = new_count;
- }
- }
-
-}
This does not seem related...
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/19] x86: Add TSC timer
Hi Simon,
On Thu, Apr 18, 2013 at 12:13 PM, Simon Glass s...@chromium.org wrote:
This timer runs at a rate that can be calculated, well over 100MHz. It is
ideal for accurate timing and does not need interrupt servicing.
Tidy up some old broken and unneeded implementations at the same time.
To provide a consistent view of boot time, we use the same time
base as coreboot. Use the base timestamp supplied by coreboot
as U-Boot's base time.
Signed-off-by: Simon Glass s...@chromium.orgbase
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/coreboot/timestamp.c | 4 +-
arch/x86/cpu/timer.c | 3 ++
arch/x86/include/asm/u-boot-x86.h | 2 +
arch/x86/lib/Makefile | 1 +
arch/x86/lib/tsc_timer.c | 103
++
include/configs/coreboot.h| 4 +-
6 files changed, 113 insertions(+), 4 deletions(-)
create mode 100644 arch/x86/lib/tsc_timer.c
diff --git a/arch/x86/cpu/coreboot/timestamp.c
b/arch/x86/cpu/coreboot/timestamp.c
index 2ca7a57..d26718e 100644
--- a/arch/x86/cpu/coreboot/timestamp.c
+++ b/arch/x86/cpu/coreboot/timestamp.c
@@ -39,7 +39,9 @@ static struct timestamp_table *ts_table
__attribute__((section(.data)));
void timestamp_init(void)
{
ts_table = lib_sysinfo.tstamp_table;
- timer_set_tsc_base(ts_table-base_time);
+#ifdef CONFIG_SYS_X86_TSC_TIMER
+ timer_set_base(ts_table-base_time);
+#endif
timestamp_add_now(TS_U_BOOT_INITTED);
}
diff --git a/arch/x86/cpu/timer.c b/arch/x86/cpu/timer.c
index 149109d..f95fce5 100644
--- a/arch/x86/cpu/timer.c
+++ b/arch/x86/cpu/timer.c
@@ -10,8 +10,11 @@
#include common.h
+/* Temporary patch to maintain bisectability, removed in next commit */
+#ifndef CONFIG_SYS_X86_TSC_TIMER
unsigned long timer_get_us(void)
{
printf(timer_get_us used but not implemented.\n);
return 0;
}
+#endif
Why bother? Why not just one commit 'Replace timer implementation with TSC
Timer'?
diff --git a/arch/x86/include/asm/u-boot-x86.h
b/arch/x86/include/asm/u-boot-x86.h
index 5a59db6..bec583f 100644
--- a/arch/x86/include/asm/u-boot-x86.h
+++ b/arch/x86/include/asm/u-boot-x86.h
@@ -39,6 +39,8 @@ void panic_puts(const char *str);
void timer_isr(void *);
typedef void (timer_fnc_t) (void);
int register_timer_isr (timer_fnc_t *isr_func);
+unsigned long get_tbclk_mhz(void);
+void timer_set_base(uint64_t base);
/* Architecture specific - can be in arch/x86/cpu/, arch/x86/lib/, or
$(BOARD)/ */
int dram_init_f(void);
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 962593d..0bc8c2f 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -37,6 +37,7 @@ COBJS-y += relocate.o
COBJS-y += physmem.o
COBJS-y+= string.o
COBJS-$(CONFIG_SYS_X86_ISR_TIMER) += timer.o
+COBJS-$(CONFIG_SYS_X86_TSC_TIMER) += tsc_timer.o
COBJS-$(CONFIG_VIDEO_VGA) += video.o
COBJS-$(CONFIG_CMD_ZBOOT) += zimage.o
diff --git a/arch/x86/lib/tsc_timer.c b/arch/x86/lib/tsc_timer.c
new file mode 100644
index 000..d931e5f
--- /dev/null
+++ b/arch/x86/lib/tsc_timer.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (c) 2012 The Chromium OS Authors.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include common.h
+#include malloc.h
+#include asm/io.h
+#include asm/i8254.h
+#include asm/ibmpc.h
+#include asm/msr.h
+#include asm/u-boot-x86.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+void timer_set_base(u64 base)
+{
+ gd-arch.tsc_base = base;
+}
+
+/*
+ * Get the number of CPU time counter ticks since it was read first time
after
+ * restart. This yields a free running counter guaranteed to take almost
6
+ * years to wrap around even at 100GHz clock rate.
+ */
+u64 get_ticks(void)
+{
+ u64 now_tick = rdtsc();
+
+ /* We assume that 0 means the base hasn't been set yet */
+ if (!gd-arch.tsc_base)
+ panic(No tick base available);
+ return now_tick - gd-arch.tsc_base;
+}
+
+#define PLATFORM_INFO_MSR 0xce
+
+/* Get the speed of the TSC timer in MHz */
+unsigned long get_tbclk_mhz(void)
+{
+ u32 ratio;
+ u64 platform_info = native_read_msr(PLATFORM_INFO_MSR);
+
+ /* 100MHz times Max Non
Re: [U-Boot] [PATCH 03/19] x86: Remove legacy board init code
Hi Simon On Thu, Apr 18, 2013 at 12:13 PM, Simon Glass s...@chromium.org wrote: Since we use CONFIG_SYS_GENERIC_BOARD on x86, we don't need this anymore. Signed-off-by: Simon Glass s...@chromium.org --- arch/x86/include/asm/init_helpers.h | 9 -- arch/x86/include/asm/init_wrappers.h | 42 -- arch/x86/include/asm/u-boot.h| 32 arch/x86/lib/Makefile| 5 - arch/x86/lib/board.c | 273 --- arch/x86/lib/init_helpers.c | 98 - arch/x86/lib/init_wrappers.c | 164 - 7 files changed, 623 deletions(-) delete mode 100644 arch/x86/include/asm/init_wrappers.h delete mode 100644 arch/x86/lib/board.c delete mode 100644 arch/x86/lib/init_wrappers.c Acked-by: Graeme Russ graeme.r...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 06/19] x86: Rationalise kernel booting logic and bootstage
Hi Simon,
On Thu, Apr 18, 2013 at 12:13 PM, Simon Glass s...@chromium.org wrote:
The 'Starting linux' message appears twice in the code, but both call
through the same place. Unify these and add calls to bootstage to
mark the occasion.
Signed-off-by: Simon Glass s...@chromium.org
Reviewed-by: Michael Spang sp...@chromium.org
---
arch/x86/cpu/cpu.c| 5 +
arch/x86/lib/bootm.c | 8
arch/x86/lib/zimage.c | 11 +++
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 1a2f85c..7a914a5 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -120,6 +120,11 @@ void setup_gdt(gd_t *id, u64 *gdt_addr)
int __weak x86_cleanup_before_linux(void)
{
+#ifdef CONFIG_BOOTSTAGE_STASH
+ bootstage_stash((void *)CONFIG_BOOTSTAGE_STASH,
+ CONFIG_BOOTSTAGE_STASH_SIZE);
+#endif
+
return 0;
}
diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c
index 83caf6b..2520228 100644
--- a/arch/x86/lib/bootm.c
+++ b/arch/x86/lib/bootm.c
@@ -93,14 +93,6 @@ int do_bootm_linux(int flag, int argc, char * const
argv[],
goto error;
}
-#ifdef DEBUG
- printf(## Transferring control to Linux (at address %08x) ...\n,
- (u32)base_ptr);
-#endif
-
- /* we assume that the kernel is in place */
- printf(\nStarting kernel ...\n\n);
-
boot_zimage(base_ptr, load_address);
/* does not return */
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 4e9e1f7..b54cf12 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -283,6 +283,13 @@ __weak void board_final_cleanup(void)
void boot_zimage(void *setup_base, void *load_address)
{
+ debug(## Transferring control to Linux (at address %08x) ...\n,
+ (u32)setup_base);
+
+ bootstage_mark_name(BOOTSTAGE_ID_BOOTM_HANDOFF, start_kernel);
+#ifdef CONFIG_BOOTSTAGE_REPORT
+ bootstage_report();
+#endif
board_final_cleanup();
printf(\nStarting kernel ...\n\n);
@@ -363,10 +370,6 @@ int do_zboot(cmd_tbl_t *cmdtp, int flag, int argc,
char *const argv[])
return -1;
}
- printf(## Transferring control to Linux
- (at address %08x) ...\n,
- (u32)base_ptr);
-
/* we assume that the kernel is in place */
boot_zimage(base_ptr, load_address);
/* does not return */
--
1.8.2.1
Acked-by: Graeme Russ graeme.r...@gmail.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] make hang() a weak function
Hi Andreas, On Tue, Apr 16, 2013 at 8:14 PM, Andreas Bießmann andreas.de...@googlemail.com wrote: This patch also does some minor coding style cleanups. Coding style cleanups belong in a separate patch - Rules are rules ;) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] make hang() a weak function
Hi Andreas,
On Tue, Apr 16, 2013 at 11:32 PM, Andreas Bießmann
andreas.de...@googlemail.com wrote:
Dear Wolfgang,
On 04/16/2013 03:05 PM, Wolfgang Denk wrote:
Dear Andreas,
In message 516d4b00.9030...@gmail.com you wrote:
So it is dead code in mainline, and we will not add it.
Well, I don't think it is dead code cause the hang() is called in some
ways.
This patch opens just the possibility to specialize the hang() by for
example a specific board. Maybe this could also be used for specific
hang() for different arches when we get closer to the common board
files.
I think it is dead code, and not needed nor useful in mainline. I
cannot even see how it would be useful for you. hang() is defined to
hang the CPU, i. e. to make sure the system will remain in the
current state. To me this naturally translates into an infinite loop,
the implementation of which is completely hardware and architecture
independent.
Yes it is independent (or should at least). But there are still slightly
different versions:
---8---
arch/blackfin/lib/board.c:void hang(void)
arch/blackfin/lib/board.c-{
arch/blackfin/lib/board.c-#ifdef CONFIG_STATUS_LED
arch/blackfin/lib/board.c- status_led_set(STATUS_LED_BOOT,
STATUS_LED_OFF);
arch/blackfin/lib/board.c- status_led_set(STATUS_LED_CRASH,
STATUS_LED_BLINKING);
---8---
---8---
arch/arm/lib/board.c:void __hang(void)
arch/arm/lib/board.c-{
arch/arm/lib/board.c- puts(### ERROR ### Please RESET the board
###\n);
arch/arm/lib/board.c- for (;;);
arch/arm/lib/board.c-}
---8---
---8---
arch/powerpc/lib/board.c:void __hang(void)
arch/powerpc/lib/board.c-{
arch/powerpc/lib/board.c- puts(### ERROR ### Please RESET the
board ###\n);
arch/powerpc/lib/board.c- bootstage_error(BOOTSTAGE_ID_NEED_RESET);
arch/powerpc/lib/board.c- for (;;)
---8---
I think that ultimately there should only be a single hang() function
Note that hang() is not supposed to do anything else, it just hangs
the system. If you have a debugger attached, you will be able to do a
simple stack backtrace and see exactly where you are hanging, and why.
Well, for this specific board I plan to panic() on wrong hardware
detection (which will in turn call hang()). My requirements say that I
have to visualize this state then, I thought it would be a good idea to
blink some lights in the endless loop in hang() for this specific board.
If you think you need to have specialized code, you are doing
something wrong.
Really? How would you solve this requirement?
Doesn't it make sense to use panic()?
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] make hang() a weak function
Hi Andreas, On Wed, Apr 17, 2013 at 12:15 AM, Andreas Bießmann andreas.de...@googlemail.com wrote: Hi Graeme, On 04/16/2013 03:35 PM, Graeme Russ wrote: Hi Andreas, On Tue, Apr 16, 2013 at 11:32 PM, Andreas Bießmann andreas.de...@googlemail.com mailto:andreas.de...@googlemail.com wrote: Dear Wolfgang, On 04/16/2013 03:05 PM, Wolfgang Denk wrote: Dear Andreas, In message 516d4b00.9030...@gmail.com mailto:516d4b00.9030...@gmail.com you wrote: snip I think that ultimately there should only be a single hang() function Ok. Note that hang() is not supposed to do anything else, it just hangs the system. If you have a debugger attached, you will be able to do a simple stack backtrace and see exactly where you are hanging, and why. Well, for this specific board I plan to panic() on wrong hardware detection (which will in turn call hang()). My requirements say that I have to visualize this state then, I thought it would be a good idea to blink some lights in the endless loop in hang() for this specific board. If you think you need to have specialized code, you are doing something wrong. Really? How would you solve this requirement? Doesn't it make sense to use panic()? In my opinion it makes sense to panic(). In my special case I also need to hang() when panic(). The next question is then how to visualize the (end-)user of that device that we hang(). In panic()? My thought would be along the lines of: - Detect something fatal - Call panic() - Do something to alert the user - puts(), start a LED blinking, etc. - Stay in panic() if you need CPU cycles to keep alerting the user (LED blinking for example) - Call hang() if you've done everything you can Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] x86: config: Init PCI before SPI
Hi Simon, On Tue, Apr 16, 2013 at 7:25 AM, Simon Glass s...@chromium.org wrote: Since the ICH SPI controller uses PCI, we must ensure that PCI is available before it is inited. This fixes the current ICH SPI: Cannot find device message on boot. Hmm, if only my new init sequence code had gained wider acceptance ;) It would have been a simple case of specifying PCI as a pre-req and the init sequence would have been re-ordered to suit (or thrown a compile error to say the sequence was impossible to build) Regards, Graeme Signed-off-by: Simon Glass s...@chromium.org --- include/configs/coreboot.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/coreboot.h b/include/configs/coreboot.h index a4aa8f7..5bacc77 100644 --- a/include/configs/coreboot.h +++ b/include/configs/coreboot.h @@ -41,6 +41,7 @@ #define CONFIG_INTEL_CORE_ARCH /* Sandy bridge and ivy bridge chipsets. */ #define CONFIG_ZBOOT_32 #define CONFIG_PHYSMEM +#define CONFIG_SYS_EARLY_PCI_INIT #define CONFIG_LMB #define CONFIG_OF_LIBFDT -- 1.8.1.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12
Hi Wolfgang, On Mon, Feb 18, 2013 at 8:59 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon, In message CAPnjgZ089gS0gLHBVBVARpX=awcyruumslgnir4hfkwzzls...@mail.gmail.com you wrote: I have started on it - I've ported over the Kbuild infrastructure into a dedicated 'kbuild' makefile which is called from the main makefile. This make modifications to the existing makefile very minimal Now it's just a case of building all the Kconfig files which is, to say the least, a massive task. I have a lot of other things going on, so unfortunately progress is slow I wonder how you got on with that? Any work-in-progress that could be used as a base? Want some help? It seems like a useful feature. I also wonder if this has to be a one-step change-it-all-at-once operation? Maybe we can add the infrastructure in a neutral way, and then start moving code to the Kconfig files step by step - similar to what we did with moving Makefile rules out into boards.cfg ? Alas I do not have access to the code I was working on (study is buried in stuff) and I really didn't get that far anyway. But, I got as far as knowing it is possible to run both the current Makefile infrastructure and the KConfig infrastructure in parallel. The trick is to create additional Makefiles (Makefile.kc for example). You just need to add stubs for the KConfig targets (menuconfig, xconfig, etc). Once the core KConfig Make infrastructure is in place, it's simply (?) a case of building all the KConfig files Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/5] Remove old unused x86 boards and code
Hi Simon, OK, now that I have seen the results of the patches in all their glory, there is a bit more trimming to do: - Delete arch/x86/lib/bios.h - Check usage of pci_shadow_rom() (defined in arch/x86/lib/pci.c) - In arch/x86/include/asm/pci.h, check if any of the following are unused: - pci_enable_legacy_video_ports() - pci_shadow_rom() - pci_remove_rom_window() - pci_get_rom_window() Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/5] Remove old unused x86 boards and code
Hi Simon, And lines 77-88 of arch/x86/cpu/u-boot.lds can go as well now Regards, Graeme P.S. So glad to finally see the end of the old 16-bit BIOS crap :) On Mon, Feb 18, 2013 at 9:30 AM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, OK, now that I have seen the results of the patches in all their glory, there is a bit more trimming to do: - Delete arch/x86/lib/bios.h - Check usage of pci_shadow_rom() (defined in arch/x86/lib/pci.c) - In arch/x86/include/asm/pci.h, check if any of the following are unused: - pci_enable_legacy_video_ports() - pci_shadow_rom() - pci_remove_rom_window() - pci_get_rom_window() Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] x86: Remove unused real mode code
Hi Simon, On Fri, Feb 15, 2013 at 1:18 AM, Simon Glass s...@chromium.org wrote: This code is pretty old and we want to support only 32-bit systems now. Keep the real mode-to-protected code in case we want to boot an x86 from power-up, but invert the polarity of the option. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Keep the real mode-to-protected code README | 7 +- arch/x86/include/asm/realmode.h | 36 --- arch/x86/lib/Makefile | 10 +- arch/x86/lib/bios.S | 569 arch/x86/lib/bios.h | 3 - arch/x86/lib/bios_pci.S | 447 --- arch/x86/lib/bios_setup.c | 179 - arch/x86/lib/realmode.c | 93 --- arch/x86/lib/video.c| 6 - arch/x86/lib/video_bios.c | 196 -- arch/x86/lib/zimage.c | 23 -- 11 files changed, 4 insertions(+), 1565 deletions(-) delete mode 100644 arch/x86/include/asm/realmode.h delete mode 100644 arch/x86/lib/bios.S delete mode 100644 arch/x86/lib/bios_pci.S delete mode 100644 arch/x86/lib/bios_setup.c delete mode 100644 arch/x86/lib/realmode.c delete mode 100644 arch/x86/lib/video_bios.c diff --git a/README b/README index 6106e0d..7b50720 100644 --- a/README +++ b/README @@ -3820,10 +3820,9 @@ Low Level (hardware related) configuration options: If defined, the x86 reset vector code is included. This is not needed when U-Boot is running from Coreboot. -- CONFIG_X86_NO_REAL_MODE - If defined, x86 real mode code is omitted. This assumes a - 32-bit environment where such code is not needed. You will - need to do this when U-Boot is running from Coreboot. +- CONFIG_X86_REAL_MODE + If defined, some 86 real mode code is included. This is not + needed when U-Boot is running from Coreboot. I think this config option can be punted completely. This define is only used to pull in the real-mode trampoline code which switches from protected-mode to real-mode before jumping into the Linux kernel's real-mode stub. The code for the initial real-mode to protected-mode switch will be pulled in by CONFIG_X86_RESET_VECTOR Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/5] x86: Remove unused real mode code
Hi Simon, On Fri, Feb 15, 2013 at 2:35 PM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Thu, Feb 14, 2013 at 2:36 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, On Fri, Feb 15, 2013 at 1:18 AM, Simon Glass s...@chromium.org wrote: This code is pretty old and we want to support only 32-bit systems now. Keep the real mode-to-protected code in case we want to boot an x86 from power-up, but invert the polarity of the option. Signed-off-by: Simon Glass s...@chromium.org [snip] diff --git a/README b/README index 6106e0d..7b50720 100644 --- a/README +++ b/README @@ -3820,10 +3820,9 @@ Low Level (hardware related) configuration options: If defined, the x86 reset vector code is included. This is not needed when U-Boot is running from Coreboot. -- CONFIG_X86_NO_REAL_MODE - If defined, x86 real mode code is omitted. This assumes a - 32-bit environment where such code is not needed. You will - need to do this when U-Boot is running from Coreboot. +- CONFIG_X86_REAL_MODE + If defined, some 86 real mode code is included. This is not + needed when U-Boot is running from Coreboot. I think this config option can be punted completely. This define is only used to pull in the real-mode trampoline code which switches from protected-mode to real-mode before jumping into the Linux kernel's real-mode stub. The code for the initial real-mode to protected-mode switch will be pulled in by CONFIG_X86_RESET_VECTOR I suppose I am confused about what is needed here. I will drop the flag, and arch/x86/lib/realmode_switch.S. Is that right? Correct. All you need to keep is: arch/x86/cpu/resetvec.S arch/x86/cpu/start16 And these are conditional on CONFIG_X86_RESET_VECTOR Looking at the most recent patch, I think you have it nailed now Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 5/5] x86: Remove unused real mode code
Hi Simon, On Fri, Feb 15, 2013 at 2:38 PM, Simon Glass s...@chromium.org wrote: This code is pretty old and we want to support only 32-bit systems now. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v3: - Punt the real mode flag altogether Changes in v2: - Keep the real mode-to-protected code README | 5 - arch/x86/include/asm/realmode.h | 36 --- arch/x86/lib/Makefile | 10 - arch/x86/lib/bios.S | 569 arch/x86/lib/bios.h | 3 - arch/x86/lib/bios_pci.S | 447 --- arch/x86/lib/bios_setup.c | 179 - arch/x86/lib/realmode.c | 93 --- arch/x86/lib/realmode_switch.S | 232 arch/x86/lib/video.c| 6 - arch/x86/lib/video_bios.c | 196 -- arch/x86/lib/zimage.c | 23 -- 12 files changed, 1799 deletions(-) delete mode 100644 arch/x86/include/asm/realmode.h delete mode 100644 arch/x86/lib/bios.S delete mode 100644 arch/x86/lib/bios_pci.S delete mode 100644 arch/x86/lib/bios_setup.c delete mode 100644 arch/x86/lib/realmode.c delete mode 100644 arch/x86/lib/realmode_switch.S delete mode 100644 arch/x86/lib/video_bios.c Acked-by: Graeme Russ graeme.r...@gmail.com Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] x86: Remove eNET boards
Hi Simon, On Sat, Feb 9, 2013 at 3:42 AM, Simon Glass s...@chromium.org wrote: These are no longer used and should be removed. Signed-off-by: Simon Glass s...@chromium.org --- board/eNET/Makefile | 52 board/eNET/eNET.c | 284 - board/eNET/eNET_pci.c | 128 -- board/eNET/eNET_start.S | 30 --- board/eNET/eNET_start16.S | 87 --- board/eNET/hardware.h | 36 --- boards.cfg| 2 - include/configs/eNET.h| 619 -- 8 files changed, 1238 deletions(-) delete mode 100644 board/eNET/Makefile delete mode 100644 board/eNET/eNET.c delete mode 100644 board/eNET/eNET_pci.c delete mode 100644 board/eNET/eNET_start.S delete mode 100644 board/eNET/eNET_start16.S delete mode 100644 board/eNET/hardware.h delete mode 100644 include/configs/eNET.h Acked-by: Graeme Russ graeme.r...@gmail.com Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] x86: Remove all real mode code
Hi Simon,
On Sat, Feb 9, 2013 at 3:42 AM, Simon Glass s...@chromium.org wrote:
This code is pretty old and we want to support only 32-bit systems now.
Signed-off-by: Simon Glass s...@chromium.org
---
README | 5 -
arch/x86/config.mk | 1 -
arch/x86/cpu/u-boot.lds | 25 --
arch/x86/include/asm/realmode.h | 36 ---
arch/x86/lib/Makefile | 10 -
arch/x86/lib/bios.S | 569
arch/x86/lib/bios.h | 3 -
arch/x86/lib/bios_pci.S | 447 ---
arch/x86/lib/bios_setup.c | 179 -
arch/x86/lib/realmode.c | 93 ---
arch/x86/lib/realmode_switch.S | 232
arch/x86/lib/video.c| 6 -
arch/x86/lib/video_bios.c | 196 --
arch/x86/lib/zimage.c | 23 --
14 files changed, 1825 deletions(-)
delete mode 100644 arch/x86/include/asm/realmode.h
delete mode 100644 arch/x86/lib/bios.S
delete mode 100644 arch/x86/lib/bios_pci.S
delete mode 100644 arch/x86/lib/bios_setup.c
delete mode 100644 arch/x86/lib/realmode.c
delete mode 100644 arch/x86/lib/realmode_switch.S
delete mode 100644 arch/x86/lib/video_bios.c
diff --git a/README b/README
index 2352e38..103036f 100644
--- a/README
+++ b/README
@@ -3820,11 +3820,6 @@ Low Level (hardware related) configuration options:
If defined, the x86 reset vector code is excluded. You will
need
to do this when U-Boot is running from Coreboot.
-- CONFIG_X86_NO_REAL_MODE
- If defined, x86 real mode code is omitted. This assumes a
- 32-bit environment where such code is not needed. You will
- need to do this when U-Boot is running from Coreboot.
-
Freescale QE/FMAN Firmware Support:
---
diff --git a/arch/x86/config.mk b/arch/x86/config.mk
index 23cacff..8356577 100644
--- a/arch/x86/config.mk
+++ b/arch/x86/config.mk
@@ -34,7 +34,6 @@ PF_CPPFLAGS_X86 := $(call cc-option, -ffreestanding) \
$(call cc-option, -mpreferred-stack-boundary=2)
PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_X86)
PLATFORM_CPPFLAGS += -fno-dwarf2-cfi-asm
-PLATFORM_CPPFLAGS += -DREALMODE_BASE=0x7c0
PLATFORM_RELFLAGS += -ffunction-sections -fvisibility=hidden
diff --git a/arch/x86/cpu/u-boot.lds b/arch/x86/cpu/u-boot.lds
index 0c6f0e3..8f5e444 100644
--- a/arch/x86/cpu/u-boot.lds
+++ b/arch/x86/cpu/u-boot.lds
@@ -73,29 +73,4 @@ SECTIONS
/DISCARD/ : { *(.plt*) }
/DISCARD/ : { *(.interp*) }
/DISCARD/ : { *(.gnu*) }
-
- /* 16bit realmode trampoline code */
- .realmode REALMODE_BASE : AT ( LOADADDR(.rel.dyn) + SIZEOF(.rel.dyn)
) { KEEP(*(.realmode)) }
-
- __realmode_start = LOADADDR(.realmode);
- __realmode_size = SIZEOF(.realmode);
-
- /* 16bit BIOS emulation code (just enough to boot Linux) */
- .bios 0 : AT ( LOADADDR(.realmode) + SIZEOF(.realmode) ) {
KEEP(*(.bios)) }
-
- __bios_start = LOADADDR(.bios);
- __bios_size = SIZEOF(.bios);
-
-#ifndef CONFIG_X86_NO_RESET_VECTOR
-
- /*
-* The following expressions place the 16-bit Real-Mode code and
-* Reset Vector at the end of the Flash ROM
-*/
- . = START_16;
- .start16 : AT (CONFIG_SYS_TEXT_BASE + (CONFIG_SYS_MONITOR_LEN -
RESET_SEG_SIZE + START_16)) { KEEP(*(.start16)); }
-
- . = RESET_VEC_LOC;
- .resetvec : AT (CONFIG_SYS_TEXT_BASE + (CONFIG_SYS_MONITOR_LEN -
RESET_SEG_SIZE + RESET_VEC_LOC)) { KEEP(*(.resetvec)); }
-#endif
Can we please keep the reset vector and real-to-protected mode code. I
know coreboot does not need it (and hence it is dead code) but it
keeps alive the thought that U-Boot can actually boot an x86 from
power-up
Apart from that, I'll be glad to see the back of this legacy crap :)
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] x86: Remove sc520 cpu
Hi Simon, On Sat, Feb 9, 2013 at 3:42 AM, Simon Glass s...@chromium.org wrote: This x86 CPU variant is no longer required as the boards that use it have been removed. Signed-off-by: Simon Glass s...@chromium.org --- arch/x86/cpu/sc520/Makefile | 58 arch/x86/cpu/sc520/asm-offsets.c| 45 --- arch/x86/cpu/sc520/sc520.c | 66 - arch/x86/cpu/sc520/sc520_car.S | 94 --- arch/x86/cpu/sc520/sc520_pci.c | 142 -- arch/x86/cpu/sc520/sc520_reset.c| 40 --- arch/x86/cpu/sc520/sc520_sdram.c| 479 arch/x86/cpu/sc520/sc520_ssi.c | 93 --- arch/x86/cpu/sc520/sc520_timer.c| 89 -- arch/x86/include/asm/arch-sc520/pci.h | 79 -- arch/x86/include/asm/arch-sc520/sc520.h | 372 - arch/x86/include/asm/arch-sc520/ssi.h | 34 --- 12 files changed, 1591 deletions(-) delete mode 100644 arch/x86/cpu/sc520/Makefile delete mode 100644 arch/x86/cpu/sc520/asm-offsets.c delete mode 100644 arch/x86/cpu/sc520/sc520.c delete mode 100644 arch/x86/cpu/sc520/sc520_car.S delete mode 100644 arch/x86/cpu/sc520/sc520_pci.c delete mode 100644 arch/x86/cpu/sc520/sc520_reset.c delete mode 100644 arch/x86/cpu/sc520/sc520_sdram.c delete mode 100644 arch/x86/cpu/sc520/sc520_ssi.c delete mode 100644 arch/x86/cpu/sc520/sc520_timer.c delete mode 100644 arch/x86/include/asm/arch-sc520/pci.h delete mode 100644 arch/x86/include/asm/arch-sc520/sc520.h delete mode 100644 arch/x86/include/asm/arch-sc520/ssi.h Acked-by: Graeme Russ graeme.r...@gmail.com Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] x86: Remove 16-bit reset code
Hi Simon, On Sat, Feb 9, 2013 at 3:42 AM, Simon Glass s...@chromium.org wrote: This code is not needed now, since we boot U-Boot from Coreboot on x86. Signed-off-by: Simon Glass s...@chromium.org --- Makefile | 4 -- README | 4 -- arch/x86/cpu/Makefile | 1 - arch/x86/cpu/resetvec.S| 38 arch/x86/cpu/start16.S | 146 - include/configs/coreboot.h | 1 - 6 files changed, 194 deletions(-) delete mode 100644 arch/x86/cpu/resetvec.S delete mode 100644 arch/x86/cpu/start16.S As mentioned in reply to the previous patch, I would like to see this code stay diff --git a/Makefile b/Makefile index 51bd918..1924d4b 100644 --- a/Makefile +++ b/Makefile @@ -230,10 +230,6 @@ endif # U-Boot objectsorder is important (i.e. start must be first) OBJS = $(CPUDIR)/start.o -ifeq ($(CPU),x86) -RESET_OBJS-$(CONFIG_X86_NO_RESET_VECTOR) += $(CPUDIR)/start16.o -RESET_OBJS-$(CONFIG_X86_NO_RESET_VECTOR) += $(CPUDIR)/resetvec.o -endif Hmm, odd - the logic here seems to be inverted - the reset vector code appears to be included if CONFIG_X86_NO_RESET_VECTOR is defined... Oh, and as discussed before, this can actually be moved out of the main Makefile and into arch/x86/cpu/Makefile. Hmm, that's odd, it looks like it already is: START-y = start.o RESET_OBJS-$(CONFIG_X86_NO_RESET_VECTOR) += resetvec.o start16.o COBJS = interrupts.o cpu.o timer.o SRCS:= $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) OBJS:= $(addprefix $(obj),$(SOBJS) $(COBJS)) START := $(addprefix $(obj),$(START-y) $(RESET_OBJS-)) But again, the logic seems to be inverted... diff --git a/README b/README index 103036f..061898c 100644 --- a/README +++ b/README @@ -3816,10 +3816,6 @@ Low Level (hardware related) configuration options: be used if available. These functions may be faster under some conditions but may increase the binary size. -- CONFIG_X86_NO_RESET_VECTOR - If defined, the x86 reset vector code is excluded. You will need - to do this when U-Boot is running from Coreboot. - Maybe we could just change this to CONFIG_X86_RESET_VECTOR and make exclusion of the 16-bit reset vector and protected mode switch the default case Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 3/4] x86: Allow cmdline setup in setup_zimage() to be optional
Hi Simon,
On Sun, Jan 13, 2013 at 4:48 AM, Simon Glass s...@chromium.org wrote:
If we are passing this using the device tree then we may not want to
set this up here. TBD.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/lib/zimage.c | 21 -
1 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/arch/x86/lib/zimage.c b/arch/x86/lib/zimage.c
index 8819afd..9fc450a 100644
--- a/arch/x86/lib/zimage.c
+++ b/arch/x86/lib/zimage.c
@@ -269,18 +269,21 @@ int setup_zimage(struct boot_params *setup_base, char
*cmd_line, int auto_boot,
hdr-loadflags |= HEAP_FLAG;
}
- if (bootproto = 0x0202) {
- hdr-cmd_line_ptr = (uintptr_t)cmd_line;
- } else if (bootproto = 0x0200) {
- setup_base-screen_info.cl_magic = COMMAND_LINE_MAGIC;
- setup_base-screen_info.cl_offset =
- (uintptr_t)cmd_line - (uintptr_t)setup_base;
+ if (cmd_line) {
+ if (bootproto = 0x0202) {
+ hdr-cmd_line_ptr = (uintptr_t)cmd_line;
+ } else if (bootproto = 0x0200) {
To be honest, I think it would be simpler if older kernels are just
completely unsupported and get rid of all this logic
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/10] x86: Permit bootstage and timer data to be used prior to relocation
Hi Simon,
On Wed, Dec 19, 2012 at 12:32 PM, Simon Glass s...@chromium.org wrote:
Hi Graeme,
On Fri, Dec 14, 2012 at 2:35 PM, Simon Glass s...@chromium.org wrote:
Hi Graeme,
On Fri, Dec 14, 2012 at 2:15 PM, Graeme Russ graeme.r...@gmail.com
wrote:
Hi Simon,
On 15/12/12 08:13, Simon Glass wrote:
It is useful to be able to access the timer before U-Boot has relocated
so that we can fully support bootstage.
Move the relevant variables to the data region to support this.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/coreboot/coreboot.c |4 ++--
arch/x86/cpu/interrupts.c|2 +-
arch/x86/lib/timer.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/cpu/coreboot/coreboot.c
b/arch/x86/cpu/coreboot/coreboot.c
index 9c9431e..22474f5 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -68,8 +68,8 @@ int board_early_init_r(void)
void show_boot_progress(int val)
{
#if MIN_PORT80_KCLOCKS_DELAY
- static uint32_t prev_stamp;
- static uint32_t base;
+ static uint32_t prev_stamp __attribute__((section(.data)));
+ static uint32_t base __attribute__((section(.data)));
NAK
This may work for coreboot where SDRAM is already initialised and you've
loaded U-Boot into RAM, but it will not work when U-Boot is in Flash as
all
sections (including .data) are read-only until after relocation.
The stack and Global Data are the only guaranteed read/write locations
prior to relocation
Ah yes, I was thinking of your comment that all boards would move to
use coreboot. If that is not the case, then I will need to add
something to global data for the timer. And I don't want to do that
while generic board is in progress since it creates conflicts.
I'm trying to remember the context of my comment regarding only having
coreboot boards. But anyway, not having any writeable data prior to
relocation (other than the stack and gd) is a fundamental principle
that we cannot simply avoid (although I must admit I don't know what
the go is with SPL and U-Boot relocation).
Any thoughts on this point, please? I presume at least I can use RAM once
dram_init() is called. But when running from coreboot the RAM is already set
up...
You will need to use global data to store the static variables. That's
what the other arches do
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
Hi Wolfgang, On Dec 15, 2012 6:30 PM, Wolfgang Denk w...@denx.de wrote: Dear Graeme Russ, In message 50cbd313.60...@gmail.com you wrote: I can give you an example - Remote Telemetry Units (RTUs). They usually have a number of serial ports. The number of ports may vary based on the sub-model. Some ports may be RS-232, some may be RS-485 or RS-422. Depending on what additional devices you want to communicate with, you may need to use the 'console/diag' port to connect to a real device. So what you want to do is route console to another port (if available) or even netconsole. Netconsole is always an option, and I think we also support switching to other serial ports here and there (after relocation, that is). But if you need console output before relocation (i. e. during debugging), then I do not see why we cannot demand that the console port is statically configured, and that you need corectly configured images to have an early working console. I have seen situations where console output by the bootloader messes up attached serial devices hence effectively dropping the serial port count by one. Pre-console buffer helps a lot (no console output until we know where to send it to). But that kills early debug. I do get your point of view. But I think a combination of storing the dynamic console info in a DT format, the pre-console buffer and getting DT available as early as possible can yield a 'non-cludgy' solution. For board or SoC vendors who, for whatever reason, have implemented non-DT storage of hardware enumeration data they will be stuck with the penalty of having to translate that data into DT format before it can be parsed by U-Boot. Maybe this could be done in SPL. Yes, it's a hack, but if it can't be worked around, push it as low as possible and as far away from the U-Boot core as possible I mostly agree here. But I still fail to see why we havet os upport this combination of early and dynamic - and only this is what causes some issues. The situations I have seen can be resolved by pre-console buffer and console configured in env. If the hardware is playing up, a factory reset to default console (without using pre-console buffer) suffices (the device is on the bench with nothing attached). But then we are back to the board specific/pre-DT problem. Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/10] x86: Permit bootstage and timer data to be used prior to relocation
Hi Simon,
On 15/12/12 08:13, Simon Glass wrote:
It is useful to be able to access the timer before U-Boot has relocated
so that we can fully support bootstage.
Move the relevant variables to the data region to support this.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/coreboot/coreboot.c |4 ++--
arch/x86/cpu/interrupts.c|2 +-
arch/x86/lib/timer.c |2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/cpu/coreboot/coreboot.c
b/arch/x86/cpu/coreboot/coreboot.c
index 9c9431e..22474f5 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -68,8 +68,8 @@ int board_early_init_r(void)
void show_boot_progress(int val)
{
#if MIN_PORT80_KCLOCKS_DELAY
- static uint32_t prev_stamp;
- static uint32_t base;
+ static uint32_t prev_stamp __attribute__((section(.data)));
+ static uint32_t base __attribute__((section(.data)));
NAK
This may work for coreboot where SDRAM is already initialised and you've
loaded U-Boot into RAM, but it will not work when U-Boot is in Flash as all
sections (including .data) are read-only until after relocation.
The stack and Global Data are the only guaranteed read/write locations
prior to relocation
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/58] x86: Move gd_addr into arch_global_data
Hi Simon,
On 14/12/12 17:48, Simon Glass wrote:
Move this field into arch_global_data and tidy up.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
arch/x86/include/asm/global_data.h |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index 9a4f141..eded279 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -28,6 +28,7 @@
/* Architecture-specific global data */
struct arch_global_data {
+ struct global_data *gd_addr;/* Location of Global Data */
};
/*
@@ -44,8 +45,6 @@ typedef struct global_data gd_t;
struct global_data {
struct arch_global_data arch; /* architecture-specific data */
- /* NOTE: gd_addr MUST be first member of struct global_data! */
- gd_t *gd_addr; /* Location of Global Data */
bd_t*bd;
unsigned long flags;
unsigned intbaudrate;
NAK - You've broken bisectability - patch 13 (slightly modified) needs to
come first
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/58] x86: Set up the global data pointer in C instead of asm
Hi Simon, On 14/12/12 17:48, Simon Glass wrote: We currently assume that the global data pointer is at the start of struct global_data. We want to remove this restriction, and it is easiest to do this in C. Remove the asm code and add equivalent code in C. This idea was proposed by Graeme Russ here: http://patchwork.ozlabs.org/patch/199741/ Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: - Add new patch to move gd pointer by C to asm on x86 arch/x86/cpu/cpu.c |4 +++- arch/x86/cpu/start.S |6 -- 2 files changed, 3 insertions(+), 7 deletions(-) diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c index 315e87a..6a23974 100644 --- a/arch/x86/cpu/cpu.c +++ b/arch/x86/cpu/cpu.c @@ -100,7 +100,9 @@ void setup_gdt(gd_t *id, u64 *gdt_addr) gdt_addr[X86_GDT_ENTRY_32BIT_DS] = GDT_ENTRY(0xc093, 0, 0xf); /* FS: data, read/write, 4 GB, base (Global Data Pointer) */ - gdt_addr[X86_GDT_ENTRY_32BIT_FS] = GDT_ENTRY(0xc093, (ulong)id, 0xf); + id-arch.gd_addr = id; + gdt_addr[X86_GDT_ENTRY_32BIT_FS] = GDT_ENTRY(0xc093, + (ulong)id-arch.gd_addr, 0xf); This patch needs to come before #12 as: - gdt_addr[X86_GDT_ENTRY_32BIT_FS] = GDT_ENTRY(0xc093, (ulong)id, 0xf); + id-gd_addr = id; + gdt_addr[X86_GDT_ENTRY_32BIT_FS] = GDT_ENTRY(0xc093, +(ulong)id-gd_addr, 0xf); Then you can move gd_addr into arch-specific global data Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
Hi Wolfgang, On 15/12/12 09:26, Wolfgang Denk wrote: Dear Tom Rini, In message 50cb8ed1.7020...@ti.com you wrote: The other part is, take a look at the Allwinner thread from a week or so ago. We really need to define how we want early board specific data to come in because if we start saying we'll accept per-SoC solutions we'll be drowning in them in short time. We want to say here's our preferred way to pass this information in. ACK! And we already have a well-defined way to do this, which is the device tree. So any attempts to implement something different should be reviewed very carefully. I'm not sure I 100% get this, but from what I understand, the SoC (or maybe even some EEPROM on a particular board family) may contain device enumeration data in some vendor specific format (i.e. not in a device tree compatible format). The way I see it, there is no way that U-Boot can dictate to SoC and board vendors and say that data must be stored in DT format. So shouldn't U-Boot instead implement a board/SoC specific translation layer which converts this custom data into DT format (maybe in SPL if possible)? But the other problem is if this data includes console specific information (UART configuration). We are left blind until the DT functions become available. So maybe we need some small standard interface to allow the console to be configured early. But we need to prevent this from being abused (i.e. being used to do all kinds of hardware setting from the raw data and bypassing DT) Am I understanding this right? Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ns16550: allow UART address to be set dynamically
Hi Wolfgang, On 15/12/12 11:32, Wolfgang Denk wrote: Dear Graeme Russ, In message 50cbb346.30...@gmail.com you wrote: And we already have a well-defined way to do this, which is the device tree. So any attempts to implement something different should be reviewed very carefully. I'm not sure I 100% get this, but from what I understand, the SoC (or maybe even some EEPROM on a particular board family) may contain device enumeration data in some vendor specific format (i.e. not in a device tree compatible format). Yes, this may, and will, happen. And we will have to support it. The question is, how to do that. I definitely do not want to see any uncontrolled growth of more and more such board or SoC specific code. The way I see it, there is no way that U-Boot can dictate to SoC and board vendors and say that data must be stored in DT format. So shouldn't U-Boot We cannot dictate, but we can encourage and discourage such decisions. If we communicate a clear position, we may even prevent ugly things from happening. Understood, but in the end, board and SoC vendors will do what is most expedient for them, and that may well be a raw binary data format buried in some reserved ROM area (either on-time-writable or EEPROM) instead implement a board/SoC specific translation layer which converts this custom data into DT format (maybe in SPL if possible)? Do you want to see each board grow it's own code to do that? Because this is the extreme that could result from such a decision, and I seriously dislike any such thought. Which is why I'm questioning the general approach when I see it first. Well if the SoC or board (but more likely SoC) has already defined the data structure, you a bit stuck. I fully agree that board developers that choose U-Boot as their primary bootloader should be following U-Boot conventions. But the other problem is if this data includes console specific information (UART configuration). We are left blind until the DT functions become available. So maybe we need some small standard interface to allow the console to be configured early. But we need to prevent this from being abused (i.e. being used to do all kinds of hardware setting from the raw data and bypassing DT) Why do we have to support such dynamic hardware configuration for a very basic thing as the console port at all? You may not find as much in consumer devices (set-top-boxes, mobile phones, tablets etc.) but you will in industrial devices. I can give you an example - Remote Telemetry Units (RTUs). They usually have a number of serial ports. The number of ports may vary based on the sub-model. Some ports may be RS-232, some may be RS-485 or RS-422. Depending on what additional devices you want to communicate with, you may need to use the 'console/diag' port to connect to a real device. So what you want to do is route console to another port (if available) or even netconsole. If the hardware designers cannot fix their minds and use a fixed console port, they should be willing to suffer fromthe penalty that they will have to use board specific board configurations that match the actual consoles settings. Why should we bend and do ugly stuff? Just because software is so much easier to change than hardware? I'm not going to buy this argument. I do get your point of view. But I think a combination of storing the dynamic console info in a DT format, the pre-console buffer and getting DT available as early as possible can yield a 'non-cludgy' solution. For board or SoC vendors who, for whatever reason, have implemented non-DT storage of hardware enumeration data they will be stuck with the penalty of having to translate that data into DT format before it can be parsed by U-Boot. Maybe this could be done in SPL. Yes, it's a hack, but if it can't be worked around, push it as low as possible and as far away from the U-Boot core as possible Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/57] RFC: Move arch-specific global data into its own structure
Hi Wolfgang, On Wed, Dec 5, 2012 at 6:25 AM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message capnjgz2kvhv6jcvojiqbrxfcfhmewfefj9blhfw_qyf5_7d...@mail.gmail.com you wrote: To be honest, I think gd should only be a temporary structure used to carry specific data through the initialisation process up to the point BSS becomes available. With the 'early malloc' patches in the pipeline, it might even be possible to malloc the gd structure early and then when BSS is available, copy the data into the final global data structure in BSS. I think that would be complicated by functions that need to use gd both before and after BSS becomes available. I mostly agree, but that sounds like an exercise in removing fields from the gd one by one in the source code. The bit I am not sure of is whether it is useful for gd to hang around post relocation to provide access to the data that was decided on early in boot (after all, the position in memory of gd changes post relocation, so why maintain two structures for the same info?). Sure. If you look back how this developed, then initially there was only struct bd_info. Then it turned out that it costs too much of code size (and performance, actually) to pass around the same struct as parameter to about each and every functiuon, so I invented GD - wit the intention to drop it as soon as writable global data becomes available, i. e. after relocation. I even think the first versions worked that way. Only later that code code optimized because it seemed easier to keep this struct and be able to use the same code before and after relocation. And open Pandora's box was... Yes, the old 'cost versus complexity' problem. Seriously, take a look at arch/x86/lib/board.c, it's nice and clean and give a good view of how we can move forward. For starters, the functions listed in init_sequence_f and init_sequence_f_r never need to be copied into RAM (there are functions they call that may need to be though). Like the Linux kernel, these can be moved into a dedicated linker section and not copied (and their relocation entries can be skipped as well). For x86, there are not a lot of functions in these two lists. Maybe these can have 'gd' passed to them init_sequence_r is the big list so passing 'gd' to each of these will result in massive code bloat. But by this stage, we have BSS, so global data is writable and there is no need to pass gd. BSS is actually available during the processing of init_sequence_f_r, so in theory it would be possible to copy data from gd (used during init_sequence_f) into BSS during the processing of init_sequence_f_r All that would be left is dealing with the (handful?) of functions that are called from both init_sequence_f and init_sequence_r (I doubt any common functions will be called during init_sequence_f_r). One option may be to pass a point to gd to these functions. If it is NULL, use the variable in BSS, otherwise use gd. Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 07/20] env: Add support for callbacks to environment vars
Hi Joe, What a series! I haven't had a really good look, so I'm having a bit of trouble getting my head around it all, but this looks very impressive. I'm almost sorry for the nit I'm about to make... On Wed, Dec 5, 2012 at 12:52 PM, Joe Hershberger joe.hershber...@ni.com wrote: Add support for per-variable callbacks to the hashtable functions. +/* + * This list of callback bindings is static, but may be overridden by defining + * a new assogiation in the .callbacks environment variable. + */ association Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/57] RFC: Move arch-specific global data into its own structure
Hi Tom, Simon, Wolfgang, On Tue, Dec 4, 2012 at 1:54 AM, Tom Rini tr...@ti.com wrote: On Tue, Nov 20, 2012 at 06:06:30AM -0800, Simon Glass wrote: Hi Wolfgang, On Mon, Nov 19, 2012 at 11:25 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message 1353100842-20126-1-git-send-email-...@chromium.org you wrote: The previous generic board series hit a snag in that we needed generic code to access some of the architecture-specific fields in global_data. [snip] - The change makes the code less readable. Reading gd-arch. instead of plain gd- is no improvements, but rather vice versa. If we really go this way, this should be improved. Yes it would be nice. Are you suggesting some sort of macro, or something else? Wolfgang? global data, architecture specific goo, ... reads fine and helpful to me, honestly. I've mentioned this before - I think gd is being abused. To me, gd should contain only data members that are explicitly required prior to SDRAM being initialised and BSS being available. It has become a bit of a 'well I need this variable everywhere, I'll dump it in gd'. To be honest, I think gd should only be a temporary structure used to carry specific data through the initialisation process up to the point BSS becomes available. With the 'early malloc' patches in the pipeline, it might even be possible to malloc the gd structure early and then when BSS is available, copy the data into the final global data structure in BSS. I think that would be complicated by functions that need to use gd both before and after BSS becomes available. Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/57] RFC: Move arch-specific global data into its own structure
Hi Tom, On Tue, Dec 4, 2012 at 10:39 AM, Tom Rini tr...@ti.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/03/12 17:19, Simon Glass wrote: Hi Graeme, On Mon, Dec 3, 2012 at 2:02 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Tom, Simon, Wolfgang, On Tue, Dec 4, 2012 at 1:54 AM, Tom Rini tr...@ti.com wrote: On Tue, Nov 20, 2012 at 06:06:30AM -0800, Simon Glass wrote: Hi Wolfgang, On Mon, Nov 19, 2012 at 11:25 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message 1353100842-20126-1-git-send-email-...@chromium.org you wrote: The previous generic board series hit a snag in that we needed generic code to access some of the architecture-specific fields in global_data. [snip] - The change makes the code less readable. Reading gd-arch. instead of plain gd- is no improvements, but rather vice versa. If we really go this way, this should be improved. Yes it would be nice. Are you suggesting some sort of macro, or something else? Wolfgang? global data, architecture specific goo, ... reads fine and helpful to me, honestly. I've mentioned this before - I think gd is being abused. To me, gd should contain only data members that are explicitly required prior to SDRAM being initialised and BSS being available. It has become a bit of a 'well I need this variable everywhere, I'll dump it in gd'. To be honest, I think gd should only be a temporary structure used to carry specific data through the initialisation process up to the point, BSS becomes available. With the 'early malloc' patches in the pipeline, it might even be possible to malloc the gd structure early and then when BSS is available, copy the data into the final global data structure in BSS. I think that would be complicated by functions that need to use gd both before and after BSS becomes available. I mostly agree, but that sounds like an exercise in removing fields from the gd one by one in the source code. The bit I am not sure of is whether it is useful for gd to hang around post relocation to provide access to the data that was decided on early in boot (after all, the position in memory of gd changes post relocation, so why maintain two structures for the same info?). At the high level, yes, such a cleaning of gd and perhaps even a re-evaluation of what kind of global data structure we need to keep around for the whole run time is warranted. And the gd-arch-foo would be a good place to start looking for shouldn't be in gd at all candidates. But that's not a blocker, to me, for this series, since it will help show the problems. I agree. While gd-arch does look a bit 'ugly', it immediately unlocks the path forward to unifying the init loop. The x86 board.c would be a good start (IMNSHO) by simply making the init sequence arrays extern. From there we can tackle what really needs to be in gd and what can simply be run of the mill global variables. I think most of what is under gd-arch may just 'fall out' Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] README.scrapyard: add missing commit IDs
Hi Wolfgang, On Thu, Nov 29, 2012 at 11:53 PM, Wolfgang Denk w...@denx.de wrote: Now that the patches have made it into mainline, we can also add the commit IDs. Signed-off-by: Wolfgang Denk w...@denx.de --- doc/README.scrapyard | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/README.scrapyard b/doc/README.scrapyard index 2b868e6..9ad9296 100644 --- a/doc/README.scrapyard +++ b/doc/README.scrapyard @@ -11,13 +11,13 @@ easily if here is something they might want to dig for... Board ArchCPU removed Commit last known maintainer/contact = -AMX860 powerpc mpc860 - - Wolfgang Denk w...@denx.de -c2mon powerpc mpc855 - - Wolfgang Denk w...@denx.de -ETX094 powerpc mpc850 - - Wolfgang Denk w...@denx.de -IAD210 powerpc mpc860 - - - -LANTEC powerpc mpc850 - - Wolfgang Denk w...@denx.de -SCMpowerpc mpc8260 - - Wolfgang Grandegger w...@denx.de -SX1arm arm925t - - +AMX860 powerpc mpc860 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +c2mon powerpc mpc855 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +ETX094 powerpc mpc850 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +IAD210 powerpc mpc860 1b0757e 2012-10-28- +LANTEC powerpc mpc850 1b0757e 2012-10-28Wolfgang Denk w...@denx.de +SCMpowerpc mpc8260 1b0757e 2012-10-28Wolfgang Grandegger w...@denx.de +SX1arm arm925t 53c4154 2012-10-26 TQM85xxpowerpc MPC85xx d923a5d5 2012-10-04Stefan Roese s...@denx.de apollon arm omap24xx 535c74f 2012-09-18Kyungmin Park kyungmin.p...@samsung.com tb0229 mipsmips32 3f3110d 2011-12-12 'removed' and 'Commit' don't match the order of the header Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/12] x86: Allow compiling out realmode/bios code
Hi Simon,
On Fri, Nov 30, 2012 at 12:57 PM, Simon Glass s...@chromium.org wrote:
From: Gabe Black gabebl...@chromium.org
We don't want this for coreboot, so provide a way of compiling it out.
Signed-off-by: Gabe Black gabebl...@chromium.org
Signed-off-by: Stefan Reinauer reina...@chromium.org
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Rename real mode option to CONFIG_X86_NO_REAL_MODE
README|6 ++
arch/x86/lib/Makefile |9 ++---
arch/x86/lib/video.c |2 ++
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/README b/README
index b9a3685..ed7d270 100644
--- a/README
+++ b/README
@@ -3668,6 +3668,12 @@ Low Level (hardware related) configuration options:
If defined, the x86 reset vector code is excluded. You will
need
to do this when U-Boot is running from Coreboot.
+- CONFIG_X86_NO_REAL_MODE
+ If defined, x86 real mode code is omitted. This assumes a
+ 32-bit environment where such code is not needed. You will
+ need to do this when U-Boot is running from Coreboot.
+
+
Freescale QE/FMAN Firmware Support:
---
diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index 51836da..4325b25 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -25,11 +25,16 @@ include $(TOPDIR)/config.mk
LIB= $(obj)lib$(ARCH).o
+ifeq ($(CONFIG_X86_NO_REAL_MODE),)
SOBJS-$(CONFIG_SYS_PC_BIOS)+= bios.o
SOBJS-$(CONFIG_SYS_PCI_BIOS) += bios_pci.o
-SOBJS-$(CONFIG_SYS_X86_REALMODE) += realmode_switch.o
+COBJS-y+= realmode.o
+SOBJS-y+= realmode_switch.o
COBJS-$(CONFIG_SYS_PC_BIOS)+= bios_setup.o
+COBJS-$(CONFIG_VIDEO) += video_bios.o
+endif
+
COBJS-y+= board.o
COBJS-y+= bootm.o
COBJS-y+= cmd_boot.o
@@ -41,11 +46,9 @@ COBJS-$(CONFIG_SYS_PCAT_INTERRUPTS) += pcat_interrupts.o
COBJS-$(CONFIG_SYS_GENERIC_TIMER) += pcat_timer.o
COBJS-$(CONFIG_PCI) += pci.o
COBJS-$(CONFIG_PCI) += pci_type1.o
-COBJS-$(CONFIG_SYS_X86_REALMODE) += realmode.o
COBJS-y+= relocate.o
COBJS-y+= string.o
COBJS-$(CONFIG_SYS_X86_ISR_TIMER) += timer.o
-COBJS-$(CONFIG_VIDEO) += video_bios.o
COBJS-$(CONFIG_VIDEO) += video.o
COBJS-$(CONFIG_CMD_ZBOOT) += zimage.o
diff --git a/arch/x86/lib/video.c b/arch/x86/lib/video.c
index 3d6b24d..20e2416 100644
--- a/arch/x86/lib/video.c
+++ b/arch/x86/lib/video.c
@@ -222,8 +222,10 @@ int video_init(void)
int drv_video_init(void)
{
+#ifndef CONFIG_X86_NO_REAL_MODE
if (video_bios_init())
return 1;
+#endif
return video_init();
}
Hmm, what to do about boot_zimage() in arch/x86/lib/zimage.c. If you
define CONFIG_X86_NO_REAL_MODE but don't define CONFIG_ZBOOT_32 you
will get a linker failure. Maybe change:
#if defined CONFIG_ZBOOT_32 to
#if (defined CONFIG_ZBOOT_32 or defined CONFIG_X86_NO_REAL_MODE)
Don't forget the end goal is to surgically remove all 16-bit support
(apart from the reset vector for non-coreboot boards)
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/12] x86: Allow compiling out realmode/bios code
Hi Simon, On Fri, Nov 30, 2012 at 1:17 PM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Thu, Nov 29, 2012 at 6:09 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, [snip] } Hmm, what to do about boot_zimage() in arch/x86/lib/zimage.c. If you define CONFIG_X86_NO_REAL_MODE but don't define CONFIG_ZBOOT_32 you will get a linker failure. Maybe change: #if defined CONFIG_ZBOOT_32 to #if (defined CONFIG_ZBOOT_32 or defined CONFIG_X86_NO_REAL_MODE) Funny I just had that and took it out. My thought was that it would be a strange board that didn't define both. I will add that code back in. Not strange - completely broken. Maybe add a #error if CONFIG_X86_NO_REAL_MODE is defined and CONFIG_ZBOOT_32 is not? It is perfectly legitimate to define CONFIG_ZBOOT_32 while not defining CONFIG_X86_NO_REAL_MODE Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/12] x86: Allow compiling out realmode/bios code
Hi Simon, On Fri, Nov 30, 2012 at 1:25 PM, Simon Glass s...@chromium.org wrote: Hi Graham, On Thu, Nov 29, 2012 at 6:19 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, On Fri, Nov 30, 2012 at 1:17 PM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Thu, Nov 29, 2012 at 6:09 PM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, [snip] } Hmm, what to do about boot_zimage() in arch/x86/lib/zimage.c. If you define CONFIG_X86_NO_REAL_MODE but don't define CONFIG_ZBOOT_32 you will get a linker failure. Maybe change: #if defined CONFIG_ZBOOT_32 to #if (defined CONFIG_ZBOOT_32 or defined CONFIG_X86_NO_REAL_MODE) Funny I just had that and took it out. My thought was that it would be a strange board that didn't define both. I will add that code back in. Not strange - completely broken. Maybe add a #error if CONFIG_X86_NO_REAL_MODE is defined and CONFIG_ZBOOT_32 is not? OK, I might need to put that in a new patch. Or do you think it is ok to stick it in here? I just sent a new version. I don't think it really matters - that code will go soon anyway Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] README.scrapyard: add missing commit IDs
Hi Wolfgang, On 30/11/2012, at 5:20 PM, Wolfgang Denk w...@denx.de wrote: Dear Graeme Russ, In message calbutcjo15hswnydpuyppsxyngvx6s9h2xp0_dq+x4rpny+...@mail.gmail.com you wrote: Board ArchCPU removed Commit last known maintainer/contact = apollon arm omap24xx 535c74f 2012-09-18Kyungmin Park kyungmin.p...@samsung.com tb0229 mipsmips32 3f3110d 2011-12-12 'removed' and 'Commit' don't match the order of the header Sorry, I don't get what you mean? Which header? Which order? The order of the field list on the first line doesn't match the order of the fields pf the entries Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] x86: Fix compilation on 64-bit build machines
Hi Simon, On Thu, Nov 29, 2012 at 6:46 AM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Tue, Nov 27, 2012 at 5:38 PM, Simon Glass s...@chromium.org wrote: From: Graeme Russ graeme.r...@gmail.com [snip] diff --git a/examples/standalone/Makefile b/examples/standalone/Makefile index baaa2fb..7c1ea5c 100644 --- a/examples/standalone/Makefile +++ b/examples/standalone/Makefile @@ -98,7 +98,7 @@ $(ELF): $(obj)%: $(obj)%.o $(LIB) $(LD) $(LDFLAGS) -g -Ttext $(CONFIG_STANDALONE_LOAD_ADDR) \ -o $@ -e $(SYM_PREFIX)$(notdir $(:.o=)) $ $(LIB) \ - -L$(gcclibdir) -lgcc + -L$(USE_PRIVATE_LIBGCC) -lgcc This forces all archs to use a private libgcc here, right? Is that the intention? It seems to break some of the powerpc boards with my Eeep - no, that was not the intent. I did this so long ago I can't even remember why I did the USE_PRIVATE_LIBGCC eldk-5.2.1 toolchain. I'm not sure of the runes to get U-Boot to compile with a 64-bit toolchain. I think it might be best to completely get to the bottom of this rather than applying part of this patch. So please can you point me to the x86 compiler you tested with? All my building is done with the latest gcc the ships with Fedora 17 (can't recall the version off the top of my head) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] x86: Fix compilation on 64-bit build machines
Hi Simon, On Thu, Nov 29, 2012 at 8:18 AM, Graeme Russ graeme.r...@gmail.com wrote: Hi Simon, On Thu, Nov 29, 2012 at 6:46 AM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Tue, Nov 27, 2012 at 5:38 PM, Simon Glass s...@chromium.org wrote: From: Graeme Russ graeme.r...@gmail.com [snip] diff --git a/examples/standalone/Makefile b/examples/standalone/Makefile index baaa2fb..7c1ea5c 100644 --- a/examples/standalone/Makefile +++ b/examples/standalone/Makefile @@ -98,7 +98,7 @@ $(ELF): $(obj)%: $(obj)%.o $(LIB) $(LD) $(LDFLAGS) -g -Ttext $(CONFIG_STANDALONE_LOAD_ADDR) \ -o $@ -e $(SYM_PREFIX)$(notdir $(:.o=)) $ $(LIB) \ - -L$(gcclibdir) -lgcc + -L$(USE_PRIVATE_LIBGCC) -lgcc This forces all archs to use a private libgcc here, right? Is that the intention? It seems to break some of the powerpc boards with my Eeep - no, that was not the intent. I did this so long ago I can't even remember why I did the USE_PRIVATE_LIBGCC I've had a closer look, and I think this part of the patch is really a hangover from commit 36b2409a3d469b5133d105fa12089429a1900bde (x86: Wrap small helper functions from libgcc to avoid an ABI mismatch) So the proper solution would be to break this patch into two patches - one that fixes the libgcc/abi mismatch for examples/standalone and one that fixes building on 64-bit build machines. There might have been some discussion about the libgcc/regparm mismatch, but I can't recall. I'm wondering if the option of dumping regparm was considered. It really only impacts the code where there is a boundary between .S and .c files and inline asm like in arch/x86/cpu/interrupts.c Overall, it might be a cleaner solution Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] x86: Forward declate gd_t
Hi Marek, On Wed, Nov 28, 2012 at 12:35 PM, Marek Vasut ma...@denx.de wrote: Dear Simon Glass, Hi Marek, On Tue, Nov 27, 2012 at 5:29 PM, Marek Vasut ma...@denx.de wrote: Dear Simon Glass, Hi, On Sun, Apr 29, 2012 at 7:23 PM, Marek Vasut ma...@denx.de wrote: Dear Graeme Russ, So it can be used as a type in struct global_data and remove an ugly typecast Signed-off-by: Graeme Russ graeme.r...@gmail.com --- arch/x86/cpu/cpu.c |2 +- arch/x86/include/asm/global_data.h |4 +++- 2 files changed, 4 insertions(+), 2 deletions(-) I had to modify this slightly to get it to build (added the same cast fix to sdram.c as you did to cpu.c). Then, applied to x86/next. It'd be really nice if you could possibly take over the x86 custodianship from Graeme, it seems this arch is rotting :( Your wish is my command :-) Not so fast, this stuff is better discussed with both of those guys (CCed) You've either had too much beer or too little sleep (or both) - Simon took over several weeks ago :) Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] x86: Forward declare gd_t
Hi Simon,
Was there a reason to repost these patches? I notice you did a couple of
tweaks and added your SoB, but for something so trivial, I don't think
there was a need to repost
Regards,
Graeme
On Wed, Nov 28, 2012 at 12:38 PM, Simon Glass s...@chromium.org wrote:
From: Graeme Russ graeme.r...@gmail.com
So it can be used as a type in struct global_data and remove an ugly
typecast
Signed-off-by: Graeme Russ graeme.r...@gmail.com
Signed-off-by: Simon Glass s...@chromium.org
Acked-by: Marek Vasut ma...@denx.de
---
arch/x86/cpu/cpu.c |2 +-
arch/x86/include/asm/global_data.h |4 +++-
arch/x86/lib/init_helpers.c|2 +-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index e9bb0d7..67de6bc 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -92,7 +92,7 @@ static void load_gdt(const u64 *boot_gdt, u16
num_entries)
void init_gd(gd_t *id, u64 *gdt_addr)
{
- id-gd_addr = (ulong)id;
+ id-gd_addr = id;
setup_gdt(id, gdt_addr);
}
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index bce999f..d471367 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -33,9 +33,11 @@
#ifndef __ASSEMBLY__
+typedef struct global_data gd_t;
+
typedefstruct global_data {
/* NOTE: gd_addr MUST be first member of struct global_data! */
- unsigned long gd_addr;/* Location of Global Data */
+ gd_t *gd_addr; /* Location of Global Data */
bd_t*bd;
unsigned long flags;
unsigned intbaudrate;
diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c
index 9ec34ff..2f718d7 100644
--- a/arch/x86/lib/init_helpers.c
+++ b/arch/x86/lib/init_helpers.c
@@ -126,7 +126,7 @@ int copy_gd_to_ram_f_r(void)
* in-RAM copy of Global Data (calculate_relocation_address()
* has already calculated the in-RAM location of the GDT)
*/
- ram_gd-gd_addr = (ulong)ram_gd;
+ ram_gd-gd_addr = ram_gd;
init_gd(ram_gd, (u64 *)gd-gdt_addr);
return 0;
--
1.7.7.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Older x86 patches
Hi Simon, On Wed, Nov 28, 2012 at 12:45 PM, Simon Glass s...@chromium.org wrote: Hi Graeme, As you may have seen I have resent your 5 patches just because it has been a while. I just realised that I failed to increment the version on the two that I tweaked. But anyway they are available in x86/next for you to take a look if you have time. I have run-tested them and will build test now. You haven't pushed them yet :P I'm really happy with the simplification that you have managed to achieve. It is really nice. Thanks - It was a labour of love. Glad to see someone else keeping it going Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 2/9] x86: Allow excluding reset vector code from u-boot
Hi Simon, On Tue, Nov 27, 2012 at 10:14 AM, Simon Glass s...@chromium.org wrote: Hi Wolfgang, On Mon, Nov 26, 2012 at 3:03 PM, Wolfgang Denk w...@denx.de wrote: Dear Simon Glass, In message 1353961997-32762-3-git-send-email-...@chromium.org you wrote: +- CONFIG_NO_RESET_CODE + If defined, the x86 reset vector code is excluded. You will need + to do this when U-Boot is running from Coreboot. Sorry fr never ending nitpicking - but either this is some x86 specific stuff, then it would probably make sense to have such indication in the name of the define, or it is not, then the comment should be fixed. +START-$(CONFIG_SYS_X86_RESET_VECTOR) += resetvec.o start16.o CONFIG_SYS_X86_RESET_VECTOR - is this just another new, undocumented variable? Yes it is new and undocumented, because it is internal to the x86 implementation and I don't want people to set it. Or a mismatch between documentation and code? Well there are now two options: 1. The user-facing CONFIG_NO_RESET_CODE option which, if not defined, asserts CONFIG_SYS_X86_RESET_VECTOR 2. CONFIG_SYS_X86_RESET_VECTOR which is used in the Makefiles I would rather have a single positive option (CONFIG_SYS_X86_RESET_VECTOR, as series v4). Failing that I would rather have ifneq in the Makefile (and just use CONFIG_NO_RESET_CODE). I am not sure how to have a negative option without an ifneq in the Makefile. I looked pretty hard but could not find an example in U-Boot. That is the crux of the problem - we want to have a config define which _excludes_ the compilation of some code (in this case the reset vector). This should be expanded to optionally exclude the 16-bit 'Real Mode' code (with the ultimate goal of dropping that code altogether). My vote would be for a CONFIG_X86_NO_RESET_VECTOR (and CONFIG_X86_NO_REAL_MODE) and just use ifneq in the Makefile Re CONFIG_NO_RESET_CODE, it probably should be CONFIG_SYS_X86_NO_RESET_CODE, but it would be even better if we could just have one option. I worry that people will be confused by one that they set, which affects another that is set if they don't see the first...In a month I will probably find it confusing. This is possible a minor point since I think Graeme said that the only other x86 board will move to Coreboot soon. Actually, I said that the only other x86 board will be dropped from U-Boot as the processor is no longer available. Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 00/22] ARM: Allwinner sunXi (A10 A13) SoC support
Hi Henrik, Thanks for your hard work - I did promise to help you through the patch submission process, but unfortunately a few personal issues took precedence. It's good to see not only the core A10 support, but several boards right off the bat. With respect to the boards, is putting them all in the same board directory the right thing to do? The are each manufactured by different vendors, and as far as I can tell the board directory follows a style more like /board/vendor/model (or /board/model for vendors with only one board) As Wolfgang mentioned, don't forget to run your patches through checkpatch.pl and make sure you properly prefix your next version v2 Regards, Graeme On Sun, Nov 25, 2012 at 10:36 PM, Henrik Nordström hen...@henriknordstrom.net wrote: This patch series adds support for Allwinner sunxi (A10 A13) SoC families, including SPL loader to boot u-boot directly from MMC/SD. Aaron (1): ARM: sunxi: MMC driver Henrik Nordstrom (14): ARM sunxi: I2C driver ARM: sunxi: watchdog support power: Add AXP209 Power Management controller (I2C) ARM sunxi: Basic GPIO driver tools: mksunixboot adding a Allwinner boot header sunxi: Add more network commands and netconsole support ARM: sunxi: U-Boot SPL capable of booting directly from MMC ARM sunxi: SPL support for Olimex A13-OLinuXino board ARM sunxi: SPL support for Mele A1000 board ARM sunxi: SPL support for Cubieboard board ARM sunxi: SPL support for Hackberry 1GB board ARM sunxi: SPL support for Mini-X board ARM sunxi: SPL support for hyundai A7HD board ARM sunxi: SPL support for Mele A3700 board Jari Helaakoski (1): ARM sunxi: SPL support for a13_mid board Sergey Lapin (1): ARM sunxi: SPL support for MK802 board Stefan Roese (2): net: Add sunxi (Allwinner) wemac driver ARM: sun4i: Enable ethernet support (wemac) on A10 boards Tom Cubie (1): ARM: sunxi: Basic Allwinner A10/A13 (sun4i/sun5i) support hehopmajieh (1): ARM sunxi: SPL support for Olinuxino A13 Micro j (1): ARM sunxi: SPL support for Rikomagic MK802II board MAINTAINERS | 13 + Makefile| 12 + arch/arm/cpu/armv7/Makefile |2 +- arch/arm/cpu/armv7/sunxi/Makefile | 51 ++ arch/arm/cpu/armv7/sunxi/board.c| 132 ++ arch/arm/cpu/armv7/sunxi/clock.c| 171 +++ arch/arm/cpu/armv7/sunxi/dram.c | 445 ++ arch/arm/cpu/armv7/sunxi/pinmux.c | 61 +++ arch/arm/cpu/armv7/sunxi/reset.S| 39 ++ arch/arm/cpu/armv7/sunxi/timer.c| 117 + arch/arm/cpu/armv7/sunxi/u-boot-spl.lds | 63 +++ arch/arm/include/asm/arch-sunxi/clock.h | 179 +++ arch/arm/include/asm/arch-sunxi/cpu.h | 146 ++ arch/arm/include/asm/arch-sunxi/dram.h | 114 + arch/arm/include/asm/arch-sunxi/gpio.h | 166 +++ arch/arm/include/asm/arch-sunxi/i2c.h | 185 arch/arm/include/asm/arch-sunxi/mmc.h | 64 +++ arch/arm/include/asm/arch-sunxi/spl.h | 34 ++ arch/arm/include/asm/arch-sunxi/sys_proto.h | 31 ++ arch/arm/include/asm/arch-sunxi/timer.h | 102 board/sunxi/Makefile| 58 +++ board/sunxi/board.c | 112 + board/sunxi/dram_a13_mid.c | 31 ++ board/sunxi/dram_a13_oli_micro.c| 32 ++ board/sunxi/dram_a13_olinuxino.c| 31 ++ board/sunxi/dram_cubieboard.c | 31 ++ board/sunxi/dram_cubieboard_512.c | 31 ++ board/sunxi/dram_hackberry.c| 31 ++ board/sunxi/dram_hyundai_a7hd.c | 31 ++ board/sunxi/dram_mele_a1000.c | 24 + board/sunxi/dram_mele_a3700.c | 31 ++ board/sunxi/dram_mini_x.c | 31 ++ board/sunxi/dram_mk802.c| 24 + board/sunxi/dram_mk802ii.c | 31 ++ boards.cfg | 16 + drivers/gpio/Makefile |1 + drivers/gpio/sunxi_gpio.c | 116 + drivers/i2c/Makefile|1 + drivers/i2c/sunxi_i2c.c | 278 +++ drivers/mmc/Makefile|1 + drivers/mmc/sunxi_mmc.c | 674 +++ drivers/net/Makefile|1 + drivers/net/sunxi_wemac.c | 533 + drivers/power/Makefile |1 + drivers/power/axp209.c | 183 drivers/watchdog/Makefile |1 + drivers/watchdog/sunxi_watchdog.c | 49 ++ include/axp209.h| 29 ++ include/configs/sun4i.h | 74 +++ include/configs/sun5i.h
Re: [U-Boot] Reg Bootstrapping u-boot on x86-64 for tizen
Hi Manohar, On 11/24/2012 06:08 PM, manohar.bet...@smartplayin.com wrote: Hi, I am getting the following error after running make all for coreboot target,from /usr/bin/ld.bfd.real: skipping incompatible /home/manoharb/Kernel_Tizen/intel_tizen/latest/u-boot/arch/x86/lib/libgcc.a when searching for -lgcc /usr/bin/ld.bfd.real: cannot find -lgcc make: *** [u-boot] Error 1 What toolchain (and version) are you using? I've never seen ld.bfd.real before Regards, Graeme Please help me. Best Regards, Manohar -Original Message- From: Graeme Russ graeme.r...@gmail.com Sent: Friday, November 23, 2012 4:23pm To: manohar.bet...@smartplayin.com Cc: Marek Vasut ma...@denx.de, u-boot@lists.denx.de, Simon Glass s...@chromium.org Subject: Re: [U-Boot] Reg Bootstrapping u-boot on x86-64 for tizen Hi Manohar, On 11/23/2012 09:10 PM, manohar.bet...@smartplayin.com wrote: Dear Graeme, Thank you! I downloaded the u-boot-x86 on Ubuntu 11.10 loaded(Linux smart-OptiPlex-390 3.0.0-26-generic x86_64 GNU/Linux) intel i5 M1H61R-MB montherboard from the given below link. http://git.denx.de/?p=u-boot/u-boot-x86.git;a=summary Depending on when you downloaded it, you may not have the latest mainline which is at: http://git.denx.de/?p=u-boot.git;a=summary Nevertheless, you will have the latest x86 patches and yes I am planning to run u-boot on x86_64 machine and my target is also x86_64 machine are the same . cd u-boot-x86 Hmm, I don't think U-Boot is what your after. There are a few problems you will be faced with: - There is no ACPI support (no power management) - No System Management Mode (SMM) support - No chipset support (No RAM initialisation) - No Cache-As-RAM init code Unless you have at least these covered, you will brick your board if you try to flash U-Boot. You might instead take a look at coreboot opened the boards.config file and appended my board details in the config file . MIH61R-MBx86 x86MIH61R-MB GenuineIntel - # Target ARCHCPU Board name VendorSoC Options and then run the below commands and i didnot modify any code other than that above line. . manoharb@smart-OptiPlex-390:~/Kernel_Tizen/intel_tizen/u-boot-x86$ vim boards.cfg manoharb@smart-OptiPlex-390:~/Kernel_Tizen/intel_tizen/u-boot-x86$ make distclean /bin/bash: i386-linux-gcc: command not found /bin/bash: i386-linux-gcc: command not found [snip] Ah, I now see that the patch I thought had been applied has not :( You will need this patch: http://patchwork.ozlabs.org/patch/155727/ Regards, Graeme ... Please help me what are the files i need to modify and provide me the documentation. Thank you! Best Regards, Manohar 8790215215 -Original Message- From: Graeme Russ graeme.r...@gmail.com Sent: Friday, November 23, 2012 12:12pm To: manohar.bet...@smartplayin.com Cc: Marek Vasut ma...@denx.de, u-boot@lists.denx.de Subject: Re: [U-Boot] Reg Bootstrapping u-boot on x86-64 for tizen Hi Manohar, On 11/23/2012 04:46 PM, manohar.bet...@smartplayin.com wrote: Dear Marek, Thank you for the reply. Can you please send me the steps/procedure to build/support u-boot on x86_64 bit (Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz. I build the x86 U-Boot target on an x86_64 i7 Linux (Fedora) system using the standard GNU gcc package. There was an issue with the Makefile and there was a need to manually create some toolchain symlinks, but the was rectified some time ago. Are you using the latest mainline U-Boot from git.denx.de? If so, what errors are you getting - please provide a copy of your build output. We need help from you is there any documentation to enable x86_64 bit pc or links to post my query. What are the config/code i need to change to make my pc as host target are the same. Are you planning on running U-Boot on an x86_64 machine? If so, you will need to create code to support that - Current U-Boot only supports 32-bit x86 targets. The sandbox target (designed for testing on a Linux host, not for downloading onto a board) should run on an x86_64 host. Please help us to build the u-boot on x86_64. Please provide more detail - what have you tried? What was the result? The build scripts should work as is on a properly configured x86_64 build machine
Re: [U-Boot] Reg Bootstrapping u-boot on x86-64 for tizen
Hi Manohar, On 11/23/2012 09:10 PM, manohar.bet...@smartplayin.com wrote: Dear Graeme, Thank you! I downloaded the u-boot-x86 on Ubuntu 11.10 loaded(Linux smart-OptiPlex-390 3.0.0-26-generic x86_64 GNU/Linux) intel i5 M1H61R-MB montherboard from the given below link. http://git.denx.de/?p=u-boot/u-boot-x86.git;a=summary Depending on when you downloaded it, you may not have the latest mainline which is at: http://git.denx.de/?p=u-boot.git;a=summary Nevertheless, you will have the latest x86 patches and yes I am planning to run u-boot on x86_64 machine and my target is also x86_64 machine are the same . cd u-boot-x86 Hmm, I don't think U-Boot is what your after. There are a few problems you will be faced with: - There is no ACPI support (no power management) - No System Management Mode (SMM) support - No chipset support (No RAM initialisation) - No Cache-As-RAM init code Unless you have at least these covered, you will brick your board if you try to flash U-Boot. You might instead take a look at coreboot opened the boards.config file and appended my board details in the config file . MIH61R-MBx86 x86MIH61R-MB GenuineIntel - # Target ARCHCPU Board name VendorSoC Options and then run the below commands and i didnot modify any code other than that above line. . manoharb@smart-OptiPlex-390:~/Kernel_Tizen/intel_tizen/u-boot-x86$ vim boards.cfg manoharb@smart-OptiPlex-390:~/Kernel_Tizen/intel_tizen/u-boot-x86$ make distclean /bin/bash: i386-linux-gcc: command not found /bin/bash: i386-linux-gcc: command not found [snip] Ah, I now see that the patch I thought had been applied has not :( You will need this patch: http://patchwork.ozlabs.org/patch/155727/ Regards, Graeme ... Please help me what are the files i need to modify and provide me the documentation. Thank you! Best Regards, Manohar 8790215215 -Original Message- From: Graeme Russ graeme.r...@gmail.com Sent: Friday, November 23, 2012 12:12pm To: manohar.bet...@smartplayin.com Cc: Marek Vasut ma...@denx.de, u-boot@lists.denx.de Subject: Re: [U-Boot] Reg Bootstrapping u-boot on x86-64 for tizen Hi Manohar, On 11/23/2012 04:46 PM, manohar.bet...@smartplayin.com wrote: Dear Marek, Thank you for the reply. Can you please send me the steps/procedure to build/support u-boot on x86_64 bit (Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz. I build the x86 U-Boot target on an x86_64 i7 Linux (Fedora) system using the standard GNU gcc package. There was an issue with the Makefile and there was a need to manually create some toolchain symlinks, but the was rectified some time ago. Are you using the latest mainline U-Boot from git.denx.de? If so, what errors are you getting - please provide a copy of your build output. We need help from you is there any documentation to enable x86_64 bit pc or links to post my query. What are the config/code i need to change to make my pc as host target are the same. Are you planning on running U-Boot on an x86_64 machine? If so, you will need to create code to support that - Current U-Boot only supports 32-bit x86 targets. The sandbox target (designed for testing on a Linux host, not for downloading onto a board) should run on an x86_64 host. Please help us to build the u-boot on x86_64. Please provide more detail - what have you tried? What was the result? The build scripts should work as is on a properly configured x86_64 build machine Regards, Graeme P.S. Please stop top posting - thanks Thank you! Best Regards, Manohar 8790215215 -Original Message- From: Marek Vasut ma...@denx.de Sent: Friday, November 23, 2012 6:08am To: u-boot@lists.denx.de Cc: manohar.bet...@smartplayin.com, Graeme Russ graeme.r...@gmail.com Subject: Re: [U-Boot] Reg Bootstrapping u-boot on x86-64 for tizen Dear manohar.bet...@smartplayin.com, Hi, I am Manohar,started boot the X86-64 (Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz) using u-boot to work for TIZEN . As I am unable to configure/build my pc using u-boot-x86 . I request you please help me how to configure it/build the u-boot-x86 on my pc as my pc is loaded with Ubuntu 11.10 and my aim is to make my PC as host and target are the same. Please resolve the issue/is my PC support for the u-boot. You need to compile
Re: [U-Boot] Reg Bootstrapping u-boot on x86-64 for tizen
Hi Manohar, On 11/23/2012 04:46 PM, manohar.bet...@smartplayin.com wrote: Dear Marek, Thank you for the reply. Can you please send me the steps/procedure to build/support u-boot on x86_64 bit (Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz. I build the x86 U-Boot target on an x86_64 i7 Linux (Fedora) system using the standard GNU gcc package. There was an issue with the Makefile and there was a need to manually create some toolchain symlinks, but the was rectified some time ago. Are you using the latest mainline U-Boot from git.denx.de? If so, what errors are you getting - please provide a copy of your build output. We need help from you is there any documentation to enable x86_64 bit pc or links to post my query. What are the config/code i need to change to make my pc as host target are the same. Are you planning on running U-Boot on an x86_64 machine? If so, you will need to create code to support that - Current U-Boot only supports 32-bit x86 targets. The sandbox target (designed for testing on a Linux host, not for downloading onto a board) should run on an x86_64 host. Please help us to build the u-boot on x86_64. Please provide more detail - what have you tried? What was the result? The build scripts should work as is on a properly configured x86_64 build machine Regards, Graeme P.S. Please stop top posting - thanks Thank you! Best Regards, Manohar 8790215215 -Original Message- From: Marek Vasut ma...@denx.de Sent: Friday, November 23, 2012 6:08am To: u-boot@lists.denx.de Cc: manohar.bet...@smartplayin.com, Graeme Russ graeme.r...@gmail.com Subject: Re: [U-Boot] Reg Bootstrapping u-boot on x86-64 for tizen Dear manohar.bet...@smartplayin.com, Hi, I am Manohar,started boot the X86-64 (Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz) using u-boot to work for TIZEN . As I am unable to configure/build my pc using u-boot-x86 . I request you please help me how to configure it/build the u-boot-x86 on my pc as my pc is loaded with Ubuntu 11.10 and my aim is to make my PC as host and target are the same. Please resolve the issue/is my PC support for the u-boot. You need to compile it on a 32bit machine ... or install 32bit cross compiler ... u-boot doesn't support x86/64. Patches are welcome though. Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/57] x86: Move new_gd_addr to arch_global_data
Hi Simon,
On 11/17/2012 08:19 AM, Simon Glass wrote:
Move this field into arch_global_data and tidy up.
This will certainly break x86, so will need Graeme's help to sort out
Yes, it most certainly will break x86 :)
the problem. I would prefer not to put the architecture-specific stuff
at the top of global_data since we relying on that seems even more ugly.
The fix is not that hard though...
The whole point of putting gdt_addr at the top of the global data structure
is to guarantee that is is the very fist void * in gd. The trick is how we
use the 'F' segment. By loading the fs register with the physical address
of gd, virtual address 0 of fs contains the address of gd.
But really, we can put the address of gd anywhere, as long as we set fs to
be that address
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/cpu.c |2 +-
arch/x86/include/asm/global_data.h | 12 +---
arch/x86/lib/init_helpers.c|2 +-
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index e9bb0d7..c276aa6 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -92,7 +92,7 @@ static void load_gdt(const u64 *boot_gdt, u16 num_entries)
void init_gd(gd_t *id, u64 *gdt_addr)
{
- id-gd_addr = (ulong)id;
+ id-arch.gd_addr = (ulong)id;
setup_gdt(id, gdt_addr);
If the original code had been:
setup_gdt((id-gd_addr), gdt_addr);
There would have been no reliance on gd_addr being the first member of gd.
So change this to:
setup_gdt((id-arch.gd_addr), gdt_addr);
And you should be pretty much set - and gd_addr can be anywhere in the arch gd.
}
diff --git a/arch/x86/include/asm/global_data.h
b/arch/x86/include/asm/global_data.h
index 3df83bb..d2eb00a 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -28,8 +28,16 @@
/* Architecture-specific global data */
struct arch_global_data {
- unsigned long gdt_addr; /* Location of GDT */
+ /*
+ * NOTE: gd_addr MUST be first member of struct global_data!
+ *
+ * But it now isn't, so this is sure to break x86. Can we change
+ * x86 to not require this? I don't think we should put the
+ * arch data first in global_data...
+ */
Yes we can - see above
unsigned long new_gd_addr; /* New location of Global Data */
+ unsigned long gd_addr; /* Location of Global Data */
+ unsigned long gdt_addr; /* Location of GDT */
};
/*
@@ -41,8 +49,6 @@ struct arch_global_data {
*/
typedef struct global_data {
- /* NOTE: gd_addr MUST be first member of struct global_data! */
- unsigned long gd_addr;/* Location of Global Data */
bd_t*bd;
unsigned long flags;
unsigned intbaudrate;
diff --git a/arch/x86/lib/init_helpers.c b/arch/x86/lib/init_helpers.c
index 05cadcd..ac789c2 100644
--- a/arch/x86/lib/init_helpers.c
+++ b/arch/x86/lib/init_helpers.c
@@ -126,7 +126,7 @@ int copy_gd_to_ram_f_r(void)
* in-RAM copy of Global Data (calculate_relocation_address()
* has already calculated the in-RAM location of the GDT)
*/
- ram_gd-gd_addr = (ulong)ram_gd;
+ ram_gd-arch.gd_addr = (ulong)ram_gd;
init_gd(ram_gd, (u64 *)gd-arch.gdt_addr);
return 0;
Regards,
Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] x86: Anyone willing to take over the reigns
Hi Simon, On Oct 31, 2012 3:21 AM, Simon Glass s...@chromium.org wrote: Hi Graeme, On Sun, Oct 28, 2012 at 4:44 AM, Graeme Russ graeme.r...@gmail.com wrote: Hi All, I think it's finally time I admitted that I simply have too much on my plate and need to give a few things up. Work and family life have got to the point where I can only manage to grab a quick hour here and there at my desk at home and I simply do not have enough time (or energy) to keep maintaining the x86 repo. It's been really good to see the Chromium guys giving U-Boot x86 some much needed love, but it has highlighted to me just how much work it has been (and will be) to keep up. To give you an idea, I haven't sync'd my local repo (much less built U-Boot) in over a month now. My bandwidth is down to making a few passing comments on very specific patches. Does anyone feel up to the task of taking on the x86 repo? If not, I'm sure that it could revert to the old days of being directly managed as 'miscellaneous' I would be happy to take this on for a while. Thanks :-). I really appreciate it Will you still be able to do some review, perhaps just for the more 'core' patches? Of course. I'll probably also provide some architectural suggestions and Acks. Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] x86: Anyone willing to take over the reigns
Hi All, I think it's finally time I admitted that I simply have too much on my plate and need to give a few things up. Work and family life have got to the point where I can only manage to grab a quick hour here and there at my desk at home and I simply do not have enough time (or energy) to keep maintaining the x86 repo. It's been really good to see the Chromium guys giving U-Boot x86 some much needed love, but it has highlighted to me just how much work it has been (and will be) to keep up. To give you an idea, I haven't sync'd my local repo (much less built U-Boot) in over a month now. My bandwidth is down to making a few passing comments on very specific patches. Does anyone feel up to the task of taking on the x86 repo? If not, I'm sure that it could revert to the old days of being directly managed as 'miscellaneous' Regards, Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9] [RFC] Add dmmalloc module for DM.
Hi Tomas,
On Fri, Oct 26, 2012 at 6:16 AM, Tomas Hlavacek tmshl...@gmail.com wrote:
Hello Graeme,
On Thu, Oct 25, 2012 at 3:40 AM, Graeme Russ graeme.r...@gmail.com wrote:
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 2b9af93..9045829 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -82,6 +82,9 @@ typedef struct global_data {
unsigned long post_log_res; /* success of POST test */
unsigned long post_init_f_time; /* When post_init_f started */
#endif
+#ifdef CONFIG_SYS_EARLY_MALLOC
+ void*early_heap;/* heap for early_malloc */
+#endif
Why not early_heap_header *early_heap; ?
It might be.
Actually it is a good point because I am using 3 different ways of
dealing with addresses: 1) struct early_heap header * or struct
early_block_header * - I am using this when I want to access members
of the stucture or compute address past the structure (which is where
the heap or block starts); 2) phys_addr_t - which is plain integer and
I use this for simple computations when I do not want to worry about
pointer arithmetic; 3) void * when I have just plain address,
especially when I want to pass an addres among logical parts of the
mallocator or outside. This may a bit controversial and perhaps I
should replace it by specific strucutre pointers internally.
I am unable to decide: Should I remove struct early_heap_header from
dmmalloc.h making it publicly unavailable or should I rather change
the void * to struct early_heap_header * in the GD structure? What do
you think is better?
I think struct early_heap_header * in the GD structure is the better way to
go as that is exactly what it is.
[snip]
+ h = (struct early_heap_header *)CONFIG_SYS_EARLY_HEAP_ADDR;
+ b = (struct early_block_header *)(h + 1);
Hmmm, does this really work? I would have thought:
b = (struct early_block_header *)(h + sizeof(struct early_heap_header));
but I could be mistaken
It seems that it works as it is (at least I wrote bunch of tests and I
inspected resulting heaps and it was all right). I believe that since
h is a pointer to the struct early_heap_header then pointer arithmetic
is in effect and h+1 actually means next element in the array of
struct early_heap_header. Which is the address past the header that
equals beginning of the heap data block. (?)
As I said, I could be mistaken - it appears I am :)
+int early_malloc_active(void)
+{
+ return ((gd-flags GD_FLG_RELOC) != GD_FLG_RELOC);
+}
I think we need another flag - GD_FLG_RELOC gets set before the permanent
heap is initialised, so there is a window of opportunity where things may
break
Well, as I wrote in the commit message - this is only a temporary
implementation. I suppose I am going to change this when we have more
coarse initialization flags wired into DM (which I believe we are
going to have it anyway). So now I am just working around forward
dependency here.
+
+void early_heap_dump(struct early_heap_header *h)
+{
+ struct early_block_header *b;
+
+ debug(heap: h=%p, h-size=%d\n, h, h-size);
+
+ b = (struct early_block_header *)(h+1);
+ while ((phys_addr_t)b + sizeof(struct early_block_header)
+(phys_addr_t)h + h-size) {
+ debug(block: h=%p h-size=%d b=%p b-size=%d
b-(used)=%d\n,
+ h, h-size, b, BLOCK_SIZE(b-size),
+ BLOCK_USED(b-size));
+ assert(BLOCK_SIZE(b-size) 0);
+ b = (struct early_block_header *)((phys_addr_t)b +
+ sizeof(struct early_block_header) +
+ BLOCK_SIZE(b-size));
+ }
+ debug(--- heap dump end ---\n);
+}
Nice touch, but could we just iterate through all ealry heap chunks starting
from gd-early_heap?
Or I can have two functions. One heap specific and one for all heaps.
I think both might be useful when somebody needs to debug early_malloc
or memory usage etc. in the early stage. Thanks.
True, just adding another function which iterates through the heaps and
calls this function would be fine.
[snip]
+static inline void *dmrealloc(void *oldaddr, size_t bytes)
+{
+#ifdef CONFIG_SYS_EARLY_MALLOC
+ char *addr;
+ struct early_block_header *h;
+ if (early_malloc_active()) {
+ addr = dmmalloc(bytes);
+ if (addr == NULL)
+ return NULL;
+
+ h = BLOCK_HEADER(oldaddr);
+ if (BLOCK_FREE(h-size))
+ return NULL;
+
+ if (bytes BLOCK_SIZE(h-size))
+ bytes = BLOCK_SIZE(h-size);
+
+ memcpy(addr, oldaddr, bytes);
+ dmfree(oldaddr);
+ return addr;
+ }
+#endif /* CONFIG_SYS_EARLY_MALLOC
