[U-Boot] Incomplete type declarations in arch/Kconfig (U-Boot-2014.10)
Hi, I'm quite new to U-Boot as well as to the whole Kconfig system, so this may be a dumb question, in which case please forgive my ignorance. I noticed that the type declarations of several items in the file arch/Kconfig are actually incomplete, lacking the prompt parameter: config SYS_ARCH string help (...) config SYS_CPU string help (...) etc. (same for SYS_SOC, SYS_VENDOR, SYS_BOARD and SYS_CONFIG_NAME) If I'm not mistaken, the string type declaration in Kconfig is supposed to look like either of the following: string something or string prompt something In this case, again if I'm not mistaken, these incomplete declarations seem to prevent the items from being created at this step, thus preventing any possibility of overriding the default values directly in a _defconfig file. So my question is: is this intentional (in which case I would probably recommend using comments for that purpose instead of incomplete declarations)? Or is this a bug (in which case I would be happy to submit a fix simply adding the prompt strings)? Here is a bit of context if need be: I'm trying to find a way to compile a variant of U-Boot for an existing board (basically just overriding a few lines in board.h), but I would like to do it without _modifying_ any file in the U-Boot distribution, nor fiddling with .config, but rather by only adding files (namely configs/myvariant_defconfig, and configs/board-myvariant.h), so that there will be nothing to merge to support later U-Boot versions. I've been struggling with this today, assuming that overriding CONFIG_SYS_CONFIG_NAME in my _defconfig would be enough (as it is for CONFIG_SYS_EXTRA_OPTIONS)... but I couldn't get it to work, as only the default value got from arch/arch/board/Kconfig was used, and I couldn't find any way to add my configuration without actually modifying something in U-Boot's core (either some Kconfig files, or the original board.h) or manually editing the generated .config. This was until I noticed that type declaration problem. As soon as I added the prompt parameters, I was able to successfully build a .config with the desired CONFIG_SYS values, and then compile everything as expected. Hence the aforementioned question... Thanks a lot for reading, and congratulations for all the work on Das U-Boot... This is a really amazing system. GMal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] spl: if MMCSD_MODE_RAW fails, try MMCSD_MODE_FS, if available
Ping.
Just a friendly reminder.
Guillaume
Le 18/11/2014 10:44, Guillaume GARDET a écrit :
In SPL MMC, boot modes are exclusive. So, if MMCSD_MODE_RAW fails, the board
hangs. This patch allows to
try MMCSD_MODE_FS then, if available.
It has been tested on a pandaboard (rev. A3).
Signed-off-by: Guillaume GARDET guillaume.gar...@free.fr
Cc: Tom Rini tr...@ti.com
---
common/spl/spl_mmc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index ee71f79..2c34b75 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -101,7 +101,8 @@ void spl_mmc_load_image(void)
err = mmc_load_image_raw(mmc,
CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR);
#if defined(CONFIG_SPL_FAT_SUPPORT) || defined(CONFIG_SPL_EXT_SUPPORT)
- } else if (boot_mode == MMCSD_MODE_FS) {
+ }
+ if (err || boot_mode == MMCSD_MODE_FS) {
debug(boot mode - FS\n);
#ifdef CONFIG_SPL_FAT_SUPPORT
#ifdef CONFIG_SPL_OS_BOOT
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Incomplete type declarations in arch/Kconfig (U-Boot-2014.10)
Hi Guilhem, On Tue, 2 Dec 2014 07:03:24 + Guilhem Malichier g...@eco-counter.com wrote: Hi, I'm quite new to U-Boot as well as to the whole Kconfig system, so this may be a dumb question, in which case please forgive my ignorance. I noticed that the type declarations of several items in the file arch/Kconfig are actually incomplete, lacking the prompt parameter: Not incomplete. It is grammatically correct and used very often. config SYS_ARCH string help (...) config SYS_CPU string help (...) etc. (same for SYS_SOC, SYS_VENDOR, SYS_BOARD and SYS_CONFIG_NAME) If I'm not mistaken, the string type declaration in Kconfig is supposed to look like either of the following: string something or string prompt something in case the option is supposed to be configured by users. In this case, again if I'm not mistaken, these incomplete declarations seem to prevent the items from being created at this step, thus preventing any possibility of overriding the default values directly in a _defconfig file. So my question is: is this intentional (in which case I would probably recommend using comments for that purpose instead of incomplete declarations)? Or is this a bug (in which case I would be happy to submit a fix simply adding the prompt strings)? It is intentional. SYS_ARCH, SYS_CPU, ... should not directly touched. They should always be set to a combination of correct values. For example, if you choose CONFIG_ARM in the architecture select menu, SYS_ARCH is automatically set to arm. Here is a bit of context if need be: I'm trying to find a way to compile a variant of U-Boot for an existing board (basically just overriding a few lines in board.h), but I would like to do it without _modifying_ any file in the U-Boot distribution, nor fiddling with .config, but rather by only adding files (namely configs/myvariant_defconfig, and configs/board-myvariant.h), so that there will be nothing to merge to support later U-Boot versions. Having your own configs/*_defconfig is easy, just add it, but I have no idea how to add your own include/configs/*.h without modifying any file. I've been struggling with this today, assuming that overriding CONFIG_SYS_CONFIG_NAME in my _defconfig would be enough (as it is for CONFIG_SYS_EXTRA_OPTIONS)... but I couldn't get it to work, as only the default value got from arch/arch/board/Kconfig was used, and I couldn't find any way to add my configuration without actually modifying something in U-Boot's core (either some Kconfig files, or the original board.h) or manually editing the generated .config. This was until I noticed that type declaration problem. As soon as I added the prompt parameters, I was able to successfully build a .config with the desired CONFIG_SYS values, and then compile everything as expected. Hence the aforementioned question... We(I) have not taken such a usage into account. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] m68k: Build problems on some boards
Dear Masahiro, I recommend you to use kernel.org toolchain as I mentioned in http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/188763/focus=190993 or git log fbe79a17fddb7f0b many thanks, i am not confident still using the archive, was using the pipermail archive, and clicking next message it was not showing your last message since it was in the next month. Will use gmane as you did. And thanks to your post i have also seen now how to build all the m68k boards in the correct way. So the tool chain you posted gives no warnings and so it is the recommended one to be used actually. Will install it tonight. In any case, i was also able to build all the boards with my current toolchain: opt/CodeSourcery/Sourcery_CodeBench_Lite_for_ColdFire_ELF/bin/m68k-elf-gcc --version m68k-elf-gcc (Sourcery CodeBench Lite 2011.09-21) 4.6.1 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - SUMMARY Boards compiled: 48 Boards with warnings but no errors: 48 ( M52277EVB M52277EVB_stmicro M5235EVB M5235EVB_Flash32 cobra5272 eb_cpu5282 eb_cpu5282_internal TASREG M5208EVBE M5249EVB M5253DEMO M5272C3 M5275EVB M5282EVB astro_mcf5373l M53017EVB M5329AFEE M5329BFEE M5373EVB M54418TWR M54418TWR_nand_mii M54418TWR_nand_rmii M54418TWR_nand_rmii_lowfreq M54418TWR_serial_mii M54418TWR_serial_rmii M54451EVB M54451EVB_stmicro M54455EVB M54455EVB_a66 M54455EVB_i66 M54455EVB_intel M54455EVB_stm33 M5475AFE M5475BFE M5475CFE M5475DFE M5475EFE M5475FFE M5475GFE M5485AFE M5485BFE M5485CFE M5485DFE M5485EFE M5485FFE M5485GFE M5485HFE M5253EVBE ) -- But it gives several warnings, more or less the same for each board, i attach them in case of any use: Building M54455EVB_stm33 board... textdata bss dec hex filename 174005 13744 221236 408985 63d99 ./u-boot tools/kwbimage.c: In function ‘kwbimage_set_header’: tools/kwbimage.c:803:8: warning: ‘headersz’ may be used uninitialized in this function [-Wmaybe-uninitialized] memcpy(ptr, image, headersz); ^ common/cli_simple.c: In function 'cli_simple_process_macros': common/cli_simple.c:73:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat] common/cli_simple.c:162:2: warning: format '%zd' expects argument of type 'signed size_t', but argument 2 has type '__kernel_size_t' [-Wformat] drivers/mtd/spi/sf.c: In function 'spi_flash_read_write': drivers/mtd/spi/sf.c:30:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] drivers/mtd/spi/sf.c:36:4: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] drivers/mtd/spi/sf_ops.c: In function 'spi_flash_cmd_write_ops': drivers/mtd/spi/sf_ops.c:324:3: warning: format '%zu' expects argument of type 'size_t', but argument 7 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'spi_flash_update_block': common/cmd_sf.c:166:2: warning: format '%zx' expects argument of type 'size_t', but argument 4 has type 'unsigned int' [-Wformat] common/cmd_sf.c:173:3: warning: format '%zx' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'spi_flash_update': common/cmd_sf.c:248:9: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_sf.c:248:9: warning: format '%zu' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'do_spi_flash_read_write': common/cmd_sf.c:303:10: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_sf.c: In function 'do_spi_flash_erase': common/cmd_sf.c:338:9: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_nvedit.c: In function 'do_env_export': common/cmd_nvedit.c:914:3: warning: format '%zX' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] common/cmd_nvedit.c: In function 'do_env_import': common/cmd_nvedit.c:1047:3: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] common/cmd_nvedit.c:1047:3: warning: format '%zX' expects argument of type 'size_t', but argument 3 has type 'unsigned int' [-Wformat] lib/hashtable.c: In function 'hexport_r': lib/hashtable.c:605:2: warning: format '%zu' expects argument of type 'size_t', but argument 5 has type 'unsigned int' [-Wformat] lib/hashtable.c:661:5: warning: format '%zu' expects argument of type 'size_t', but argument 2 has type 'unsigned int' [-Wformat] lib/hashtable.c:661:5: warning:
Re: [U-Boot] [PATCH 00/18] Support for eMMC partitioning and related fixes
Diego Santa Cruz diego.santac...@spinetix.com wrote on 2014/11/28 12:12:56: Hi, -Original Message- From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se] Sent: Friday, November 28, 2014 11:05 AM To: Diego Santa Cruz Cc: pa...@antoniou-consulting.com; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 00/18] Support for eMMC partitioning and related fixes I have the need to hardware partition eMMC devices from U-Boot along with setting enhanced and reliable write attributes. This series of patches adds this support to U-Boot via a new mmc API, a few new members of struct mmc and a new mmc sub-command. It also features several fixes to the eMMC hardware partition support. I have tested this with Micron eMMC 4.41 parts and it is working as expected. This is really great, thanks. Good to know it may be useful to other people. I do wonder(I am fairly new to eMMC) about 512B emulation. In mmc utils there is a: mmc disable 512B emulation device Set the eMMC data sector size to 4KB by disabling emulation on device. I am hoping 4K size will increase performance and reliability? Could you add this feature too to your patch set? I think this was introduced in eMMC 4.51. I do not have any 4.51 devices at hand to test with but I am not sure there would be any performance benefit to issue reads and writes in the 4KB large sector size. All eMMC devices I've seen write in chunks much larger than 4 KB internally anyhow (the ones I'm using now have a superpage size of 32 KB). Writes should be aligned to the superpage size to get good performance. Sorry for the delay, I guess this option is there for a reason and performance/reliability is the only thing that comes to mind. I guess Linux is happier with 4K sector sizes? Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 09/12] lcd: introduce getters for bg/fg color
Hi Simon,
On 11/30/2014 09:27 PM, Simon Glass wrote:
Hi Nikita,
On 30 November 2014 at 05:29, Nikita Kiryanov nik...@compulab.co.il wrote:
Introduce lcd_getbgcolor() and lcd_getfgcolor(), and use them where
applicable.
This is a preparatory step for extracting lcd console code into its own
file.
Signed-off-by: Nikita Kiryanov nik...@compulab.co.il
c: Anatolij Gustschin ag...@denx.de
Cc: Simon Glass s...@chromium.org
---
Changes in V2:
- New patch.
common/lcd.c | 20 +++-
include/lcd.h | 14 ++
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index f98aaaf..a75c616 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -186,7 +186,7 @@ static void console_scrollup(void)
/* Clear the last rows */
#if (LCD_BPP != LCD_COLOR32)
memset(lcd_console_address + CONSOLE_SIZE - CONSOLE_ROW_SIZE * rows,
- lcd_color_bg,
+ lcd_getbgcolor(),
CONSOLE_ROW_SIZE * rows);
#else
u32 *ppix = lcd_console_address +
@@ -195,7 +195,7 @@ static void console_scrollup(void)
for (i = 0;
i (CONSOLE_ROW_SIZE * rows) / NBYTES(panel_info.vl_bpix);
i++) {
- *ppix++ = lcd_color_bg;
+ *ppix++ = lcd_getbgcolor();
}
#endif
lcd_sync();
@@ -342,7 +342,7 @@ static void lcd_drawchars(ushort x, ushort y, uchar *str,
int count)
for (c = 0; c 8; ++c) {
*d++ = (bits 0x80) ?
- lcd_color_fg : lcd_color_bg;
+ lcd_getfgcolor() : lcd_getbgcolor();
Won't this slow things down slightly?
I suppose.. Although, perhaps the compiler is smart enough to optimize
this?
Should you cache the values at the top?
I don't know if it's necessary, but I don't mind doing that.
bits = 1;
}
}
@@ -460,7 +460,7 @@ void lcd_clear(void)
/* set framebuffer to background color */
#if (LCD_BPP != LCD_COLOR32)
memset((char *)lcd_base,
- lcd_color_bg,
+ lcd_getbgcolor(),
lcd_line_length * panel_info.vl_row);
#else
u32 *ppix = lcd_base;
@@ -468,7 +468,7 @@ void lcd_clear(void)
for (i = 0;
i (lcd_line_length *
panel_info.vl_row)/NBYTES(panel_info.vl_bpix);
i++) {
- *ppix++ = lcd_color_bg;
+ *ppix++ = lcd_getbgcolor();
}
#endif
#endif
@@ -575,6 +575,11 @@ static void lcd_setfgcolor(int color)
lcd_color_fg = color;
}
+int lcd_getfgcolor(void)
+{
+ return lcd_color_fg;
+}
+
/*--*/
static void lcd_setbgcolor(int color)
@@ -582,6 +587,11 @@ static void lcd_setbgcolor(int color)
lcd_color_bg = color;
}
+int lcd_getbgcolor(void)
+{
+ return lcd_color_bg;
+}
+
//
/* ** Chipset depending Bitmap / Logo stuff... */
//
diff --git a/include/lcd.h b/include/lcd.h
index 01609ac..2235b9b 100644
--- a/include/lcd.h
+++ b/include/lcd.h
@@ -291,6 +291,20 @@ int lcd_get_screen_rows(void);
int lcd_get_screen_columns(void);
/**
+ * Get the background color of the LCD
+ *
+ * @return background color value
This is just the raw value of the pixel in the display I think.
I'll rephrase it to include a reference to the pixels.
+ */
+int lcd_getbgcolor(void);
+
+/**
+ * Get the foreground color of the LCD
+ *
+ * @return foreground color value
+ */
+int lcd_getfgcolor(void);
+
+/**
* Set the position of the text cursor
*
* @param col Column to place cursor (0 = left side)
--
1.9.1
Regards,
Simon
--
Regards,
Nikita Kiryanov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 06/12] lcd: replace CONSOLE_(ROWS|COLS) with variables
Hi Simon, On 11/30/2014 09:25 PM, Simon Glass wrote: On 30 November 2014 at 05:29, Nikita Kiryanov nik...@compulab.co.il wrote: Replace CONSOLE_(ROWS|COLS) macros with variables, and assign the original macro values. This is a preparatory step for extracting lcd console code into its own file. Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Cc: Anatolij Gustschin ag...@denx.de Cc: Simon Glass s...@chromium.org --- Changes in V2: - New patch. Are you intended to want to support multiple displays, or just to change the resolution after start? This did cross my mind as possible future work, but for this patch set the change was driven by the goal of decoupling lcd_console stuff as much as possible from the rest of the code, which meant that I did not want to bring panel_info references into lcd_console.c (there's actually one use of panel_info still remaining in console_scrollup() but I'll get rid of it if/when this series is applied). In the case of console_cols and console_rows, the idea was that the use of panel_info can be avoided if lcd.c would pass the values as parameters to lcd_init_console() (introduced in a later patch), which meant that the macros had to be replaced with variables. Acked-by: Simon Glass s...@chromium.org Tested on pit, LCD works fine. Tested-by: Simon Glass s...@chromium.org This mail did not reach mainline, so I'm Cc-ing the mailing list. I don't know if patchworks will register the Ack and Tested-by though, can you maybe resend them in a separate reply? -- Regards, Nikita Kiryanov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-x86.git
On Wed, Nov 26, 2014 at 09:28:50AM -0700, Simon Glass wrote: Hi Tom, This is the last of the bare x86 support for this release. I also brought in some interrupt fixes from Bin. The following changes since commit 2a82ec77d27ef5f860a107c4b764643a655dceeb: Prepare v2015.01-rc2 (2014-11-24 17:08:47 -0500) are available in the git repository at: git://git.denx.de/u-boot-x86.git for you to fetch changes up to 908ec6e4d1d12f746cb9b7cc73430a268ceb2c92: tools: Add ifdtool to .gitignore (2014-11-25 07:11:17 -0700) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-fdt.git (take 2)
On Mon, Dec 01, 2014 at 08:26:37AM -0700, Simon Glass wrote: Hi Tom, I just pulled this down from patchwork again, adding two more Tested-by: credits. The following changes since commit 85bafb6da4dddfffa78479aa49a72ae48578a4ce: Merge branch 'master' of git://git.denx.de/u-boot-fsl-qoriq (2014-11-26 11:23:26 -0500) are available in the git repository at: git://git.denx.de/u-boot-fdt.git for you to fetch changes up to ffccb84c1a8e276fa7263ec4ca8186f06312305c: fdt: Fix regression in fdt_pack_reg() (2014-12-01 08:23:32 -0700) Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] powerpc/bsc913x: Convert to use generic board code
Signed-off-by: Harninder Rai harninder@freescale.com --- include/configs/BSC9131RDB.h |3 +++ include/configs/BSC9132QDS.h |3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/include/configs/BSC9131RDB.h b/include/configs/BSC9131RDB.h index adb8146..eeb0671 100644 --- a/include/configs/BSC9131RDB.h +++ b/include/configs/BSC9131RDB.h @@ -11,6 +11,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO + #ifdef CONFIG_BSC9131RDB #define CONFIG_BSC9131 #define CONFIG_NAND_FSL_IFC diff --git a/include/configs/BSC9132QDS.h b/include/configs/BSC9132QDS.h index 2722a32..e8a8d29 100644 --- a/include/configs/BSC9132QDS.h +++ b/include/configs/BSC9132QDS.h @@ -11,6 +11,9 @@ #ifndef __CONFIG_H #define __CONFIG_H +#define CONFIG_SYS_GENERIC_BOARD +#define CONFIG_DISPLAY_BOARDINFO + #ifdef CONFIG_BSC9132QDS #define CONFIG_BSC9132 #endif -- 1.7.6.GIT ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mtd: nand: mxs: Add support for multiple NAND chips
This patch adds support for multiple NAND chips connected to the
i.MX6. Linux already supports this configuration. So lets port
the missing features to the U-Boot driver to support more than
one NAND chip here as well.
The necessary changes in detail are:
- Only use DMA channel 0 for all NAND chips:
Linux: a7c12d01 (mtd: gpmi: use DMA channel 0 for all the
nand chips)
d159d8b7 (mtd: gpmi: decouple the chip select from
the DMA channel)
- On i.MX6 only use ready/busy pin for CS0:
Linux: 7caa4fd2 (mtd: gpmi: imx6: fix the wrong method for
checking ready/busy)
To enable this feature the board needs to configure
CONFIG_SYS_NAND_MAX_CHIPS to 2 (or more).
With these changes I'm able to detect and acces 2 NAND chips:
= nand device
Device 0: 2x nand0, sector size 128 KiB
Page size 2048 b
OOB size 64 b
Erase size 131072 b
Please note that this is also needed to support a NAND chip with
multiple chips embedded in one die, e.g. Micron MT29F32G08QAA.
Tested on a i.MX6DL based board with 2 Micron MT29F4G08AB
chips.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Marek Vasut ma...@denx.de
Cc: Stefano Babic sba...@denx.de
Cc: Fabio Estevam fabio.este...@freescale.com
Cc: Scott Wood scottw...@freescale.com
---
drivers/mtd/nand/mxs_nand.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index 7a064ab..5013246 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -263,7 +263,7 @@ static void mxs_nand_cmd_ctrl(struct mtd_info *mtd, int
data, unsigned int ctrl)
struct nand_chip *nand = mtd-priv;
struct mxs_nand_info *nand_info = nand-priv;
struct mxs_dma_desc *d;
- uint32_t channel = MXS_DMA_CHANNEL_AHB_APBH_GPMI0 + nand_info-cur_chip;
+ uint32_t channel = MXS_DMA_CHANNEL_AHB_APBH_GPMI0;
int ret;
/*
@@ -340,13 +340,17 @@ static void mxs_nand_cmd_ctrl(struct mtd_info *mtd, int
data, unsigned int ctrl)
static int mxs_nand_device_ready(struct mtd_info *mtd)
{
struct nand_chip *chip = mtd-priv;
- struct mxs_nand_info *nand_info = chip-priv;
+ __maybe_unused struct mxs_nand_info *nand_info = chip-priv;
struct mxs_gpmi_regs *gpmi_regs =
(struct mxs_gpmi_regs *)MXS_GPMI_BASE;
uint32_t tmp;
tmp = readl(gpmi_regs-hw_gpmi_stat);
+#if defined(CONFIG_MX6)
+ tmp = (GPMI_STAT_READY_BUSY_OFFSET + 0);
+#else
tmp = (GPMI_STAT_READY_BUSY_OFFSET + nand_info-cur_chip);
+#endif
return tmp 1;
}
@@ -409,7 +413,7 @@ static void mxs_nand_read_buf(struct mtd_info *mtd, uint8_t
*buf, int length)
struct nand_chip *nand = mtd-priv;
struct mxs_nand_info *nand_info = nand-priv;
struct mxs_dma_desc *d;
- uint32_t channel = MXS_DMA_CHANNEL_AHB_APBH_GPMI0 + nand_info-cur_chip;
+ uint32_t channel = MXS_DMA_CHANNEL_AHB_APBH_GPMI0;
int ret;
if (length NAND_MAX_PAGESIZE) {
@@ -490,7 +494,7 @@ static void mxs_nand_write_buf(struct mtd_info *mtd, const
uint8_t *buf,
struct nand_chip *nand = mtd-priv;
struct mxs_nand_info *nand_info = nand-priv;
struct mxs_dma_desc *d;
- uint32_t channel = MXS_DMA_CHANNEL_AHB_APBH_GPMI0 + nand_info-cur_chip;
+ uint32_t channel = MXS_DMA_CHANNEL_AHB_APBH_GPMI0;
int ret;
if (length NAND_MAX_PAGESIZE) {
@@ -554,7 +558,7 @@ static int mxs_nand_ecc_read_page(struct mtd_info *mtd,
struct nand_chip *nand,
{
struct mxs_nand_info *nand_info = nand-priv;
struct mxs_dma_desc *d;
- uint32_t channel = MXS_DMA_CHANNEL_AHB_APBH_GPMI0 + nand_info-cur_chip;
+ uint32_t channel = MXS_DMA_CHANNEL_AHB_APBH_GPMI0;
uint32_t corrected = 0, failed = 0;
uint8_t *status;
int i, ret;
@@ -701,7 +705,7 @@ static int mxs_nand_ecc_write_page(struct mtd_info *mtd,
{
struct mxs_nand_info *nand_info = nand-priv;
struct mxs_dma_desc *d;
- uint32_t channel = MXS_DMA_CHANNEL_AHB_APBH_GPMI0 + nand_info-cur_chip;
+ uint32_t channel = MXS_DMA_CHANNEL_AHB_APBH_GPMI0;
int ret;
memcpy(nand_info-data_buf, buf, mtd-writesize);
@@ -1068,7 +1072,7 @@ int mxs_nand_init(struct mxs_nand_info *info)
(struct mxs_gpmi_regs *)MXS_GPMI_BASE;
struct mxs_bch_regs *bch_regs =
(struct mxs_bch_regs *)MXS_BCH_BASE;
- int i = 0, j;
+ int i = 0;
info-desc = malloc(sizeof(struct mxs_dma_desc *) *
MXS_NAND_DMA_DESCRIPTOR_COUNT);
@@ -1083,11 +1087,8 @@ int mxs_nand_init(struct mxs_nand_info *info)
}
/* Init the DMA controller. */
- for (j = MXS_DMA_CHANNEL_AHB_APBH_GPMI0;
- j = MXS_DMA_CHANNEL_AHB_APBH_GPMI7; j++) {
- if (mxs_dma_init_channel(j))
- goto
Re: [U-Boot] Incomplete type declarations in arch/Kconfig (U-Boot-2014.10)
Hi Masahiro, thank you for this very quick answer. Thanks a lot for clarifying the grammar point too. If I got it correctly, the syntax is valid and meant to be used for non-user-controlled items, which seems to make a lot of sense now :). Actually the only item I would really need to override in is SYS_CONFIG_NAME, in order to have the custom board.h being processed instead of the default one. (I have no intention in fiddling with SYS_ARCH or others.) But I understand that this kind of extension model doesn't fall in the standard U-Boot usage, so I guess I'll then stick to the updated board.h technique... Thanks again! GMal -Message d'origine- De : Masahiro Yamada [mailto:yamad...@jp.panasonic.com] Envoyé : 2 décembre 2014 04:01 Hi Guilhem, On Tue, 2 Dec 2014 07:03:24 + Guilhem Malichier g...@eco-counter.com wrote: Hi, I'm quite new to U-Boot as well as to the whole Kconfig system, so this may be a dumb question, in which case please forgive my ignorance. I noticed that the type declarations of several items in the file arch/Kconfig are actually incomplete, lacking the prompt parameter: Not incomplete. It is grammatically correct and used very often. config SYS_ARCH string help (...) config SYS_CPU string help (...) etc. (same for SYS_SOC, SYS_VENDOR, SYS_BOARD and SYS_CONFIG_NAME) If I'm not mistaken, the string type declaration in Kconfig is supposed to look like either of the following: string something or string prompt something in case the option is supposed to be configured by users. In this case, again if I'm not mistaken, these incomplete declarations seem to prevent the items from being created at this step, thus preventing any possibility of overriding the default values directly in a _defconfig file. So my question is: is this intentional (in which case I would probably recommend using comments for that purpose instead of incomplete declarations)? Or is this a bug (in which case I would be happy to submit a fix simply adding the prompt strings)? It is intentional. SYS_ARCH, SYS_CPU, ... should not directly touched. They should always be set to a combination of correct values. For example, if you choose CONFIG_ARM in the architecture select menu, SYS_ARCH is automatically set to arm. Here is a bit of context if need be: I'm trying to find a way to compile a variant of U-Boot for an existing board (basically just overriding a few lines in board.h), but I would like to do it without _modifying_ any file in the U-Boot distribution, nor fiddling with .config, but rather by only adding files (namely configs/myvariant_defconfig, and configs/board-myvariant.h), so that there will be nothing to merge to support later U-Boot versions. Having your own configs/*_defconfig is easy, just add it, but I have no idea how to add your own include/configs/*.h without modifying any file. I've been struggling with this today, assuming that overriding CONFIG_SYS_CONFIG_NAME in my _defconfig would be enough (as it is for CONFIG_SYS_EXTRA_OPTIONS)... but I couldn't get it to work, as only the default value got from arch/arch/board/Kconfig was used, and I couldn't find any way to add my configuration without actually modifying something in U-Boot's core (either some Kconfig files, or the original board.h) or manually editing the generated .config. This was until I noticed that type declaration problem. As soon as I added the prompt parameters, I was able to successfully build a .config with the desired CONFIG_SYS values, and then compile everything as expected. Hence the aforementioned question... We(I) have not taken such a usage into account. Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bare x86 support is merged to u-boot-x86
Hi Bin, 2014-12-02 5:38 GMT+01:00 Bin Meng bmeng...@gmail.com: Hi Bruce, On Tue, Dec 2, 2014 at 4:28 AM, bruce_leon...@selinc.com wrote: Simon, From: Simon Glass s...@chromium.org To: bruce_leon...@selinc.com Cc: tr...@ti.com tr...@ti.com, U-Boot Mailing List u- b...@lists.denx.de, u-boot-boun...@lists.denx.de, Bin Meng bmeng...@gmail.com Date: 12/01/2014 12:14 PM Subject: Re: [U-Boot] Bare x86 support is merged to u-boot-x86 Sent by: s...@google.com +Bin Hi Bruce, On 1 December 2014 at 12:33, bruce_leon...@selinc.com wrote: Hi Simon and Bin, u-boot-boun...@lists.denx.de wrote on 11/25/2014 01:51:06 PM: From: Simon Glass s...@chromium.org To: U-Boot Mailing List u-boot@lists.denx.de Cc: tr...@ti.com tr...@ti.com Date: 11/25/2014 01:52 PM Subject: [U-Boot] Bare x86 support is merged to u-boot-x86 Sent by: u-boot-boun...@lists.denx.de Hi Bin (and others interested in U-Boot on x86), I've applied the remaining x86 patches to u-boot-x86. It runs on chromebook_link (Pixel) with support for most hardware relevant to a boot loader: SDRAM, SPI, PCI, USB (and USB Ethernet), SATA (internal 32GB SSD), SD card, LCD, UART, keyboard, EC. Bin this should be a good base for you to send patches for your Atom platform and I have no major work pending now so should not get in your way. Instructions on how to build and run are here: http://www.denx.de/wiki/U-Boot/X86 For this platform 4 binary blobs are needed. This is an unavoidable feature of the platform at present. The blobs cover flash descriptor, SDRAM init, video init and Management Engine. Instructions on how to get these are on the same page. Here is a list of some missing features: - README.x86 in the source (mostly the content from the Wiki page would be a good start) - MTRR support (for performance) - Audio - Chrome OS verified boot (only a rough rebase has been done, I'm not sure how to track mainline anyway) - SMI and ACPI support, to provide platform info and facilities to Linux This is awesome! Thanks so much for the work you two have done on this. We've been using u-boot on our PPC platforms for years and love it. We're considering moving to an Atom processor and wanted to continue to use u-boot, but were worried about getting it up and running with the FSL from Intel so we haven't made the jump yet. This is going to be a hugeleg up in my argument for actually getting that project off the ground. If we do, I'll be sure to be pushing out any work we do that isn't in the mainline. Thanks again guys! Sounds good! What Atom are you using? It might be the same one as Bin. Not sure yet. We had originally settled on the first one Intel put out, but since we've waited so long and we're not locked in by design yet, we'll probably pick a newer generation. Our products tend to be in service for a long time (upwards of 20 years) so we like to get as cutting edge as we can without losing a finger :) I am currently working on patches to support Intel Atom E6xx with Platform Controller Hub EG20T. This Atom platform aims at the embedded market. More newer Atom would be Bay Trail, which is an SoC and I believe Simon is going to support that platform once he gets a board. The latest Atom would be Braswell. If Intel keeps open for the chipset datasheet, I think we can try to support that too. We will see. That sound really interesting! My company is also using Intel Atom E6xx based designs and I would love to see u-boot/coreboot running on them. What is the current state of your work? -- Christian Gmeiner, MSc https://soundcloud.com/christian-gmeiner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v10 1/4] config: exynos5420: move non common configs to specific board files
On 2 December 2014 at 00:07, Hyungwon Hwang human.hw...@samsung.com wrote: The media for boot and environment is a board-specific feature, not a processor-specific. This is same to console port number and some other addresses. This patch moves the that kinds of configs to each board-specific files from the common config file for Exynos5420. Signed-off-by: Hyungwon Hwang human.hw...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Simon Glass s...@chromium.org --- Changes for v10: - Newly added Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v10 3/4] Odroid-XU3: Add documentation for Odroid-XU3
Hi, On 2 December 2014 at 00:07, Hyungwon Hwang human.hw...@samsung.com wrote: This patch adds documentation for Odroid-XU3. This documentation is based on that of Odroid (doc/README-odroid) made by Przemyslaw Marczak. The documentation includes basic information about boot media layout, environment, partition layout, and the instruction to burn the u-boot image to boot media. Signed-off-by: Hyungwon Hwang human.hw...@samsung.com Cc: Minkyu Kang mk7.k...@samsung.com Cc: Lukasz Majewski l.majew...@samsung.com Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk Cc: Javier Martinez Canillas jav...@dowhile0.org Cc: Simon Glass s...@chromium.org --- Changes for v6: - Newly added Changes for v7: - Fix several errata in the documentation Changes for v8: - None Changes for v9: - Add the new contents to the documentation of Odroid X2/U2, instead of making new document for Odorid XU3 Acked-by: Simon Glass s...@chromium.org Should you mention that networking is not available? Probably not that important. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v10 4/4] Odroid-XU3: Add entry for DTS EHCI GPIO
Hi,
On 2 December 2014 at 00:07, Hyungwon Hwang human.hw...@samsung.com wrote:
From: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Add samsung,vbus-gpio information for the XU3. This allows the usage of
the EHCI controller on the XU3, which is connected to the SMSC LAN9514
chip (usb hub + network).
Note that this patch doesn't enable support for USB/USB networking in
the default config as makes the u-boot binary too big for the current odroid
setup.
Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Signed-off-by: Hyungwon Hwang human.hw...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Cc: Javier Martinez Canillas jav...@dowhile0.org
Cc: Simon Glass s...@chromium.org
---
Changes for v10:
- Newly added
arch/arm/dts/exynos5422-odroidxu3.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts
b/arch/arm/dts/exynos5422-odroidxu3.dts
index cff32a9..be20f1b 100644
--- a/arch/arm/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -31,6 +31,10 @@
0xb000 0xea0;
};
+ ehci@1211 {
+ samsung,vbus-gpio = gpio 0x316 0; /* X26 */
Are you sure this is right? By my count this should be 0x66, not
0x316. This might be historical.
It almost feels like you could drop this patch until you actually have
working USB support.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v10 2/4] Odroid-XU3: Add support for Odroid-XU3
On 2 December 2014 at 00:07, Hyungwon Hwang human.hw...@samsung.com wrote:
This patch adds support for Odroid-XU3.
Signed-off-by: Hyungwon Hwang human.hw...@samsung.com
Cc: Minkyu Kang mk7.k...@samsung.com
Cc: Lukasz Majewski l.majew...@samsung.com
Cc: Sjoerd Simons sjoerd.sim...@collabora.co.uk
Cc: Javier Martinez Canillas jav...@dowhile0.org
Cc: Simon Glass s...@chromium.org
---
Changes for v3:
- Remove unnecessary node from DT file
- Remove unnecessary features from config file
- Remove unnecessary macros from board-specific header file
- Fix some trivial typos in comments
Changes for v4:
- Add MMC FIFO buffer's configuration to DT file
- Make CONFIG_OF_CONTROL be set by the target information
- Add basic document to doc/README.odroid-xu3
- Add CONFIG_CMD_EXT4 to config file
- Add environment size and offset to config file
- Add extra default environment to make bootable without modification
- Remove unnecessary features from config file
Changes for v5:
- Convert /include/ to #include in DT file
Changes for v6:
- Separate out the documentation to new commit
- Remove unnecessary header file inclusions from the board-specific setup file
- Make the function board_clock_init be declared, only when
CONFIG_BOARD_EARLY_INIT_F is defined
Changes for v7:
- Remove OF_CONTROL dependency from !SPL_BUILD
Changes for v8:
- Remove unnecessary properties in DT mmc node
Changes for v9:
- Remove useless variables in the default environment
- Replace the detailed information to the reference to the documentation
Changes for v10:
- Remove the config unsets which are added to make the result image small
This is needless now, because the image is not small enough even though
these
unsets are added.
- Remove redundant DT node and properties
- Remove the odroid-xu3 board file and make odroid-xu3 a variant of smdk5420
Acked-by: Simon Glass s...@chromium.org
arch/arm/cpu/armv7/exynos/Kconfig | 4 +++
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/exynos5422-odroidxu3.dts | 45 +
board/samsung/smdk5420/Kconfig| 13 +
configs/odroid-xu3_defconfig | 4 +++
include/configs/odroid_xu3.h | 54
+++
6 files changed, 122 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/exynos5422-odroidxu3.dts
create mode 100644 configs/odroid-xu3_defconfig
create mode 100644 include/configs/odroid_xu3.h
diff --git a/arch/arm/cpu/armv7/exynos/Kconfig
b/arch/arm/cpu/armv7/exynos/Kconfig
index f3eadb4..7fcb5d2 100644
--- a/arch/arm/cpu/armv7/exynos/Kconfig
+++ b/arch/arm/cpu/armv7/exynos/Kconfig
@@ -24,6 +24,10 @@ config TARGET_TRATS2
config TARGET_ODROID
bool Exynos4412 Odroid board
+config TARGET_ODROID_XU3
+ bool Exynos5422 Odroid board
+ select OF_CONTROL
+
config TARGET_ARNDALE
bool Exynos5250 Arndale board
select CPU_V7_HAS_NONSEC
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e5846ea..a811b1b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -13,7 +13,8 @@ dtb-$(CONFIG_EXYNOS5) += exynos5250-arndale.dtb \
exynos5250-smdk5250.dtb \
exynos5420-smdk5420.dtb \
exynos5420-peach-pit.dtb \
- exynos5800-peach-pi.dtb
+ exynos5800-peach-pi.dtb \
+ exynos5422-odroidxu3.dtb
dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
tegra20-medcom-wide.dtb \
tegra20-paz00.dtb \
diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts
b/arch/arm/dts/exynos5422-odroidxu3.dts
new file mode 100644
index 000..cff32a9
--- /dev/null
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -0,0 +1,45 @@
+/*
+ * Odroid XU3 device tree source
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+#include exynos54xx.dtsi
+
+/ {
+ model = Odroid XU3 based on EXYNOS5422;
+ compatible = samsung,odroidxu3, samsung,exynos5;
+
+ aliases {
+ serial0 = /serial@12C0;
+ console = /serial@12C2;
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x4000 0x1000
+ 0x5000 0x1000
+ 0x6000 0x1000
+ 0x7000 0x1000
+ 0x8000 0x1000
+ 0x9000 0x1000
+ 0xa000 0x1000
+ 0xb000 0xea0;
+ };
+
+ serial@12C2 {
+ status=okay;
+ };
+
+ mmc@1220 {
+ fifoth_val = 0x201f0020;
+ };
+
+ mmc@1222 {
+ fifoth_val = 0x201f0020;
+ };
+};
diff --git a/board/samsung/smdk5420/Kconfig b/board/samsung/smdk5420/Kconfig
index
Re: [U-Boot] [PATCH V2 06/12] lcd: replace CONSOLE_(ROWS|COLS) with variables
On 30 November 2014 at 05:29, Nikita Kiryanov nik...@compulab.co.il wrote: Replace CONSOLE_(ROWS|COLS) macros with variables, and assign the original macro values. This is a preparatory step for extracting lcd console code into its own file. Signed-off-by: Nikita Kiryanov nik...@compulab.co.il Cc: Anatolij Gustschin ag...@denx.de Cc: Simon Glass s...@chromium.org Acked-by: Simon Glass s...@chromium.org Tested on pit, LCD works fine. Tested-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/10] dm: i2c: Add a uclass for I2C
Hi, On 1 December 2014 at 23:29, Heiko Schocher h...@denx.de wrote: Hello Simon, Am 02.12.2014 05:31, schrieb Simon Glass: +Heiko - are you OK with the new msg-based approach? Yes, you can add my acked-by to the hole series. OK good, I'm going to continue on this line, and work through Masahiro's comments (and add a few more tests) over the next few days. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [Driver Model] post_bind() and pre_unbind() handler
Hi Masahiro, On 1 December 2014 at 22:31, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Simon, I have a question about handlers of struct uclass_driver. When binding a device, uc-uc_drv-post_bind() is called *before* drv-bind(), so the name pre_bind() is more suitable than post_bind(), isn't it? The uclass post_bind() is called after the device is bound to the uclass. The device's bind() call is made last, so that it can do any last-minute adjustments, and can rely on any uclass setup having occurred. The 'bind' step does not rely on calling the device's bind(). In fact the bind has already happened. This is just offering the device an opportunity to do a little after-processing. Likewise, when unbinding a device, uc-uc_drv-pre_unbind() is called *after* drv-unbind() so the name post_unbind() is more suitable than pre_unbind(). Similar to the above. I think pre_ and post_ is opposite here, and it looks confusing to me. Am I misunderstanding something? Do you have a need to change the ordering? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building fw_env tools seems broken
Ping on this one. I tried few different defconfigs - the results are mixed, where sandbox and some other machines do work, but some are broken as below. Tried different toolchains as well - gcc-4.7 and 4.9. Any pointers or any help in resolving this issue would be greatly appreciated! Thanks. On Mon, Nov 24, 2014 at 04:19:17PM -0500, Denys Dmytriyenko wrote: Hi, I came across this issue recently, that affects 2014.10 as well as master, but used to work fine in 2014.07 and older. Please let me know if I'm missing something or you need additional info. Thanks! $ make CROSS_COMPILE=arm-linux-gnueabihf- am335x_evm_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # # # configuration written to spl/.config # $ make CROSS_COMPILE=arm-linux-gnueabihf- env scripts/kconfig/conf --silentoldconfig Kconfig scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config.h GEN include/autoconf.mk GEN include/autoconf.mk.dep GEN spl/include/autoconf.mk HOSTCC tools/env/fw_env.o In file included from tools/env/fw_env.c:117:0: include/env_default.h:110:11: error: expected ‘}’ before ‘CONFIG_SYS_ARCH’ scripts/Makefile.host:108: recipe for target 'tools/env/fw_env.o' failed make[1]: *** [tools/env/fw_env.o] Error 1 Makefile:1208: recipe for target 'env' failed make: *** [env] Error 2 -- Denys ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch v3] driver/ddr/fsl: Fix MRC_CYC calculation for DDR3
For DDR controller version 4.7 or newer, MRC_CYC (mode register set
cycle time) is max(tMRD, tMOD). tMRD is 4nCK, or 8nCK (RDIMM). tMOD
is max(12nCK, 15ns) according to JEDEC spec.
DDR4 is not affected by this change.
Signed-off-by: York Sun york...@freescale.com
---
Change log
v3: Add cast for using max()
v2: Apply the change only to DDR controller newer than v4.7
Older DDRC needs to take into account of RDIMM for tMRD
drivers/ddr/fsl/ctrl_regs.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/ddr/fsl/ctrl_regs.c b/drivers/ddr/fsl/ctrl_regs.c
index fe8aa98..03d7ff1 100644
--- a/drivers/ddr/fsl/ctrl_regs.c
+++ b/drivers/ddr/fsl/ctrl_regs.c
@@ -324,6 +324,7 @@ static void set_timing_cfg_0(fsl_ddr_cfg_regs_t *ddr,
#elif defined(CONFIG_SYS_FSL_DDR3)
unsigned int data_rate = get_ddr_freq(0);
int txp;
+ unsigned int ip_rev;
int odt_overlap;
/*
* (tXARD and tXARDS). Empirical?
@@ -336,7 +337,25 @@ static void set_timing_cfg_0(fsl_ddr_cfg_regs_t *ddr,
*/
txp = max((int)mclk_ps * 3, (mclk_ps 1540 ? 7500 : 6000));
- tmrd_mclk = 4;
+ ip_rev = fsl_ddr_get_version();
+ if (ip_rev = 0x40700) {
+ /*
+* MRS_CYC = max(tMRD, tMOD)
+* tMRD = 4nCK (8nCK for RDIMM)
+* tMOD = max(12nCK, 15ns)
+*/
+ tmrd_mclk = max((unsigned int)12, picos_to_mclk(15000));
+ } else {
+ /*
+* MRS_CYC = tMRD
+* tMRD = 4nCK (8nCK for RDIMM)
+*/
+ if (popts-registered_dimm_en)
+ tmrd_mclk = 8;
+ else
+ tmrd_mclk = 4;
+ }
+
/* set the turnaround time */
/*
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch v3] powerpc/mpc85xx: Fix DDR TLB mapping leftover
Commit f29f804a93e87c17670607641d120f431a3b0633 generalized the TLB
mapping function, but made the DDR mapping leftover size to zero,
causing the message not printed.
Signed-off-by: York Sun york...@freescale.com
CC: Alexander Graf ag...@suse.de
CC: Scott Wood scottw...@freescale.com
---
Change log
v3: Add checking for memsize CONFIG_MAX_MEM_MAPPED for print_size
v2: Fix unnecessary parentheses
arch/powerpc/cpu/mpc85xx/tlb.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/tlb.c b/arch/powerpc/cpu/mpc85xx/tlb.c
index 4adba95..8e0508f 100644
--- a/arch/powerpc/cpu/mpc85xx/tlb.c
+++ b/arch/powerpc/cpu/mpc85xx/tlb.c
@@ -299,12 +299,16 @@ unsigned int setup_ddr_tlbs_phys(phys_addr_t p_addr,
{
unsigned int ram_tlb_address = (unsigned int)CONFIG_SYS_DDR_SDRAM_BASE;
u64 memsize = (u64)memsize_in_meg 20;
+ u64 size;
- memsize = min(memsize, (u64)CONFIG_MAX_MEM_MAPPED);
- memsize = tlb_map_range(ram_tlb_address, p_addr, memsize, TLB_MAP_RAM);
+ size = min(memsize, (u64)CONFIG_MAX_MEM_MAPPED);
+ size = tlb_map_range(ram_tlb_address, p_addr, size, TLB_MAP_RAM);
- if (memsize)
- print_size(memsize, left unmapped\n);
+ if (size || memsize CONFIG_MAX_MEM_MAPPED) {
+ print_size(memsize CONFIG_MAX_MEM_MAPPED ?
+ memsize - CONFIG_MAX_MEM_MAPPED + size : size,
+ left unmapped\n);
+ }
return memsize_in_meg;
}
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/12] bootm: Tidy up decompression and add tests
(Note: this builds on a single patch left over from a recent series, which is why it is v2. That patch refactored the code but did not add tests.) bootm's decompression functions currently have tests in the 'test_compression' unit test command, but this calls the decompression routines directly and is more aimed at ensuring that they never overwrite their output buffer. But bootm is critical code and it is important that test coverage be adequate for the task it performs. Existing tests in test/image provide some coverage, but not for decompression. This series adds a new unit test specifically for bootm's decompression. It tests that bootm deals correctly with a normal decompress, a case where there is insufficient output buffer space, and a case where part of the data is corrupted. Previously the uncompressed case had no error checking, so this is added. This is a change in behaviour so I hope it will not cause problems. The current error message on failure is confusing, since it is unclear whether the image is too large or the data is corrupt. This is improved and patches added to make sure we can distinguish these two cases for each decompression method in most situations. The existing 'Must RESET board to recover' message is retained, but this is likely to be unnecessary, since all decompressions routines are, I believe, careful not to overwrite their output buffer even in the case of corrupted data. It may be desirable to remove it later. The output of the new sandbox 'ut_image_decomp' command is below: Testing: gzip compressed Uncompressing Kernel Image ... OK Uncompressing Kernel Image ... Error: inflate() returned -5 Image too large: increase CONFIG_SYS_BOOTM_LEN Must RESET board to recover Uncompressing Kernel Image ... Error: inflate() returned -5 Image too large: increase CONFIG_SYS_BOOTM_LEN Must RESET board to recover Testing: bzip2 compressed Uncompressing Kernel Image ... OK Uncompressing Kernel Image ... Image too large: increase CONFIG_SYS_BOOTM_LEN Must RESET board to recover Uncompressing Kernel Image ... bzip2 compressed: uncompress error -4 Must RESET board to recover Testing: lzma compressed Uncompressing Kernel Image ... OK Uncompressing Kernel Image ... Image too large: increase CONFIG_SYS_BOOTM_LEN Must RESET board to recover Uncompressing Kernel Image ... lzma compressed: uncompress error 1 Must RESET board to recover Testing: lzo compressed Uncompressing Kernel Image ... OK Uncompressing Kernel Image ... Image too large: increase CONFIG_SYS_BOOTM_LEN Must RESET board to recover Uncompressing Kernel Image ... lzo compressed: uncompress error -6 Must RESET board to recover Testing: uncompressed Loading Kernel Image ... OK Loading Kernel Image ... Image too large: increase CONFIG_SYS_BOOTM_LEN Must RESET board to recover ut_image_decomp ok Changes in v2: - Add tests to cover the code changes - Correct the overflow check for bzip2 Simon Glass (12): lzma: fix buffer bound check error further bootm: Move compression progress/error messages into a function sandbox: Correct ordering of 'sb save' commands test: Add DEBUG output option to test-fit.py bootm: Export bootm_decomp_image() test: Rename test_compression to ut_compression test: Add unit tests for bootm image decompression bootm: Use print_decomp_msg() in all cases bootm: Factor out common parts of image decompression code bzlib: Update destLen even on error gunzip: Update lenp even on error lzo: Update dst_len even on error common/bootm.c | 150 ++--- common/cmd_sandbox.c | 2 +- include/bootm.h| 17 + lib/bzlib.c| 2 +- lib/gunzip.c | 7 ++- lib/lzma/LzmaTools.c | 4 +- lib/lzo/lzo1x_decompress.c | 4 +- test/compression.c | 93 ++-- test/dm/sf.c | 2 +- test/image/test-fit.py | 16 - 10 files changed, 218 insertions(+), 79 deletions(-) -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 04/12] test: Add DEBUG output option to test-fit.py
Sometimes it is useful to see the output from U-Boot, so add an option to
make this easier.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
test/image/test-fit.py | 10 ++
1 file changed, 10 insertions(+)
diff --git a/test/image/test-fit.py b/test/image/test-fit.py
index 0eb424d..e9e756a 100755
--- a/test/image/test-fit.py
+++ b/test/image/test-fit.py
@@ -20,6 +20,9 @@ import struct
import sys
import tempfile
+# Enable printing of all U-Boot output
+DEBUG = True
+
# The 'command' library in patman is convenient for running commands
base_path = os.path.dirname(sys.argv[0])
patman = os.path.join(base_path, '../../tools/patman')
@@ -103,6 +106,10 @@ sb save hostfs 0 %(ramdisk_addr)x %(ramdisk_out)s
%(ramdisk_size)x
reset
'''
+def debug_stdout(stdout):
+if DEBUG:
+print stdout
+
def make_fname(leaf):
Make a temporary filename
@@ -328,6 +335,7 @@ def run_fit_test(mkimage, u_boot):
# We could perhaps reduce duplication with some loss of readability
set_test('Kernel load')
stdout = command.Output(u_boot, '-d', control_dtb, '-c', cmd)
+debug_stdout(stdout)
if read_file(kernel) != read_file(kernel_out):
fail('Kernel not loaded', stdout)
if read_file(control_dtb) == read_file(fdt_out):
@@ -352,6 +360,7 @@ def run_fit_test(mkimage, u_boot):
params['fdt_load'] = 'load = %#x;' % params['fdt_addr']
fit = make_fit(mkimage, params)
stdout = command.Output(u_boot, '-d', control_dtb, '-c', cmd)
+debug_stdout(stdout)
if read_file(kernel) != read_file(kernel_out):
fail('Kernel not loaded', stdout)
if read_file(control_dtb) != read_file(fdt_out):
@@ -365,6 +374,7 @@ def run_fit_test(mkimage, u_boot):
params['ramdisk_load'] = 'load = %#x;' % params['ramdisk_addr']
fit = make_fit(mkimage, params)
stdout = command.Output(u_boot, '-d', control_dtb, '-c', cmd)
+debug_stdout(stdout)
if read_file(ramdisk) != read_file(ramdisk_out):
fail('Ramdisk not loaded', stdout)
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 02/12] bootm: Move compression progress/error messages into a function
This code is repeated in several places, and does not detect a common
fault where the image is too large. Move it into its own function and
provide a more helpful messages in this case, for compression schemes
which support this.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2:
- Add tests to cover the code changes
- Correct the overflow check for bzip2
common/bootm.c | 71 ++
1 file changed, 47 insertions(+), 24 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index 6b3ea8c..915d537 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -264,7 +264,30 @@ static int bootm_find_other(cmd_tbl_t *cmdtp, int flag,
int argc,
return 0;
}
-#endif /* USE_HOSTCC */
+#endif /* USE_HOSTC */
+
+#if defined(CONFIG_GZIP) || defined(CONFIG_GZIP) || defined(CONFIG_BZIP2) || \
+ defined(CONFIG_LZMA) || defined(CONFIG_LZO)
+static void print_decomp_msg(const char *type_name)
+{
+ printf( Uncompressing %s ... , type_name);
+}
+
+static int handle_decomp_error(const char *algo, size_t size, size_t unc_len,
+ int ret)
+{
+ if (size = unc_len)
+ puts(Image too large: increase CONFIG_SYS_BOOTM_LEN\n);
+ else
+ printf(%s: uncompress or overwrite error %d\n, algo, ret);
+ puts(Must RESET board to recover\n);
+#ifndef USE_HOSTCC
+ bootstage_error(BOOTSTAGE_ID_DECOMP_IMAGE);
+#endif
+
+ return BOOTM_ERR_RESET;
+}
+#endif
/**
* decomp_image() - decompress the operating system
@@ -296,19 +319,25 @@ static int decomp_image(int comp, ulong load, ulong
image_start, int type,
*load_end = load + image_len;
break;
#ifdef CONFIG_GZIP
- case IH_COMP_GZIP:
- printf( Uncompressing %s ... , type_name);
- if (gunzip(load_buf, unc_len, image_buf, image_len) != 0) {
- puts(GUNZIP: uncompress, out-of-mem or overwrite error
- must RESET board to recover\n);
- return BOOTM_ERR_RESET;
+ case IH_COMP_GZIP: {
+ int ret;
+
+ print_decomp_msg(type_name);
+ ret = gunzip(load_buf, unc_len, image_buf, image_len);
+ if (ret != 0) {
+ return handle_decomp_error(GUNZIP, image_len,
+ unc_len, ret);
}
*load_end = load + image_len;
break;
+ }
#endif /* CONFIG_GZIP */
#ifdef CONFIG_BZIP2
- case IH_COMP_BZIP2:
- printf( Uncompressing %s ... , type_name);
+ case IH_COMP_BZIP2: {
+ size_t size = unc_len;
+
+ print_decomp_msg(type_name);
/*
* If we've got less than 4 MB of malloc() space,
* use slower decompression algorithm which requires
@@ -318,30 +347,27 @@ static int decomp_image(int comp, ulong load, ulong
image_start, int type,
image_buf, image_len,
CONFIG_SYS_MALLOC_LEN (4096 * 1024), 0);
if (i != BZ_OK) {
- printf(BUNZIP2: uncompress or overwrite error %d -
must RESET board to recover\n,
- i);
- return BOOTM_ERR_RESET;
+ return handle_decomp_error(BUNZIP2, size, unc_len,
+ i);
}
*load_end = load + unc_len;
break;
+ }
#endif /* CONFIG_BZIP2 */
#ifdef CONFIG_LZMA
case IH_COMP_LZMA: {
SizeT lzma_len = unc_len;
int ret;
- printf( Uncompressing %s ... , type_name);
-
+ print_decomp_msg(type_name);
ret = lzmaBuffToBuffDecompress(load_buf, lzma_len,
image_buf, image_len);
- unc_len = lzma_len;
if (ret != SZ_OK) {
- printf(LZMA: uncompress or overwrite error %d - must
RESET board to recover\n,
- ret);
- bootstage_error(BOOTSTAGE_ID_DECOMP_IMAGE);
- return BOOTM_ERR_RESET;
+ return handle_decomp_error(LZMA, lzma_len, unc_len,
+ ret);
}
+ unc_len = lzma_len;
*load_end = load + unc_len;
break;
}
@@ -351,14 +377,11 @@ static int decomp_image(int comp, ulong load, ulong
image_start, int type,
size_t size = unc_len;
int ret;
- printf( Uncompressing %s ... , type_name);
+ print_decomp_msg(type_name);
ret = lzop_decompress(image_buf, image_len, load_buf, size);
- if (ret != LZO_E_OK) {
- printf(LZO:
[U-Boot] [PATCH v2 01/12] lzma: fix buffer bound check error further
Commit 4d3b8a0d fixed a problem with lzma decompress where it would
run out of bytes to decompress. The algorithm needs to know how many
uncompressed bytes it is expected to produce.
However, the fix introduced a potential buffer overrun, and causes
the compression test to fail (test_compression command in sandbox).
The correct fix seems to be to use the minimum of the expected number
of uncompressed bytes and the amount of output space available. That
way things work normally when there is enough space, and return an
error (without overrunning available space) when there is not.
Signed-off-by: Antonios Vamporakis a...@area128.com
CC: Kees Cook keesc...@chromium.org
CC: Simon Glass s...@chromium.org
CC: Daniel Schwierzeck daniel.schwierz...@gmail.com
CC: Luka Perkov l...@openwrt.org
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
lib/lzma/LzmaTools.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/lzma/LzmaTools.c b/lib/lzma/LzmaTools.c
index cfc7cb0..f88629b 100644
--- a/lib/lzma/LzmaTools.c
+++ b/lib/lzma/LzmaTools.c
@@ -102,7 +102,7 @@ int lzmaBuffToBuffDecompress (unsigned char *outStream,
SizeT *uncompressedSize,
return SZ_ERROR_OUTPUT_EOF;
/* Decompress */
-outProcessed = outSizeFull;
+outProcessed = min(outSizeFull, *uncompressedSize);
WATCHDOG_RESET();
@@ -112,7 +112,7 @@ int lzmaBuffToBuffDecompress (unsigned char *outStream,
SizeT *uncompressedSize,
inStream, LZMA_PROPS_SIZE, LZMA_FINISH_END, state, g_Alloc);
*uncompressedSize = outProcessed;
-debug(LZMA: Uncompresed 0x%zx\n, outProcessed);
+debug(LZMA: Uncompressed ... 0x%zx\n, outProcessed);
if (res != SZ_OK) {
return res;
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 06/12] test: Rename test_compression to ut_compression
Try to keep the names of the unit test commands consistent.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
test/compression.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/test/compression.c b/test/compression.c
index 139ea01..c460567 100644
--- a/test/compression.c
+++ b/test/compression.c
@@ -313,9 +313,8 @@ out:
return ret;
}
-
-static int do_test_compression(cmd_tbl_t *cmdtp, int flag, int argc,
- char * const argv[])
+static int do_ut_compression(cmd_tbl_t *cmdtp, int flag, int argc,
+char *const argv[])
{
int err = 0;
@@ -324,12 +323,12 @@ static int do_test_compression(cmd_tbl_t *cmdtp, int
flag, int argc,
err += run_test(lzma, compress_using_lzma, uncompress_using_lzma);
err += run_test(lzo, compress_using_lzo, uncompress_using_lzo);
- printf(test_compression %s\n, err == 0 ? ok : FAILED);
+ printf(ut_compression %s\n, err == 0 ? ok : FAILED);
return err;
}
U_BOOT_CMD(
- test_compression, 5, 1, do_test_compression,
+ ut_compression, 5, 1, do_ut_compression,
Basic test of compressors: gzip bzip2 lzma lzo,
);
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 10/12] bzlib: Update destLen even on error
This allows the caller to easily detect how much of the destination buffer has been used. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None lib/bzlib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/bzlib.c b/lib/bzlib.c index 5844e18..9262e40 100644 --- a/lib/bzlib.c +++ b/lib/bzlib.c @@ -1350,11 +1350,11 @@ int BZ_API(BZ2_bzBuffToBuffDecompress) strm.avail_out = *destLen; ret = BZ2_bzDecompress ( strm ); + *destLen -= strm.avail_out; if (ret == BZ_OK) goto output_overflow_or_eof; if (ret != BZ_STREAM_END) goto errhandler; /* normal termination */ - *destLen -= strm.avail_out; BZ2_bzDecompressEnd ( strm ); return BZ_OK; -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 07/12] test: Add unit tests for bootm image decompression
Use each compression method (including uncompressed). Test for normal
operation, insufficient space and corrupted data.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
test/compression.c | 84 ++
1 file changed, 84 insertions(+)
diff --git a/test/compression.c b/test/compression.c
index c460567..ea2e4ad 100644
--- a/test/compression.c
+++ b/test/compression.c
@@ -7,8 +7,10 @@
#define DEBUG
#include common.h
+#include bootm.h
#include command.h
#include malloc.h
+#include asm/io.h
#include u-boot/zlib.h
#include bzlib.h
@@ -328,7 +330,89 @@ static int do_ut_compression(cmd_tbl_t *cmdtp, int flag,
int argc,
return err;
}
+static int compress_using_none(void *in, unsigned long in_size,
+ void *out, unsigned long out_max,
+ unsigned long *out_size)
+{
+ /* Here we just copy */
+ memcpy(out, in, in_size);
+ *out_size = in_size;
+
+ return 0;
+}
+
+/**
+ * run_bootm_test() - Run tests on the bootm decopmression function
+ *
+ * @comp_type: Compression type to test
+ * @compress: Our function to compress data
+ * @return 0 if OK, non-zero on failure
+ */
+static int run_bootm_test(int comp_type, mutate_func compress)
+{
+ ulong compress_size = 1024;
+ void *compress_buff;
+ int unc_len;
+ int err = 0;
+ const ulong image_start = 0;
+ const ulong load_addr = 0x1000;
+ ulong load_end;
+
+ printf(Testing: %s\n, genimg_get_comp_name(comp_type));
+ compress_buff = map_sysmem(image_start, 0);
+ unc_len = strlen(plain);
+ compress((void *)plain, unc_len, compress_buff, compress_size,
+compress_size);
+ err = bootm_decomp_image(comp_type, load_addr, image_start,
+IH_TYPE_KERNEL, map_sysmem(load_addr, 0),
+compress_buff, compress_size, unc_len,
+load_end);
+ if (err)
+ return err;
+ err = bootm_decomp_image(comp_type, load_addr, image_start,
+IH_TYPE_KERNEL, map_sysmem(load_addr, 0),
+compress_buff, compress_size, unc_len - 1,
+load_end);
+ if (!err)
+ return -EINVAL;
+
+ /* We can't detect corruption when not decompressing */
+ if (comp_type == IH_COMP_NONE)
+ return 0;
+ memset(compress_buff + compress_size / 2, '\x49',
+ compress_size / 2);
+ err = bootm_decomp_image(comp_type, load_addr, image_start,
+IH_TYPE_KERNEL, map_sysmem(load_addr, 0),
+compress_buff, compress_size, 0x1,
+load_end);
+ if (!err)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int do_ut_image_decomp(cmd_tbl_t *cmdtp, int flag, int argc,
+ char *const argv[])
+{
+ int err = 0;
+
+ err = run_bootm_test(IH_COMP_GZIP, compress_using_gzip);
+ err |= run_bootm_test(IH_COMP_BZIP2, compress_using_bzip2);
+ err |= run_bootm_test(IH_COMP_LZMA, compress_using_lzma);
+ err |= run_bootm_test(IH_COMP_LZO, compress_using_lzo);
+ err |= run_bootm_test(IH_COMP_NONE, compress_using_none);
+
+ printf(ut_image_decomp %s\n, err == 0 ? ok : FAILED);
+
+ return 0;
+}
+
U_BOOT_CMD(
ut_compression, 5, 1, do_ut_compression,
Basic test of compressors: gzip bzip2 lzma lzo,
);
+
+U_BOOT_CMD(
+ ut_image_decomp,5, 1, do_ut_image_decomp,
+ Basic test of bootm decompression,
+);
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 03/12] sandbox: Correct ordering of 'sb save' commands
Prior to commit d455d87 there was an inconsistency between the position of the 'address' parameter in 'sb load' and 'sb save'. This was corrected but it broke some tests. Fix the tests and also the help for 'sb save'. Signed-off-by: Simon Glass s...@chromium.org --- Changes in v2: None common/cmd_sandbox.c | 2 +- test/dm/sf.c | 2 +- test/image/test-fit.py | 6 +++--- 3 files changed, 5 insertions(+), 5 deletions(-) diff --git a/common/cmd_sandbox.c b/common/cmd_sandbox.c index 3d9fce7..4286969 100644 --- a/common/cmd_sandbox.c +++ b/common/cmd_sandbox.c @@ -117,7 +117,7 @@ U_BOOT_CMD( load hostfs - addr filename [bytes offset] - load a file from host\n sb ls hostfs - filename- list files on host\n - sb save hostfs - filename addr bytes [offset] - + sb save hostfs - addr filename bytes [offset] - save a file to host\n sb bind dev [filename] - bind \host\ device to file\n sb info [dev]- show device binding info\n diff --git a/test/dm/sf.c b/test/dm/sf.c index 57dd134..08098a1 100644 --- a/test/dm/sf.c +++ b/test/dm/sf.c @@ -29,7 +29,7 @@ static int dm_test_spi_flash(struct dm_test_state *dms) * benefit is worth the extra complexity. */ ut_asserteq(0, run_command_list( - sb save hostfs - spi.bin 0 20; + sb save hostfs - 0 spi.bin 20; sf probe; sf test 0 1, -1, 0)); /* diff --git a/test/image/test-fit.py b/test/image/test-fit.py index b065fcb..0eb424d 100755 --- a/test/image/test-fit.py +++ b/test/image/test-fit.py @@ -97,9 +97,9 @@ sb load hostfs 0 %(fit_addr)x %(fit)s fdt addr %(fit_addr)x bootm start %(fit_addr)x bootm loados -sb save hostfs 0 %(kernel_out)s %(kernel_addr)x %(kernel_size)x -sb save hostfs 0 %(fdt_out)s %(fdt_addr)x %(fdt_size)x -sb save hostfs 0 %(ramdisk_out)s %(ramdisk_addr)x %(ramdisk_size)x +sb save hostfs 0 %(kernel_addr)x %(kernel_out)s %(kernel_size)x +sb save hostfs 0 %(fdt_addr)x %(fdt_out)s %(fdt_size)x +sb save hostfs 0 %(ramdisk_addr)x %(ramdisk_out)s %(ramdisk_size)x reset ''' -- 2.2.0.rc0.207.ga3a616c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 05/12] bootm: Export bootm_decomp_image()
Export this function for testing. Also add a parameter so that values other
than CONFIG_SYS_BOOTM_LEN can be used for the maximum uncompressed size.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
common/bootm.c | 29 ++---
include/bootm.h | 17 +
2 files changed, 27 insertions(+), 19 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index 915d537..10c15ef 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -289,23 +289,11 @@ static int handle_decomp_error(const char *algo, size_t
size, size_t unc_len,
}
#endif
-/**
- * decomp_image() - decompress the operating system
- *
- * @comp: Compression algorithm that is used (IH_COMP_...)
- * @load: Destination load address in U-Boot memory
- * @image_start Image start address (where we are decompressing from)
- * @type: OS type (IH_OS_...)
- * @load_bug: Place to decompress to
- * @image_buf: Address to decompress from
- * @return 0 if OK, -ve on error (BOOTM_ERR_...)
- */
-static int decomp_image(int comp, ulong load, ulong image_start, int type,
- void *load_buf, void *image_buf, ulong image_len,
- ulong *load_end)
+int bootm_decomp_image(int comp, ulong load, ulong image_start, int type,
+ void *load_buf, void *image_buf, ulong image_len,
+ uint unc_len, ulong *load_end)
{
const char *type_name = genimg_get_type_name(type);
- __attribute__((unused)) uint unc_len = CONFIG_SYS_BOOTM_LEN;
*load_end = load;
switch (comp) {
@@ -413,8 +401,9 @@ static int bootm_load_os(bootm_headers_t *images, unsigned
long *load_end,
load_buf = map_sysmem(load, 0);
image_buf = map_sysmem(os.image_start, image_len);
- err = decomp_image(os.comp, load, os.image_start, os.type, load_buf,
- image_buf, image_len, load_end);
+ err = bootm_decomp_image(os.comp, load, os.image_start, os.type,
+load_buf, image_buf, image_len,
+CONFIG_SYS_BOOTM_LEN, load_end);
if (err) {
bootstage_error(BOOTSTAGE_ID_DECOMP_IMAGE);
return err;
@@ -905,9 +894,11 @@ static int bootm_host_load_image(const void *fit, int
req_image_type)
/* Allow the image to expand by a factor of 4, should be safe */
load_buf = malloc((1 20) + len * 4);
- ret = decomp_image(imape_comp, 0, data, image_type, load_buf,
- (void *)data, len, load_end);
+ ret = bootm_decomp_image(imape_comp, 0, data, image_type, load_buf,
+(void *)data, len, CONFIG_SYS_BOOTM_LEN,
+load_end);
free(load_buf);
+
if (ret ret != BOOTM_ERR_UNIMPLEMENTED)
return ret;
diff --git a/include/bootm.h b/include/bootm.h
index b3d1a62..6181488 100644
--- a/include/bootm.h
+++ b/include/bootm.h
@@ -56,4 +56,21 @@ int do_bootm_states(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[],
void arch_preboot_os(void);
+/**
+ * bootm_decomp_image() - decompress the operating system
+ *
+ * @comp: Compression algorithm that is used (IH_COMP_...)
+ * @load: Destination load address in U-Boot memory
+ * @image_start Image start address (where we are decompressing from)
+ * @type: OS type (IH_OS_...)
+ * @load_bug: Place to decompress to
+ * @image_buf: Address to decompress from
+ * @image_len: Number of bytes in @image_buf to decompress
+ * @unc_len: Available space for decompression
+ * @return 0 if OK, -ve on error (BOOTM_ERR_...)
+ */
+int bootm_decomp_image(int comp, ulong load, ulong image_start, int type,
+ void *load_buf, void *image_buf, ulong image_len,
+ uint unc_len, ulong *load_end);
+
#endif
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 08/12] bootm: Use print_decomp_msg() in all cases
Refactor to allow this function to be used to announce the image being
loaded regardless of compression type and even when there is no
decompression.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
common/bootm.c | 34 ++
1 file changed, 18 insertions(+), 16 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index 10c15ef..4a5c5ea 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -266,13 +266,25 @@ static int bootm_find_other(cmd_tbl_t *cmdtp, int flag,
int argc,
}
#endif /* USE_HOSTC */
-#if defined(CONFIG_GZIP) || defined(CONFIG_GZIP) || defined(CONFIG_BZIP2) || \
- defined(CONFIG_LZMA) || defined(CONFIG_LZO)
-static void print_decomp_msg(const char *type_name)
+/**
+ * print_decomp_msg() - Print a suitable decompression/loading message
+ *
+ * @type: OS type (IH_OS_...)
+ * @comp_type: Compression type being used (IH_COMP_...)
+ * @is_xip:true if the load address matches the image start
+ */
+static void print_decomp_msg(int comp_type, int type, bool is_xip)
{
- printf( Uncompressing %s ... , type_name);
+ const char *name = genimg_get_type_name(type);
+
+ if (comp_type == IH_COMP_NONE)
+ printf( %s %s ... , is_xip ? XIP : Loading, name);
+ else
+ printf( Uncompressing %s ... , name);
}
+#if defined(CONFIG_GZIP) || defined(CONFIG_GZIP) || defined(CONFIG_BZIP2) || \
+ defined(CONFIG_LZMA) || defined(CONFIG_LZO)
static int handle_decomp_error(const char *algo, size_t size, size_t unc_len,
int ret)
{
@@ -293,24 +305,18 @@ int bootm_decomp_image(int comp, ulong load, ulong
image_start, int type,
void *load_buf, void *image_buf, ulong image_len,
uint unc_len, ulong *load_end)
{
- const char *type_name = genimg_get_type_name(type);
-
*load_end = load;
+ print_decomp_msg(comp, type, load == image_start);
switch (comp) {
case IH_COMP_NONE:
- if (load == image_start) {
- printf( XIP %s ... , type_name);
- } else {
- printf( Loading %s ... , type_name);
+ if (load != image_start)
memmove_wd(load_buf, image_buf, image_len, CHUNKSZ);
- }
*load_end = load + image_len;
break;
#ifdef CONFIG_GZIP
case IH_COMP_GZIP: {
int ret;
- print_decomp_msg(type_name);
ret = gunzip(load_buf, unc_len, image_buf, image_len);
if (ret != 0) {
return handle_decomp_error(GUNZIP, image_len,
@@ -325,7 +331,6 @@ int bootm_decomp_image(int comp, ulong load, ulong
image_start, int type,
case IH_COMP_BZIP2: {
size_t size = unc_len;
- print_decomp_msg(type_name);
/*
* If we've got less than 4 MB of malloc() space,
* use slower decompression algorithm which requires
@@ -348,7 +353,6 @@ int bootm_decomp_image(int comp, ulong load, ulong
image_start, int type,
SizeT lzma_len = unc_len;
int ret;
- print_decomp_msg(type_name);
ret = lzmaBuffToBuffDecompress(load_buf, lzma_len,
image_buf, image_len);
if (ret != SZ_OK) {
@@ -365,8 +369,6 @@ int bootm_decomp_image(int comp, ulong load, ulong
image_start, int type,
size_t size = unc_len;
int ret;
- print_decomp_msg(type_name);
-
ret = lzop_decompress(image_buf, image_len, load_buf, size);
if (ret != LZO_E_OK)
return handle_decomp_error(LZO, size, unc_len, ret);
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 09/12] bootm: Factor out common parts of image decompression code
Adjust the code so that the error reporting can all be done at the end,
and is the same for each decompression method. Try to detect when
decompression fails due to lack of space. Keep the behaviour of
resetting on failure even though there should be no memory corruption
now.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
common/bootm.c | 88 --
1 file changed, 49 insertions(+), 39 deletions(-)
diff --git a/common/bootm.c b/common/bootm.c
index 4a5c5ea..e2dc164 100644
--- a/common/bootm.c
+++ b/common/bootm.c
@@ -283,97 +283,103 @@ static void print_decomp_msg(int comp_type, int type,
bool is_xip)
printf( Uncompressing %s ... , name);
}
-#if defined(CONFIG_GZIP) || defined(CONFIG_GZIP) || defined(CONFIG_BZIP2) || \
- defined(CONFIG_LZMA) || defined(CONFIG_LZO)
-static int handle_decomp_error(const char *algo, size_t size, size_t unc_len,
- int ret)
+/**
+ * handle_decomp_error() - display a decompression error
+ *
+ * This function tries to produce a useful message. In the case where the
+ * uncompressed size is the same as the available space, we can assume that
+ * the image is too large for the buffer.
+ *
+ * @comp_type: Compression type being used (IH_COMP_...)
+ * @uncomp_size: Number of bytes uncompressed
+ * @unc_len: Amount of space available for decompression
+ * @ret: Error code to report
+ * @return BOOTM_ERR_RESET, indicating that the board must be reset
+ */
+static int handle_decomp_error(int comp_type, size_t uncomp_size,
+ size_t unc_len, int ret)
{
- if (size = unc_len)
- puts(Image too large: increase CONFIG_SYS_BOOTM_LEN\n);
+ const char *name = genimg_get_comp_name(comp_type);
+
+ if (uncomp_size = unc_len)
+ printf(Image too large: increase CONFIG_SYS_BOOTM_LEN\n);
else
- printf(%s: uncompress or overwrite error %d\n, algo, ret);
- puts(Must RESET board to recover\n);
+ printf(%s: uncompress error %d\n, name, ret);
+
+ /*
+* The decompression routines are now safe, so will not write beyond
+* their bounds. Probably it is not necessary to reset, but maintain
+* the current behaviour for now.
+*/
+ printf(Must RESET board to recover\n);
#ifndef USE_HOSTCC
bootstage_error(BOOTSTAGE_ID_DECOMP_IMAGE);
#endif
return BOOTM_ERR_RESET;
}
-#endif
int bootm_decomp_image(int comp, ulong load, ulong image_start, int type,
void *load_buf, void *image_buf, ulong image_len,
uint unc_len, ulong *load_end)
{
+ int ret = 0;
+
*load_end = load;
print_decomp_msg(comp, type, load == image_start);
+
+ /*
+* Load the image to the right place, decompressing if needed. After
+* this, image_len will be set to the number of uncompressed bytes
+* loaded, ret will be non-zero on error.
+*/
switch (comp) {
case IH_COMP_NONE:
- if (load != image_start)
+ if (load == image_start)
+ break;
+ if (image_len = unc_len)
memmove_wd(load_buf, image_buf, image_len, CHUNKSZ);
- *load_end = load + image_len;
+ else
+ ret = 1;
break;
#ifdef CONFIG_GZIP
case IH_COMP_GZIP: {
- int ret;
-
ret = gunzip(load_buf, unc_len, image_buf, image_len);
- if (ret != 0) {
- return handle_decomp_error(GUNZIP, image_len,
- unc_len, ret);
- }
-
- *load_end = load + image_len;
break;
}
#endif /* CONFIG_GZIP */
#ifdef CONFIG_BZIP2
case IH_COMP_BZIP2: {
- size_t size = unc_len;
+ uint size = unc_len;
/*
* If we've got less than 4 MB of malloc() space,
* use slower decompression algorithm which requires
* at most 2300 KB of memory.
*/
- int i = BZ2_bzBuffToBuffDecompress(load_buf, unc_len,
+ ret = BZ2_bzBuffToBuffDecompress(load_buf, size,
image_buf, image_len,
CONFIG_SYS_MALLOC_LEN (4096 * 1024), 0);
- if (i != BZ_OK) {
- return handle_decomp_error(BUNZIP2, size, unc_len,
- i);
- }
-
- *load_end = load + unc_len;
+ image_len = size;
break;
}
#endif /* CONFIG_BZIP2 */
#ifdef CONFIG_LZMA
case IH_COMP_LZMA: {
SizeT lzma_len = unc_len;
- int ret;
[U-Boot] [PATCH v2 11/12] gunzip: Update lenp even on error
This allows the caller to easily detect how much of the destination buffer
has been used.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
lib/gunzip.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/lib/gunzip.c b/lib/gunzip.c
index 35abfb3..f469fcbe 100644
--- a/lib/gunzip.c
+++ b/lib/gunzip.c
@@ -73,6 +73,7 @@ int zunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp,
int stoponerr, int offset)
{
z_stream s;
+ int err = 0;
int r;
s.zalloc = gzalloc;
@@ -92,13 +93,13 @@ int zunzip(void *dst, int dstlen, unsigned char *src,
unsigned long *lenp,
if (stoponerr == 1 r != Z_STREAM_END
(s.avail_out == 0 || r != Z_BUF_ERROR)) {
printf(Error: inflate() returned %d\n, r);
- inflateEnd(s);
- return -1;
+ err = -1;
+ break;
}
s.avail_in = *lenp - offset - (int)(s.next_out - (unsigned
char*)dst);
} while (r == Z_BUF_ERROR);
*lenp = s.next_out - (unsigned char *) dst;
inflateEnd(s);
- return 0;
+ return err;
}
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 12/12] lzo: Update dst_len even on error
This allows the caller to easily detect how much of the destination buffer
has been used.
Signed-off-by: Simon Glass s...@chromium.org
---
Changes in v2: None
lib/lzo/lzo1x_decompress.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/lzo/lzo1x_decompress.c b/lib/lzo/lzo1x_decompress.c
index 35f3793..ebdf10b 100644
--- a/lib/lzo/lzo1x_decompress.c
+++ b/lib/lzo/lzo1x_decompress.c
@@ -102,8 +102,10 @@ int lzop_decompress(const unsigned char *src, size_t
src_len,
tmp = dlen;
r = lzo1x_decompress_safe((u8 *) src, slen, dst, tmp);
- if (r != LZO_E_OK)
+ if (r != LZO_E_OK) {
+ *dst_len = dst - start;
return r;
+ }
if (dlen != tmp)
return LZO_E_ERROR;
--
2.2.0.rc0.207.ga3a616c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] sf: stmicro: Add support for N25Q32
On 25 November 2014 at 17:16, xixiguo xixigu...@163.com wrote:
I add it's probe in stmicro.c as follow :
/static const struct stmicro_spi_flash_params stmicro_spi_flash_table[] = {
...
+ {
+ .id = 0xba16,
+ .pages_per_sector = 256,
+ .nr_sectors = 64,
+ .name = N25Q32,
+ },
...
struct spi_flash *spi_flash_probe_stmicro(struct spi_slave *spi, u8 *
idcode) {
...
+ /* clear BP# bit for locked flash */
+ spi_flash_cmd_write_status(flash, 0);
.../
Then I add the macro definition of CONFIG_SPI_FLASH_STMICRO. I got the flash
was detected :
/U-Boot# sf probe
SF:: Got idcodes
: 20 ba 16 10 00
SF: Detected N25Q32 with page size 64 KiB, total 4 MiB/
This flash erase_size works with SECT_4K, please try to use ML u-boot.
we unified flash
individual vendor flash to common.
Can it prove the drvier is correct?
And when I erase the flash, it never come out error, it seemed erase
correctly :
/SF: erase d8 1 0 0 (2)
status=0x0
...
SF: erase d8 21 0 0 (22)
status=0x0
SF: Successfully erased 2228224 bytes @ 0x0/
But I read out the data, it is not 0xff.
thanks!
--
Jagan.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] spi: add common spi3 controller driver
On 18 November 2014 at 14:28, Scott Jiang scott.jiang.li...@gmail.com wrote: 2014-11-17 3:23 GMT+08:00 Jagan Teki jagannadh.t...@gmail.com: Hi Scott, On 25 September 2014 14:55, Scott Jiang scott.jiang.li...@gmail.com wrote: SPI3 controller is not only used on BF609 platform. So we add a common controller driver and leave machine specific configuration in board drivers. Remove obsolete spi6xx.h and select new board driver in configuration file. Signed-off-by: Scott Jiang scott.jiang.li...@gmail.com --- drivers/spi/Makefile |1 + drivers/spi/adi_spi3.c | 222 I think adi_spi3.c is a copy of bfin_spi6xx.c with excluded-ed stuff of bf609 And also the difference is of chipselect and slave setup handling, why can't we use same driver my making this difference stuff in particular macro. Please try in that sense, It's not looking good to have one driver file with only having chip selct handing and slave setup. Would you mind moving spi_cs_is_valid() to arch/xx/include/asm/mach-xxx/spi.h? Because the number of spi controllers and the cs number of each controller might be different for different board. It use macros to do this before, while it's more difficult as boards become more. IMHO, it's not a good idea to move the driver stuff to arc/xx/include I do understand that the this logic is more designed towards specific board. Solutions on my mind: - try to use dm - then make a cs logic and get the attributes from the dts. thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Problem converting da850evm to generic board and use libfdt
I'm trying to make two changes to building u-boot for the da850evm. * Use the generic board code to get rid of the warning, and * Enable libfdt to allow booting of linux with a standalone dtb image. The first part appears to be simple. Just adding #define CONFIG_SYS_GENERIC_BOARD in include/configs/da850evm.h works with no obvious side-effects. However, adding #define CONFIG_OF_LIBFDT is a different story. It appears to introduce memory corruption when loading the environment. On first boot it gives the bad CRC! warning and uses the default environment. If you *don't* save the environment you can boot fine (including manual editing of the environment). However if you save the environment via saveenv bad things happen on the next boot. An example log: U-Boot SPL 2015.01-rc1 (Nov 27 2014 - 14:30:26) U-Boot 2015.01-rc1 (Nov 27 2014 - 14:30:26) I2C: ready DRAM: 64 MiB WARNING: Caches not enabled MMC: davinci: 0 SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB In:serial Out: serial Err: serial SF: Detected M25P64 with page size 256 Bytes, erase size 64 KiB, total 8 MiB Warning: Invalid MAC address read from SPI flash Net: DaVinci-EMAC Error: DaVinci-EMAC address not set. U-Boot help data abort pc : [c108ffd8] lr : [c10900b4] sp : c3e5f838 ip : fp : c3e5fda4 r10: c10b1f28 r9 : c3e5ff08 r8 : 000e r7 : c10b22c4 r6 : c10aa2a0 r5 : r4 : 001b r3 : c10b8f70 r2 : 0001 r1 : c3e5f840 r0 : Flags: Nzcv IRQs off FIQs off Mode SVC_32 Resetting CPU ... If I rebuild with CONFIG_OF_LIBFDT removed again from da850evm.h the problem disappears. And you can see that the saveenv worked (i.e. the environment is what was saved before the reboot and data abort). I've traced the problem as far as the inline version of console_puts() in common/console.c. The table dispatch there and the fact that the problem appears only when you load the environment makes me think it's memory corruption. Note: if you do *not* specify CONFIG_SYS_GENERIC_BOARD you still get the data abort, however it takes a bit more effort to trigger (like actually looking at the environment :-) ) (Note: This is building against the u-boot-2015.01-rc1 tree) Suggestions? -- Peter Howard p...@northern-ridge.com.au ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc/mpc85xx: SECURE BOOT- Add secure boot target for P5040DS
On 12/01/2014 09:50 PM, Gaurav Rana wrote: From: Gaurav Kumar Rana gaurav.r...@freescale.com Secure boot target is added for P5040DS platform. Signed-off-by: Gaurav Kumar Rana gaurav.r...@freescale.com --- configs/P5040DS_SECURE_BOOT_defconfig | 4 1 file changed, 4 insertions(+) create mode 100644 configs/P5040DS_SECURE_BOOT_defconfig diff --git a/configs/P5040DS_SECURE_BOOT_defconfig b/configs/P5040DS_SECURE_BOOT_defconfig new file mode 100644 index 000..8e21ca5 --- /dev/null +++ b/configs/P5040DS_SECURE_BOOT_defconfig @@ -0,0 +1,4 @@ +CONFIG_SYS_EXTRA_OPTIONS=SECURE_BOOT +CONFIG_PPC=y +CONFIG_MPC85xx=y +CONFIG_TARGET_P5040DS=y This is a new target. Please update MAINTAINER file. Please make sure you tested it on top of tree. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v9 2/2] Odroid-XU3: Add documentation for Odroid-XU3
Hi Simon, Hi, On 28 November 2014 at 06:46, Lukasz Majewski l.majew...@majess.pl wrote: Hello Javier, Hello Lukasz, On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski l.majew...@majess.pl wrote: I have yet to take him up on that offer though, but it sounds like a good way forward. The current layout really isn't practical. It indeed isn't very practical, but this is what you received from HardKernel when you buy XU3 board. Of course you can grab their sources, modify the layout, prepare u-boot's SPL and send it to them to be signed. However, it is not the way the normal user do things. He or she would like to replace standard (and outdated) HardKernel u-boot on their SD card and go forward with booting kernel. I agree with Sjoed that normal users don't replace the low-level components that are provided by the board vendor. After all you can boot a mainline kernel using the vendor u-boot, just append the DTB and create a uImage. The practical reason why someone would want to replace the vendor u-boot is to have more features but is very hard to do if there is a constraint in the maximum u-boot image size (even harder if the maximum is such small like in the XU3). I agree that 328 KiB size for u-boot is a constraint. I don't know HardKernel's justification for this. For now we _must_ focus on supporting XU3 with default BL1/BL2 and hence we are obliged to have u-boot size smaller than 328 KiB. It is challenging but for sure doable. It is doable but I don't see why the default BL2 _must_ be used. For practical/pragmatic reasons: 1. It is difficult to have signed BL2 - each time we need to ask HardKernel for signing it. It is impractical and hampers usage of mainline SPL (BL2) with XU3. 2. All the documentation on the HardKernel wiki site refers to the default BL2. 3. We will have new BL2, which source code is based on 2012.07 mainline u-boot. 4. Two BL2 binaries - IMHO will hurt (i.e. brick) some device sooner or latter. A user that wants to replace the kernel or u-boot is already tech-savy and can for sure replace the BL2 as well if it's publicly available. Sorry, but I'm a bit sceptical about updating such low level code. Bad things do happen. Maybe hardkernel folks can even make the modified BL2 available on their website and the link added in the comment explaining the layout? We would then require HardKernel to: 1. Provide updated BL2.img 2. Update their wiki to reflect the new BL2. Also, it is an artificial constraint after all and can be easily modified. In fact I think we should push hardkernel to change that layout by default and use a BL2/SPL that has more sensible size for the u-boot binary even if they don't need it for their vendor u-boot which seems to be quite small. I totally agree. I'd like to propose a following plan: 1. Accept Hyungwon's patches to have XU3 u-boot 328 KiB (with link to default BL2) to have XU3 support in place (and treat it as a starting point) 2. If u-boot's size less than 328 KiB is _really_ a problem to somebody then ask hardkernel to change BL2 or: - modify their sources to change the layout (I regard this as a quick hack solution) - with a lot of pain develop BL2/SPL (by whom?) which base on newest mainline (then for each test hardkernel must sign the binary). My 2p worth... The current Hardkernel BL1 looks broken to me - it is just too old. +1 While it is shipped with the board if you get an eMMC, the main way people will get this is by downloading it from their site. So why not download something different? As far as I remember U3 and probably XU3 in their README only points for HardKernel's site to grab BL1 and BL2. We don't plan to include their binaries to u-boot repository. Re the plan, I think 1 is fine so long as it is protected by a big ugly hack CONFIG and we can turn it off soon and revert the code. Hyungwon's patches only touch u-boot and rely (temporary I hope) on BL1 and BL2/SPL from Hardkernel. For 2, the size issue is one problem, but the clock code in U-Boot is another IMO. We should try to get both resolved. Maybe it is possible to use the peach-pit BL2 and get hardkernel to test it and sign it? I guess that SPL from peach-pit should be tunable to work with XU3 (in a finite number of iterations including signing from HardKernel). As it is based on recent u-boot it should be easy to produce BL2/SPL only for XU3 (if needed). Then people will download that one instead. is there a contact at hardkernel on the mailing list? As fair as I know no. I was posting questions on their forum. Maybe it is a right place to ask for contact point? As fair as I remember they were willing to sign SPL/BL2 when sent to them. Regards, Simon Best regards, Lukasz Majewski signature.asc
Re: [U-Boot] [PATCH v9 2/2] Odroid-XU3: Add documentation for Odroid-XU3
Hello Simon, Lukasz, On Tue, Dec 2, 2014 at 2:29 PM, Lukasz Majewski l.majew...@majess.pl wrote: Hi Simon, Hi, On 28 November 2014 at 06:46, Lukasz Majewski l.majew...@majess.pl wrote: Hello Javier, Hello Lukasz, On Fri, Nov 28, 2014 at 9:39 AM, Lukasz Majewski l.majew...@majess.pl wrote: I have yet to take him up on that offer though, but it sounds like a good way forward. The current layout really isn't practical. It indeed isn't very practical, but this is what you received from HardKernel when you buy XU3 board. Of course you can grab their sources, modify the layout, prepare u-boot's SPL and send it to them to be signed. However, it is not the way the normal user do things. He or she would like to replace standard (and outdated) HardKernel u-boot on their SD card and go forward with booting kernel. I agree with Sjoed that normal users don't replace the low-level components that are provided by the board vendor. After all you can boot a mainline kernel using the vendor u-boot, just append the DTB and create a uImage. The practical reason why someone would want to replace the vendor u-boot is to have more features but is very hard to do if there is a constraint in the maximum u-boot image size (even harder if the maximum is such small like in the XU3). I agree that 328 KiB size for u-boot is a constraint. I don't know HardKernel's justification for this. For now we _must_ focus on supporting XU3 with default BL1/BL2 and hence we are obliged to have u-boot size smaller than 328 KiB. It is challenging but for sure doable. It is doable but I don't see why the default BL2 _must_ be used. For practical/pragmatic reasons: 1. It is difficult to have signed BL2 - each time we need to ask HardKernel for signing it. It is impractical and hampers usage of mainline SPL (BL2) with XU3. 2. All the documentation on the HardKernel wiki site refers to the default BL2. 3. We will have new BL2, which source code is based on 2012.07 mainline u-boot. 4. Two BL2 binaries - IMHO will hurt (i.e. brick) some device sooner or latter. A user that wants to replace the kernel or u-boot is already tech-savy and can for sure replace the BL2 as well if it's publicly available. Sorry, but I'm a bit sceptical about updating such low level code. Bad things do happen. Maybe hardkernel folks can even make the modified BL2 available on their website and the link added in the comment explaining the layout? We would then require HardKernel to: 1. Provide updated BL2.img 2. Update their wiki to reflect the new BL2. Also, it is an artificial constraint after all and can be easily modified. In fact I think we should push hardkernel to change that layout by default and use a BL2/SPL that has more sensible size for the u-boot binary even if they don't need it for their vendor u-boot which seems to be quite small. I totally agree. I'd like to propose a following plan: 1. Accept Hyungwon's patches to have XU3 u-boot 328 KiB (with link to default BL2) to have XU3 support in place (and treat it as a starting point) 2. If u-boot's size less than 328 KiB is _really_ a problem to somebody then ask hardkernel to change BL2 or: - modify their sources to change the layout (I regard this as a quick hack solution) - with a lot of pain develop BL2/SPL (by whom?) which base on newest mainline (then for each test hardkernel must sign the binary). My 2p worth... The current Hardkernel BL1 looks broken to me - it is just too old. +1 While it is shipped with the board if you get an eMMC, the main way people will get this is by downloading it from their site. So why not download something different? As far as I remember U3 and probably XU3 in their README only points for HardKernel's site to grab BL1 and BL2. We don't plan to include their binaries to u-boot repository. Re the plan, I think 1 is fine so long as it is protected by a big ugly hack CONFIG and we can turn it off soon and revert the code. Hyungwon's patches only touch u-boot and rely (temporary I hope) on BL1 and BL2/SPL from Hardkernel. For 2, the size issue is one problem, but the clock code in U-Boot is another IMO. We should try to get both resolved. Maybe it is possible to use the peach-pit BL2 and get hardkernel to test it and sign it? I guess that SPL from peach-pit should be tunable to work with XU3 (in a finite number of iterations including signing from HardKernel). As it is based on recent u-boot it should be easy to produce BL2/SPL only for XU3 (if needed). Then people will download that one instead. is there a contact at hardkernel on the mailing list? As fair as I know no. I was posting questions on their forum. Maybe it is a right place to ask for contact point? As fair as I remember they were
[U-Boot] [PATCH] tools: env: fix build error
Since CONFIG_SYS_ARCH, CONFIG_SYS_CPU, ... were moved to Kconfig, tools/env/fw_printenv fails to build if CONFIG_ENV_VARS_UBOOT_CONFIG is defined. (I do not think this is the right way to fix the problem, but for now I do not have enough time to take a close look.) Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Reported-by: Denys Dmytriyenko de...@ti.com --- tools/env/fw_env.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/tools/env/fw_env.c b/tools/env/fw_env.c index 1173eea..698fe51 100644 --- a/tools/env/fw_env.c +++ b/tools/env/fw_env.c @@ -8,6 +8,9 @@ * SPDX-License-Identifier:GPL-2.0+ */ +/* FIXME: Do not include this */ +#include linux/kconfig.h + #include errno.h #include env_flags.h #include fcntl.h -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Building fw_env tools seems broken
Hi Denys, Sorry, I missed your mail. On Tue, 2 Dec 2014 13:09:11 -0500 Denys Dmytriyenko de...@ti.com wrote: Ping on this one. I tried few different defconfigs - the results are mixed, where sandbox and some other machines do work, but some are broken as below. Tried different toolchains as well - gcc-4.7 and 4.9. Any pointers or any help in resolving this issue would be greatly appreciated! Thanks. The build fails if CONFIG_ENV_VARS_UBOOT_CONFIG is defined. am335x_evm defines it, whereas sandbox does not. Could you check if this patch solves your problem? http://patchwork.ozlabs.org/patch/417192/ On Mon, Nov 24, 2014 at 04:19:17PM -0500, Denys Dmytriyenko wrote: Hi, I came across this issue recently, that affects 2014.10 as well as master, but used to work fine in 2014.07 and older. Please let me know if I'm missing something or you need additional info. Thanks! $ make CROSS_COMPILE=arm-linux-gnueabihf- am335x_evm_defconfig HOSTCC scripts/basic/fixdep HOSTCC scripts/kconfig/conf.o HOSTCC scripts/kconfig/zconf.tab.o HOSTLD scripts/kconfig/conf # # configuration written to .config # # # configuration written to spl/.config # $ make CROSS_COMPILE=arm-linux-gnueabihf- env scripts/kconfig/conf --silentoldconfig Kconfig scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config.h GEN include/autoconf.mk GEN include/autoconf.mk.dep GEN spl/include/autoconf.mk HOSTCC tools/env/fw_env.o In file included from tools/env/fw_env.c:117:0: include/env_default.h:110:11: error: expected ‘}’ before ‘CONFIG_SYS_ARCH’ scripts/Makefile.host:108: recipe for target 'tools/env/fw_env.o' failed make[1]: *** [tools/env/fw_env.o] Error 1 Makefile:1208: recipe for target 'env' failed make: *** [env] Error 2 -- Denys Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bare x86 support is merged to u-boot-x86
Hi Christian, On Wed, Dec 3, 2014 at 12:02 AM, Christian Gmeiner christian.gmei...@gmail.com wrote: Hi Bin, 2014-12-02 5:38 GMT+01:00 Bin Meng bmeng...@gmail.com: Hi Bruce, On Tue, Dec 2, 2014 at 4:28 AM, bruce_leon...@selinc.com wrote: Simon, From: Simon Glass s...@chromium.org To: bruce_leon...@selinc.com Cc: tr...@ti.com tr...@ti.com, U-Boot Mailing List u- b...@lists.denx.de, u-boot-boun...@lists.denx.de, Bin Meng bmeng...@gmail.com Date: 12/01/2014 12:14 PM Subject: Re: [U-Boot] Bare x86 support is merged to u-boot-x86 Sent by: s...@google.com +Bin Hi Bruce, On 1 December 2014 at 12:33, bruce_leon...@selinc.com wrote: Hi Simon and Bin, u-boot-boun...@lists.denx.de wrote on 11/25/2014 01:51:06 PM: From: Simon Glass s...@chromium.org To: U-Boot Mailing List u-boot@lists.denx.de Cc: tr...@ti.com tr...@ti.com Date: 11/25/2014 01:52 PM Subject: [U-Boot] Bare x86 support is merged to u-boot-x86 Sent by: u-boot-boun...@lists.denx.de Hi Bin (and others interested in U-Boot on x86), I've applied the remaining x86 patches to u-boot-x86. It runs on chromebook_link (Pixel) with support for most hardware relevant to a boot loader: SDRAM, SPI, PCI, USB (and USB Ethernet), SATA (internal 32GB SSD), SD card, LCD, UART, keyboard, EC. Bin this should be a good base for you to send patches for your Atom platform and I have no major work pending now so should not get in your way. Instructions on how to build and run are here: http://www.denx.de/wiki/U-Boot/X86 For this platform 4 binary blobs are needed. This is an unavoidable feature of the platform at present. The blobs cover flash descriptor, SDRAM init, video init and Management Engine. Instructions on how to get these are on the same page. Here is a list of some missing features: - README.x86 in the source (mostly the content from the Wiki page would be a good start) - MTRR support (for performance) - Audio - Chrome OS verified boot (only a rough rebase has been done, I'm not sure how to track mainline anyway) - SMI and ACPI support, to provide platform info and facilities to Linux This is awesome! Thanks so much for the work you two have done on this. We've been using u-boot on our PPC platforms for years and love it. We're considering moving to an Atom processor and wanted to continue to use u-boot, but were worried about getting it up and running with the FSL from Intel so we haven't made the jump yet. This is going to be a hugeleg up in my argument for actually getting that project off the ground. If we do, I'll be sure to be pushing out any work we do that isn't in the mainline. Thanks again guys! Sounds good! What Atom are you using? It might be the same one as Bin. Not sure yet. We had originally settled on the first one Intel put out, but since we've waited so long and we're not locked in by design yet, we'll probably pick a newer generation. Our products tend to be in service for a long time (upwards of 20 years) so we like to get as cutting edge as we can without losing a finger :) I am currently working on patches to support Intel Atom E6xx with Platform Controller Hub EG20T. This Atom platform aims at the embedded market. More newer Atom would be Bay Trail, which is an SoC and I believe Simon is going to support that platform once he gets a board. The latest Atom would be Braswell. If Intel keeps open for the chipset datasheet, I think we can try to support that too. We will see. That sound really interesting! My company is also using Intel Atom E6xx based designs and I would love to see u-boot/coreboot running on them. What is the current state of your work? The Atom E6xx U-Boot initial port is almost done and I plan to send patch series by the end of this week. Hopefully it could catch the last merge window of v2015.01 release. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mtd/spi: Add support for SST25WF040B
Add support for SST25WF040B-40I-SN flash.
Tested on T1024QDS board.
Signed-off-by: Shengzhou Liu shengzhou@freescale.com
---
drivers/mtd/spi/sf_params.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 61545ca..6e3a270 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -98,6 +98,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
{SST25WF010, 0xbf2502, 0x0, 64 * 1024, 2, 0,
SECT_4K | SST_WP},
{SST25WF020, 0xbf2503, 0x0, 64 * 1024, 4, 0,
SECT_4K | SST_WP},
{SST25WF040, 0xbf2504, 0x0, 64 * 1024, 8, 0,
SECT_4K | SST_WP},
+ {SST25WF040B,0x621613, 0x0, 64 * 1024, 8, 0,
SECT_4K | SST_WP},
{SST25WF080, 0xbf2505, 0x0, 64 * 1024,16, 0,
SECT_4K | SST_WP},
#endif
#ifdef CONFIG_SPI_FLASH_WINBOND/* WINBOND */
--
1.8.0
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/12] spi: sf: ICH SPI driver fix and flash params update
Hi Jagan, On Sun, Nov 23, 2014 at 9:43 PM, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Wed, Nov 12, 2014 at 3:04 PM, Jagan Teki jagannadh.t...@gmail.com wrote: On 12 November 2014 07:57, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Wed, Nov 5, 2014 at 10:56 AM, Bin Meng bmeng...@gmail.com wrote: Hi Jagan, On Wed, Nov 5, 2014 at 5:21 AM, Jagan Teki jagannadh.t...@gmail.com wrote: On 1 November 2014 14:23, Bin Meng bmeng...@gmail.com wrote: This series fix several bugs in current ICH SPI driver as well as adding byte program support for the SST25* flash. Flash params are updated to explicitly list supported read commands and change flash sector size to 4KiB as long as flash supports sector erase (20h) command. Changes for v2: - Rebased to u-boot-spi/mater. - Reviewed and updated the params of all currently supported flash parts per their datasheets. - Corrected AT25DF321 JEDEC ID. - Corrected Atmel bulk erase command to 50h instead of D8h. - Added AT25DF321A, W25X10, W25X20, W25X80 params. Bin Meng (12): spi/ich.c: Fix a bug of reading from a non-64 bytes aligned address spi/ich.c: Set the rx operation mode for ich 7 spi: sf: Support byte program for sst spi flash sf: Update SST flash params sf: Update Atmel flash params sf: Update EON flash params sf: Update GigaDevice flash params sf: Update Macronix flash params sf: Update Spansion flash params sf: Update Micron flash params sf: Update Winbond flash params sf: Give proper spacing between flash table params I think you combined two or more changes(unrelated) in a common patches and Added Bulk erase support in e_cmd_rd of sf_params ie quite not correct. Do you mean I should let PATCH 1/2/3 go as a separate patch set? Since these 3 are tested on my x86 board, could it be Simon to pick up these patches instead of through the u-boot-spi? Also I don't understand you comments about adding bulk erase support in e_cmd_rd is not correct. The e_cmd_rd in sf_params is updated to specify all supported read commands the flash can support. There is no bulk erase here. Please fix those and send me one more. Mean while I will look at your scenario like you're controller only supports AS, As I said before as AS of AF both are similar way of transferring except the dummy bits passing from the driver, try to see the fix on driver point of of instead of digging common sf stuff. Fixing on the driver part might be possible, might be not. Even though it is possible, I don't want to do that as the ICH manual explicitly says fast read command (0Bh) is not supported by the controller. As far as I can test, actually all of the commands which require an additional dummy byte after the address cycle fail to work. The matches what the manual says. Regards, Bin A gentle ping. Will back soon, please give some time. Any update on this patch series? Ping? Is there any chance this patch series will be merged into v2015.01? I see some other people are posting patches to add more SPI flash support in the parameter table which might do something different from what my patch series are trying to correct. Also I am going to post my x86 patches, and the SPI flash support on my x86 board requires the first 4 patches in this series. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 0/9] Add SD/NAND boot support for LS1021AQDS/TWR board
This series contain SD boot support for LS1021AQDS/TWR board and NAND boot support for LS1021AQDS board.SPL framework is used. PBL initialize the internal RAM and copy SPL to it, then SPL initialize DDR using SPD and copy u-boot from SD card or NAND flash to DDR, finally SPL transfer control to u-boot. Change log: v4: Add SUPPORT_SPL support for LS1021A. Enable IFC in SD boot. Use some defines instead of the magic numbers. v3: Change the Copyright year. Gave more explaination in the commit. Update MAINTAINERS files. Update PBI and RCW for SD boot. v2: Remove the definition of CONFIG_SPL_MAX_SIZE. Pad the variable u-boot size to 64 byte boundary in pblimage tool. Use pblimage_check_params() insteady of basing on the file name. Use generic u-boot-spl.lds. Alison Wang (9): ls102xa: pblimage: Add pblimage tool support for LS102xA spl: Use u-boot.img instead of u-boot.bin arm: spl: Add I2C linker list in generic .lds common: spl: Add interactive DDR debugger support for SPL image kconfig: ls1021a: add SUPPORT_SPL ls102xa: qixis: Add CONFIG_QIXIS_I2C_ACCESS macro arm: ls102xa: Add SD boot support for LS1021AQDS board arm: ls102xa: Add SD boot support for LS1021ATWR board arm: ls102xa: Add NAND boot support for LS1021AQDS board Makefile | 11 ++-- arch/arm/Kconfig | 2 ++ arch/arm/cpu/armv7/ls102xa/Makefile | 1 + arch/arm/cpu/armv7/ls102xa/spl.c | 33 arch/arm/cpu/u-boot-spl.lds | 3 +++ arch/arm/include/asm/arch-ls102xa/config.h| 1 + arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 5 arch/arm/include/asm/arch-ls102xa/spl.h | 20 +++ board/freescale/common/qixis.h| 7 ++ board/freescale/ls1021aqds/MAINTAINERS| 2 ++ board/freescale/ls1021aqds/ddr.c | 5 +++- board/freescale/ls1021aqds/ls1021aqds.c | 55 board/freescale/ls1021aqds/ls102xa_pbi.cfg| 12 + board/freescale/ls1021aqds/ls102xa_rcw_nand.cfg | 7 ++ board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg | 14 +++ board/freescale/ls1021atwr/MAINTAINERS| 1 + board/freescale/ls1021atwr/ls1021atwr.c | 20 +++ board/freescale/ls1021atwr/ls102xa_pbi.cfg| 12 + board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg | 14 +++ common/Makefile | 20 +++ configs/ls1021aqds_nand_defconfig | 4 +++ configs/ls1021aqds_sdcard_defconfig | 4 +++ configs/ls1021atwr_sdcard_defconfig | 4 +++ drivers/mtd/nand/fsl_ifc_spl.c| 10 include/configs/ls1021aqds.h | 117 + include/configs/ls1021atwr.h | 44 tools/pblimage.c | 110 +-- 27 files changed, 490 insertions(+), 48 deletions(-) create mode 100644 arch/arm/cpu/armv7/ls102xa/spl.c create mode 100644 arch/arm/include/asm/arch-ls102xa/spl.h create mode 100644 board/freescale/ls1021aqds/ls102xa_pbi.cfg create mode 100644 board/freescale/ls1021aqds/ls102xa_rcw_nand.cfg create mode 100644 board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg create mode 100644 board/freescale/ls1021atwr/ls102xa_pbi.cfg create mode 100644 board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg create mode 100644 configs/ls1021aqds_nand_defconfig create mode 100644 configs/ls1021aqds_sdcard_defconfig create mode 100644 configs/ls1021atwr_sdcard_defconfig ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 2/9] spl: Use u-boot.img instead of u-boot.bin
In SD boot, the magic number of u-boot image will be checked. For LS102xA, u-boot.bin doesn't have the magic number. So use u-boot.img which includes the magic number instead of u-boot.bin when producing u-boot-with-spl-pbl.bin. Signed-off-by: Alison Wang alison.w...@freescale.com --- Change log: v4: No change. v3: No change. v2: No change. Makefile | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index b1a8acd..0d83fbf 100644 --- a/Makefile +++ b/Makefile @@ -1022,10 +1022,16 @@ MKIMAGEFLAGS_u-boot-spl.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:%=%) \ spl/u-boot-spl.pbl: spl/u-boot-spl.bin FORCE $(call if_changed,mkimage) +ifeq ($(ARCH),arm) +UBOOT_BINLOAD := u-boot.img +else +UBOOT_BINLOAD := u-boot.bin +endif + OBJCOPYFLAGS_u-boot-with-spl-pbl.bin = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) \ --gap-fill=0xff -u-boot-with-spl-pbl.bin: spl/u-boot-spl.pbl u-boot.bin FORCE +u-boot-with-spl-pbl.bin: spl/u-boot-spl.pbl $(UBOOT_BINLOAD) FORCE $(call if_changed,pad_cat) # PPC4xx needs the SPL at the end of the image, since the reset vector -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 1/9] ls102xa: pblimage: Add pblimage tool support for LS102xA
For LS102xA, the size of spl/u-boot-spl.bin is variable.
This patch adds the support to deal with the variable
u-boot size in pblimage tool. It will be padded to 64
byte boundary.
Use pblimage_check_params() to add the specific operations
for ARM, such as PBI CRC and END command and the calculation
of pbl_cmd_initaddr.
Signed-off-by: Alison Wang alison.w...@freescale.com
---
Change log:
v4: No change.
v3: Change the Copyright year.
v2: Remove the definition of CONFIG_SPL_MAX_SIZE.
Pad the variable u-boot size to 64 byte boundary in pblimage tool.
Use pblimage_check_params() insteady of basing on the file name.
Makefile | 3 +-
tools/pblimage.c | 110 +--
2 files changed, 77 insertions(+), 36 deletions(-)
diff --git a/Makefile b/Makefile
index b4ed775..b1a8acd 100644
--- a/Makefile
+++ b/Makefile
@@ -1016,7 +1016,8 @@ u-boot-img.bin: spl/u-boot-spl.bin u-boot.img FORCE
#concatenated with u-boot binary. It is need by PowerPC SoC having
#internal SRAM = 512KB.
MKIMAGEFLAGS_u-boot-spl.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:%=%) \
- -R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:%=%) -T pblimage
+ -R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:%=%) -T pblimage \
+ -A $(ARCH) -a $(CONFIG_SPL_TEXT_BASE)
spl/u-boot-spl.pbl: spl/u-boot-spl.bin FORCE
$(call if_changed,mkimage)
diff --git a/tools/pblimage.c b/tools/pblimage.c
index 6e6e801..2a799ab 100644
--- a/tools/pblimage.c
+++ b/tools/pblimage.c
@@ -1,5 +1,5 @@
/*
- * Copyright 2012 Freescale Semiconductor, Inc.
+ * Copyright 2012-2014 Freescale Semiconductor, Inc.
*
* SPDX-License-Identifier:GPL-2.0+
*/
@@ -8,6 +8,10 @@
#include pblimage.h
#include pbl_crc32.h
+#define roundup(x, y) x) + ((y) - 1)) / (y)) * (y))
+#define PBL_ACS_CONT_CMD 0x8100
+#define PBL_ADDR_24BIT_MASK0x00ff
+
/*
* Initialize to an invalid value.
*/
@@ -22,6 +26,13 @@ static int pbl_size;
static char *fname = Unknown;
static int lineno = -1;
static struct pbl_header pblimage_header;
+static int uboot_size;
+static int arch_flag;
+
+static uint32_t pbl_cmd_initaddr;
+static uint32_t pbi_crc_cmd1;
+static uint32_t pbi_crc_cmd2;
+static uint32_t pbl_end_cmd[4];
static union
{
@@ -38,20 +49,6 @@ static union
* start offset by subtracting the size of the u-boot image from the
* top of the allowable 24-bit range.
*/
-static void init_next_pbl_cmd(FILE *fp_uboot)
-{
- struct stat st;
- int fd = fileno(fp_uboot);
-
- if (fstat(fd, st) == -1) {
- printf(Error: Could not determine u-boot image size. %s\n,
- strerror(errno));
- exit(EXIT_FAILURE);
- }
-
- next_pbl_cmd = 0x8200 - st.st_size;
-}
-
static void generate_pbl_cmd(void)
{
uint32_t val = next_pbl_cmd;
@@ -66,11 +63,15 @@ static void generate_pbl_cmd(void)
static void pbl_fget(size_t size, FILE *stream)
{
- unsigned char c;
+ unsigned char c = 0xff;
int c_temp;
- while (size (c_temp = fgetc(stream)) != EOF) {
- c = (unsigned char)c_temp;
+ while (size) {
+ c_temp = fgetc(stream);
+ if (c_temp != EOF)
+ c = (unsigned char)c_temp;
+ else if ((c_temp == EOF) (arch_flag == IH_ARCH_ARM))
+ c = 0xff;
*pmem_buf++ = c;
pbl_size++;
size--;
@@ -80,8 +81,8 @@ static void pbl_fget(size_t size, FILE *stream)
/* load split u-boot with PBI command 81xx. */
static void load_uboot(FILE *fp_uboot)
{
- init_next_pbl_cmd(fp_uboot);
- while (next_pbl_cmd 0x8200) {
+ next_pbl_cmd = pbl_cmd_initaddr - uboot_size;
+ while (next_pbl_cmd pbl_cmd_initaddr) {
generate_pbl_cmd();
pbl_fget(64, fp_uboot);
}
@@ -154,8 +155,6 @@ static uint32_t reverse_byte(uint32_t val)
/* write end command and crc command to memory. */
static void add_end_cmd(void)
{
- uint32_t pbl_end_cmd[4] = {0x09138000, 0x,
- 0x091380c0, 0x};
uint32_t crc32_pbl;
int i;
unsigned char *p = (unsigned char *)pbl_end_cmd;
@@ -172,8 +171,8 @@ static void add_end_cmd(void)
/* Add PBI CRC command. */
*pmem_buf++ = 0x08;
- *pmem_buf++ = 0x13;
- *pmem_buf++ = 0x80;
+ *pmem_buf++ = pbi_crc_cmd1;
+ *pmem_buf++ = pbi_crc_cmd2;
*pmem_buf++ = 0x40;
pbl_size += 4;
@@ -184,17 +183,6 @@ static void add_end_cmd(void)
*pmem_buf++ = (crc32_pbl 8) 0xff;
*pmem_buf++ = (crc32_pbl) 0xff;
pbl_size += 4;
-
- if ((pbl_size % 16) != 0) {
- for (i = 0; i 8; i++) {
- *pmem_buf++ = 0x0;
- pbl_size++;
- }
- }
- if ((pbl_size % 16 != 0)) {
-
[U-Boot] [PATCH v4 4/9] common: spl: Add interactive DDR debugger support for SPL image
To support interactive DDR debugger, cli_simple.o, cli.o, cli_readline.o, command.o, s_record.o, xyzModem.o and cmd_disk.o are all needed for drivers/ddr/fsl/interactive.c. In current common/Makefile, the above .o files are only produced when CONFIG_SPL_BUILD is disabled. For LS102xA, interactive DDR debugger is needed in SD/NAND boot too, and I enabled CONFIG_FSL_DDR_INTERACTIVE. But according to the current common/Makfile, all the above .o files are not produced in SPL part because CONFIG_SPL_BUILD is enabled in SPL part, the following error will be shown, drivers/ddr/fsl/built-in.o: In function `fsl_ddr_interactive': /home/wangh/layerscape/u-boot/drivers/ddr/fsl/interactive.c:1871: undefined reference to `cli_readline_into_buffer' /home/wangh/layerscape/u-boot/drivers/ddr/fsl/interactive.c:1873: undefined reference to `cli_simple_parse_line' make[1]: *** [spl/u-boot-spl] Error 1 make: *** [spl/u-boot-spl] Error 2 So this patch fixed this issue and the above .o files will be produced no matter CONFIG_SPL_BUILD is enabled or disabled. Signed-off-by: Alison Wang alison.w...@freescale.com --- Change log: v4: No change. v3: Gave more explaination in the commit. v2: No change. common/Makefile | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/common/Makefile b/common/Makefile index 9c47e20..c668a2f 100644 --- a/common/Makefile +++ b/common/Makefile @@ -8,22 +8,12 @@ # core ifndef CONFIG_SPL_BUILD obj-y += main.o -obj-y += command.o obj-y += exports.o obj-y += hash.o ifdef CONFIG_SYS_HUSH_PARSER obj-y += cli_hush.o endif -# We always have this since drivers/ddr/fs/interactive.c needs it -obj-y += cli_simple.o - -obj-y += cli.o -obj-y += cli_readline.o -obj-y += s_record.o -obj-y += xyzModem.o -obj-y += cmd_disk.o - # This option is not just y/n - it can have a numeric value ifdef CONFIG_BOOTDELAY obj-y += autoboot.o @@ -272,4 +262,14 @@ endif obj-$(CONFIG_CMD_BLOB) += cmd_blob.o +# We always have this since drivers/ddr/fs/interactive.c needs it +obj-y += cli_simple.o + +obj-y += cli.o +obj-y += cli_readline.o +obj-y += command.o +obj-y += s_record.o +obj-y += xyzModem.o +obj-y += cmd_disk.o + CFLAGS_env_embedded.o := -Wa,--no-warn -DENV_CRC=$(shell tools/envcrc 2/dev/null) -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 7/9] arm: ls102xa: Add SD boot support for LS1021AQDS board
This patch adds SD boot support for LS1021AQDS board. SPL
framework is used. PBL initialize the internal RAM and copy
SPL to it, then SPL initialize DDR using SPD and copy u-boot
from SD card to DDR, finally SPL transfer control to u-boot.
Signed-off-by: Alison Wang alison.w...@freescale.com
Signed-off-by: Jason Jin jason@freescale.com
---
Change log:
v4: Enable IFC in SD boot.
v3: Update MAINTAINERS file.
Update PBI and RCW for SD boot.
v2: Use generic u-boot-spl.lds.
arch/arm/cpu/armv7/ls102xa/Makefile | 1 +
arch/arm/cpu/armv7/ls102xa/spl.c | 33
arch/arm/include/asm/arch-ls102xa/spl.h | 20
board/freescale/ls1021aqds/MAINTAINERS| 1 +
board/freescale/ls1021aqds/ddr.c | 5 ++-
board/freescale/ls1021aqds/ls1021aqds.c | 39 +++
board/freescale/ls1021aqds/ls102xa_pbi.cfg| 12 +++
board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg | 14 +
configs/ls1021aqds_sdcard_defconfig | 4 +++
include/configs/ls1021aqds.h | 45 +++
10 files changed, 173 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/cpu/armv7/ls102xa/spl.c
create mode 100644 arch/arm/include/asm/arch-ls102xa/spl.h
create mode 100644 board/freescale/ls1021aqds/ls102xa_pbi.cfg
create mode 100644 board/freescale/ls1021aqds/ls102xa_rcw_sd.cfg
create mode 100644 configs/ls1021aqds_sdcard_defconfig
diff --git a/arch/arm/cpu/armv7/ls102xa/Makefile
b/arch/arm/cpu/armv7/ls102xa/Makefile
index d82ce8d..56ef3a7 100644
--- a/arch/arm/cpu/armv7/ls102xa/Makefile
+++ b/arch/arm/cpu/armv7/ls102xa/Makefile
@@ -10,3 +10,4 @@ obj-y += timer.o
obj-$(CONFIG_OF_LIBFDT) += fdt.o
obj-$(CONFIG_SYS_HAS_SERDES) += fsl_ls1_serdes.o ls102xa_serdes.o
+obj-$(CONFIG_SPL) += spl.o
diff --git a/arch/arm/cpu/armv7/ls102xa/spl.c b/arch/arm/cpu/armv7/ls102xa/spl.c
new file mode 100644
index 000..1dfbf54
--- /dev/null
+++ b/arch/arm/cpu/armv7/ls102xa/spl.c
@@ -0,0 +1,33 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
+#include spl.h
+
+u32 spl_boot_device(void)
+{
+#ifdef CONFIG_SPL_MMC_SUPPORT
+ return BOOT_DEVICE_MMC1;
+#endif
+ return BOOT_DEVICE_NAND;
+}
+
+u32 spl_boot_mode(void)
+{
+ switch (spl_boot_device()) {
+ case BOOT_DEVICE_MMC1:
+#ifdef CONFIG_SPL_FAT_SUPPORT
+ return MMCSD_MODE_FAT;
+#else
+ return MMCSD_MODE_RAW;
+#endif
+ case BOOT_DEVICE_NAND:
+ return 0;
+ default:
+ puts(spl: error: unsupported device\n);
+ hang();
+ }
+}
diff --git a/arch/arm/include/asm/arch-ls102xa/spl.h
b/arch/arm/include/asm/arch-ls102xa/spl.h
new file mode 100644
index 000..26e4ea1
--- /dev/null
+++ b/arch/arm/include/asm/arch-ls102xa/spl.h
@@ -0,0 +1,20 @@
+/*
+ * Copyright 2014 Freescale Semiconductor, Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __ASM_ARCH_SPL_H__
+#define __ASM_ARCH_SPL_H__
+
+#define BOOT_DEVICE_NONE 0
+#define BOOT_DEVICE_XIP1
+#define BOOT_DEVICE_XIPWAIT2
+#define BOOT_DEVICE_NAND 3
+#define BOOT_DEVICE_ONENAND4
+#define BOOT_DEVICE_MMC1 5
+#define BOOT_DEVICE_MMC2 6
+#define BOOT_DEVICE_MMC2_2 7
+#define BOOT_DEVICE_SPI10
+
+#endif /* __ASM_ARCH_SPL_H__ */
diff --git a/board/freescale/ls1021aqds/MAINTAINERS
b/board/freescale/ls1021aqds/MAINTAINERS
index e30e944..962176b 100644
--- a/board/freescale/ls1021aqds/MAINTAINERS
+++ b/board/freescale/ls1021aqds/MAINTAINERS
@@ -6,3 +6,4 @@ F: include/configs/ls1021aqds.h
F: configs/ls1021aqds_nor_defconfig
F: configs/ls1021aqds_ddr4_nor_defconfig
F: configs/ls1021aqds_nor_SECURE_BOOT_defconfig
+F: configs/ls1021aqds_sdcard_defconfig
diff --git a/board/freescale/ls1021aqds/ddr.c b/board/freescale/ls1021aqds/ddr.c
index 5898e33..a539ff9 100644
--- a/board/freescale/ls1021aqds/ddr.c
+++ b/board/freescale/ls1021aqds/ddr.c
@@ -153,9 +153,12 @@ phys_size_t initdram(int board_type)
{
phys_size_t dram_size;
+#if defined(CONFIG_SPL_BUILD) || !defined(CONFIG_SPL)
puts(Initializing DDRusing SPD\n);
dram_size = fsl_ddr_sdram();
-
+#else
+ dram_size = fsl_ddr_sdram_size();
+#endif
return dram_size;
}
diff --git a/board/freescale/ls1021aqds/ls1021aqds.c
b/board/freescale/ls1021aqds/ls1021aqds.c
index 0a7720a..bb1ec72 100644
--- a/board/freescale/ls1021aqds/ls1021aqds.c
+++ b/board/freescale/ls1021aqds/ls1021aqds.c
@@ -14,6 +14,7 @@
#include fsl_esdhc.h
#include fsl_ifc.h
#include fsl_sec.h
+#include spl.h
#include ../common/qixis.h
#include ls1021aqds_qixis.h
@@ -33,10 +34,17 @@ enum {
int checkboard(void)
{
char buf[64];
+#if !defined(CONFIG_SD_BOOT) !defined(CONFIG_QSPI_BOOT)
u8 sw;
+#endif
puts(Board: LS1021AQDS\n);
+#ifdef
[U-Boot] [PATCH v4 3/9] arm: spl: Add I2C linker list in generic .lds
On LS1, DDR is initialized by reading SPD through I2C interface
in SPL code. For I2C, ll_entry_count() is called, and it returns
the number of elements of a linker-generated array placed into
subsection of .u_boot_list section specified by _list argument.
So add I2C linker list in the generic .lds to fix the issue about
using I2C in SPL.
Signed-off-by: Alison Wang alison.w...@freescale.com
---
Change log:
v4: No change.
v3: No change.
v2: New file.
arch/arm/cpu/u-boot-spl.lds | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/cpu/u-boot-spl.lds b/arch/arm/cpu/u-boot-spl.lds
index a69b006..a8be204 100644
--- a/arch/arm/cpu/u-boot-spl.lds
+++ b/arch/arm/cpu/u-boot-spl.lds
@@ -32,6 +32,9 @@ SECTIONS
}
. = ALIGN(4);
+ .u_boot_list : {
+ KEEP(*(SORT(.u_boot_list*_i2c_*)));
+ }
. = .;
#ifdef CONFIG_SPL_DM
--
2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 6/9] ls102xa: qixis: Add CONFIG_QIXIS_I2C_ACCESS macro
Through adding CONFIG_QIXIS_I2C_ACCESS macro, QIXIS_READ(reg)/QIXIS_WRITE(reg, value) can be used for both i2c and ifc access to QIXIS FPGA. This is more convenient for coding. Signed-off-by: Jason Jin jason@freescale.com Signed-off-by: Alison Wang alison.w...@freescale.com --- Change log: v4: No change. v3: No change. v2: No change. board/freescale/common/qixis.h | 7 +++ 1 file changed, 7 insertions(+) diff --git a/board/freescale/common/qixis.h b/board/freescale/common/qixis.h index d8fed14..52d2021 100644 --- a/board/freescale/common/qixis.h +++ b/board/freescale/common/qixis.h @@ -100,8 +100,15 @@ u8 qixis_read_i2c(unsigned int reg); void qixis_write_i2c(unsigned int reg, u8 value); #endif +#if defined(CONFIG_QIXIS_I2C_ACCESS) defined(CONFIG_SYS_I2C_FPGA_ADDR) +#define QIXIS_READ(reg) qixis_read_i2c(offsetof(struct qixis, reg)) +#define QIXIS_WRITE(reg, value) \ + qixis_write_i2c(offsetof(struct qixis, reg), value) +#else #define QIXIS_READ(reg) qixis_read(offsetof(struct qixis, reg)) #define QIXIS_WRITE(reg, value) qixis_write(offsetof(struct qixis, reg), value) +#endif + #ifdef CONFIG_SYS_I2C_FPGA_ADDR #define QIXIS_READ_I2C(reg) qixis_read_i2c(offsetof(struct qixis, reg)) #define QIXIS_WRITE_I2C(reg, value) \ -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 8/9] arm: ls102xa: Add SD boot support for LS1021ATWR board
This patch adds SD boot support for LS1021ATWR board. SPL
framework is used. PBL initialize the internal RAM and copy
SPL to it, then SPL initialize DDR using SPD and copy u-boot
from SD card to DDR, finally SPL transfer control to u-boot.
Signed-off-by: Chen Lu chen...@freescale.com
Signed-off-by: Alison Wang alison.w...@freescale.com
Signed-off-by: Jason Jin jason@freescale.com
---
Change log:
v4: Enable IFC in SD boot.
v3: Update MAINTAINERS file.
Update PBI and RCW for SD boot.
v2: Use generic u-boot-spl.lds.
board/freescale/ls1021atwr/MAINTAINERS| 1 +
board/freescale/ls1021atwr/ls1021atwr.c | 20
board/freescale/ls1021atwr/ls102xa_pbi.cfg| 12
board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg | 14 +
configs/ls1021atwr_sdcard_defconfig | 4 +++
include/configs/ls1021atwr.h | 44 +++
6 files changed, 95 insertions(+)
create mode 100644 board/freescale/ls1021atwr/ls102xa_pbi.cfg
create mode 100644 board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg
create mode 100644 configs/ls1021atwr_sdcard_defconfig
diff --git a/board/freescale/ls1021atwr/MAINTAINERS
b/board/freescale/ls1021atwr/MAINTAINERS
index 8def0e5..2312e00 100644
--- a/board/freescale/ls1021atwr/MAINTAINERS
+++ b/board/freescale/ls1021atwr/MAINTAINERS
@@ -5,3 +5,4 @@ F: board/freescale/ls1021atwr/
F: include/configs/ls1021atwr.h
F: configs/ls1021atwr_nor_defconfig
F: configs/ls1021atwr_nor_SECURE_BOOT_defconfig
+F: configs/ls1021atwr_sdcard_defconfig
diff --git a/board/freescale/ls1021atwr/ls1021atwr.c
b/board/freescale/ls1021atwr/ls1021atwr.c
index 3e8c37b..a157262 100644
--- a/board/freescale/ls1021atwr/ls1021atwr.c
+++ b/board/freescale/ls1021atwr/ls1021atwr.c
@@ -17,6 +17,7 @@
#include fsl_mdio.h
#include tsec.h
#include fsl_sec.h
+#include spl.h
#ifdef CONFIG_U_QE
#include ../../../drivers/qe/qe.h
#endif
@@ -270,6 +271,25 @@ int board_early_init_f(void)
return 0;
}
+#ifdef CONFIG_SPL_BUILD
+void board_init_f(ulong dummy)
+{
+ /* Set global data pointer */
+ gd = gdata;
+
+ /* Clear the BSS */
+ memset(__bss_start, 0, __bss_end - __bss_start);
+
+ get_clocks();
+
+ preloader_console_init();
+
+ dram_init();
+
+ board_init_r(NULL, 0);
+}
+#endif
+
int board_init(void)
{
struct ccsr_cci400 *cci = (struct ccsr_cci400 *)CONFIG_SYS_CCI400_ADDR;
diff --git a/board/freescale/ls1021atwr/ls102xa_pbi.cfg
b/board/freescale/ls1021atwr/ls102xa_pbi.cfg
new file mode 100644
index 000..f1a1b63
--- /dev/null
+++ b/board/freescale/ls1021atwr/ls102xa_pbi.cfg
@@ -0,0 +1,12 @@
+#PBI commands
+
+09570200
+09570158 0300
+8940007c 21f47300
+
+#Configure Scratch register
+09ee0200 1000
+#Configure alternate space
+09570158 1000
+#Flush PBL data
+096100c0 000F
diff --git a/board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg
b/board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg
new file mode 100644
index 000..9c3e3b0
--- /dev/null
+++ b/board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg
@@ -0,0 +1,14 @@
+#PBL preamble and RCW header
+aa55aa55 01ee0100
+
+#enable IFC, disable QSPI and DSPI
+0608000a
+2000 00407900 60040a00 21046000
+ 00038000
+0008 881b7340
+
+#disable IFC, enable QSPI and DSPI
+#0608000a
+#2000 00407900 60040a00 21046000
+# 00038000
+#20084800 881b7340
diff --git a/configs/ls1021atwr_sdcard_defconfig
b/configs/ls1021atwr_sdcard_defconfig
new file mode 100644
index 000..0eb556a
--- /dev/null
+++ b/configs/ls1021atwr_sdcard_defconfig
@@ -0,0 +1,4 @@
+CONFIG_SPL=y
+CONFIG_SYS_EXTRA_OPTIONS=RAMBOOT_PBL,SPL_FSL_PBL,SD_BOOT
++S:CONFIG_ARM=y
++S:CONFIG_TARGET_LS1021ATWR=y
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 3eac7ee..945463f 100644
--- a/include/configs/ls1021atwr.h
+++ b/include/configs/ls1021atwr.h
@@ -35,6 +35,38 @@
#define CONFIG_SYS_CLK_FREQ1
#define CONFIG_DDR_CLK_FREQ1
+#ifdef CONFIG_RAMBOOT_PBL
+#define CONFIG_SYS_FSL_PBL_PBI board/freescale/ls1021atwr/ls102xa_pbi.cfg
+#endif
+
+#ifdef CONFIG_SD_BOOT
+#define CONFIG_SYS_FSL_PBL_RCW board/freescale/ls1021atwr/ls102xa_rcw_sd.cfg
+#define CONFIG_SPL_FRAMEWORK
+#define CONFIG_SPL_LDSCRIPTarch/$(ARCH)/cpu/u-boot-spl.lds
+#define CONFIG_SPL_LIBCOMMON_SUPPORT
+#define CONFIG_SPL_LIBGENERIC_SUPPORT
+#define CONFIG_SPL_ENV_SUPPORT
+#define CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT
+#define CONFIG_SPL_I2C_SUPPORT
+#define CONFIG_SPL_WATCHDOG_SUPPORT
+#define CONFIG_SPL_SERIAL_SUPPORT
+#define CONFIG_SPL_MMC_SUPPORT
+#define CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR0xe8
+#define CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS 0x400
+
+#define CONFIG_SPL_TEXT_BASE 0x1000
+#define CONFIG_SPL_MAX_SIZE0x1a000
[U-Boot] [PATCH v4 9/9] arm: ls102xa: Add NAND boot support for LS1021AQDS board
This patch adds NAND boot support for LS1021AQDS board. SPL
framework is used. PBL initialize the internal RAM and copy
SPL to it, then SPL initialize DDR using SPD and copy u-boot
from NAND flash to DDR, finally SPL transfer control to u-boot.
Signed-off-by: Prabhakar Kushwaha prabha...@freescale.com
Signed-off-by: Alison Wang alison.w...@freescale.com
---
Change log:
v4: Use some defines instead of the magic numbers.
v3: New file.
arch/arm/include/asm/arch-ls102xa/config.h| 1 +
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 2 +
board/freescale/ls1021aqds/MAINTAINERS| 1 +
board/freescale/ls1021aqds/ls1021aqds.c | 16 ++
board/freescale/ls1021aqds/ls102xa_rcw_nand.cfg | 7 +++
configs/ls1021aqds_nand_defconfig | 4 ++
drivers/mtd/nand/fsl_ifc_spl.c| 8 +++
include/configs/ls1021aqds.h | 68 +++
8 files changed, 107 insertions(+)
create mode 100644 board/freescale/ls1021aqds/ls102xa_rcw_nand.cfg
create mode 100644 configs/ls1021aqds_nand_defconfig
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h
b/arch/arm/include/asm/arch-ls102xa/config.h
index a500b5b..da7537c 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -13,6 +13,7 @@
#define OCRAM_SIZE 0x0002
#define CONFIG_SYS_IMMR0x0100
arch/arm/include/asm/arch-ls102xa/config.h| 1 +
arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h | 5 ++
board/freescale/ls1021aqds/MAINTAINERS| 1 +
board/freescale/ls1021aqds/ls1021aqds.c | 16 +
board/freescale/ls1021aqds/ls102xa_rcw_nand.cfg | 7 +++
configs/ls1021aqds_nand_defconfig | 4 ++
drivers/mtd/nand/fsl_ifc_spl.c| 10
include/configs/ls1021aqds.h | 72 +++
8 files changed, 116 insertions(+)
create mode 100644 board/freescale/ls1021aqds/ls102xa_rcw_nand.cfg
create mode 100644 configs/ls1021aqds_nand_defconfig
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h
b/arch/arm/include/asm/arch-ls102xa/config.h
index ba86eea..8318c91 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -13,6 +13,7 @@
#define OCRAM_SIZE 0x0002
#define CONFIG_SYS_IMMR0x0100
+#define CONFIG_SYS_DCSRBAR 0x2020
#define CONFIG_SYS_FSL_DDR_ADDR(CONFIG_SYS_IMMR +
0x0008)
#define CONFIG_SYS_CCI400_ADDR (CONFIG_SYS_IMMR + 0x0018)
diff --git a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
index b0c267c..3af63f8 100644
--- a/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
+++ b/arch/arm/include/asm/arch-ls102xa/immap_ls102xa.h
@@ -29,6 +29,11 @@
#define ARCH_TIMER_CTRL_ENABLE (1 0)
#define SYS_COUNTER_CTRL_ENABLE(1 24)
+#define DCFG_CCSR_PORSR1_RCW_MASK 0xff80
+#define DCFG_CCSR_PORSR1_RCW_SRC_I2C 0x2480
+
+#define DCFG_DCSR_PORCR1 0x2
+
struct sys_info {
unsigned long freq_processor[CONFIG_MAX_CPUS];
unsigned long freq_systembus;
diff --git a/board/freescale/ls1021aqds/MAINTAINERS
b/board/freescale/ls1021aqds/MAINTAINERS
index 962176b..b7d85dc 100644
--- a/board/freescale/ls1021aqds/MAINTAINERS
+++ b/board/freescale/ls1021aqds/MAINTAINERS
@@ -7,3 +7,4 @@ F: configs/ls1021aqds_nor_defconfig
F: configs/ls1021aqds_ddr4_nor_defconfig
F: configs/ls1021aqds_nor_SECURE_BOOT_defconfig
F: configs/ls1021aqds_sdcard_defconfig
+F: configs/ls1021aqds_nand_defconfig
diff --git a/board/freescale/ls1021aqds/ls1021aqds.c
b/board/freescale/ls1021aqds/ls1021aqds.c
index bb1ec72..a8e6276 100644
--- a/board/freescale/ls1021aqds/ls1021aqds.c
+++ b/board/freescale/ls1021aqds/ls1021aqds.c
@@ -172,6 +172,22 @@ void board_init_f(ulong dummy)
{
struct ccsr_cci400 *cci = (struct ccsr_cci400 *)CONFIG_SYS_CCI400_ADDR;
+#ifdef CONFIG_NAND_BOOT
+ struct ccsr_gur __iomem *gur = (void *)CONFIG_SYS_FSL_GUTS_ADDR;
+ u32 porsr1, pinctl;
+
+ /*
+* There is LS1 SoC issue where NOR, FPGA are inaccessible during
+* NAND boot because IFC signals IFC_AD7 are not enabled.
+* This workaround changes RCW source to make all signals enabled.
+*/
+ porsr1 = in_be32(gur-porsr1);
+ pinctl = ((porsr1 ~(DCFG_CCSR_PORSR1_RCW_MASK)) |
+DCFG_CCSR_PORSR1_RCW_SRC_I2C);
+ out_be32((unsigned int *)(CONFIG_SYS_DCSRBAR + DCFG_DCSR_PORCR1),
+pinctl);
+#endif
+
/* Set global data pointer */
gd = gdata;
diff --git a/board/freescale/ls1021aqds/ls102xa_rcw_nand.cfg
b/board/freescale/ls1021aqds/ls102xa_rcw_nand.cfg
new file mode
Re: [U-Boot] [PATCH v3 4/8] common: spl: Add interactive DDR debugger support for SPL image
Hi, York, On 11/17/2014 11:02 PM, Albert ARIBAUD wrote: Hello York, On Mon, 17 Nov 2014 15:00:42 -0800, York Sun york...@freescale.com wrote: On 10/27/2014 06:48 PM, Wang Huan-B18965 wrote: Hello, Albert, snip --- Change log: v3: Gave more explaination in the commit. v2: No change. This does not apply cleanly. Could you rebase and resubmit? [Alison Wang] ok, I will rebase and resubmit the set. Thanks. Alison, Where are we on this patch? If you haven't sent an update, I can take this one and resolve the conflict. Albert, This set primarily deals with FSL specific boards. I can take them in if you don't see any issue with the patches (except the conflicts). Thanks York for the proposal, but I would prefer the patch to be rebased and resubmitted, as rebasing does require some changes which could be trivial, and thus be handled by the custodian, or not trivial, and thus require review; best, therefore, to rebase and repost. All right, then. Alison, please send a new set after you test it. I will mark this set change requested. [Alison Wang] I rebased, tested and submitted the new set. Please help to review it. Thanks. Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4 5/9] kconfig: ls1021a: add SUPPORT_SPL
Add SUPPORT_SPL feature for SD and NAND boot on LS1021AQDS and LS1021ATWR. Signed-off-by: Alison Wang alison.w...@freescale.com --- Change log: v4: New file. arch/arm/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 0982117..1f00e93 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -730,10 +730,12 @@ config TARGET_LS2085A_SIMU config TARGET_LS1021AQDS bool Support ls1021aqds_nor select CPU_V7 + select SUPPORT_SPL config TARGET_LS1021ATWR bool Support ls1021atwr_nor select CPU_V7 + select SUPPORT_SPL config TARGET_BALLOON3 bool Support balloon3 -- 2.1.0.27.g96db324 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 5/9] kconfig: ls1021a: add SUPPORT_SPL
Hi Alison, On Wed, 3 Dec 2014 15:00:45 +0800 Alison Wang b18...@freescale.com wrote: Add SUPPORT_SPL feature for SD and NAND boot on LS1021AQDS and LS1021ATWR. Signed-off-by: Alison Wang alison.w...@freescale.com --- Change log: v4: New file. arch/arm/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 0982117..1f00e93 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -730,10 +730,12 @@ config TARGET_LS2085A_SIMU config TARGET_LS1021AQDS bool Support ls1021aqds_nor select CPU_V7 + select SUPPORT_SPL config TARGET_LS1021ATWR bool Support ls1021atwr_nor select CPU_V7 + select SUPPORT_SPL config TARGET_BALLOON3 bool Support balloon3 -- While you are here, could you fix the prompts too? ls1021aqds_nor implies NOR boot, but you are adding SD/NAND boot, right? Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] i2c: Fix deselection of muxes
Hi Mark,
This might get more attention if Heiko was on the Cc list.
On Tue, Dec 2, 2014 at 8:49 AM, Mark Tomlinson
mark.tomlin...@alliedtelesis.co.nz wrote:
Due to an uninitialised variable, when muxes were deselected, any value
could be written to the mux control register. On the PCA9548, this could
result in multiple channels being selected, thus enabling multiple
pull-up resistors, and much bus capacitance.
The fix is simply to initialise the written value to zero.
Signed-off-by: Mark Tomlinson mark.tomlin...@alliedtelesis.co.nz
---
drivers/i2c/i2c_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
index d34b749..4539667 100644
--- a/drivers/i2c/i2c_core.c
+++ b/drivers/i2c/i2c_core.c
@@ -178,7 +178,7 @@ static int i2c_mux_disconnet_all(void)
{
struct i2c_bus_hose *i2c_bus_tmp = i2c_bus[I2C_BUS];
int i;
- uint8_t buf;
+ uint8_t buf = 0;
if (I2C_ADAP-init_done == 0)
return 0;
--
1.9.1
___
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 2/2] i2c: Correct spelling error
This one too.
On Tue, Dec 2, 2014 at 8:49 AM, Mark Tomlinson
mark.tomlin...@alliedtelesis.co.nz wrote:
diconnect and disconnet should both be disconnect.
Signed-off-by: Mark Tomlinson mark.tomlin...@alliedtelesis.co.nz
---
drivers/i2c/i2c_core.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/i2c_core.c b/drivers/i2c/i2c_core.c
index 4539667..41cc3b8 100644
--- a/drivers/i2c/i2c_core.c
+++ b/drivers/i2c/i2c_core.c
@@ -174,7 +174,7 @@ static int i2c_mux_set_all(void)
return 0;
}
-static int i2c_mux_disconnet_all(void)
+static int i2c_mux_disconnect_all(void)
{
struct i2c_bus_hose *i2c_bus_tmp = i2c_bus[I2C_BUS];
int i;
@@ -197,7 +197,7 @@ static int i2c_mux_disconnet_all(void)
ret = I2C_ADAP-write(I2C_ADAP, chip, 0, 0, buf, 1);
if (ret != 0) {
- printf(i2c: mux diconnect error\n);
+ printf(i2c: mux disconnect error\n);
return ret;
}
} while (i 0);
@@ -293,7 +293,7 @@ int i2c_set_bus_num(unsigned int bus)
}
#ifndef CONFIG_SYS_I2C_DIRECT_BUS
- i2c_mux_disconnet_all();
+ i2c_mux_disconnect_all();
#endif
gd-cur_i2c_bus = bus;
--
1.9.1
___
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 v4 5/9] kconfig: ls1021a: add SUPPORT_SPL
Hi, Yamada, On Wed, 3 Dec 2014 15:00:45 +0800 Alison Wang b18...@freescale.com wrote: Add SUPPORT_SPL feature for SD and NAND boot on LS1021AQDS and LS1021ATWR. Signed-off-by: Alison Wang alison.w...@freescale.com --- Change log: v4: New file. arch/arm/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 0982117..1f00e93 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -730,10 +730,12 @@ config TARGET_LS2085A_SIMU config TARGET_LS1021AQDS bool Support ls1021aqds_nor select CPU_V7 + select SUPPORT_SPL config TARGET_LS1021ATWR bool Support ls1021atwr_nor select CPU_V7 + select SUPPORT_SPL config TARGET_BALLOON3 bool Support balloon3 -- While you are here, could you fix the prompts too? ls1021aqds_nor implies NOR boot, but you are adding SD/NAND boot, right? [Alison Wang] Yes, I add SUPPORT_SPL is for SD/NAND boot. ls1021aqds_nor is not clear, I could change it to ls1021aqds. Best Regards, Alison Wang ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
