[U-Boot] [PATCH 9/9] [v3] rsa: Use checksum algorithms from struct hash_algo
Sorry. Resending as message bounced on uboot mailing list.
Hi Simon,
-Original Message-
From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
Sent: Wednesday, December 24, 2014 6:20 AM
To: Gupta Ruchika-R66431
Cc: U-Boot Mailing List; Sun York-R58495
Subject: Re: [PATCH 9/9] [v3] rsa: Use checksum algorithms from struct
hash_algo
Hi Ruchika,
On 23 December 2014 at 04:32, Ruchika Gupta ruchika.gu...@freescale.com
wrote:
Currently the hash functions used in RSA are called directly from the
sha1 and sha256 libraries. Change the RSA checksum library to use the
progressive hash API's registered with struct hash_algo. This will
allow the checksum library to use the hardware accelerated progressive hash
API's once available.
Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
CC: Simon Glass s...@chromium.org
---
Changes in v3:
Modified rsa-verify to check for return from checksum function
Changes in v2:
Added generic function hash_calculate. Pass an additional argument as
name of algorithm.
common/image-sig.c| 6 ++---
include/image.h | 5 ++--
include/u-boot/rsa-checksum.h | 7 +++---
lib/rsa/rsa-checksum.c| 53
+++
lib/rsa/rsa-verify.c | 7 +-
5 files changed, 64 insertions(+), 14 deletions(-)
diff --git a/common/image-sig.c b/common/image-sig.c index
8601eda..2c9f0cd 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -38,7 +38,7 @@ struct checksum_algo checksum_algos[] = { #if
IMAGE_ENABLE_SIGN
EVP_sha1,
#endif
- sha1_calculate,
+ hash_calculate,
padding_sha1_rsa2048,
},
{
@@ -48,7 +48,7 @@ struct checksum_algo checksum_algos[] = { #if
IMAGE_ENABLE_SIGN
EVP_sha256,
#endif
- sha256_calculate,
+ hash_calculate,
padding_sha256_rsa2048,
},
{
@@ -58,7 +58,7 @@ struct checksum_algo checksum_algos[] = { #if
IMAGE_ENABLE_SIGN
EVP_sha256,
#endif
- sha256_calculate,
+ hash_calculate,
padding_sha256_rsa4096,
}
diff --git a/include/image.h b/include/image.h index af30d60..ec55f23
100644
--- a/include/image.h
+++ b/include/image.h
@@ -926,8 +926,9 @@ struct checksum_algo { #if IMAGE_ENABLE_SIGN
const EVP_MD *(*calculate_sign)(void); #endif
- void (*calculate)(const struct image_region region[],
- int region_count, uint8_t *checksum);
+ int (*calculate)(const char *name,
+const struct image_region region[],
+int region_count, uint8_t *checksum);
const uint8_t *rsa_padding;
};
diff --git a/include/u-boot/rsa-checksum.h
b/include/u-boot/rsa-checksum.h index c996fb3..c546c80 100644
--- a/include/u-boot/rsa-checksum.h
+++ b/include/u-boot/rsa-checksum.h
@@ -16,9 +16,8 @@ extern const uint8_t padding_sha256_rsa4096[];
extern const uint8_t padding_sha256_rsa2048[]; extern const uint8_t
padding_sha1_rsa2048[];
-void sha256_calculate(const struct image_region region[], int
region_count,
- uint8_t *checksum);
-void sha1_calculate(const struct image_region region[], int region_count,
- uint8_t *checksum);
+int hash_calculate(const char *name,
+ const struct image_region region[], int region_count,
+ uint8_t *checksum);
This could use a function comment.
#endif
diff --git a/lib/rsa/rsa-checksum.c b/lib/rsa/rsa-checksum.c index
8d8b59f..7f1909a 100644
--- a/lib/rsa/rsa-checksum.c
+++ b/lib/rsa/rsa-checksum.c
@@ -10,12 +10,13 @@
#include asm/byteorder.h
#include asm/errno.h
#include asm/unaligned.h
+#include hash.h
#else
#include fdt_host.h
-#endif
-#include u-boot/rsa.h
#include u-boot/sha1.h
#include u-boot/sha256.h
+#endif
+#include u-boot/rsa.h
/* PKCS 1.5 paddings as described in the RSA PKCS#1 v2.1 standard. */
@@ -136,7 +137,33 @@ const uint8_t padding_sha256_rsa4096[RSA4096_BYTES -
SHA256_SUM_LEN] = {
0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20 };
-void sha1_calculate(const struct image_region region[], int
region_count,
+#ifndef USE_HOSTCC
+int hash_calculate(const char *name,
+ const struct image_region region[],
+ int region_count, uint8_t *checksum) {
+ struct hash_algo *algo;
+ int ret = 0;
+ void *ctx;
+ uint32_t i;
+ i = 0;
+
+ ret = hash_progressive_lookup_algo(name, algo);
+ if (ret)
+ return ret;
+
+ algo-hash_init(algo, ctx);
+ for (i = 0; i region_count - 1; i++)
+
[U-Boot] [PATCH v2] arc: introduce mdbtrick target
MetaWare debugger (MDB) is still used as a primary tool for interaction with target via JTAG. Moreover some very advanced features are not yet implemented in GDB for ARC (and not sure if they will be implemnted sometime soon given complexity and rare need for those features for common user). So if we're talking about development process when U-Boot is loaded in target memory not by low-level boot-loader but manually through JTAG chances are high developer uses MDB for it. But MDB doesn't support PIE (position-independent executable) - it will refuse to even start - that means no chance to load elf contents on target. Then the only way to load U-Boot in MDB is to fake it by: 1. Reset PIE flag in ELF header This is simpe - on attempt to open elf MDB checks header and if it doesn't match its expectation refuces to use provided elf. 2. Strip all debug information from elf If (1) is done then MDB will open elf but on parsing of elf's debug info it will refuse to process due to debug info it cannot understand (symbols with PIE relocation). Even though it could be done manually (I got it documented quite a while ago here http://www.denx.de/wiki/U-Boot/ARCNotes) having this automated way is very convenient. User may build U-Boot that will be loaded on target via MDB saying make mdbtrick. Then if we now apply the manipulation MDB will happily start and will load all required sections into the target. Indeed there will be no source-level debug info available. But still MDB will do its work on showing disassembly, global symbols, registers, accessing low-level debug facilities etc. As a summary - this is a pretty dirty hack but it simplifies life a lot for us ARc developers. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Tom Rini tr...@ti.com Cc: Wolfgang Denk w...@denx.de --- In v2 I only updated commit message with more info on why we do need this change --- arch/arc/Makefile | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arc/Makefile b/arch/arc/Makefile index de25cc9..03ea6db 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefile @@ -6,3 +6,18 @@ head-y := arch/arc/cpu/$(CPU)/start.o libs-y += arch/arc/cpu/$(CPU)/ libs-y += arch/arc/lib/ + +# MetaWare debugger doesn't support PIE (position-independent executable) +# so the only way to load U-Boot in MDB is to fake it by: +# 1. Reset PIE flag in ELF header +# 2. Strip all debug information from elf +ifdef CONFIG_SYS_LITTLE_ENDIAN + EXEC_TYPE_OFFSET=16 +else + EXEC_TYPE_OFFSET=17 +endif + +mdbtrick: u-boot + $(Q)printf '\x02' | dd of=u-boot bs=1 seek=$(EXEC_TYPE_OFFSET) count=1 \ + conv=notrunc /dev/null + $(Q)$(CROSS_COMPILE)strip -g u-boot -- 2.1.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] fw_readenv not working with uboot.env stored on FAT partition BAD CRC
Hello, i'm using a Raspberry Pi with u-boot. I'm building a stock RPI Kernel 3.12.y with buildroot. The u-boot version is 2015.01-rc3. U-Boot is working fine and when i call saveenv a file uboot.env is written to the first FAT Partition on the SD Card. But when i try to access the boot params with fw_readenv, i always get the BAD CRC error. I tried every possible configuration in fw_env.config, but it will not work. if first tried the obvious configuration /dev/mmcblk0p10x0x4000 does not work, then i tried to calculate the offset from /dev/mmcblk0: /dev/mmcblk0p10x100x4000 0x10 because startsecotor is 2048 * 512 byte = 1048576 = 0x10 in hex It will not work. I'm a little confused if this configuration makes sense at all, i thought, with the rpi config, fw_readenv will look for the file uboot.env in the given partition? My partion layout is as follows 243 heads, 62 sectors/track, 1022 cylinders, total 15407104 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0xee294a37 Device Boot Start End Blocks Id System /dev/sdf1 *2048 104447 51200e W95 FAT16 (LBA) /dev/sdf2 104448 411647 153600 83 Linux /dev/sdf3 411648 718847 153600 83 Linux /dev/sdf4 71884815407103 7344128 83 Linux Regards Christian Erhardt ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sunxi: gpio: Add support for gpio pins on the AXP209 pmic
On Sun, 2014-12-28 at 11:35 +0100, Hans de Goede wrote: Some boards use GPIO-s on the pmic, one example of this is the A13-OLinuXino board, which uses gpio0 of the axp209 for the lcd-power signal. This commit adds support for gpio pins on the AXP209 pmic, the sunxi_gpio.c changes are universal, adding gpio support for the other AXP pmics (when necessary) should be a matter of adding the necessary axp_gpio_foo functions to their resp. drivers, and add #define AXP_GPIO to their header file. Note this commit only adds support for the non device-model version of the gpio code, patches for adding support to the device-model version are very welcome. The string representation for these gpio-s is AXP0-#, the 0 in the AXP0 prefix is there in case we need to support gpio-s on more then 1 pmic in the future. At least A80 boards have 2 pmics, and we may end up needing to support gpio-s on both. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sunxi: video: Improve monitor video-mode option handling
On Sun, 2014-12-28 at 11:58 +0100, Hans de Goede wrote: Add a sunxi_monitor enum and parse the monitor option string into this enum once, rather then doing strcmp-s on it in various places. This also adds checking for it being a valid value. This also adds new none and lcd values in preparation for lcd support. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 07/17] sunxi: video: Modify sunxi_lcdc_pll_set to work with both tcon0 and tcon1
On Wed, 2014-12-24 at 20:06 +0100, Hans de Goede wrote: Modify sunxi_lcdc_pll_set to work with both tcon0 and tcon1, this is a preparation patch for adding lcd support. While at it also swap the divider search order, searching from low to high, as the comment above the code says we should do. In cases where there are multiple solutions this will result in picking a lower pll clock and divider, which is more stable and saves power. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 08/17] sunxi: video: Move sunxi_drc_init
On Thu, 2014-12-25 at 11:22 +0100, Hans de Goede wrote: Hi, On 25-12-14 10:08, Chen-Yu Tsai wrote: On Thu, Dec 25, 2014 at 3:06 AM, Hans de Goede hdego...@redhat.com wrote: Move sunxi_drc_init to directly above sunxi_engines_init, to avoid unnecessary Unfinished commit message? Sortof the next line read: #ifdef-ery in later patches. But git commit acted on the # and treated the line as a comment, Awesome! and I did not notice this until you pointed it out. I'll amend the commit message in my personal tree. That version: Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 09/17] sunxi: video: Add lcd output support
On Wed, 2014-12-24 at 20:06 +0100, Hans de Goede wrote:
+static void sunxi_lcdc_panel_enable(void)
+{
+ int pin;
+
+ /*
+ * Start with backlight disabled to avoid the screen flashing to
+ * white while the lcd inits.
+ */
+ pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_BL_EN);
+ if (pin != -1) {
+ gpio_request(pin, lcd_backlight_enable);
You request this and the backlight pwm again in backlight_enable. Are
such multiple requests OK?
+ gpio_direction_output(pin, 0);
+ }
+
+ pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_BL_PWM);
+ if (pin != -1) {
+ gpio_request(pin, lcd_backlight_pwm);
+ /* backlight pwm is inverted, set to 1 to disable backlight */
+ gpio_direction_output(pin, 1);
+ }
+
+ /* Give the backlight some time to turn off and power up the panel. */
+ mdelay(40);
+ pin = sunxi_name_to_gpio(CONFIG_VIDEO_LCD_POWER);
+ if (pin != -1) {
+ gpio_request(pin, lcd_power);
+ gpio_direction_output(pin, 1);
+ }
+}
+
+static void sunxi_lcdc_backlight_enable(void)
+{
+ int pin;
+
+ /*
+ * We want to have scanned out atleast one frame before enabling the
at least.
+ * backlight to avoid the screen flashing to white when we enable it.
+ */
+ mdelay(40);
I take it there isn't a vsync status bit or something we can watch for?
[...]
+ switch (sunxi_display.monitor) {
+ case sunxi_monitor_none:
+ return 0;
+ case sunxi_monitor_dvi:
+ case sunxi_monitor_hdmi:
+ pipeline = de_be0-lcd0-hdmi;
+ break;
+ case sunxi_monitor_lcd:
+ pipeline = de_be0-lcd0;
+ break;
+ case sunxi_monitor_vga:
+ break;
+ }
+
/* Find a framebuffer node, with pipeline == de_be0-lcd0-hdmi */
This comment is no longer accurate.
offset = fdt_node_offset_by_compatible(blob, -1,
allwinner,simple-framebuffer);
while (offset = 0) {
ret = fdt_find_string(blob, offset, allwinner,pipeline,
- de_be0-lcd0-hdmi);
+ pipeline);
if (ret == 0)
break;
offset = fdt_node_offset_by_compatible(blob, offset,
Ian.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 10/17] sunxi: video: Add suppport SoCs without HDMI, e.g. the A13 and A23
On Wed, 2014-12-24 at 20:06 +0100, Hans de Goede wrote: You've got three p's in suppport in the subject. Some SoCs, specifically the A13 (sun5i variant) and the A23 (sun8i) only have lcd output support. Signed-off-by: Hans de Goede hdego...@redhat.com --- board/sunxi/Kconfig | 7 +++ drivers/video/sunxi_display.c | 30 ++ 2 files changed, 33 insertions(+), 4 deletions(-) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 35c59e9..7a8503b 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -246,6 +246,13 @@ config VIDEO or VGA output found on most sunxi devices. See doc/README.video for info on how to select the video output and mode. +config VIDEO_HDMI + boolean HDMI output support + depends on VIDEO !MACH_SUN8I There is no !MACH_SUN5I here because there are sun5i variants other than the A13 which do have HDMI, correct? @@ -278,7 +282,7 @@ static void sunxi_composer_init(void) (struct sunxi_de_be_reg *)SUNXI_DE_BE0_BASE; int i; -#ifdef CONFIG_MACH_SUN6I +#if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I These seem a bit odd. If the sun8i has no HDMI why are we messing with the reset bits? (Or at least, why is such messing new in this particular patch). I think perhaps rather than disabling the non-existent HDMI on sun8i which is how I read the patch description I should have read enable video on sun8i, which supports LCD but not HDMI? Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/17] sunxi: video: Add support for VGA via external DACs connected to the LCD pins
On Wed, 2014-12-24 at 20:06 +0100, Hans de Goede wrote: Add support for external DACs connected to the parallel LCD interface driving a VGA connector, such as found on the Olimex A13 boards. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk --- board/sunxi/Kconfig | 9 + drivers/video/sunxi_display.c | 14 ++ 2 files changed, 23 insertions(+) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 7a8503b..3e42866 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -253,6 +253,15 @@ config VIDEO_HDMI ---help--- Say Y here to add support for outputting video over HDMI. +config VIDEO_VGA_VIA_LCD + boolean VGA via LCD controller support + depends on VIDEO + default n + ---help--- + Say Y here to add support for external DACs connected to the parallel + LCD interface driving a VGA connector, such as found on the + Olimex A13 boards. But not unique to those boards I take it? I'd be inclined to drop everything from the , to the end of the sentence. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 12/17] sunxi: sunxi-common.h: Reduce bootm_size to take the framebuffer into account
On Wed, 2014-12-24 at 20:06 +0100, Hans de Goede wrote: Before video output support can be enabled on the A13-OLinuXinoM, bootm_size must first be reduced to take into account that the framebuffer is shaved of the top of the DRAM. For other boards this is not an issue since bootm was set to 256M and all boards have at least 512M except for the A13-OLinuXinoM. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 13/17] sunxi: A13-OLinuXino defconfigs: Enable VGA output, add lcd-mode for 7 LCD
On Wed, 2014-12-24 at 20:06 +0100, Hans de Goede wrote: Enable VGA output on the A13-OLinuXino and A13-OLinuXinoM now that we've support for it. Also add LCD timing and gpio info for the Olimex 7 LCD module. We can safely put this in the default config on this boards, since by default we will always use VGA, and the LCD timing info will only get used if the user explicitly sets monitor=lcd in the video-mode env. variable. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/17] sunxi: Add 2 defconfigs for using the Olimex 7 lcd with olinuxino boards
On Wed, 2014-12-24 at 20:06 +0100, Hans de Goede wrote: Add defconfigs for using the Olimex 7 lcd with the A10s-OLinuXino-M and the A20-OLinuXino_MICRO boards. Note this cannot be added to the regular defconfigs, like with the A13 boards, because the video code will automatically fallback to driving the LCD if no HDMI cable is connected (this is the desired behavior on e.g. tablets), but the LCD connector on the Olimex dev boards may be used for something completely different, so we do not want to automatically enable it. Note I do not intend to add defconfigs for all possible permutation of Olimex boards and LCD displays, these 2 serve mostly as examples. Does the A13 one not serve that function already without the downside of duplicating up the defconfig? In the long run this should be solved by moving all the LCD info into dts files and using devicetree overlays for add-on modules like the LCD displays. Signed-off-by: Hans de Goede hdego...@redhat.com --- configs/A10s-OLinuXino-M-lcd7_defconfig| 14 ++ configs/A20-OLinuXino_MICRO-lcd7_defconfig | 13 + 2 files changed, 27 insertions(+) create mode 100644 configs/A10s-OLinuXino-M-lcd7_defconfig create mode 100644 configs/A20-OLinuXino_MICRO-lcd7_defconfig diff --git a/configs/A10s-OLinuXino-M-lcd7_defconfig b/configs/A10s-OLinuXino-M-lcd7_defconfig new file mode 100644 index 000..eafa974 --- /dev/null +++ b/configs/A10s-OLinuXino-M-lcd7_defconfig @@ -0,0 +1,14 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=AXP152_POWER,SUNXI_EMAC,USB_EHCI +CONFIG_FDTFILE=sun5i-a10s-olinuxino-micro.dtb +CONFIG_MMC_SUNXI_SLOT_EXTRA=1 +CONFIG_USB1_VBUS_PIN=PB10 +CONFIG_VIDEO_LCD_MODE=x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:0,vmode:0 +CONFIG_VIDEO_LCD_POWER=PB9 +CONFIG_VIDEO_LCD_BL_PWM=PB2 ++S:CONFIG_MMC0_CD_PIN=PG1 ++S:CONFIG_MMC1_CD_PIN=PG13 ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN5I=y ++S:CONFIG_TARGET_A10S_OLINUXINO_M=y diff --git a/configs/A20-OLinuXino_MICRO-lcd7_defconfig b/configs/A20-OLinuXino_MICRO-lcd7_defconfig new file mode 100644 index 000..05674d7 --- /dev/null +++ b/configs/A20-OLinuXino_MICRO-lcd7_defconfig @@ -0,0 +1,13 @@ +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS=AXP209_POWER,SUNXI_GMAC,AHCI,SATAPWR=SUNXI_GPB(8),USB_EHCI +CONFIG_FDTFILE=sun7i-a20-olinuxino-micro.dtb +CONFIG_MMC_SUNXI_SLOT_EXTRA=3 +CONFIG_VIDEO_LCD_MODE=x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:0,vmode:0 +CONFIG_VIDEO_LCD_POWER=PH8 +CONFIG_VIDEO_LCD_BL_PWM=PB2 ++S:CONFIG_MMC0_CD_PIN=PH1 ++S:CONFIG_MMC3_CD_PIN=PH11 ++S:CONFIG_ARM=y ++S:CONFIG_ARCH_SUNXI=y ++S:CONFIG_MACH_SUN7I=y ++S:CONFIG_TARGET_A20_OLINUXINO_M=y ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/17] sunxi: Ippo_q8h defconfigs: Enable the LCD panel found on these tablets.
On Fri, 2014-12-26 at 14:44 +0800, Chen-Yu Tsai wrote: So if I'm not mistaken for the Ippo_q8h_v5 the timings should be: CONFIG_VIDEO_LCD_MODE=x:800,y:480,depth:18,pclk_khz:33000,le:87,ri:168,up:31,lo:13,hs:1,vs:1,sync:0,vmode:0 The new values look better. Thanks. I've not seen a v2 of this patch, but assuming a patch with these new values were to be posted I would say: Acked-by: Ian Campbell i...@hellion.org.uk I think we should add your Tested-by too. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 16/17] sunxi: video: Remove sunxi_display.enabled variable
On Wed, 2014-12-24 at 20:06 +0100, Hans de Goede wrote: Having both a sunxi_display.enabled variable and sunxi_display.monitor == sunxi_monitor_none duplicates state, use sunxi_display.monitor = sunxi_monitor_none when ever we do not have a display. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 17/17] sunxi: video: Use sunxi_lcdc_get_clk_delay to calculate tcon1 delay
On Wed, 2014-12-24 at 20:06 +0100, Hans de Goede wrote: Use sunxi_lcdc_get_clk_delay to calculate tcon1 delay instead of hardcoding it to 30. We will still end up using 30 for most modes, but for e.g. 800x600 this makes a (small) difference. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] sunxi: video: Add a hpd_delay parameter to configure hpd delay
On Sun, 2014-12-28 at 17:08 +0100, Hans de Goede wrote: In some extreme cases it may be necessary to wait 1.5 seconds or more for a hpd signal to show up (and be able to read edid info), but we do not want to penalize all headless boots with an extra second boot delay, so add a hpd_delay parameter which can be set through the video-mode env. variable. While at it raise the default from 300ms to 500ms as 300 may very well be too low in many cases. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sunxi: clock_sun6i: Remove magic m and k params from clock_set_pll5
On Sun, 2014-12-28 at 17:08 +0100, Hans de Goede wrote: Let clock_set_pll5 pick the optimal m and k values itself based on the requested rate, rather then passing them in as magic constants. Suggested-by: Siarhei Siamashka siarhei.siamas...@gmail.com Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk If it's not too disruptive given the original patch adding those params is still in #next you could fold it in, but if that causes rebasing hell I'#m fine with leaving it as an incremental fix. Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] coreboot uboot qemu x86
Hi, On 28 December 2014 at 21:38, Ajoy Das dasajo...@gmail.com wrote: Hi Need Help I want to run U-BOOT as coreboot payload on QEMU platform I am on uboot-x86 git Compiled U-BOOT with make coreboot-x86_defconfig and make all Running qemu with qemu-system-i386 -bios ../coreboot/build/coreboot.rom -hda disk.img -nographic -m 1g But The system crashes with the following message qemu: fatal: Trying to execute code outside RAM or ROM at 0x5e2a36c2 Loading Segment: addr: 0x0111 memsz: 0x000588e8 filesz: 0x000252eb lb: [0x0010, 0x0012b030) Post relocation: addr: 0x0111 memsz: 0x000588e8 filesz: 0x000252eb using LZMA [ 0x0111, 011688e8, 0x011688e8) - fffd2770 dest 0111, end 011688e8, bouncebuffer 3ff77000 Loaded segments Jumping to boot code at 01110015 CPU0: stack: 00126000 - 00127000, lowest used address 00126b8c, stack used: 1140 bytes entry= 0x01110015 lb_start = 0x0010 lb_size = 0x0002b030 buffer = 0x3ff77000 qemu: fatal: Trying to execute code outside RAM or ROM at 0x5e2a36c2 EAX=000a EBX=000186a0 ECX=01145d15 EDX=19203eb0 ESI= EDI= EBP=01145f6c ESP=01145f54 EIP=5e2a36c2 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0018 00cf9300 DPL=0 DS [-WA] CS =0010 00cf9b00 DPL=0 CS32 [-RA] SS =0018 00cf9300 DPL=0 DS [-WA] DS =0018 00cf9300 DPL=0 DS [-WA] FS =0020 19203f5c 00cf9300 DPL=0 DS [-WA] GS =0018 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 19203e60 0047 IDT= CR0=6033 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 CCS=0218 CCD=01145f50 CCO=ADDL EFER= FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= Aborted (core dumped) qemu-system-i386 --version QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard Is QEMU not supported for coreboot and u-boot I'm not sure it's been tried but there's no reason why it should work. It seems to be crashing in U-Boot before there is any serial output. Did you put u-boot-dtb.bin as the payload? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] sun7i: Add support for taking CPUs offline via PSCI
On Mon, 2014-12-15 at 12:37 +0100, Jan Kiszka wrote: + movwr8, #(GICC_BASE 0x) + movtr8, #(GICC_BASE 16) + ldr r9, [r8, #GICC_IAR] + movwr10, #0x3ff + movtr10, #0 + cmp r9, r10 + beq out + movwr10, #0x3fe + cmp r9, r10 + beq out + str r9, [r8, #GICC_EOIR] + dsb This block could do with a leading comment like the others. It is reading IAR and discarding any spurious interrupts (1022+1023), but not explicitly checking for SGI15, presumably because it can be asserted that there is no other possible interrupt which can end up here, is that right? + +.globl psci_cpu_off +psci_cpu_off: + mrc p15, 0, r0, c1, c0, 0 @ SCTLR + bic r0, r0, #(1 2) @ Clear C bit + mcr p15, 0, r0, c1, c0, 0 @ SCTLR + isb + dsb + + bl v7_flush_dcache_all + + clrex @ Why??? Anyone got any clues? (Just curiosity, not a blocker) Apart from the comment: Acked-by: Ian Campbell i...@hellion.org.uk Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] sun7i: Add PSCI v0.2 support
On Mon, 2014-12-15 at 12:37 +0100, Jan Kiszka wrote: This extends the PSCI support for the A20 to a dual v0.2 and v0.1 interface. Recent OSes will prefer v0.2, olders will still find the original interface, just at v0.2 service IDs. In addition to the existing services, v0.2 requires us to implement both system off and reset. At least Linux will make use of them in favor of its own implementations and, thus, fail if they do not work. What functionality does v0.2 give us over v0.1 that you are aiming to expose here? Ian. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4] sunxi: video: Fix tcon0 hsync / vsync setting
On Sat, 2014-12-27 at 16:53 +0100, Hans de Goede wrote: It turns out that the problems I was seeing were due to a bad powersupply, so enable proper negative hsync / vsync support. Also adjust various defconfigs to keep the hsync and vsync for the lcd panels positive, changing sync:0 into sync:3. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] vexpress64: switch to generic board
Hi Linus. On 23 December 2014 at 18:02, Linus Walleij linus.wall...@linaro.org wrote: The few Versatile Express ARMv8 platforms we have may just as well be switched to generic board from the beginning. Tested on the ARM foundation model and the in progress support for the ARMv8 Juno board. Signed-off-by: Linus Walleij linus.wall...@linaro.org --- include/configs/vexpress_aemv8a.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index f3af971214a5..027d78b59171 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -8,6 +8,9 @@ #ifndef __VEXPRESS_AEMV8A_H #define __VEXPRESS_AEMV8A_H +/* We use generic board for v8 Versatile Express */ +#define CONFIG_SYS_GENERIC_BOARD + #ifdef CONFIG_BASE_FVP #ifndef CONFIG_SEMIHOSTING #error CONFIG_BASE_FVP requires CONFIG_SEMIHOSTING @@ -25,8 +28,6 @@ /*#define CONFIG_ARMV8_SWITCH_TO_EL1*/ -/*#define CONFIG_SYS_GENERIC_BOARD*/ - #define CONFIG_SYS_NO_FLASH #define CONFIG_SUPPORT_RAW_INITRD Also it would be good to switch to driver model as we should not be adding new boards that don't support it. The PL011 serial driver supports driver model so it should be pretty simple. Here is the Raspberry Pi conversion as an example as i uses the same UART (you only need to look at the CONFIG changes in he GPIO commit) 1150666 dm: rpi: Move serial to driver model 41e98e0 dm: rpi: Convert GPIO driver to driver model Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4] sunxi: video: Add support for using PORTD hsync/vsync pins with tcon1
On Sat, 2014-12-27 at 16:53 +0100, Hans de Goede wrote: Add support for using PORTD hsync/vsync pins with tcon1, this is a preparation patch for adding native VGA support. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] sunxi: video: Fallback from HDMI to VGA on boards with VGA
On Sat, 2014-12-27 at 18:02 +0100, Hans de Goede wrote: If a board has no LCD, but does have VGA fallback to VGA when no HDMI cable is connected (unless hpd=0). Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] sunxi: video: Add VGA output support
On Sat, 2014-12-27 at 16:53 +0100, Hans de Goede wrote:
diff --git a/arch/arm/include/asm/arch-sunxi/display.h
b/arch/arm/include/asm/arch-sunxi/display.h
index 908c5d9..8c25ad4 100644
--- a/arch/arm/include/asm/arch-sunxi/display.h
+++ b/arch/arm/include/asm/arch-sunxi/display.h
@@ -158,6 +158,52 @@ struct sunxi_hdmi_reg {
};
/*
+ * This is based on the A10s User Manual, and the A10s only supports
+ * composite video and not vga like the A10 / A20 does, still other
+ * then the removed vga out capability the tvencoder seems to be the same.
You mean other than I think.
Other than (sorry ;-)) that:
Acked-by: Ian Campbell i...@hellion.org.uk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] coreboot uboot qemu x86
Hi Simon Thanks for your reply I have added u-boot ELF as the coreboot payload u-boot: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), statically linked, not stripped. Got this link but its a year old. http://lists.denx.de/pipermail/u-boot/2013-July/159140.html Thanks Ajoy On Mon, Dec 29, 2014 at 7:36 PM, Simon Glass s...@chromium.org wrote: Hi, On 28 December 2014 at 21:38, Ajoy Das dasajo...@gmail.com wrote: Hi Need Help I want to run U-BOOT as coreboot payload on QEMU platform I am on uboot-x86 git Compiled U-BOOT with make coreboot-x86_defconfig and make all Running qemu with qemu-system-i386 -bios ../coreboot/build/coreboot.rom -hda disk.img -nographic -m 1g But The system crashes with the following message qemu: fatal: Trying to execute code outside RAM or ROM at 0x5e2a36c2 Loading Segment: addr: 0x0111 memsz: 0x000588e8 filesz: 0x000252eb lb: [0x0010, 0x0012b030) Post relocation: addr: 0x0111 memsz: 0x000588e8 filesz: 0x000252eb using LZMA [ 0x0111, 011688e8, 0x011688e8) - fffd2770 dest 0111, end 011688e8, bouncebuffer 3ff77000 Loaded segments Jumping to boot code at 01110015 CPU0: stack: 00126000 - 00127000, lowest used address 00126b8c, stack used: 1140 bytes entry= 0x01110015 lb_start = 0x0010 lb_size = 0x0002b030 buffer = 0x3ff77000 qemu: fatal: Trying to execute code outside RAM or ROM at 0x5e2a36c2 EAX=000a EBX=000186a0 ECX=01145d15 EDX=19203eb0 ESI= EDI= EBP=01145f6c ESP=01145f54 EIP=5e2a36c2 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0018 00cf9300 DPL=0 DS [-WA] CS =0010 00cf9b00 DPL=0 CS32 [-RA] SS =0018 00cf9300 DPL=0 DS [-WA] DS =0018 00cf9300 DPL=0 DS [-WA] FS =0020 19203f5c 00cf9300 DPL=0 DS [-WA] GS =0018 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 19203e60 0047 IDT= CR0=6033 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 CCS=0218 CCD=01145f50 CCO=ADDL EFER= FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= Aborted (core dumped) qemu-system-i386 --version QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard Is QEMU not supported for coreboot and u-boot I'm not sure it's been tried but there's no reason why it should work. It seems to be crashing in U-Boot before there is any serial output. Did you put u-boot-dtb.bin as the payload? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Issue with uboot on imx6slevk
Hi,
I would like to use Buildroot to generate a linux for imx6 sololitevk.
I found an existing configuration done for this board in the master
branch of Buildroot.
To generate my image :
make freescale_imx6sololiteevk_defconfig
make all
Then I used this script in
board/freescale/imx6sabresd/create-boot-sd.sh to generate an sd card
by typing :
sudo ./create-boot-sd.sh /dev/mmcblk0
When I tried to run my sdcard on the board current result is :
___
reading uImage
5258568 bytes read in 267 ms (18.8 MiB/s)
Booting from mmc ...
reading imx6sl-evk.dtb
33925 bytes read in 18 ms (1.8 MiB/s)
## Booting kernel from Legacy Image at 8080 ...
Image Name: Linux-3.10.17
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:5258504 Bytes = 5 MiB
Load Address: 10008000
Entry Point: 10008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 8300
Booting using the fdt blob at 0x8300
Loading Kernel Image ... data abort
MAYBE you should read doc/README.arm-unaligned-accesses
pc : [bff939d8] lr : [bff70ee8]
sp : bfc6b9d0 ip : fp :
r10: 80d03d48 r9 : r8 : bfc6bf38
r7 : 8080 r6 : r5 : bfc6ba14 r4 : 10008000
r3 : r2 : 00503d08 r1 : 80800040 r0 : 10008000
Flags: Nzcv IRQs off FIQs off Mode SVC_32
Resetting CPU ...
resetting ...
U-Boot 2013.04 (Dec 24 2014 - 14:30:31)
___
Is it normal ? Do I wrong somewhere in my process ?
Do I must add a patch on uboot to fix that ?
I see some stuff like this for example :
https://gitorious.org/rowboat/u-boot/commit/7894b625259b89cd117685a0855a2c84b11a38f5
Current printenv :
= printenv
baudrate=115200
boot_fdt=try
bootargs=console=ttymxc0,115200 root=/dev/nfs ip=dhcp nfsroot=:,v3,tcp
bootcmd=mmc dev ${mmcdev};mmc dev ${mmcdev}; if mmc rescan; then if
run loadbootscript; then run bootscript; else if run loaduimage; then
run mmcboot; else rui
bootcmd_mfg=run mfgtool_args;bootm ${loadaddr} ${initrd_addr} ${fdt_addr};
bootdelay=3
bootscript=echo Running bootscript from mmc ...; source
console=ttymxc0
ethact=FEC
ethaddr=00:04:9f:03:59:a4
ethprime=FEC
fdt_addr=0x8300
fdt_file=imx6sl-evk.dtb
fdt_high=0x
get_cmd=dhcp
initrd_addr=0x8380
initrd_high=0x
ip_dyn=yes
loadaddr=0x8080
loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};
loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}
loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}
mfgtool_args=setenv bootargs console=${console},${baudrate}
rdinit=/linuxrc g_mass_storage.stall=0 g_mass_storage.removable=1
g_mass_storage.idVendor=0x066F g
mmcargs=setenv bootargs console=${console},${baudrate} root=${mmcroot}
mmcboot=echo Booting from mmc ...; run mmcargs; if test ${boot_fdt} =
yes || test ${boot_fdt} = try; then if run loadfdt; then bootm
${loadaddr} - ${fdt_addr};
mmcdev=1
mmcpart=1
mmcroot=/dev/mmcblk0p2 rootwait rw
netargs=setenv bootargs console=${console},${baudrate} root=/dev/nfs
ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp
netboot=echo Booting from net ...; run netargs; if test ${ip_dyn} =
yes; then setenv get_cmd dhcp; else setenv get_cmd tftp; fi;
${get_cmd} ${uimage}; if test;
script=boot.scr
stderr=serial
stdin=serial
stdout=serial
uimage=uImage
Thanks Regards,
Arthur
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm: fix exception vectors
After relocation, exception vectors still point to the old code (not relocated). This patch fixes them. Signed-off-by: Luca Ellero luca.ell...@brickedbrain.com --- arch/arm/lib/relocate.S | 15 +++ 1 file changed, 15 insertions(+) diff --git a/arch/arm/lib/relocate.S b/arch/arm/lib/relocate.S index 92f5314..4186344 100644 --- a/arch/arm/lib/relocate.S +++ b/arch/arm/lib/relocate.S @@ -76,6 +76,21 @@ copy_loop: blo copy_loop /* +* fix exception vectors +*/ + ldr r2, =_undefined_instruction + ldr r3, =_fiq + add r2, r2, r4 + add r3, r3, r4 +fix_exceptions: + ldr r0, [r2] + add r0, r0, r4 + str r0, [r2] + cmp r2,r3 + add r2, #4 + blo fix_exceptions + + /* * fix .rel.dyn relocations */ ldr r2, =__rel_dyn_start/* r2 - SRC __rel_dyn_start */ -- 1.7.10.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with uboot on imx6slevk
On Mon, Dec 29, 2014 at 11:55 AM, Arthur Lambert lambertarthu...@gmail.com wrote: Hi, I would like to use Buildroot to generate a linux for imx6 sololitevk. I found an existing configuration done for this board in the master branch of Buildroot. It seems that posting to the buildroot list would be more appropriate in your case. resetting ... U-Boot 2013.04 (Dec 24 2014 - 14:30:31) Please use U-boot 2014.10 or 2015.01-rc3 instead. If you have issues, then you can post here again ;-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/17] sunxi: Ippo_q8h defconfigs: Enable the LCD panel found on these tablets.
On Mon, Dec 29, 2014 at 9:57 PM, Ian Campbell i...@hellion.org.uk wrote: On Fri, 2014-12-26 at 14:44 +0800, Chen-Yu Tsai wrote: So if I'm not mistaken for the Ippo_q8h_v5 the timings should be: CONFIG_VIDEO_LCD_MODE=x:800,y:480,depth:18,pclk_khz:33000,le:87,ri:168,up:31,lo:13,hs:1,vs:1,sync:0,vmode:0 The new values look better. Thanks. I've not seen a v2 of this patch, but assuming a patch with these new values were to be posted I would say: Acked-by: Ian Campbell i...@hellion.org.uk I think we should add your Tested-by too. Tested-by: Chen-Yu Tsai w...@csie.org for the new values. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] coreboot uboot qemu x86
Hi Ajoy, On 29 December 2014 at 07:34, Ajoy Das dasajo...@gmail.com wrote: Hi Simon Thanks for your reply I have added u-boot ELF as the coreboot payload u-boot: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), statically linked, not stripped. Got this link but its a year old. http://lists.denx.de/pipermail/u-boot/2013-July/159140.html Thanks Ajoy Please avoid top posting as it doesn't work well on mailing lists. I suggest using cbfstool add-flat-binary -f u-boot-dtb.bin -n fallback/payload -c lzma -l text_base -e entry For text_base use CONFIG_SYS_TEXT_BASE which is probably 111 For entry use _start which is probably 1110015. Of course I'm not sure whether your problem is with Coreboot, U-Boot or qemu, but we'll see. Also, please can you reply to the list with instructions when you get it working, or send a patch to doc/README.x86. Regards, Simon On Mon, Dec 29, 2014 at 7:36 PM, Simon Glass s...@chromium.org wrote: Hi, On 28 December 2014 at 21:38, Ajoy Das dasajo...@gmail.com wrote: Hi Need Help I want to run U-BOOT as coreboot payload on QEMU platform I am on uboot-x86 git Compiled U-BOOT with make coreboot-x86_defconfig and make all Running qemu with qemu-system-i386 -bios ../coreboot/build/coreboot.rom -hda disk.img -nographic -m 1g But The system crashes with the following message qemu: fatal: Trying to execute code outside RAM or ROM at 0x5e2a36c2 Loading Segment: addr: 0x0111 memsz: 0x000588e8 filesz: 0x000252eb lb: [0x0010, 0x0012b030) Post relocation: addr: 0x0111 memsz: 0x000588e8 filesz: 0x000252eb using LZMA [ 0x0111, 011688e8, 0x011688e8) - fffd2770 dest 0111, end 011688e8, bouncebuffer 3ff77000 Loaded segments Jumping to boot code at 01110015 CPU0: stack: 00126000 - 00127000, lowest used address 00126b8c, stack used: 1140 bytes entry= 0x01110015 lb_start = 0x0010 lb_size = 0x0002b030 buffer = 0x3ff77000 qemu: fatal: Trying to execute code outside RAM or ROM at 0x5e2a36c2 EAX=000a EBX=000186a0 ECX=01145d15 EDX=19203eb0 ESI= EDI= EBP=01145f6c ESP=01145f54 EIP=5e2a36c2 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0018 00cf9300 DPL=0 DS [-WA] CS =0010 00cf9b00 DPL=0 CS32 [-RA] SS =0018 00cf9300 DPL=0 DS [-WA] DS =0018 00cf9300 DPL=0 DS [-WA] FS =0020 19203f5c 00cf9300 DPL=0 DS [-WA] GS =0018 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 19203e60 0047 IDT= CR0=6033 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 CCS=0218 CCD=01145f50 CCO=ADDL EFER= FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= Aborted (core dumped) qemu-system-i386 --version QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard Is QEMU not supported for coreboot and u-boot I'm not sure it's been tried but there's no reason why it should work. It seems to be crashing in U-Boot before there is any serial output. Did you put u-boot-dtb.bin as the payload? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 5/7] serial: ns16550: Support ns16550 compatible pci uart devices
Hi Bin,
On 28 December 2014 at 23:15, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Sun, Dec 28, 2014 at 9:55 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 27 December 2014 at 05:10, Bin Meng bmeng...@gmail.com wrote:
There are many pci uart devices which are ns16550 compatible. We can
describe them in the board dts file and use it as the U-Boot serial
console as specified in the chosen node 'stdout-path' property.
Those pci uart devices can have their register be memory mapped, or
memory-mapped
i/o mapped. The driver will try to use memory mapped register if the
i/o-mapped
s/memory mapped/the memory-mapped/
reg property in the node has an entry to describe the memory mapped
memory-mapped
register, otherwise i/o mapped register will be used.
i/o-mapped
Signed-off-by: Bin Meng bmeng...@gmail.com
---
Changes in v2:
- New patch to support ns16550 compatible pci uart devices
drivers/serial/ns16550.c | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index af5beba..2001fac 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -289,10 +289,41 @@ int ns16550_serial_ofdata_to_platdata(struct udevice
*dev)
struct ns16550_platdata *plat = dev-platdata;
fdt_addr_t addr;
+ /* try plb device first */
What is plb?
I mean Processor Local Bus, a concept I believe is popular in the
embedded powerpc world, but I realized it might not be that popuar to
other architectures. Maybe I could just remove it.
Seems fine, but might want to write it out in full.
addr = fdtdec_get_addr(gd-fdt_blob, dev-of_offset, reg);
- if (addr == FDT_ADDR_T_NONE)
+ if (addr == FDT_ADDR_T_NONE) {
+#ifdef CONFIG_PCI
+ /* then try pci device */
+ struct fdt_pci_addr pci_addr;
+ u32 bar;
+ int ret;
+
+ /* we prefer to use memory mapped register */
a memory-mapped
+ ret = fdtdec_get_pci_addr(gd-fdt_blob, dev-of_offset,
+ FDT_PCI_SPACE_MEM32, reg,
+ pci_addr);
+ if (ret) {
+ /* try if there is any io mapped register */
+ ret = fdtdec_get_pci_addr(gd-fdt_blob,
+ dev-of_offset,
+ FDT_PCI_SPACE_IO,
+ reg, pci_addr);
+ if (ret)
+ return ret;
+ }
+
+ ret = fdtdec_get_pci_bar32(gd-fdt_blob, dev-of_offset,
+ pci_addr, bar);
+ if (ret)
+ return ret;
+
+ addr = bar;
+ goto cont;
+#endif
return -EINVAL;
+ }
Instead of the above 4 lines, move the #ifdef CONFIG_PCI up one line, then
here:
}
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
This avoids the goto.
Yep, this is better. Will fix it.
+cont:
plat-base = addr;
plat-reg_shift = fdtdec_get_int(gd-fdt_blob, dev-of_offset,
reg-shift, 1);
--
1.8.2.1
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/9] sunxi: Move SPL s_init() code to board_init_f()
Hi Ian,
On 28 December 2014 at 02:19, Ian Campbell i...@hellion.org.uk wrote:
On Tue, 2014-12-23 at 12:04 -0700, Simon Glass wrote:
+void board_init_f(ulong dummy)
+{
[...]
+ /* Clear the BSS. */
+ memset(__bss_start, 0, __bss_end - __bss_start);
+
+ board_init_r(NULL, 0);
The previous (__weak) version of board_init_f also sets gd, which you've
also removed from s_init here and not added back anywhere (indeed, this
is the point...). But where is gd initialised now?
It's still in start.S, I've just removed this duplicate.
The patch generally looks good, two quick questions: has it been tested
in both FEL and regular mode, and has it been tested with a legacy as
well as a driver model system? (I might be able to find time in a day or
two to answer these myself, but for now I'll just ask).
I haven't tried FEL, I only just heard of it in your email. I'll see
if I can figure out how to test that.
I don't think this patch affects any drivers, but I can test that too.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] L2 cache and LCD on sunxi
Hi Hans, On 24 December 2014 at 09:47, Hans de Goede hdego...@redhat.com wrote: Hi, On 23-12-14 05:36, Simon Glass wrote: Hi Hans, On 22 December 2014 at 09:45, Hans de Goede hdego...@redhat.com wrote: Hi, On 21-12-14 19:52, Simon Glass wrote: Hi, I ran up a banana PI and noticed that HDMI works in U-Boot. Great! Scrolling seems very slow though - is the L2 cache disabled perhaps? I don't think so, but it could be, I think the scrolling code is just very inefficient. Feel free to poke things a bit around this, ARM cache management is not my forte. I think it need ssomething like the code in exynos/soc.c - see v7_outer_cache_enable(). Even with the 7 inch it's very slow. I've run some tests, and it is not slower then on say the A10 (cortex A8), also I've been unable to find any docs or allwinner code pointing to allwinner specific l2 cache init. As such ATM I do not believe that we've the l2 cache disabled. Yes the code is not super-efficient (and could use the arch-specific memcpy()) but I'm mostly interested in whether the platform is running at full speed. I'm comparing it to say an Exynos 5250 which is 1.7GHz Cortex-A15. Without the L2 cache it scrolls quite slowly but with it it is fast. There is probably some cache setup required. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/9] arm: Add warnings about using gdata
Hi Igor, On 23 December 2014 at 23:53, Igor Grinberg grinb...@compulab.co.il wrote: Hi Simon, On 12/23/14 21:04, Simon Glass wrote: We need to get rid of this SPL-specific setting of the global_data pointer. It is already set up in start.S immediately before board_init_f() is called, and there may be information there that is needed (e.g. pre-reloc malloc info). Signed-off-by: Simon Glass s...@chromium.org --- arch/arm/lib/spl.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm/lib/spl.c b/arch/arm/lib/spl.c index dfcc596..c41850a 100644 --- a/arch/arm/lib/spl.c +++ b/arch/arm/lib/spl.c @@ -15,6 +15,11 @@ /* Pointer to as well as the global data structure for SPL */ DECLARE_GLOBAL_DATA_PTR; + +/* + * WARNING: This is going away very soon. Don't use it and don't submit + * pafches that rely on it. The global_data area is set up in crt0.S. + */ gd_t gdata __attribute__ ((section(.data))); /* @@ -28,7 +33,7 @@ void __weak board_init_f(ulong dummy) /* Clear the BSS. */ memset(__bss_start, 0, __bss_end - __bss_start); - /* Set global data pointer. */ + /* TODO: Remove settings of the global data pointer here */ Why do you need this patch at all if you remove this stuff in 9/9? I imagine that 9/9 might take some time to be applied, since it needs testing, so I've put that in as a clean-up patch. gd = gdata; board_init_r(NULL, 0); Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] x86: ahci: Make sure interface is not busy after enabling the port
Hi Bin,
On 23 December 2014 at 18:42, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Wed, Dec 24, 2014 at 3:42 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 23 December 2014 at 01:01, Bin Meng bmeng...@gmail.com wrote:
Each time U-Boot boots on Intel Crown Bay board, the displayed hard
drive information is wrong. It could be either wrong capacity or just
a 'Capacity: not available' message. After enabling the debug switch,
we can see the scsi inquiry command did not execute successfully.
However, doing a 'scsi scan' in the U-Boot shell does not expose
this issue.
This sounds like an error condition is not being propagated.
Actually an error condition not checked.
SCSI: Target spinup took 0 ms.
SATA link 1 timeout.
AHCI 0001.0100 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
scanning bus for devices...
ahci_device_data_io: 0 byte transferred. --- scsi inquiry fails
ahci_device_data_io: 512 byte transferred.
ahci_device_data_io: 512 byte transferred.
ahci_device_data_io: 512 byte transferred.
Device 0: (0:0) Vendor: ATA Prod.: Rev: ?8
Type: Hard Disk
Capacity: 912968.3 MB = 891.5 GB (1869759264 x
512)
Found 1 device(s).
So uninitialized contents on the stack were passed to dev_print() to
display those wrong information.
The symptom were observed on two hard drives (one is Seagate, the
other one is Western Digital). The fix is to make sure the AHCI
interface is not busy by checking the error and status information
from task file register after enabling the port in ahci_port_start()
before proceeding other operations like scsi_scan().
Signed-off-by: Bin Meng bmeng...@gmail.com
---
drivers/block/ahci.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index c9a3beb..7ca8f40 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -505,8 +505,9 @@ static int ahci_port_start(u8 port)
{
struct ahci_ioports *pp = (probe_ent-port[port]);
volatile u8 *port_mmio = (volatile u8 *)pp-port_mmio;
- u32 port_status;
+ u32 port_status, tf_data;
u32 mem;
+ int i = 0;
debug(Enter start port: %d\n, port);
port_status = readl(port_mmio + PORT_SCR_STAT);
@@ -564,6 +565,18 @@ static int ahci_port_start(u8 port)
PORT_CMD_POWER_ON | PORT_CMD_SPIN_UP |
PORT_CMD_START, port_mmio + PORT_CMD);
+ /*
+* Make sure interface is not busy based on error and status
+* information from task file data register before proceeding
+*/
+ while (i WAIT_MS_SPINUP) {
+ tf_data = readl(port_mmio + PORT_TFDATA);
+ if (!(tf_data ATA_BUSY))
+ break;
+ udelay(1000);
+ i++;
+ }
+
Doesn't this fall through after a timeout and fail to report an error?
Ah, yes! We should return error code when timeout. But some other
routines in the scsi initialization path do no check return values,
like initr_scsi()-scsi_init()-scsi_low_level_init().
I suppose that could be improved separately but does it affect this patch?
As a matter of style I think something like the below is better
because it the timeout will be more accurate in the case where you
have a lot of processing each time around the loop.
static int wait_spinup(void)
{
ulong start;
start = get_timer(0);
do {
tf_data = ...;
if (!((tf_data ATA_BUSY))
return 0;
while (get_timer(start) WAIT_MS_SPINUP);
return -ETIMEDOUT;
}
Looks like the original codes there are using i++ style for the
timeout check instead of get_timer().
Also how does this relate to the existing spinup delay code in
ahci_host_init()?
This seems to me they are not related. Per my understanding, the check
we need here is because we write something to the port command
register, but we missed the task file data busy indication.
writel_with_flush(PORT_CMD_ICC_ACTIVE | PORT_CMD_FIS_RX |
PORT_CMD_POWER_ON | PORT_CMD_SPIN_UP |
PORT_CMD_START, port_mmio + PORT_CMD);
[snip]
OK.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] da850evm: Use generic board and libfdt, fix size for SPI flash
On 22 December 2014 at 02:27, Peter Howard p...@northern-ridge.com.au wrote: On Fri, 2014-12-19 at 12:14 +0530, Jagan Teki wrote: On 19 December 2014 at 02:54, Peter Howard p...@northern-ridge.com.au wrote: On Thu, 2014-12-18 at 12:33 +0530, Jagan Teki wrote: On 17 December 2014 at 06:44, Peter Howard p...@northern-ridge.com.au wrote: Add defines to use CONFIG_SYS_GENERIC_BOARD and CONFIG_OF_LIBFDT. Semi-separate to this: the size of the image for the da850evm has increased to the point that the size in da850evm.h and the offset for the environment in SPI flash no longer work. They are modified to account for the larger image size. Signed-off-by: Peter Howard phow...@gme.net.au --- include/configs/da850evm.h | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/include/configs/da850evm.h b/include/configs/da850evm.h index e5f8afe..e5a612c 100644 --- a/include/configs/da850evm.h +++ b/include/configs/da850evm.h @@ -157,7 +157,7 @@ #define CONFIG_SPL_SPI_FLASH_SUPPORT #define CONFIG_SPL_SPI_LOAD #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x8000 -#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x3 +#define CONFIG_SYS_SPI_U_BOOT_SIZE 0x4 #endif /* @@ -251,7 +251,7 @@ #undef CONFIG_ENV_IS_IN_NAND #define CONFIG_ENV_IS_IN_SPI_FLASH #define CONFIG_ENV_SIZE(64 10) -#define CONFIG_ENV_OFFSET (256 10) +#define CONFIG_ENV_OFFSET (512 10) Please make sure the proper testing of this new flash env size. What sort of testing were you thinking of? I've confirmed that it basically works (i.e. saving/loading/editing+save) - env size is 64K, SPI is 8MB and offset is only 512K in, so it fits. u-boot image size is ~260K so there's plenty of room before the env. Looks fine to me, but we have some recent changes in sf which we published on master 5 days back - did you test on top of that? If you're referring to commits 54ba653ab63b31c8f5405fb0ee9dfba05cbb1521, 74c2cee4e82bb71953267e87900e279ab5aa1dc3, b648742a17c16639976ac5b38f246cb0f7d41da5, and 6dd6e90e13acc4014634d78fc469e7e82eefc255, then yes I tested on top of those. Is there something more you wanted? Thanks. Reviewed-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com #define CONFIG_ENV_SECT_SIZE (64 10) #define CONFIG_SYS_NO_FLASH #endif @@ -259,6 +259,7 @@ /* * U-Boot general configuration */ +#define CONFIG_SYS_GENERIC_BOARD #define CONFIG_MISC_INIT_R #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_BOOTFILEuImage /* Boot file name */ @@ -275,6 +276,7 @@ #define CONFIG_SYS_LONGHELP #define CONFIG_CRC32_VERIFY #define CONFIG_MX_CYCLIC +#define CONFIG_OF_LIBFDT /* * Linux Information -- 1.9.3 Reviewed-by: Jagannadha Sutradharudu Teki jagannadh.t...@gmail.com thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request: u-boot-spi/master
Hi Tom, Please pull this PR. thanks! Jagan. The following changes since commit e3bf81b1e841ecabe7c8b3d48621256db8b8623e: Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx (2014-12-16 15:20:02 -0500) are available in the git repository at: git://git.denx.de/u-boot-spi.git master for you to fetch changes up to babe6994ca28e5a354ee32b33b7a54b0276d9df1: sf: sf_params: Add S25FL164K flash identifier info (2014-12-18 18:48:30 +0530) Adnan Ali (2): sf: sf_params: Add S25FL116K flash support sf: sf_params: Add S25FL164K flash identifier info Jagannadha Sutradharudu Teki (1): mtd: sf: Zap ramtron driver Shengzhou Liu (1): mtd/spi: Add support for SST25WF040B drivers/mtd/spi/Makefile| 1 - drivers/mtd/spi/ramtron.c | 404 drivers/mtd/spi/sf_params.c | 3 + 3 files changed, 3 insertions(+), 405 deletions(-) delete mode 100644 drivers/mtd/spi/ramtron.c ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6sxsabresd: Remove unneeded board_late_init()
From: Fabio Estevam fabio.este...@freescale.com
Since commit 1f98e31bc0b2c37a (imx: mx6sxsabresd: Use the pfuze common init
function) board_late_init() became empty, so we can safely remove this unneeded
function.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx6sxsabresd/mx6sxsabresd.c | 5 -
include/configs/mx6sxsabresd.h | 1 -
2 files changed, 6 deletions(-)
diff --git a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
index fd8bc72..83e0508 100644
--- a/board/freescale/mx6sxsabresd/mx6sxsabresd.c
+++ b/board/freescale/mx6sxsabresd/mx6sxsabresd.c
@@ -383,11 +383,6 @@ int board_init(void)
return 0;
}
-int board_late_init(void)
-{
- return 0;
-}
-
int checkboard(void)
{
puts(Board: MX6SX SABRE SDB\n);
diff --git a/include/configs/mx6sxsabresd.h b/include/configs/mx6sxsabresd.h
index 61a7a7a..3d35c4b 100644
--- a/include/configs/mx6sxsabresd.h
+++ b/include/configs/mx6sxsabresd.h
@@ -28,7 +28,6 @@
#define CONFIG_SYS_MALLOC_LEN (3 * SZ_1M)
#define CONFIG_BOARD_EARLY_INIT_F
-#define CONFIG_BOARD_LATE_INIT
#define CONFIG_MXC_GPIO
#define CONFIG_MXC_UART
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] arm:mx6sx add QSPI support
Hi Jagan, On Fri, Oct 10, 2014 at 6:58 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Jagan said he would review both patches. Once he gives his Acked-by, the patches will go in -- but note that the series is an addition, not a fix, and came in after the 2014.10 merge window, so it'll go in only after the upcoming release (that's only a few days anyway). Any comments about this series, please? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] arm:mx6sx add QSPI support
On 29 December 2014 at 23:58, Fabio Estevam feste...@gmail.com wrote: Hi Jagan, On Fri, Oct 10, 2014 at 6:58 AM, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Jagan said he would review both patches. Once he gives his Acked-by, the patches will go in -- but note that the series is an addition, not a fix, and came in after the 2014.10 merge window, so it'll go in only after the upcoming release (that's only a few days anyway). Any comments about this series, please? I believe there is a v3 series for this - will comment those. thanks! -- Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] L2 cache and LCD on sunxi
Hi, On 29-12-14 17:23, Simon Glass wrote: Hi Hans, On 24 December 2014 at 09:47, Hans de Goede hdego...@redhat.com wrote: Hi, On 23-12-14 05:36, Simon Glass wrote: Hi Hans, On 22 December 2014 at 09:45, Hans de Goede hdego...@redhat.com wrote: Hi, On 21-12-14 19:52, Simon Glass wrote: Hi, I ran up a banana PI and noticed that HDMI works in U-Boot. Great! Scrolling seems very slow though - is the L2 cache disabled perhaps? I don't think so, but it could be, I think the scrolling code is just very inefficient. Feel free to poke things a bit around this, ARM cache management is not my forte. I think it need ssomething like the code in exynos/soc.c - see v7_outer_cache_enable(). Even with the 7 inch it's very slow. I've run some tests, and it is not slower then on say the A10 (cortex A8), also I've been unable to find any docs or allwinner code pointing to allwinner specific l2 cache init. As such ATM I do not believe that we've the l2 cache disabled. Yes the code is not super-efficient (and could use the arch-specific memcpy()) but I'm mostly interested in whether the platform is running at full speed. I'm comparing it to say an Exynos 5250 which is 1.7GHz Cortex-A15. Without the L2 cache it scrolls quite slowly but with it it is fast. Well this is a 1 GHz Cortex A7, and one with likely a much less efficient DRAM controller / less DRAM bandwidth. There is probably some cache setup required. That could be, but if that is the case then I don't know where to start looking for it. I certainly cannot find any such thing in allwinner;s boot0 / boot1 bootloader. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/17] sunxi: video: Add support for VGA via external DACs connected to the LCD pins
Hi, On 29-12-14 14:51, Ian Campbell wrote: On Wed, 2014-12-24 at 20:06 +0100, Hans de Goede wrote: Add support for external DACs connected to the parallel LCD interface driving a VGA connector, such as found on the Olimex A13 boards. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk --- board/sunxi/Kconfig | 9 + drivers/video/sunxi_display.c | 14 ++ 2 files changed, 23 insertions(+) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 7a8503b..3e42866 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -253,6 +253,15 @@ config VIDEO_HDMI ---help--- Say Y here to add support for outputting video over HDMI. +config VIDEO_VGA_VIA_LCD + boolean VGA via LCD controller support + depends on VIDEO + default n + ---help--- + Say Y here to add support for external DACs connected to the parallel + LCD interface driving a VGA connector, such as found on the + Olimex A13 boards. But not unique to those boards I take it? Actually sofar it is unique to those boards, both the normal and the Micro variant (in theory we could see something similar on other boards one day). Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 14/17] sunxi: Add 2 defconfigs for using the Olimex 7 lcd with olinuxino boards
Hi, On 29-12-14 14:55, Ian Campbell wrote: On Wed, 2014-12-24 at 20:06 +0100, Hans de Goede wrote: Add defconfigs for using the Olimex 7 lcd with the A10s-OLinuXino-M and the A20-OLinuXino_MICRO boards. Note this cannot be added to the regular defconfigs, like with the A13 boards, because the video code will automatically fallback to driving the LCD if no HDMI cable is connected (this is the desired behavior on e.g. tablets), but the LCD connector on the Olimex dev boards may be used for something completely different, so we do not want to automatically enable it. Note I do not intend to add defconfigs for all possible permutation of Olimex boards and LCD displays, these 2 serve mostly as examples. Does the A13 one not serve that function already without the downside of duplicating up the defconfig? True, I wrote these before doing the A13 stuff, then ammended the commit message to explain why these where different from the A13 case later. But you're right the A13 configs do more or less serve the same purpose so we could drop these. I take it that dropping these has your preference ? Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 15/17] sunxi: Ippo_q8h defconfigs: Enable the LCD panel found on these tablets.
Hi, On 29-12-14 16:56, Chen-Yu Tsai wrote: On Mon, Dec 29, 2014 at 9:57 PM, Ian Campbell i...@hellion.org.uk wrote: On Fri, 2014-12-26 at 14:44 +0800, Chen-Yu Tsai wrote: So if I'm not mistaken for the Ippo_q8h_v5 the timings should be: CONFIG_VIDEO_LCD_MODE=x:800,y:480,depth:18,pclk_khz:33000,le:87,ri:168,up:31,lo:13,hs:1,vs:1,sync:0,vmode:0 The new values look better. Thanks. I've not seen a v2 of this patch, but assuming a patch with these new values were to be posted I would say: Acked-by: Ian Campbell i...@hellion.org.uk I think we should add your Tested-by too. Tested-by: Chen-Yu Tsai w...@csie.org Thanks, I've added both the Acked-by and the Tested-by to the commit in my personal tree, which has the new values. Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] L2 cache and LCD on sunxi
Hi Hans, On 29 December 2014 at 12:17, Hans de Goede hdego...@redhat.com wrote: Hi, On 29-12-14 17:23, Simon Glass wrote: Hi Hans, On 24 December 2014 at 09:47, Hans de Goede hdego...@redhat.com wrote: Hi, On 23-12-14 05:36, Simon Glass wrote: Hi Hans, On 22 December 2014 at 09:45, Hans de Goede hdego...@redhat.com wrote: Hi, On 21-12-14 19:52, Simon Glass wrote: Hi, I ran up a banana PI and noticed that HDMI works in U-Boot. Great! Scrolling seems very slow though - is the L2 cache disabled perhaps? I don't think so, but it could be, I think the scrolling code is just very inefficient. Feel free to poke things a bit around this, ARM cache management is not my forte. I think it need ssomething like the code in exynos/soc.c - see v7_outer_cache_enable(). Even with the 7 inch it's very slow. I've run some tests, and it is not slower then on say the A10 (cortex A8), also I've been unable to find any docs or allwinner code pointing to allwinner specific l2 cache init. As such ATM I do not believe that we've the l2 cache disabled. Yes the code is not super-efficient (and could use the arch-specific memcpy()) but I'm mostly interested in whether the platform is running at full speed. I'm comparing it to say an Exynos 5250 which is 1.7GHz Cortex-A15. Without the L2 cache it scrolls quite slowly but with it it is fast. Well this is a 1 GHz Cortex A7, and one with likely a much less efficient DRAM controller / less DRAM bandwidth. There is probably some cache setup required. That could be, but if that is the case then I don't know where to start looking for it. I certainly cannot find any such thing in allwinner;s boot0 / boot1 bootloader. Me neither, although I suppose the kernel sets it up. It should only be a few instructions to enable. It would be nice to have some memory bandwidth testing code in U-Boot perhaps... Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] sunxi: video: Add VGA output support
Hi,
On 29-12-14 15:18, Ian Campbell wrote:
On Sat, 2014-12-27 at 16:53 +0100, Hans de Goede wrote:
diff --git a/arch/arm/include/asm/arch-sunxi/display.h
b/arch/arm/include/asm/arch-sunxi/display.h
index 908c5d9..8c25ad4 100644
--- a/arch/arm/include/asm/arch-sunxi/display.h
+++ b/arch/arm/include/asm/arch-sunxi/display.h
@@ -158,6 +158,52 @@ struct sunxi_hdmi_reg {
};
/*
+ * This is based on the A10s User Manual, and the A10s only supports
+ * composite video and not vga like the A10 / A20 does, still other
+ * then the removed vga out capability the tvencoder seems to be the same.
You mean other than I think.
Fixed in my personal tree, and added your ack.
Thanks for all the reviews!
I'll go and poke Anatolij to get his ack for the videomodes.c changes,
with that (+ a respin of a few remaining patches you had comments on)
the entire display series can be queued up for merging in next.
Regards,
Hans
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] x86: Remove include directory in arch/x86/dts
Hi Bin, On 28 December 2014 at 23:04, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Sun, Dec 28, 2014 at 9:02 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 23 December 2014 at 22:06, Bin Meng bmeng...@gmail.com wrote: The include directory in arch/x86/dts is not used, so remove it. Signed-off-by: Bin Meng bmeng...@gmail.com --- Actually we do need this - the Chrome OS keyboard .dtsi will use a binding when I get around to updating it. OK, so maybe we can just put anything we do need into the include instead of a symbolic link to the genric one? The idea as (I understand it) is that include/dt-bindings is the standard directory for all archs to put their bindings. This is how ARM works too. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 18/23] ARM: Implement non-cached memory support
Hi Albert, On 19 December 2014 at 00:02, Albert ARIBAUD albert.u.b...@aribaud.net wrote: Hello Tom, On Thu, 18 Dec 2014 21:33:09 +, Tom Warren twar...@nvidia.com wrote: Albert, Please pull u-boot-tegra.git/master into ARM master. ./MAKEALL -s tegra is clean. I assume this is actually for Tom Rini, as non-core ARM trees now merge directly into mainline.1 Yes I think Tom Rini will apply this when he gets back. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx6slevk: Remove get_board_rev()
From: Fabio Estevam fabio.este...@freescale.com
get_board_rev() just returns the cpu revision, which does not make it really
useful for distinguishing between revisions of the board.
Let's get rid of get_board_rev() as it is not being used with its correct
meaning.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
board/freescale/mx6slevk/mx6slevk.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/board/freescale/mx6slevk/mx6slevk.c
b/board/freescale/mx6slevk/mx6slevk.c
index 3834eec..838ea6c 100644
--- a/board/freescale/mx6slevk/mx6slevk.c
+++ b/board/freescale/mx6slevk/mx6slevk.c
@@ -308,11 +308,6 @@ int board_init(void)
return 0;
}
-u32 get_board_rev(void)
-{
- return get_cpu_rev();
-}
-
int checkboard(void)
{
puts(Board: MX6SLEVK\n);
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 6/7] x86: Use ePAPR defined properties for x86-uart
Hi Bin, On 29 December 2014 at 00:45, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Sun, Dec 28, 2014 at 9:55 AM, Simon Glass s...@chromium.org wrote: On 27 December 2014 at 05:10, Bin Meng bmeng...@gmail.com wrote: Use ePAPR defined properties for x86-uart: clock-frequency and current-speed. Assign the value of clock-frequency in device tree to plat-clock of x86-uart instead of using hardcoded number. Signed-off-by: Bin Meng bmeng...@gmail.com --- Changes in v2: - New patch to use ePAPR defined properties for x86-uart arch/x86/dts/serial.dtsi| 5 ++--- drivers/serial/serial_x86.c | 8 +++- 2 files changed, 9 insertions(+), 4 deletions(-) diff --git a/arch/x86/dts/serial.dtsi b/arch/x86/dts/serial.dtsi index ebdda76..9b097f4 100644 --- a/arch/x86/dts/serial.dtsi +++ b/arch/x86/dts/serial.dtsi @@ -3,8 +3,7 @@ compatible = x86-uart; reg = 0x3f8 8; reg-shift = 0; - io-mapped = 1; - multiplier = 1; - baudrate = 115200; + clock-frequency = 1843200; + current-speed = 115200; Where is current speed used? If it is needed, please update the binding at doc/device-tree-bindings/serial/ns16550.txt The current-speed is the baud rate of the serial port. Currently it is put there for ePAPR completeness and not used by U-Boot as U-Boot is using gd-baudrate for the serial console. OK I see, thanks. 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] Issue with uboot on imx6slevk
Hi Fabio, Ok I will test it tomorrow. Thanks for the reply. I did not know that I can use the main uboot for my build instead of the fork from Freescale for mx6 Arthur. 2014-12-29 21:07 GMT+01:00 Fabio Estevam feste...@gmail.com: Arthur, On Mon, Dec 29, 2014 at 1:39 PM, Fabio Estevam feste...@gmail.com wrote: Please use U-boot 2014.10 or 2015.01-rc3 instead. If you have issues, then you can post here again ;-) By the way, just tested top of tree U-boot on a mx6sl evk and I didn't see any issues on booting the kernel. -- - Arthur LAMBERT ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with uboot on imx6slevk
Arthur, On Mon, Dec 29, 2014 at 1:39 PM, Fabio Estevam feste...@gmail.com wrote: Please use U-boot 2014.10 or 2015.01-rc3 instead. If you have issues, then you can post here again ;-) By the way, just tested top of tree U-boot on a mx6sl evk and I didn't see any issues on booting the kernel. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Issue with uboot on imx6slevk
Hi Arthur, On Mon, Dec 29, 2014 at 6:12 PM, Arthur Lambert lambertarthu...@gmail.com wrote: Hi Fabio, Ok I will test it tomorrow. Thanks for the reply. I did not know that I can use the main uboot for my build instead of the fork from Freescale for mx6 I think I understand the issue you reported. You are booting a uImage kernel: ## Booting kernel from Legacy Image at 8080 ... Image Name: Linux-3.10.17 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:5258504 Bytes = 5 MiB Load Address: 10008000 Entry Point: 10008000 Verifying Checksum ... OK ,but the LOADADDR is incorrect: instead of 10008000 it should be 80008000 (0x10008000 is the LOADADDR for the other mx6 SoCs, but not for solo-lite). So you should generate your kernel with the correct LOADADDR: make uImage LOADADDR=0x80008000 Then you should be able to boot it with your current 2013.04 U-boot. With the latest U-boot version we use zImage by default, so there is no need to worry about passing the correct LOADADDR. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/9] [v3] DM: crypto/rsa: Add rsa Modular Exponentiation DM driver
Hi Ruchika,
On 28 December 2014 at 20:53, Ruchika Gupta ruchika.gu...@freescale.com wrote:
Re-sending as delivery to uboot mailing list failed last time...
Hi Simon,
Thanks for the review comments.
-Original Message-
From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
Sent: Wednesday, December 24, 2014 6:19 AM
To: Gupta Ruchika-R66431
Cc: U-Boot Mailing List; Sun York-R58495
Subject: Re: [PATCH 3/9] [v3] DM: crypto/rsa: Add rsa Modular
Exponentiation DM driver
Hi Ruchika,
On 23 December 2014 at 04:32, Ruchika Gupta
ruchika.gu...@freescale.com
wrote:
Add a new rsa uclass for performing modular exponentiation and
implement the software driver basing on this uclass.
Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
CC: Simon Glass s...@chromium.org
---
Changes in v3:
New patch with driver model for RSA UCLASS
drivers/crypto/Kconfig | 1 +
drivers/crypto/Makefile | 1 +
drivers/crypto/rsa/Kconfig | 5 +
drivers/crypto/rsa/Makefile | 8
drivers/crypto/rsa/rsa_sw.c | 39
+++
drivers/crypto/rsa/rsa_uclass.c | 31 +++
include/dm/uclass-id.h | 1 +
include/u-boot/rsa-mod-exp.h| 40
8 files changed, 126 insertions(+)
create mode 100644 drivers/crypto/rsa/Kconfig create mode 100644
drivers/crypto/rsa/Makefile create mode 100644
drivers/crypto/rsa/rsa_sw.c create mode 100644
drivers/crypto/rsa/rsa_uclass.c
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig index
e69de29..75f3479 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -0,0 +1 @@
+source drivers/crypto/rsa/Kconfig
diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile index
7b79237..a2f30fc 100644
--- a/drivers/crypto/Makefile
+++ b/drivers/crypto/Makefile
@@ -6,4 +6,5 @@
#
obj-$(CONFIG_EXYNOS_ACE_SHA) += ace_sha.o
+obj-y += rsa/
obj-y += fsl/
diff --git a/drivers/crypto/rsa/Kconfig b/drivers/crypto/rsa/Kconfig
new file mode 100644 index 000..7eb90a1
--- /dev/null
+++ b/drivers/crypto/rsa/Kconfig
@@ -0,0 +1,5 @@
+config DM_RSA
+ bool Enable Driver Model for RSA
+ depends on DM
+ help
+ If you want to use driver model for RSA Modular
+Exponentiation,
say Y.
Can you send a new patch (later if you prefer) which removes this
option altogether? It should be the default. In other words, RSA
should always use driver model.
If we make it mandatory for RSA to use driver model, all platforms would need
to use DM by default in their defconfig. Would that be acceptable ?
Secondly if I force select DM and DM_RSA when CONFIG_RSA is selected, this
may result in duplication of CONFIG_DM with platforms having it defined
already.
Please suggest.
Yes that is correct, all platforms with RSA can use DM. As far as I
know they do, but if not we can add a patch to fix that.
diff --git a/drivers/crypto/rsa/Makefile
b/drivers/crypto/rsa/Makefile new file mode 100644 index
000..fae4f8c
--- /dev/null
+++ b/drivers/crypto/rsa/Makefile
@@ -0,0 +1,8 @@
+#
+# (C) Copyright 2014 Freescale Semiconductor, Inc.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+obj-$(CONFIG_DM_RSA) += rsa_uclass.o
+obj-$(CONFIG_RSA_SW) += rsa_sw.o
diff --git a/drivers/crypto/rsa/rsa_sw.c
b/drivers/crypto/rsa/rsa_sw.c new file mode 100644 index
000..5d94754
--- /dev/null
+++ b/drivers/crypto/rsa/rsa_sw.c
@@ -0,0 +1,39 @@
+/*
+ * (C) Copyright 2014 Freescale Semiconductor, Inc.
+ * Author: Ruchika Gupta ruchika.gu...@freescale.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include config.h
+#include common.h
+#include dm.h
+#include u-boot/rsa-mod-exp.h
+
+int mod_exp_sw(struct udevice *dev, const uint8_t *sig, uint32_t sig_len,
+ struct key_prop *prop, uint8_t *out) {
+ int ret = 0;
+
+ ret = rsa_mod_exp_sw(sig, sig_len, prop, out);
+
+ if (ret) {
+ debug(%s: RSA failed to verify: %d\n, __func__, ret);
+ return ret;
+ }
+ return 0;
+}
+
+static const struct rsa_ops rsa_ops_sw = {
+ .get_mod_exp= mod_exp_sw,
+};
+
+U_BOOT_DRIVER(fsl_rsa) = {
+ .name = rsa_sw,
+ .id = UCLASS_RSA,
+ .ops= rsa_ops_sw,
+};
+
+U_BOOT_DEVICE(rsa_sw) = {
+ .name = rsa_sw,
+};
diff --git a/drivers/crypto/rsa/rsa_uclass.c
b/drivers/crypto/rsa/rsa_uclass.c new file mode 100644 index
000..f4f4f39
--- /dev/null
+++ b/drivers/crypto/rsa/rsa_uclass.c
@@ -0,0 +1,31 @@
+/*
+ * (C) Copyright 2014 Freescale Semiconductor, Inc
+ * Author: Ruchika Gupta ruchika.gu...@freescale.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include common.h
Re: [U-Boot] [PATCH 5/9] [v3] lib/rsa: Modify rsa to use DM driver if available
Hi Ruchika,
On 28 December 2014 at 23:58, Ruchika Gupta ruchika.gu...@freescale.com wrote:
Resending as the message bounced from u-boot mailing list.
Hi Simon,
-Original Message-
From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
Sent: Wednesday, December 24, 2014 6:19 AM
To: Gupta Ruchika-R66431
Cc: U-Boot Mailing List; Sun York-R58495
Subject: Re: [PATCH 5/9] [v3] lib/rsa: Modify rsa to use DM driver if
available
Hi Ruchika,
On 23 December 2014 at 04:32, Ruchika Gupta
ruchika.gu...@freescale.com
wrote:
Modify rsa_verify to use the rsa driver of DM library available.The
tools and the configurations which don't use Driver Model, will
continue to use the same RSA sw library. The software implementation
of RSA Modular Exponentation is now compiled if RSA_MOD_EXP_SW is selected.
Kconfig options are also added for rsa library.
Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
CC: Simon Glass s...@chromium.org
---
Changes in v3:
New patch
include/configs/am335x_evm.h | 1 +
lib/Kconfig | 6 +-
lib/rsa/Kconfig | 31 +++
lib/rsa/Makefile | 3 ++-
lib/rsa/rsa-verify.c | 18 ++
5 files changed, 53 insertions(+), 6 deletions(-) create mode
100644 lib/rsa/Kconfig
diff --git a/include/configs/am335x_evm.h
b/include/configs/am335x_evm.h index cc36985..aa79841 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -25,6 +25,7 @@
# ifdef CONFIG_ENABLE_VBOOT
# define CONFIG_FIT_SIGNATURE
# define CONFIG_RSA
+# define CONFIG_RSA_MOD_EXP_SW
This should go in am335x_boneblack_vboot_defconfig I think.
I didn’t move it in the defconfig as it was conditionally defined under
CONFIG_ENABLE_VBOOT
# endif
#endif
diff --git a/lib/Kconfig b/lib/Kconfig index 602dd37..a1f30a2 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -27,10 +27,6 @@ config SYS_HZ
get_timer() must operate in milliseconds and this option must be
set to 1000.
-config RSA
- bool Use RSA Library
- help
- RSA support.This enables the RSA algorithm used for FIT image
- verification in U-Boot.
+source lib/rsa/Kconfig
endmenu
diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig new file mode 100644
index 000..8f9aa44
--- /dev/null
+++ b/lib/rsa/Kconfig
@@ -0,0 +1,31 @@
+config RSA
+ bool Use RSA Library
+ select RSA_MOD_EXP_SW if !DM
+ select DM_RSA if DM
+ help
+ RSA support.This enables the RSA algorithm used for FIT image
+ verification in U-Boot.
+ See doc/uImage.FIT/signature.txt for more details.
+
+if RSA DM_RSA
+
+config RSA_SW
+ bool User driver Model for RSA Modular Exponentiation in software
+ depends on DM DM_RSA RSA
+ select RSA_MOD_EXP_SW
+ default y
+ help
+ Enables driver for modular exponentiation in software.
+This is a
RSA
+ algorithm used in FIT image verification. It required RSA Key as
+ input.
+ See doc/uImage.FIT/signature.txt for more details.
+
+endif
+
+config RSA_MOD_EXP_SW
+ bool
+ default n
+ help
+ Library for SW implementation of RSA Modular Exponentiation. This
+ library is used by the mkimage tool(not selected through
+this
option)
+ as well as by the RSA driver model with SW implementation.
diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile index
cc25b3c..ccc6060 100644
--- a/lib/rsa/Makefile
+++ b/lib/rsa/Makefile
@@ -7,4 +7,5 @@
# SPDX-License-Identifier: GPL-2.0+
#
-obj-$(CONFIG_FIT_SIGNATURE) += rsa-verify.o rsa-checksum.o
rsa-mod-exp.o
+obj-$(CONFIG_FIT_SIGNATURE) += rsa-verify.o rsa-checksum.o
+obj-$(CONFIG_RSA_MOD_EXP_SW) += rsa-mod-exp.o
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c index
f8bc086..27f10ef 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -12,6 +12,7 @@
#include asm/errno.h
#include asm/types.h
#include asm/unaligned.h
+#include dm.h
#else
#include fdt_host.h
#include mkimage.h
@@ -43,6 +44,9 @@ static int rsa_verify_key(struct key_prop *prop,
const
uint8_t *sig,
const uint8_t *padding;
int pad_len;
int ret;
+#if defined(CONFIG_DM_RSA) !defined(USE_HOSTCC)
+ struct udevice *rsa_dev;
+#endif
if (!prop || !sig || !hash || !algo)
return -EIO;
@@ -63,11 +67,25 @@ static int rsa_verify_key(struct key_prop *prop,
const uint8_t *sig,
uint8_t buf[sig_len];
+#if defined(CONFIG_DM_RSA) !defined(USE_HOSTCC)
+ ret = uclass_get_device(UCLASS_RSA, 0, rsa_dev);
+ if (!ret) {
+ ret = rsa_mod_exp(rsa_dev, sig, sig_len, prop, buf);
+ if (ret) {
Re: [U-Boot] [PATCH 7/9] [v3] lib/rsa: Add Kconfig option for HW accelerated RSA
Hi Ruchika,
On 29 December 2014 at 00:05, Ruchika Gupta ruchika.gu...@freescale.com wrote:
Hi Simon,
-Original Message-
From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
Sent: Wednesday, December 24, 2014 6:20 AM
To: Gupta Ruchika-R66431
Cc: U-Boot Mailing List; Sun York-R58495
Subject: Re: [PATCH 7/9] [v3] lib/rsa: Add Kconfig option for HW accelerated
RSA
Hi Ruchika,
On 23 December 2014 at 04:32, Ruchika Gupta ruchika.gu...@freescale.com
wrote:
Kconfig option added for devices which support RSA Verification
(Modular Exponentiation) operation in hardware
Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
CC: Simon Glass s...@chromium.org
---
Changes in v3:
New patch
lib/rsa/Kconfig | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
I think this needs tweaking such that RSA_SW is a driver (use RSA_SOFTWARE
might be better).
For your freescale one, it should be RSA_FREESCALE_EXP or similar. We might
want to support multiple such devices. Don't use RSA_HW - that's not a
descriptive name.
If we are using driver Model, can multiple devices be selected at the same
time for the RSA_UCLASS ? I am little confused.
Yes, they can be accessed using uclass_get_device_by_seq() if they are
numbered in the aliases:
aliases {
mod_exp0 = /path/to/hardware-node;
mod_exp1 = /path/to/software-node;
}
or uclass_get_device() if there is no sequence numbering.
diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig index 8f9aa44..fc8a1e7
100644
--- a/lib/rsa/Kconfig
+++ b/lib/rsa/Kconfig
@@ -11,7 +11,7 @@ if RSA DM_RSA
config RSA_SW
bool User driver Model for RSA Modular Exponentiation in software
- depends on DM DM_RSA RSA
+ depends on DM DM_RSA RSA !RSA_HW
You should drop the last term since it should be possible to have both
software and hardware.
This option selects the driver model for RSA software implementation suing
RSA uclass. If I define both I get this error :
drivers/crypto/fsl/built-in.o:(.u_boot_list_2_driver_2_fsl_rsa+0x0): multiple
definition of `_u_boot_list_2_driver_2_fsl_rsa'
drivers/crypto/rsa/built-in.o:(.u_boot_list_2_driver_2_fsl_rsa+0x0): first
defined here
Make sure you use a different name - it seems like you are using
fsl_rsa for both.
select RSA_MOD_EXP_SW
default y
help
@@ -20,6 +20,27 @@ config RSA_SW
input.
See doc/uImage.FIT/signature.txt for more details.
+menuconfig RSA_HW
+ bool Use crypto devices to implement RSA Modular Exponentiation
+ default y
+ help
+ Say Y here to get to see options for hardware crypto devices and
+ processors. This option alone does not enable the crypto device.
+
+ If you say N,all options in this submenu will be skipped and
disabled.
Space after N
+
+if RSA_HW
+
+config FSL_RSA
+ bool Implement RSA Modular Exponentiation with FSL crypto
accelerator
+ depends on DM DM_RSA RSA FSL_CAAM
+ default y
+ help
+ Enables driver for RSA modular exponentiation using Freescale's
+ cryptographic accelerator - CAAM.
+
+endif
+
endif
config RSA_MOD_EXP_SW
--
1.8.1.4
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] FW: [PATCH 5/9] [v3] lib/rsa: Modify rsa to use DM driver if available
Hi Ruchika, On 24 December 2014 at 03:29, Ruchika Gupta ruchika.gu...@freescale.com wrote: My Patches to the mailing list using outlook client are failing. So forwarding the message. Any pointers on how to correct the issue will be highly appreciated. I don't use Microsoft Outlook but someone on the list might know. I know that in Gmail I have it set to plain text. IMO the only sane approach is to set up 'git send-email' so that it works properly. Then patman will create, process and email your patches correctly each time. Regards, Ruchika -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of u-boot-ow...@lists.denx.de Sent: Wednesday, December 24, 2014 3:59 PM To: Gupta Ruchika-R66431 Subject: RE: [PATCH 5/9] [v3] lib/rsa: Modify rsa to use DM driver if available Message rejected. No base64 encoded MIME text parts allowed. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] [v3] lib/rsa: Modify rsa to use DM driver if available
Hi Ruchika,
On 24 December 2014 at 03:28, Ruchika Gupta ruchika.gu...@freescale.com wrote:
Hi Simon,
-Original Message-
From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
Sent: Wednesday, December 24, 2014 6:19 AM
To: Gupta Ruchika-R66431
Cc: U-Boot Mailing List; Sun York-R58495
Subject: Re: [PATCH 5/9] [v3] lib/rsa: Modify rsa to use DM driver if
available
Hi Ruchika,
On 23 December 2014 at 04:32, Ruchika Gupta ruchika.gu...@freescale.com
wrote:
Modify rsa_verify to use the rsa driver of DM library available.The
tools and the configurations which don't use Driver Model, will
continue to use the same RSA sw library. The software implementation
of RSA Modular Exponentation is now compiled if RSA_MOD_EXP_SW is selected.
Kconfig options are also added for rsa library.
Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
CC: Simon Glass s...@chromium.org
---
Changes in v3:
New patch
include/configs/am335x_evm.h | 1 +
lib/Kconfig | 6 +-
lib/rsa/Kconfig | 31 +++
lib/rsa/Makefile | 3 ++-
lib/rsa/rsa-verify.c | 18 ++
5 files changed, 53 insertions(+), 6 deletions(-) create mode 100644
lib/rsa/Kconfig
diff --git a/include/configs/am335x_evm.h
b/include/configs/am335x_evm.h index cc36985..aa79841 100644
--- a/include/configs/am335x_evm.h
+++ b/include/configs/am335x_evm.h
@@ -25,6 +25,7 @@
# ifdef CONFIG_ENABLE_VBOOT
# define CONFIG_FIT_SIGNATURE
# define CONFIG_RSA
+# define CONFIG_RSA_MOD_EXP_SW
This should go in am335x_boneblack_vboot_defconfig I think.
I didn’t move it in the defconfig as it was conditionally defined under
CONFIG_ENABLE_VBOOT
Ah OK I see.
# endif
#endif
diff --git a/lib/Kconfig b/lib/Kconfig index 602dd37..a1f30a2 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -27,10 +27,6 @@ config SYS_HZ
get_timer() must operate in milliseconds and this option must be
set to 1000.
-config RSA
- bool Use RSA Library
- help
- RSA support.This enables the RSA algorithm used for FIT image
- verification in U-Boot.
+source lib/rsa/Kconfig
endmenu
diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig new file mode 100644
index 000..8f9aa44
--- /dev/null
+++ b/lib/rsa/Kconfig
@@ -0,0 +1,31 @@
+config RSA
+ bool Use RSA Library
+ select RSA_MOD_EXP_SW if !DM
+ select DM_RSA if DM
+ help
+ RSA support.This enables the RSA algorithm used for FIT image
+ verification in U-Boot.
+ See doc/uImage.FIT/signature.txt for more details.
+
+if RSA DM_RSA
+
+config RSA_SW
+ bool User driver Model for RSA Modular Exponentiation in software
+ depends on DM DM_RSA RSA
+ select RSA_MOD_EXP_SW
+ default y
+ help
+ Enables driver for modular exponentiation in software. This is a
RSA
+ algorithm used in FIT image verification. It required RSA Key as
+ input.
+ See doc/uImage.FIT/signature.txt for more details.
+
+endif
+
+config RSA_MOD_EXP_SW
+ bool
+ default n
+ help
+ Library for SW implementation of RSA Modular Exponentiation. This
+ library is used by the mkimage tool(not selected through this
option)
+ as well as by the RSA driver model with SW implementation.
diff --git a/lib/rsa/Makefile b/lib/rsa/Makefile index
cc25b3c..ccc6060 100644
--- a/lib/rsa/Makefile
+++ b/lib/rsa/Makefile
@@ -7,4 +7,5 @@
# SPDX-License-Identifier: GPL-2.0+
#
-obj-$(CONFIG_FIT_SIGNATURE) += rsa-verify.o rsa-checksum.o
rsa-mod-exp.o
+obj-$(CONFIG_FIT_SIGNATURE) += rsa-verify.o rsa-checksum.o
+obj-$(CONFIG_RSA_MOD_EXP_SW) += rsa-mod-exp.o
diff --git a/lib/rsa/rsa-verify.c b/lib/rsa/rsa-verify.c index
f8bc086..27f10ef 100644
--- a/lib/rsa/rsa-verify.c
+++ b/lib/rsa/rsa-verify.c
@@ -12,6 +12,7 @@
#include asm/errno.h
#include asm/types.h
#include asm/unaligned.h
+#include dm.h
#else
#include fdt_host.h
#include mkimage.h
@@ -43,6 +44,9 @@ static int rsa_verify_key(struct key_prop *prop, const
uint8_t *sig,
const uint8_t *padding;
int pad_len;
int ret;
+#if defined(CONFIG_DM_RSA) !defined(USE_HOSTCC)
+ struct udevice *rsa_dev;
+#endif
if (!prop || !sig || !hash || !algo)
return -EIO;
@@ -63,11 +67,25 @@ static int rsa_verify_key(struct key_prop *prop,
const uint8_t *sig,
uint8_t buf[sig_len];
+#if defined(CONFIG_DM_RSA) !defined(USE_HOSTCC)
+ ret = uclass_get_device(UCLASS_RSA, 0, rsa_dev);
+ if (!ret) {
+ ret = rsa_mod_exp(rsa_dev, sig, sig_len, prop, buf);
+ if (ret) {
+ debug(Error in Modular
Re: [U-Boot] [PATCH 9/9] [v3] rsa: Use checksum algorithms from struct hash_algo
Hi Ruchika,
On 29 December 2014 at 00:59, Ruchika Gupta ruchika.gu...@freescale.com wrote:
Hi Simon,
-Original Message-
From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
Sent: Wednesday, December 24, 2014 6:20 AM
To: Gupta Ruchika-R66431
Cc: U-Boot Mailing List; Sun York-R58495
Subject: Re: [PATCH 9/9] [v3] rsa: Use checksum algorithms from struct
hash_algo
Hi Ruchika,
On 23 December 2014 at 04:32, Ruchika Gupta ruchika.gu...@freescale.com
wrote:
Currently the hash functions used in RSA are called directly from the
sha1 and sha256 libraries. Change the RSA checksum library to use the
progressive hash API's registered with struct hash_algo. This will
allow the checksum library to use the hardware accelerated progressive hash
API's once available.
Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com
CC: Simon Glass s...@chromium.org
---
Changes in v3:
Modified rsa-verify to check for return from checksum function
Changes in v2:
Added generic function hash_calculate. Pass an additional argument as
name of algorithm.
common/image-sig.c| 6 ++---
include/image.h | 5 ++--
include/u-boot/rsa-checksum.h | 7 +++---
lib/rsa/rsa-checksum.c| 53
+++
lib/rsa/rsa-verify.c | 7 +-
5 files changed, 64 insertions(+), 14 deletions(-)
diff --git a/common/image-sig.c b/common/image-sig.c index
8601eda..2c9f0cd 100644
--- a/common/image-sig.c
+++ b/common/image-sig.c
@@ -38,7 +38,7 @@ struct checksum_algo checksum_algos[] = { #if
IMAGE_ENABLE_SIGN
EVP_sha1,
#endif
- sha1_calculate,
+ hash_calculate,
padding_sha1_rsa2048,
},
{
@@ -48,7 +48,7 @@ struct checksum_algo checksum_algos[] = { #if
IMAGE_ENABLE_SIGN
EVP_sha256,
#endif
- sha256_calculate,
+ hash_calculate,
padding_sha256_rsa2048,
},
{
@@ -58,7 +58,7 @@ struct checksum_algo checksum_algos[] = { #if
IMAGE_ENABLE_SIGN
EVP_sha256,
#endif
- sha256_calculate,
+ hash_calculate,
padding_sha256_rsa4096,
}
diff --git a/include/image.h b/include/image.h index af30d60..ec55f23
100644
--- a/include/image.h
+++ b/include/image.h
@@ -926,8 +926,9 @@ struct checksum_algo { #if IMAGE_ENABLE_SIGN
const EVP_MD *(*calculate_sign)(void); #endif
- void (*calculate)(const struct image_region region[],
- int region_count, uint8_t *checksum);
+ int (*calculate)(const char *name,
+const struct image_region region[],
+int region_count, uint8_t *checksum);
const uint8_t *rsa_padding;
};
diff --git a/include/u-boot/rsa-checksum.h
b/include/u-boot/rsa-checksum.h index c996fb3..c546c80 100644
--- a/include/u-boot/rsa-checksum.h
+++ b/include/u-boot/rsa-checksum.h
@@ -16,9 +16,8 @@ extern const uint8_t padding_sha256_rsa4096[];
extern const uint8_t padding_sha256_rsa2048[]; extern const uint8_t
padding_sha1_rsa2048[];
-void sha256_calculate(const struct image_region region[], int
region_count,
- uint8_t *checksum);
-void sha1_calculate(const struct image_region region[], int region_count,
- uint8_t *checksum);
+int hash_calculate(const char *name,
+ const struct image_region region[], int region_count,
+ uint8_t *checksum);
This could use a function comment.
#endif
diff --git a/lib/rsa/rsa-checksum.c b/lib/rsa/rsa-checksum.c index
8d8b59f..7f1909a 100644
--- a/lib/rsa/rsa-checksum.c
+++ b/lib/rsa/rsa-checksum.c
@@ -10,12 +10,13 @@
#include asm/byteorder.h
#include asm/errno.h
#include asm/unaligned.h
+#include hash.h
#else
#include fdt_host.h
-#endif
-#include u-boot/rsa.h
#include u-boot/sha1.h
#include u-boot/sha256.h
+#endif
+#include u-boot/rsa.h
/* PKCS 1.5 paddings as described in the RSA PKCS#1 v2.1 standard. */
@@ -136,7 +137,33 @@ const uint8_t padding_sha256_rsa4096[RSA4096_BYTES -
SHA256_SUM_LEN] = {
0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20 };
-void sha1_calculate(const struct image_region region[], int
region_count,
+#ifndef USE_HOSTCC
+int hash_calculate(const char *name,
+ const struct image_region region[],
+ int region_count, uint8_t *checksum) {
+ struct hash_algo *algo;
+ int ret = 0;
+ void *ctx;
+ uint32_t i;
+ i = 0;
+
+ ret = hash_progressive_lookup_algo(name, algo);
+ if (ret)
+ return ret;
+
+ algo-hash_init(algo, ctx);
+ for (i = 0; i region_count - 1; i++)
+
Re: [U-Boot] [PATCH 8/9] [v3] hash: Add function to find hash_algo struct with progressive hash
+Wolfgang Hi Ruchika, On 29 December 2014 at 00:07, Ruchika Gupta ruchika.gu...@freescale.com wrote: Hi Simon, -Original Message- From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass Sent: Wednesday, December 24, 2014 6:20 AM To: Gupta Ruchika-R66431 Cc: U-Boot Mailing List; Sun York-R58495 Subject: Re: [PATCH 8/9] [v3] hash: Add function to find hash_algo struct with progressive hash Hi Ruchika, On 23 December 2014 at 04:32, Ruchika Gupta ruchika.gu...@freescale.com wrote: The hash_algo structure has some implementations in which progressive hash API's are not defined. These are basically the hardware based implementations of SHA. An API is added to find the algo which has progressive hash API's defined. This can then be integrated with RSA checksum library which uses Progressive Hash API's. Signed-off-by: Ruchika Gupta ruchika.gu...@freescale.com CC: Simon Glass s...@chromium.org --- Changes in v3 : Corrected ifdef for SHA1 Changes in v2 : Added commit message common/hash.c | 33 - include/hash.h | 15 +++ 2 files changed, 39 insertions(+), 9 deletions(-) diff --git a/common/hash.c b/common/hash.c index 12d6759..ea1ec60 100644 --- a/common/hash.c +++ b/common/hash.c @@ -20,7 +20,7 @@ #include asm/io.h #include asm/errno.h -#ifdef CONFIG_CMD_SHA1SUM +#ifdef CONFIG_SHA1 I'm still not sure about this. I suspect this will bloat the code for boards that use CONFIG_SHA1 (most) but not CONFIG_CMD_SHA1SUM. You could check that, but I went through some contortions to make sure that the hash API was not compiled in when not needed. Since we will be using this API now in RSA checksum, defining CONFIG_SHA1 should allow the compilation of this structure. Asking user to enable CONFIG_CMD_SHA1SUM for using rsa-checksum doesn’t look right. Please suggest. Agreed it doesn't, it was just a code size hack. Wolfgang might be able to chime in with thoughts here (+Cc). But still, do you need to change it? After all, CONFIG_CMD_SHA1SUM should be a superest for CONFIG_SHA1. [snip] Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] initcall: add explicit hint if initcall was relocated
On 27 December 2014 at 15:35, Alexey Brodkin alexey.brod...@synopsys.com wrote: Commit initcall: Improve debugging support makes sense and indeed simplifies process of matching initcalls executed with static disassembly. Until you are debugging relocation functionality. Existign output may make you think that at some point execution somehow returned back to non-relocated area. And there're many reasons/problems that may provoke this behavior. In order to make things clear let's add explicit mention in case initall was actually relocated like this: -- initcall: 810015f8 Relocation Offset is: 0efcf000 Relocating to 8ffcf000, new gd at 8fdced3c, sp at 8fdced20 initcall: 810015b8 initcall: 8ffd093c initcall: 8ffd0a14 initcall: 81001940 (relocated to 8ffd0940) initcall: 81001958 (relocated to 8ffd0958) -- Note unexpected jump from 0x8f... area to 0x81... area. Without explanation this raises many questions: execution jumped in relocated area right as expected and then for some reason returned back? But I hope comment in brackets will save some time for those curious developers who are careful enough to catch unexpected jump to pre-reloc area or those unlucky ones who'll have to deal with relocation debugging. Signed-off-by: Alexey Brodkin abrod...@synopsys.com Cc: Simon Glass s...@chromium.org Cc: Minkyu Kang mk7.k...@samsung.com --- lib/initcall.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) Acked-by: Simon Glass s...@chromium.org ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Exynos: Move down common USB configuration
USB is a pretty common feature on exynos 5 board, so it seems sensible to configure it directly from exynos5-common. As a side-effect this makes USB available from u-boot on exynos 5420 based boards. While there enable support for common USB ethernet cards to make it more likely the default config allows booting for network and enable XHCI on SMDK5420 which has it defined in the dts but not in its config. Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk Acked-by: Simon Glass s...@chromium.org --- Changes in v2: Rebased on u-boot-samsung (fb56435f504b40) include/configs/arndale.h | 4 include/configs/exynos5-common.h| 10 ++ include/configs/exynos5250-common.h | 5 - include/configs/exynos5420-common.h | 2 -- include/configs/smdk5420.h | 4 5 files changed, 14 insertions(+), 11 deletions(-) diff --git a/include/configs/arndale.h b/include/configs/arndale.h index 81e8a7c..6bd27a2 100644 --- a/include/configs/arndale.h +++ b/include/configs/arndale.h @@ -24,10 +24,6 @@ #define CONFIG_USB_EHCI #define CONFIG_USB_EHCI_EXYNOS -#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 -#define CONFIG_USB_HOST_ETHER -#define CONFIG_USB_ETHER_ASIX - /* MMC SPL */ #define CONFIG_EXYNOS_SPL diff --git a/include/configs/exynos5-common.h b/include/configs/exynos5-common.h index 8f9b780..ad63f3c 100644 --- a/include/configs/exynos5-common.h +++ b/include/configs/exynos5-common.h @@ -174,6 +174,16 @@ #define CONFIG_CMD_GPIO +/* USB */ +#define CONFIG_CMD_USB +#define CONFIG_USB_STORAGE +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 3 +#define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2 + +#define CONFIG_USB_HOST_ETHER +#define CONFIG_USB_ETHER_ASIX +#define CONFIG_USB_ETHER_SMSC95XX + /* USB boot mode */ #define CONFIG_USB_BOOTING #define EXYNOS_COPY_USB_FNPTR_ADDR 0x02020070 diff --git a/include/configs/exynos5250-common.h b/include/configs/exynos5250-common.h index a0107e8..6714313 100644 --- a/include/configs/exynos5250-common.h +++ b/include/configs/exynos5250-common.h @@ -22,11 +22,6 @@ #define CONFIG_SPL_MAX_FOOTPRINT (14 * 1024) -/* USB */ -#define CONFIG_CMD_USB -#define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2 -#define CONFIG_USB_STORAGE - #define CONFIG_SPL_TEXT_BASE 0x02023400 #define CONFIG_IRAM_STACK 0x0205 diff --git a/include/configs/exynos5420-common.h b/include/configs/exynos5420-common.h index 7322f33..fe72bd0 100644 --- a/include/configs/exynos5420-common.h +++ b/include/configs/exynos5420-common.h @@ -38,6 +38,4 @@ #define CONFIG_BOARD_REV_GPIO_COUNT2 -#define CONFIG_SYS_USB_XHCI_MAX_ROOT_PORTS 2 - #endif /* __CONFIG_EXYNOS5420_H */ diff --git a/include/configs/smdk5420.h b/include/configs/smdk5420.h index 6b45948..61f582f 100644 --- a/include/configs/smdk5420.h +++ b/include/configs/smdk5420.h @@ -34,6 +34,10 @@ #define CONFIG_IDENT_STRING for SMDK5420 #define CONFIG_DEFAULT_CONSOLE console=ttySAC1,115200n8\0 +/* USB */ +#define CONFIG_USB_XHCI +#define CONFIG_USB_XHCI_EXYNOS + /* DRAM Memory Banks */ #define CONFIG_NR_DRAM_BANKS 7 #define SDRAM_BANK_SIZE(512UL 20UL) /* 512 MB */ -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] vexpress64: get rid of CONFIG_SYS_EXTRA_OPTIONS
On Wed, Dec 24, 2014 at 02:02:59AM +0100, Linus Walleij wrote: The Versatile Express ARMv8 semihosted FVP platform is still using the legacy CONFIG_SYS_EXTRA_OPTIONS method to configure some compile-time flags. Get rid of this and create a Kconfig entry for the FVP model, and a selectable bool for the semihosting library. The FVP subboard is now modeled as a target choice so we can eventually choose between different ARMv8 versatile express boards (FVP, base model, Juno...) this way. All dependent symbols are updated to reflect this. The 64bit Versatile Express board symbols are renamed VEXPRESS64 so we have some chance to see what is actually going on. Tested on the FVP fast model. Signed-off-by: Linus Walleij linus.wall...@linaro.org This breaks building of vexpress_aemv8a by itself, at least for me: GEN include/autoconf.mk In file included from ../include/common.h:18:0: include/config.h:4:22: fatal error: configs/.h: No such file or directory #include configs/.h -- 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] [PATCH 4/4] vexpress64: support the Juno Development Platform
On Wed, Dec 24, 2014 at 02:03:16AM +0100, Linus Walleij wrote: The Juno Development Platform is a physical Versatile Express device with some differences from the emulated semihosting models. The main difference is that the system is split in a SoC and an FPGA where the SoC hosts the serial ports at totally different adresses. Ah so that's what it was, thanks! [snip] @@ -21,9 +21,11 @@ #define CONFIG_REMAKE_ELF -#ifndef CONFIG_TARGET_VEXPRESS64_BASE_FVP +#if !defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP) \ +!defined(CONFIG_TARGET_VEXPRESS64_JUNO) /* Base FVP and Juno not using GICv3 yet */ #define CONFIG_GICV3 +//#define CONFIG_GICV2 No // style comments. -- 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] coreboot uboot qemu x86
Hi Simon I executed the commands mentioned above. But getting LZMA decode error on coreboot coreboot.rom: 256 kB, bootblocksize 944, romsize 262144, offset 0x0 alignment: 64 bytes, architecture: x86 Name Offset Type Size cmos_layout.bin0x0cmos_layout 1160 fallback/romstage 0x4c0 stage17960 fallback/ramstage 0x4b40 stage56161 config 0x12700raw 2986 revision 0x13300raw 692 (empty)0x13600null 181720 ./cbfstool ../../coreboot.rom add-flat-binary -v -f /home/ajoy/CISCO-2/uboot/u-boot/u-boot-dtb.bin -n fallback/payload -c lzma -l 0111 -e 1110015 fallback/payload 0x13600payload 173965 code (LZMA compression, offset: 0x38, load: 0x49000, length: 173909/391062) entry (0x10efff) (empty)0x3de00null 7640 Wrote coreboot table at: 3ffce000, 0x154 bytes, checksum 8ea6 coreboot table: 364 bytes. CBMEM ROOT 0. 3000 1000 CAR GLOBALS 1. 3fffe000 1000 ROMSTAGE2. 3fffd000 1000 GDT 3. 3fffc000 1000 IRQ TABLE 4. 3fffb000 1000 ACPI5. 3ffd7000 00024000 SMBIOS 6. 3ffd6000 1000 COREBOOT7. 3ffce000 8000 CBFS: located payload @ fffd3638, 173965 bytes. Loading segment from rom address 0xfffd3638 code (compression=1) New segment dstaddr 0x49000 memsize 0x5f796 srcaddr 0xfffd3670 filesize 0x2a755 (cleaned up) New segment addr 0x49000 size 0x5f796 offset 0xfffd3670 filesize 0x2a755 Loading segment from rom address 0xfffd3654 Entry Point 0x0010efff Payload being loaded below 1MiB without region being marked as RAM usable. Bounce Buffer at 3ff77000, 352352 bytes Loading Segment: addr: 0x00049000 memsz: 0x0005f796 filesz: 0x0002a755 lb: [0x0010, 0x0012b030) Post relocation: addr: 0x00049000 memsz: 0x0005f796 filesz: 0x0002a755 using LZMA lzma: Decoding error = 1 Could not load payload Thanks Ajoy On Mon, Dec 29, 2014 at 9:28 PM, Simon Glass s...@chromium.org wrote: Hi Ajoy, On 29 December 2014 at 07:34, Ajoy Das dasajo...@gmail.com wrote: Hi Simon Thanks for your reply I have added u-boot ELF as the coreboot payload u-boot: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), statically linked, not stripped. Got this link but its a year old. http://lists.denx.de/pipermail/u-boot/2013-July/159140.html Thanks Ajoy Please avoid top posting as it doesn't work well on mailing lists. I suggest using cbfstool add-flat-binary -f u-boot-dtb.bin -n fallback/payload -c lzma -l text_base -e entry For text_base use CONFIG_SYS_TEXT_BASE which is probably 111 For entry use _start which is probably 1110015. Of course I'm not sure whether your problem is with Coreboot, U-Boot or qemu, but we'll see. Also, please can you reply to the list with instructions when you get it working, or send a patch to doc/README.x86. Regards, Simon On Mon, Dec 29, 2014 at 7:36 PM, Simon Glass s...@chromium.org wrote: Hi, On 28 December 2014 at 21:38, Ajoy Das dasajo...@gmail.com wrote: Hi Need Help I want to run U-BOOT as coreboot payload on QEMU platform I am on uboot-x86 git Compiled U-BOOT with make coreboot-x86_defconfig and make all Running qemu with qemu-system-i386 -bios ../coreboot/build/coreboot.rom -hda disk.img -nographic -m 1g But The system crashes with the following message qemu: fatal: Trying to execute code outside RAM or ROM at 0x5e2a36c2 Loading Segment: addr: 0x0111 memsz: 0x000588e8 filesz: 0x000252eb lb: [0x0010, 0x0012b030) Post relocation: addr: 0x0111 memsz: 0x000588e8 filesz: 0x000252eb using LZMA [ 0x0111, 011688e8, 0x011688e8) - fffd2770 dest 0111, end 011688e8, bouncebuffer 3ff77000 Loaded segments Jumping to boot code at 01110015 CPU0: stack: 00126000 - 00127000, lowest used address 00126b8c, stack used: 1140 bytes entry= 0x01110015 lb_start = 0x0010 lb_size = 0x0002b030 buffer = 0x3ff77000 qemu: fatal: Trying to execute code outside RAM or ROM at 0x5e2a36c2 EAX=000a EBX=000186a0 ECX=01145d15 EDX=19203eb0 ESI= EDI= EBP=01145f6c ESP=01145f54 EIP=5e2a36c2 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0018 00cf9300 DPL=0 DS [-WA] CS =0010 00cf9b00 DPL=0 CS32 [-RA] SS =0018 00cf9300 DPL=0 DS [-WA] DS =0018 00cf9300 DPL=0 DS [-WA] FS =0020 19203f5c 00cf9300 DPL=0 DS [-WA] GS =0018 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR =
Re: [U-Boot] [OpenQuestion] stdint.h and inttypes.h in U-Boot ?
-Gabe, who no longer works in this group
(Also we have 4 threads going so I'm only going to reply to this one)
Hi Masahiro,
On 24 December 2014 at 01:41, Masahiro Yamada yamad...@jp.panasonic.com wrote:
Hi Simon,
On Mon, 22 Dec 2014 21:58:49 -0700
Simon Glass s...@chromium.org wrote:
Until commit 0d296cc2d, U-Boot has used the hard-coded defines like
Linux.
Well it still does, only that it also now has the *option* of using
stdint.h.
No.
It is not Do not worry, it is optional things.
You have changed code here ard threr for the optional feature.
Commit aac618a32 (ext4: Use inttypes for printf() string)
Commit 19ea4678c (Use int64_t for time types)
Commit 6bf672592 (Use uint64_t instead of u64 in put_dec())
Commit c6da9ae8a (Tidy up data sizes and function comment in
display_options)
etc.
These are all very small commits and only deal with 64-bit printf()s.
It seems a small price to pay for the compatibility benefits of
supporting stdint.h. The 32-bit madness is a red herring I think.
Why do you want to 64-bit types and printf()s only,
and leave 32-bit ones hard-coded ?
It is not clear to me.
But anyway it seems like we can fix this problem so that stdint.h can
be included without changing the types, as the kernel apparently does.
This statment implies your intention is *not* to change the typedefs.
If so, why do you want to include stdint.h?
Please explain your main motivation of including stdint.h.
See below.
In my understaing, we should only use ILP32 and LP64 compilers.
short int longlonglong
pointer
ILP32 (32bit system) 1632 3264
32
LP64 (64bit Unix-like system) 1632 6464
64
Whether it is 32bit or 64bit system, we can hard-code
u32/uint32_tas unsigned int
u64/uint64_tas unsigned long long
uintptr_t as unsigned long
We do not need to refer to compiler-provided headers.
Moreover, we __should not__ refer to compiler-provided stdint.h.
Including stdint.h means that we use uint32_t defined by the compiler.
It is unsigned int on some compilers, and unsigned long on
some compilers.
I don't seem to have that problem, or at least I have not noticed it
with printf().
You are not trying to see the problem. You should try.
Go to Linaro page and download the bare-metal toolchain.
http://www.linaro.org/downloads/
Fair enough, I do use Linaro gcc-linaro-arm-linux-gnueabihf-4.8-2013
which doesn't seem to be broken in this way. Obviously I have just not
tried enough compilers, although I did see the problem you describe on
m68k.
Have you check my reply?
http://lists.denx.de/pipermail/u-boot/2014-December/199393.html
If you are mentioning size_t problem on m68k, it is also a red herring, I
think.
It is another issue discussed separately.
OK, my point was just that we don't have a problem with anything other
than 64-bit types at present on the platforms I use.
How do you explain stdint.h? So many projects use it - it is now part
of the C99 standard. Has the world gone mad?
It is trade-off and consistency things.
If you make a decision to use stdint.h, it must be consistent everywhere.
stdint.h gives int{8,16,32,64}_t and uint{8,16,32,64}_t, uintptr_t etc.
We should always use them for fixed-width variable types
and should never use hard-coded ones.
That means we should not use include/linux/types.h and friends
to hard-code u8/u16/u32/u64 etc.
We always have to use PRIxN, PRIdN etc. to avoid printf-related warnings.
For that, compiler-provided inttypes.h must be included.
When you start a new project, you can include stdint.h and inttypes.h
and follow the that rule from the beginning.
You will see horrible things if you try to apply that rule on U-Boot.
I would like to find a solution to this. It does not seem like rocket
science. If we accept that stdint.h is useful (I believe it is) then
we can make it work perhaps as the kernel does. In other words, we can
redefine the types (__INT32_TYPE__ etc.) instead of using the stdint.h
ones. The effect is the same because it is not the bit widths that are
different - it is just the type names.
I disagree about the statement stdint.h is useful.
It is true the kernel includes stdint.h for ARM NEON
as Documentation/arm/kernel_mode_neon.txt,
but it is just one of a few exceptional cases.
The kernel never includes stdint.h in general use-cases.
Right, and neither does U-Boot. We just need to support doing it to
allow other software to build against U-Boot. An example is Chrome OS
verified boot, but I'm sure there will be others, since stdint is a
standard function of C compilers now.
I'm not sure if that is what you are suggesting or not. But it seems
like it
Re: [U-Boot] [RFC PATCH 1/2] cmd_i2c: change variable type for 10bit addressing support
Hi, On 19 December 2014 at 14:23, Simon Glass s...@chromium.org wrote: On 19 December 2014 at 11:34, Masahiro Yamada yamad...@jp.panasonic.com wrote: To store 10bit chip address, the variable type should not be uchar, but uint. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org --- common/cmd_i2c.c | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) Acked-by: Simon Glass s...@chromium.org I feel I should apply this to u-boot-dm as a bug fix, but please let me know if there are any objections. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 2/2] dm: i2c: support 10bit addressing in I2C uclass layer
Hi Masahiro, On 21 December 2014 at 11:53, Simon Glass s...@chromium.org wrote: Hi Masahiro, On 20 December 2014 at 00:25, Masahiro YAMADA yamad...@jp.panasonic.com wrote: Hi Simon, 2014-12-20 6:34 GMT+09:00 Simon Glass s...@chromium.org: Hi Masahiro, On 19 December 2014 at 11:34, Masahiro Yamada yamad...@jp.panasonic.com wrote: Master send to / receive from 10-bit addressed slave devices can be supported by software layer without any hardware change because the LSB 8bit of the slave address is treated as data part. Master Send to a 10bit-addressed slave chip is performed like this: DIRFormat M-S 0 + address[9:8] + R/W(0) M-S address[7:0] M-S data0 M-S data1 ... Master Receive from a 10bit-addressed slave chip is like this: DIRFormat M-S 0 + address[9:8] + R/W(0) M-S address[7:0] (Restart) M-S 10 + address[9:8] + R/W(1) S-M data0 S-M data1 ... Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com Cc: Heiko Schocher h...@denx.de Cc: Simon Glass s...@chromium.org --- drivers/i2c/i2c-uclass.c | 80 +++- include/i2c.h| 4 +++ 2 files changed, 56 insertions(+), 28 deletions(-) Seems like a good idea if we can make it work... But this is driver-specific. Some drivers have hardware to send the address and it isn't part of the message. For example see the tegra driver. So what you have here feels a bit like a hack to me. Can't the driver implement it? If you are trying to avoid driver work to support 10-bit addresses, maybe it should be an option that we can enable for each driver, so we don't break the other drivers? I was writing two I2C drivers on DM, both of which have no dedicated hardware support for 10bit addressing. Of course, the driver could implement it, but it means I put the completely the same code in each of driver. For write transaction, for example, we create a new buffer and copy offset-address + data in Uclass layer. Do I have to create a new buffer again, in my driver, and copy lower-slave-address + offset-address + data ? I see your point! Perhaps, is it a good idea to have it optional? DM_I2C_FLAG_SW_TENBIT - if set, uclass takes care of 10bit addressing by software if unset, each driver is responsible to handle I2C_M_TEN correctly altough I do think 10bit support on U-Boot is urgent necessity... I've thought about this quite a bit. We have only just changed the API to be the same as Linux (the list of messages). It seems wrong to now hack it around, such that the address field only stores the first part of the address in 10-bit mode. Did we like the API or not? I see two options that are somewhat sane and defensible: - Add a helper function in the uclass that the driver can call to turn the address + message into a single stream of bytes (we can avoid a second malloc() by reserving space for the address bytes before the message or similar similar, so long is it is clearly documented) - Allow the driver to request that the message bytes should always contain the address, which would remove the address-processing code from the driver. I think this needs a little more discussion before we decide what to do. Where do you want to take this one? Please see my suggestions above. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] dm: README: recommend u-boot.dtb to try driver-model on sandbox
On 22 December 2014 at 12:57, Simon Glass s...@chromium.org wrote: Hi Masahiro, On 21 December 2014 at 19:49, Masahiro Yamada yamad...@jp.panasonic.com wrote: Hi Simon, On Fri, 19 Dec 2014 13:48:16 -0700 Simon Glass s...@chromium.org wrote: On 19 December 2014 at 06:39, Masahiro Yamada yamad...@jp.panasonic.com wrote: Jagan, On Fri, 19 Dec 2014 18:43:37 +0530 Jagan Teki jagannadh.t...@gmail.com wrote: On 19 December 2014 at 10:46, Masahiro Yamada yamad...@jp.panasonic.com wrote: To enjoy driver-model on sandbox, using device tree is recommended. While we are here, change sandbox_config to sandbox_defconfig too. Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- doc/driver-model/README.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt index 3e2f622..eafa825 100644 --- a/doc/driver-model/README.txt +++ b/doc/driver-model/README.txt @@ -36,9 +36,9 @@ How to try it Build U-Boot sandbox and run it: - make sandbox_config + make sandbox_defconfig make - ./u-boot + ./u-boot -d u-boot.dtb this -d is an optional I suppose without dtb we can able to access dm isn't it? Without -d, DM can still have access to platform data, but arch/sandbox/sandbox.dts provies us more features. With -d u-boot.dtb, you will notice a difference at glance: cyan terminal. Acked-by: Simon Glass s...@chromium.org Masahiro, do you think U-Boot should automatically pick up u-boot.dtb in the same directory as the executable, unless -d gives another file? I suppose we could add a '--nodtb' option too. I generally do not like programs to do what I do not ask to do behind the scene, so I personally think it should be as it is. (If you want to save -d u-boot.dtb, you can use CONFIG_OF_EMBED) OK, let's leave it then. I suppose another option would be -D to cause it to search for u-boot.dtb. I do find it something of a pain to type each time. This is a sandbox commit. Applied to u-boot-x86 branch misc. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] i2c_eeprom: include linux/err.h to fix build error
On 18 December 2014 at 06:18, Simon Glass s...@chromium.org wrote: On 18 December 2014 at 04:00, Masahiro Yamada yamad...@jp.panasonic.com wrote: drivers/misc/i2c_eeprom.c fails to build unless CONFIG_FIT_SIGNATURE is defined. CC drivers/misc/i2c_eeprom.o drivers/misc/i2c_eeprom.c: In function 'i2c_eeprom_read': drivers/misc/i2c_eeprom.c:15:10: error: 'ENODEV' undeclared (first use in this function) drivers/misc/i2c_eeprom.c:15:10: note: each undeclared identifier is reported only once for each function it appears in drivers/misc/i2c_eeprom.c: In function 'i2c_eeprom_write': drivers/misc/i2c_eeprom.c:21:10: error: 'ENODEV' undeclared (first use in this function) drivers/misc/i2c_eeprom.c:22:1: warning: control reaches end of non-void function [-Wreturn-type] drivers/misc/i2c_eeprom.c: In function 'i2c_eeprom_read': drivers/misc/i2c_eeprom.c:16:1: warning: control reaches end of non-void function [-Wreturn-type] make[2]: *** [drivers/misc/i2c_eeprom.o] Error 1 make[1]: *** [drivers/misc] Error 2 make: *** [drivers] Error 2 By the way, Sandbox (enabling CONFIG_FIT_SIGNATURE) is luckily working depending on it. Sandbox includes include/asm-generic/errno.h from include/errno.h from include/u-boot/rsa-checksum.h from include/image.h from include/common.h from drivers/misc/i2c_eeprom.c Signed-off-by: Masahiro Yamada yamad...@jp.panasonic.com --- drivers/misc/i2c_eeprom.c | 1 + 1 file changed, 1 insertion(+) Thanks! Acked-by: Simon Glass s...@chromium.org Applied to u-boot-x86 branch misc. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cros-ec-keyboard: Synchronize DT binding from linux
On 17 December 2014 at 20:41, Simon Glass s...@chromium.org wrote: Hi, On 16 December 2014 at 01:03, Sjoerd Simons sjoerd.sim...@collabora.co.uk wrote: On Mon, 2014-12-15 at 23:34 +0100, Pavel Machek wrote: On Thu 2014-11-27 16:34:08, Sjoerd Simons wrote: The ChromeOS EC keyboard is used by various different chromebooks. Peach pi being the third board in the u-boot tree to use it (snow and peach pit the other two). Rather then embedding the same big DT node in the peach-pi DT again, copy the dtsi snippit bindings documentation from linux and include it in all 3 boards. This slightly changes the dt bindings in u-boot: ... * google,repeat-delay-ms and google,repeat-rate-ms are no longer used and replaced by hardcoded values (similar to tegra kbc) If more than one board needs this (and it clearly does) it would be good to make the binding official...? I guess that means talking to linux Documentation/devicetree maintainers... Device tree is for describing hardware, while repeat rate delay are user preferences, not something inherent to the hardware. As such, those properties do not belong in device-tree in the first place. Fwiw, Linux by default uses a delay of 250ms and a period of 33ms unless the driver handles auto-repeat (e.g. for PS2 which does repeat in hardware). If your goal is to fix the hardcoding of these values in various drivers, it's probably better to make u-boot input core have sane defaults for repeat rather then pushing it out into device-tree. This patch could be adjusted to drop the common keyboard file, which is now in mainline. But on the other hand, it will probably apply cleaning for Minkyu. I'll pick this up and apply it on top of my previous change. Applied to u-boot-x86 branch misc, thanks! - Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-x86.git branch misc
Hi Tom, Here are a few misc fixes and updates. Note that the branch is 'misc' (there is also a 'master' branch pull out there). The following changes since commit d8bec60c1b0de7770f9b56ad092ab9be801d99af: ARM: UniPhier: enable CONFIG_CMD_DM (2014-12-18 23:34:30 +0900) are available in the git repository at: git://git.denx.de/u-boot-x86.git for you to fetch changes up to 90f20e002e16c53f7857740a5e6baaa7183f584c: cros-ec-keyboard: Synchronize DT binding from linux (2014-12-29 15:02:02 -0700) Masahiro Yamada (2): dm: README: recommend u-boot.dtb to try driver-model on sandbox i2c_eeprom: include linux/err.h to fix build error Sjoerd Simons (1): cros-ec-keyboard: Synchronize DT binding from linux arch/arm/dts/exynos5250-snow.dts| 59 +++ arch/arm/dts/exynos5420-peach-pit.dts | 59 +++ arch/arm/dts/exynos5800-peach-pi.dts| 4 +++- doc/device-tree-bindings/input/cros-ec-keyb.txt | 53 +++-- doc/driver-model/README.txt | 4 ++-- drivers/input/cros_ec_keyb.c| 16 ++-- drivers/misc/i2c_eeprom.c | 1 + 7 files changed, 41 insertions(+), 155 deletions(-) Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] coreboot uboot qemu x86
Hi Ajoy, On Mon, Dec 29, 2014 at 9:28 PM, Simon Glass s...@chromium.org wrote: Hi Ajoy, On Mon, Dec 29, 2014 at 7:36 PM, Simon Glass s...@chromium.org wrote: Hi, On 28 December 2014 at 21:38, Ajoy Das dasajo...@gmail.com wrote: Hi Need Help I want to run U-BOOT as coreboot payload on QEMU platform I am on uboot-x86 git Compiled U-BOOT with make coreboot-x86_defconfig and make all Running qemu with qemu-system-i386 -bios ../coreboot/build/coreboot.rom -hda disk.img -nographic -m 1g But The system crashes with the following message qemu: fatal: Trying to execute code outside RAM or ROM at 0x5e2a36c2 Loading Segment: addr: 0x0111 memsz: 0x000588e8 filesz: 0x000252eb lb: [0x0010, 0x0012b030) Post relocation: addr: 0x0111 memsz: 0x000588e8 filesz: 0x000252eb using LZMA [ 0x0111, 011688e8, 0x011688e8) - fffd2770 dest 0111, end 011688e8, bouncebuffer 3ff77000 Loaded segments Jumping to boot code at 01110015 CPU0: stack: 00126000 - 00127000, lowest used address 00126b8c, stack used: 1140 bytes entry= 0x01110015 lb_start = 0x0010 lb_size = 0x0002b030 buffer = 0x3ff77000 qemu: fatal: Trying to execute code outside RAM or ROM at 0x5e2a36c2 EAX=000a EBX=000186a0 ECX=01145d15 EDX=19203eb0 ESI= EDI= EBP=01145f6c ESP=01145f54 EIP=5e2a36c2 EFL=0002 [---] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0018 00cf9300 DPL=0 DS [-WA] CS =0010 00cf9b00 DPL=0 CS32 [-RA] SS =0018 00cf9300 DPL=0 DS [-WA] DS =0018 00cf9300 DPL=0 DS [-WA] FS =0020 19203f5c 00cf9300 DPL=0 DS [-WA] GS =0018 00cf9300 DPL=0 DS [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 19203e60 0047 IDT= CR0=6033 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 CCS=0218 CCD=01145f50 CCO=ADDL EFER= FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= Aborted (core dumped) qemu-system-i386 --version QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard Is QEMU not supported for coreboot and u-boot I'm not sure it's been tried but there's no reason why it should work. It seems to be crashing in U-Boot before there is any serial output. Did you put u-boot-dtb.bin as the payload? On 29 December 2014 at 07:34, Ajoy Das dasajo...@gmail.com wrote: Hi Simon Thanks for your reply I have added u-boot ELF as the coreboot payload u-boot: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), statically linked, not stripped. Got this link but its a year old. http://lists.denx.de/pipermail/u-boot/2013-July/159140.html Thanks Ajoy [snip] I suggest using cbfstool add-flat-binary -f u-boot-dtb.bin -n fallback/payload -c lzma -l text_base -e entry For text_base use CONFIG_SYS_TEXT_BASE which is probably 111 For entry use _start which is probably 1110015. Of course I'm not sure whether your problem is with Coreboot, U-Boot or qemu, but we'll see. Also, please can you reply to the list with instructions when you get it working, or send a patch to doc/README.x86. PLEASE add your reply below mine, not above. I have gone to the trouble of rearranging the thread for this email. Also leave me on Cc otherwise I might not see your reply. On 29 December 2014 at 14:31, Ajoy Das dasajo...@gmail.com wrote: Hi Simon I executed the commands mentioned above. But getting LZMA decode error on coreboot coreboot.rom: 256 kB, bootblocksize 944, romsize 262144, offset 0x0 alignment: 64 bytes, architecture: x86 Name Offset Type Size cmos_layout.bin0x0cmos_layout 1160 fallback/romstage 0x4c0 stage17960 fallback/ramstage 0x4b40 stage56161 config 0x12700raw 2986 revision 0x13300raw 692 (empty)0x13600null 181720 ./cbfstool
[U-Boot] [PATCH 02/10] x86: Add checksum implementation
Add a checksum implementation that can be used with CMOS RAM.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/Makefile | 1 +
arch/x86/cpu/ip_checksum.c | 61 ++
arch/x86/include/asm/ip_checksum.h | 16 ++
3 files changed, 78 insertions(+)
create mode 100644 arch/x86/cpu/ip_checksum.c
create mode 100644 arch/x86/include/asm/ip_checksum.h
diff --git a/arch/x86/cpu/Makefile b/arch/x86/cpu/Makefile
index 62e43c0..eee2289 100644
--- a/arch/x86/cpu/Makefile
+++ b/arch/x86/cpu/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_SYS_COREBOOT) += coreboot/
obj-$(CONFIG_NORTHBRIDGE_INTEL_SANDYBRIDGE) += ivybridge/
obj-$(CONFIG_NORTHBRIDGE_INTEL_IVYBRIDGE) += ivybridge/
obj-$(CONFIG_INTEL_QUEENSBAY) += queensbay/
+obj-y += ip_checksum.o
obj-y += lapic.o
obj-y += mtrr.o
obj-$(CONFIG_PCI) += pci.o
diff --git a/arch/x86/cpu/ip_checksum.c b/arch/x86/cpu/ip_checksum.c
new file mode 100644
index 000..17f9417
--- /dev/null
+++ b/arch/x86/cpu/ip_checksum.c
@@ -0,0 +1,61 @@
+/*
+ * From Coreboot compute_ip_checksum.c
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include common.h
+#include asm/ip_checksum.h
+
+/* This function is functionally the same as NetCksum() - should we unify? */
+unsigned long compute_ip_checksum(void *addr, unsigned long length)
+{
+ uint8_t *ptr;
+ union {
+ uint8_t byte[2];
+ uint16_t word;
+ } value;
+ unsigned long sum;
+ unsigned long i;
+
+ sum = 0;
+ ptr = addr;
+ for (i = 0; i length; i++) {
+ unsigned long v;
+
+ v = ptr[i];
+ if (i 1)
+ v = 8;
+ /* Add the new value */
+ sum += v;
+ /* Wrap around the carry */
+ if (sum 0x)
+ sum = (sum + (sum 16)) 0x;
+ }
+ value.byte[0] = sum 0xff;
+ value.byte[1] = (sum 8) 0xff;
+ return (~value.word) 0x;
+}
+
+unsigned long add_ip_checksums(unsigned long offset, unsigned long sum,
+ unsigned long new)
+{
+ unsigned long checksum;
+
+ sum = ~sum 0x;
+ new = ~new 0x;
+ if (offset 1) {
+ /*
+* byte-swap the sum if it came from an odd offset; since the
+* computation is endian independant this works.
+*/
+ new = ((new 8) 0xff) | ((new 8) 0xff00);
+ }
+ checksum = sum + new;
+ if (checksum 0x)
+ checksum -= 0x;
+
+ return (~checksum) 0x;
+}
diff --git a/arch/x86/include/asm/ip_checksum.h
b/arch/x86/include/asm/ip_checksum.h
new file mode 100644
index 000..6553d7b
--- /dev/null
+++ b/arch/x86/include/asm/ip_checksum.h
@@ -0,0 +1,16 @@
+/*
+ * From Coreboot ip_checksum.h
+ *
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#ifndef _IP_CHECKSUM_H
+#define _IP_CHECKSUM_H
+
+unsigned long compute_ip_checksum(void *addr, unsigned long length);
+unsigned long add_ip_checksums(unsigned long offset, unsigned long sum,
+ unsigned long new);
+
+#endif /* IP_CHECKSUM_H */
--
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 06/10] x86: dts: Add SPI flash MRC details for chromebook_link
Correct the SPI flash compatible string, add an alias and specify the
position of the MRC cache, used to store SDRAM training settings for the
Memory Reference Code.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/dts/link.dts | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/x86/dts/link.dts b/arch/x86/dts/link.dts
index 1ebc334..c322510 100644
--- a/arch/x86/dts/link.dts
+++ b/arch/x86/dts/link.dts
@@ -8,6 +8,10 @@
model = Google Link;
compatible = google,link, intel,celeron-ivybridge;
+ aliases {
+ spi0 = /spi;
+ };
+
config {
silent_console = 0;
};
@@ -155,11 +159,20 @@
spi {
#address-cells = 1;
#size-cells = 0;
- compatible = intel,ich9;
+ compatible = intel,ich9-spi;
spi-flash@0 {
+ #size-cells = 1;
+ #address-cells = 1;
reg = 0;
compatible = winbond,w25q64, spi-flash;
memory-map = 0xff80 0x0080;
+ rw-mrc-cache {
+ label = rw-mrc-cache;
+ /* Alignment: 4k (for updating) */
+ reg = 0x003e 0x0001;
+ type = wiped;
+ wipe-value = [ff];
+ };
};
};
--
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 08/10] x86: config: Enable hook for saving MRC configuration
Add a hook to ensure that this information is saved. Signed-off-by: Simon Glass s...@chromium.org --- include/configs/chromebook_link.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/chromebook_link.h b/include/configs/chromebook_link.h index 8930210..22cb134 100644 --- a/include/configs/chromebook_link.h +++ b/include/configs/chromebook_link.h @@ -22,6 +22,7 @@ #define CONFIG_SYS_X86_START16 0xf800 #define CONFIG_BOARD_EARLY_INIT_F #define CONFIG_DISPLAY_CPUINFO +#define CONFIG_MISC_INIT_R #define CONFIG_X86_RESET_VECTOR #define CONFIG_NR_DRAM_BANKS 8 -- 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 04/10] x86: spi: Add device tree support
As a temporary measure before the ICH driver moves over to driver model,
add device tree support to the driver.
Signed-off-by: Simon Glass s...@chromium.org
---
drivers/spi/ich.c| 7 +++
include/configs/x86-common.h | 1 +
2 files changed, 8 insertions(+)
diff --git a/drivers/spi/ich.c b/drivers/spi/ich.c
index 0379444..fdff158 100644
--- a/drivers/spi/ich.c
+++ b/drivers/spi/ich.c
@@ -153,6 +153,13 @@ struct spi_slave *spi_setup_slave(unsigned int bus,
unsigned int cs,
return ich-slave;
}
+struct spi_slave *spi_setup_slave_fdt(const void *blob, int slave_node,
+ int spi_node)
+{
+ /* We only support a single SPI at present */
+ return spi_setup_slave(0, 0, 2000, 0);
+}
+
void spi_free_slave(struct spi_slave *slave)
{
struct ich_spi_slave *ich = to_ich_spi(slave);
diff --git a/include/configs/x86-common.h b/include/configs/x86-common.h
index 4f0a3c5..ecedfc3 100644
--- a/include/configs/x86-common.h
+++ b/include/configs/x86-common.h
@@ -211,6 +211,7 @@
#define CONFIG_CMD_SF_TEST
#define CONFIG_CMD_SPI
#define CONFIG_SPI
+#define CONFIG_OF_SPI_FLASH
/*---
* Environment configuration
--
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 01/10] x86: dts: Add compatible string for Intel ICH9 SPI controller
Add this to the enum so that we can use the various fdtdec functions. A
later commit will move this driver to driver model.
Signed-off-by: Simon Glass s...@chromium.org
---
include/fdtdec.h | 1 +
lib/fdtdec.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index d2b665c..c8e19b5 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -123,6 +123,7 @@ enum fdt_compat_id {
COMPAT_INTEL_PANTHERPOINT_AHCI, /* Intel Pantherpoint AHCI */
COMPAT_INTEL_MODEL_206AX, /* Intel Model 206AX CPU */
COMPAT_INTEL_GMA, /* Intel Graphics Media Accelerator */
+ COMPAT_INTEL_ICH9_SPI, /* Intel ICH9 SPI controller */
COMPAT_COUNT,
};
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 9d86dba..7ada20e 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -78,6 +78,7 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(INTEL_PANTHERPOINT_AHCI, intel,pantherpoint-ahci),
COMPAT(INTEL_MODEL_206AX, intel,model-206ax),
COMPAT(INTEL_GMA, intel,gma),
+ COMPAT(INTEL_ICH9_SPI, intel,ich9-spi),
};
const char *fdtdec_get_compatible(enum fdt_compat_id id)
--
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 05/10] Allow architecture-specific memory reservation
All memory to be reserved for use after relocation by adding a new call
to perform this reservation.
Signed-off-by: Simon Glass s...@chromium.org
---
common/board_f.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/common/board_f.c b/common/board_f.c
index 1b65575..ae5d425 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -807,6 +807,12 @@ static int initf_dm(void)
return 0;
}
+/* Architecture-specific memory reservation */
+__weak int reserve_arch(void)
+{
+ return 0;
+}
+
static init_fnc_t init_sequence_f[] = {
#ifdef CONFIG_SANDBOX
setup_ram_buf,
@@ -968,6 +974,7 @@ static init_fnc_t init_sequence_f[] = {
setup_machine,
reserve_global_data,
reserve_fdt,
+ reserve_arch,
reserve_stacks,
setup_dram_config,
show_dram_config,
--
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 03/10] x86: Add helpers to read/write CMOS RAM
On x86 we use CMOS RAM to read and write some settings. Add basic support
for this.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/include/asm/cmos.h | 181
1 file changed, 181 insertions(+)
create mode 100644 arch/x86/include/asm/cmos.h
diff --git a/arch/x86/include/asm/cmos.h b/arch/x86/include/asm/cmos.h
new file mode 100644
index 000..9e16301
--- /dev/null
+++ b/arch/x86/include/asm/cmos.h
@@ -0,0 +1,181 @@
+/*
+ * Taken from Coreboot mc146818rtc.h
+ * TODO: This should be an RTC driver
+
+ * Copyright (c) 2014 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#ifndef __ASM_CMOS_H
+#define __ASM_CMOS_H
+
+#include asm/io.h
+
+#define RTC_BASE_PORT 0x70
+
+#define RTC_PORT(x)(RTC_BASE_PORT + (x))
+
+/* Control registers - Moto names */
+#define RTC_REG_A 10
+#define RTC_REG_B 11
+#define RTC_REG_C 12
+#define RTC_REG_D 13
+
+
+/* register details */
+#define RTC_FREQ_SELECTRTC_REG_A
+
+/*
+ * update-in-progress - set to 1 244 microsecs before RTC goes off the bus,
+ * reset after update (may take 1.984ms @ 32768Hz RefClock) is complete,
+ * totalling to a max high interval of 2.228 ms.
+ */
+#define RTC_UIP0x80
+#define RTC_DIV_CTL0x70
+/* divider control: refclock values 4.194 / 1.049 MHz / 32.768 kHz */
+#define RTC_REF_CLCK_4MHZ 0x00
+#define RTC_REF_CLCK_1MHZ 0x10
+#define RTC_REF_CLCK_32KHZ 0x20
+/* 2 values for divider stage reset, others for testing purposes only */
+#define RTC_DIV_RESET1 0x60
+#define RTC_DIV_RESET2 0x70
+/* Periodic intr. / Square wave rate select. 0=none, 1=32.8kHz,... 15=2Hz */
+#define RTC_RATE_SELECT0x0f
+#define RTC_RATE_NONE 0x00
+#define RTC_RATE_32786HZ 0x01
+#define RTC_RATE_16384HZ 0x02
+#define RTC_RATE_8192HZ0x03
+#define RTC_RATE_4096HZ0x04
+#define RTC_RATE_2048HZ0x05
+#define RTC_RATE_1024HZ0x06
+#define RTC_RATE_512HZ 0x07
+#define RTC_RATE_256HZ 0x08
+#define RTC_RATE_128HZ 0x09
+#define RTC_RATE_64HZ 0x0a
+#define RTC_RATE_32HZ 0x0b
+#define RTC_RATE_16HZ 0x0c
+#define RTC_RATE_8HZ 0x0d
+#define RTC_RATE_4HZ 0x0e
+#define RTC_RATE_2HZ 0x0f
+
+/**/
+#define RTC_CONTROLRTC_REG_B
+#define RTC_SET0x80/* disable updates for clock setting */
+#define RTC_PIE0x40/* periodic interrupt enable */
+#define RTC_AIE0x20/* alarm interrupt enable */
+#define RTC_UIE0x10/* update-finished interrupt enable */
+#define RTC_SQWE 0x08/* enable square-wave output */
+#define RTC_DM_BINARY 0x04/* all time/date values are BCD if clear */
+#define RTC_24H0x02/* 24 hour mode - else hours bit 7
means pm */
+#define RTC_DST_EN 0x01/* auto switch DST - works for USA only */
+
+/**/
+#define RTC_INTR_FLAGS RTC_REG_C
+/* caution - cleared by read */
+#define RTC_IRQF 0x80/* any of the following 3 is active */
+#define RTC_PF 0x40
+#define RTC_AF 0x20
+#define RTC_UF 0x10
+
+/**/
+#define RTC_VALID RTC_REG_D
+#define RTC_VRT0x80/* valid RAM and time */
+/**/
+
+/* Date and Time in RTC CMOS */
+#define RTC_CLK_SECOND 0
+#define RTC_CLK_SECOND_ALARM 1
+#define RTC_CLK_MINUTE 2
+#define RTC_CLK_MINUTE_ALARM 3
+#define RTC_CLK_HOUR 4
+#define RTC_CLK_HOUR_ALARM 5
+#define RTC_CLK_DAYOFWEEK 6
+#define RTC_CLK_DAYOFMONTH 7
+#define RTC_CLK_MONTH 8
+#define RTC_CLK_YEAR 9
+#define RTC_CLK_ALTCENTURY 0x32
+
+/* On PCs, the checksum is built only over bytes 16..45 */
+#define PC_CKS_RANGE_START 16
+#define PC_CKS_RANGE_END 45
+#define PC_CKS_LOC 46
+
+static inline unsigned char cmos_read(unsigned char addr)
+{
+ int offs = 0;
+
+ if (addr = 128) {
+ offs = 2;
+ addr -= 128;
+ }
+ outb(addr, RTC_BASE_PORT + offs + 0);
+
+ return inb(RTC_BASE_PORT + offs + 1);
+}
+
+static inline void cmos_write_inner(unsigned char val, unsigned char addr)
+{
+ int offs = 0;
+
+ if (addr = 128) {
+ offs = 2;
+ addr -= 128;
+ }
+ outb(addr, RTC_BASE_PORT + offs + 0);
+
+ outb(val, RTC_BASE_PORT + offs + 1);
+}
+
+static inline void cmos_write(unsigned char val, unsigned char addr)
+{
+ int control_state = cmos_read(RTC_CONTROL);
+
+ /*
+* There are various
[U-Boot] [PATCH 09/10] x86: ivybridge: Drop the Kconfig MRC cache information
This is now stored in the device tree. Signed-off-by: Simon Glass s...@chromium.org --- arch/x86/cpu/ivybridge/Kconfig | 28 1 file changed, 28 deletions(-) diff --git a/arch/x86/cpu/ivybridge/Kconfig b/arch/x86/cpu/ivybridge/Kconfig index afca957..e4595be 100644 --- a/arch/x86/cpu/ivybridge/Kconfig +++ b/arch/x86/cpu/ivybridge/Kconfig @@ -26,20 +26,6 @@ config CACHE_MRC_SIZE_KB int default 256 -config MRC_CACHE_BASE - hex - default 0xff80 - -config MRC_CACHE_LOCATION - hex - depends on !CHROMEOS - default 0x1ec000 - -config MRC_CACHE_SIZE - hex - depends on !CHROMEOS - default 0x1 - config DCACHE_RAM_BASE hex default 0xff7f @@ -64,20 +50,6 @@ config CACHE_MRC_SIZE_KB int default 512 -config MRC_CACHE_BASE - hex - default 0xff80 - -config MRC_CACHE_LOCATION - hex - depends on !CHROMEOS - default 0x37 - -config MRC_CACHE_SIZE - hex - depends on !CHROMEOS - default 0x1 - config DCACHE_RAM_BASE hex default 0xff7e -- 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 07/10] x86: Implement a cache for Memory Reference Code parameters
The memory reference code takes a very long time to 'train' its SDRAM
interface, around half a second. To avoid this delay on every boot we can
store the parameters from the last training sessions to speed up the next.
Add an implementation of this, storing the training data in CMOS RAM and
SPI flash.
Signed-off-by: Simon Glass s...@chromium.org
---
arch/x86/cpu/ivybridge/Makefile| 1 +
arch/x86/cpu/ivybridge/mrccache.c | 156 ++
arch/x86/cpu/ivybridge/sdram.c | 277 +
arch/x86/include/asm/arch-ivybridge/mrccache.h | 51 +
arch/x86/include/asm/global_data.h | 3 +
5 files changed, 488 insertions(+)
create mode 100644 arch/x86/cpu/ivybridge/mrccache.c
create mode 100644 arch/x86/include/asm/arch-ivybridge/mrccache.h
diff --git a/arch/x86/cpu/ivybridge/Makefile b/arch/x86/cpu/ivybridge/Makefile
index 0c7efae..3576b83 100644
--- a/arch/x86/cpu/ivybridge/Makefile
+++ b/arch/x86/cpu/ivybridge/Makefile
@@ -14,6 +14,7 @@ obj-y += lpc.o
obj-y += me_status.o
obj-y += model_206ax.o
obj-y += microcode_intel.o
+obj-y += mrccache.o
obj-y += northbridge.o
obj-y += pch.o
obj-y += pci.o
diff --git a/arch/x86/cpu/ivybridge/mrccache.c
b/arch/x86/cpu/ivybridge/mrccache.c
new file mode 100644
index 000..182c995
--- /dev/null
+++ b/arch/x86/cpu/ivybridge/mrccache.c
@@ -0,0 +1,156 @@
+/*
+ * From Coreboot src/southbridge/intel/bd82x6x/mrccache.c
+ *
+ * Copyright (C) 2014 Google Inc.
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include common.h
+#include errno.h
+#include fdtdec.h
+#include spi.h
+#include spi_flash.h
+#include asm/ip_checksum.h
+#include asm/arch/mrccache.h
+#include asm/arch/sandybridge.h
+
+static struct mrc_data_container *next_mrc_block(
+ struct mrc_data_container *mrc_cache)
+{
+ /* MRC data blocks are aligned within the region */
+ u32 mrc_size = sizeof(*mrc_cache) + mrc_cache-data_size;
+ if (mrc_size (MRC_DATA_ALIGN - 1UL)) {
+ mrc_size = ~(MRC_DATA_ALIGN - 1UL);
+ mrc_size += MRC_DATA_ALIGN;
+ }
+
+ u8 *region_ptr = (u8 *)mrc_cache;
+ region_ptr += mrc_size;
+ return (struct mrc_data_container *)region_ptr;
+}
+
+static int is_mrc_cache(struct mrc_data_container *cache)
+{
+ return cache (cache-signature == MRC_DATA_SIGNATURE);
+}
+
+/*
+ * Find the largest index block in the MRC cache. Return NULL if none is
+ * found.
+ */
+struct mrc_data_container *mrccache_find_current(struct fmap_entry *entry)
+{
+ struct mrc_data_container *cache, *next;
+ ulong base_addr, end_addr;
+ uint id;
+
+ base_addr = (1ULL 32) - CONFIG_ROM_SIZE + entry-offset;
+ end_addr = base_addr + entry-length;
+ cache = NULL;
+
+ /* Search for the last filled entry in the region */
+ for (id = 0, next = (struct mrc_data_container *)base_addr;
+is_mrc_cache(next);
+id++) {
+ cache = next;
+ next = next_mrc_block(next);
+ if ((ulong)next = end_addr)
+ break;
+ }
+
+ if (id-- == 0) {
+ debug(%s: No valid MRC cache found.\n, __func__);
+ return NULL;
+ }
+
+ /* Verify checksum */
+ if (cache-checksum != compute_ip_checksum(cache-data,
+ cache-data_size)) {
+ printf(%s: MRC cache checksum mismatch\n, __func__);
+ return NULL;
+ }
+
+ debug(%s: picked entry %u from cache block\n, __func__, id);
+
+ return cache;
+}
+
+/**
+ * find_next_mrc_cache() - get next cache entry
+ *
+ * @entry: MRC cache flash area
+ * @cache: Entry to start from
+ *
+ * @return next cache entry if found, NULL if we got to the end
+ */
+static struct mrc_data_container *find_next_mrc_cache(struct fmap_entry *entry,
+ struct mrc_data_container *cache)
+{
+ ulong base_addr, end_addr;
+
+ base_addr = (1ULL 32) - CONFIG_ROM_SIZE + entry-offset;
+ end_addr = base_addr + entry-length;
+
+ cache = next_mrc_block(cache);
+ if ((ulong)cache = end_addr) {
+ /* Crossed the boundary */
+ cache = NULL;
+ debug(%s: no available entries found\n, __func__);
+ } else {
+ debug(%s: picked next entry from cache block at %p\n,
+ __func__, cache);
+ }
+
+ return cache;
+}
+
+int mrccache_update(struct spi_flash *sf, struct fmap_entry *entry,
+ struct mrc_data_container *cur)
+{
+ struct mrc_data_container *cache;
+ ulong offset;
+ ulong base_addr;
+ int ret;
+
+ /* Find the last used block */
+ base_addr = (1ULL 32) - CONFIG_ROM_SIZE + entry-offset;
+ debug(Updating MRC cache data\n);
+ cache = mrccache_find_current(entry);
+ if (cache (cache-data_size == cur-data_size)
[U-Boot] [PATCH 10/10] x86: config: chromebook_link: Enable environment
Enable an environment area. Signed-off-by: Simon Glass s...@chromium.org --- include/configs/chromebook_link.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/chromebook_link.h b/include/configs/chromebook_link.h index 22cb134..9b70435 100644 --- a/include/configs/chromebook_link.h +++ b/include/configs/chromebook_link.h @@ -68,6 +68,11 @@ #define CONFIG_CMD_CROS_EC #define CONFIG_ARCH_EARLY_INIT_R +#undef CONFIG_ENV_IS_NOWHERE +#define CONFIG_ENV_IS_IN_SPI_FLASH +#define CONFIG_ENV_OFFSET 0x003f8000 +#define CONFIG_ENV_SECT_SIZE 256 + #define CONFIG_STD_DEVICES_SETTINGS stdin=usbkbd,vga,serial\0 \ stdout=vga,serial\0 \ stderr=vga,serial\0 -- 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/5] x86: Remove include directory in arch/x86/dts
Hi Simon, On Tue, Dec 30, 2014 at 3:39 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 28 December 2014 at 23:04, Bin Meng bmeng...@gmail.com wrote: Hi Simon, On Sun, Dec 28, 2014 at 9:02 AM, Simon Glass s...@chromium.org wrote: Hi Bin, On 23 December 2014 at 22:06, Bin Meng bmeng...@gmail.com wrote: The include directory in arch/x86/dts is not used, so remove it. Signed-off-by: Bin Meng bmeng...@gmail.com --- Actually we do need this - the Chrome OS keyboard .dtsi will use a binding when I get around to updating it. OK, so maybe we can just put anything we do need into the include instead of a symbolic link to the genric one? The idea as (I understand it) is that include/dt-bindings is the standard directory for all archs to put their bindings. This is how ARM works too. OK, thanks for the clarification. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] x86: ahci: Make sure interface is not busy after enabling the port
Hi Simon,
On Tue, Dec 30, 2014 at 12:33 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 23 December 2014 at 18:42, Bin Meng bmeng...@gmail.com wrote:
Hi Simon,
On Wed, Dec 24, 2014 at 3:42 AM, Simon Glass s...@chromium.org wrote:
Hi Bin,
On 23 December 2014 at 01:01, Bin Meng bmeng...@gmail.com wrote:
Each time U-Boot boots on Intel Crown Bay board, the displayed hard
drive information is wrong. It could be either wrong capacity or just
a 'Capacity: not available' message. After enabling the debug switch,
we can see the scsi inquiry command did not execute successfully.
However, doing a 'scsi scan' in the U-Boot shell does not expose
this issue.
This sounds like an error condition is not being propagated.
Actually an error condition not checked.
SCSI: Target spinup took 0 ms.
SATA link 1 timeout.
AHCI 0001.0100 32 slots 2 ports 3 Gbps 0x3 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part ccc apst
scanning bus for devices...
ahci_device_data_io: 0 byte transferred. --- scsi inquiry fails
ahci_device_data_io: 512 byte transferred.
ahci_device_data_io: 512 byte transferred.
ahci_device_data_io: 512 byte transferred.
Device 0: (0:0) Vendor: ATA Prod.: Rev: ?8
Type: Hard Disk
Capacity: 912968.3 MB = 891.5 GB (1869759264 x
512)
Found 1 device(s).
So uninitialized contents on the stack were passed to dev_print() to
display those wrong information.
The symptom were observed on two hard drives (one is Seagate, the
other one is Western Digital). The fix is to make sure the AHCI
interface is not busy by checking the error and status information
from task file register after enabling the port in ahci_port_start()
before proceeding other operations like scsi_scan().
Signed-off-by: Bin Meng bmeng...@gmail.com
---
drivers/block/ahci.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/block/ahci.c b/drivers/block/ahci.c
index c9a3beb..7ca8f40 100644
--- a/drivers/block/ahci.c
+++ b/drivers/block/ahci.c
@@ -505,8 +505,9 @@ static int ahci_port_start(u8 port)
{
struct ahci_ioports *pp = (probe_ent-port[port]);
volatile u8 *port_mmio = (volatile u8 *)pp-port_mmio;
- u32 port_status;
+ u32 port_status, tf_data;
u32 mem;
+ int i = 0;
debug(Enter start port: %d\n, port);
port_status = readl(port_mmio + PORT_SCR_STAT);
@@ -564,6 +565,18 @@ static int ahci_port_start(u8 port)
PORT_CMD_POWER_ON | PORT_CMD_SPIN_UP |
PORT_CMD_START, port_mmio + PORT_CMD);
+ /*
+* Make sure interface is not busy based on error and status
+* information from task file data register before proceeding
+*/
+ while (i WAIT_MS_SPINUP) {
+ tf_data = readl(port_mmio + PORT_TFDATA);
+ if (!(tf_data ATA_BUSY))
+ break;
+ udelay(1000);
+ i++;
+ }
+
Doesn't this fall through after a timeout and fail to report an error?
Ah, yes! We should return error code when timeout. But some other
routines in the scsi initialization path do no check return values,
like initr_scsi()-scsi_init()-scsi_low_level_init().
I suppose that could be improved separately but does it affect this patch?
No, it doesn't affect this patch. Yes, we could improve those places
with a separate patch.
As a matter of style I think something like the below is better
because it the timeout will be more accurate in the case where you
have a lot of processing each time around the loop.
static int wait_spinup(void)
{
ulong start;
start = get_timer(0);
do {
tf_data = ...;
if (!((tf_data ATA_BUSY))
return 0;
while (get_timer(start) WAIT_MS_SPINUP);
return -ETIMEDOUT;
}
Looks like the original codes there are using i++ style for the
timeout check instead of get_timer().
Also how does this relate to the existing spinup delay code in
ahci_host_init()?
This seems to me they are not related. Per my understanding, the check
we need here is because we write something to the port command
register, but we missed the task file data busy indication.
writel_with_flush(PORT_CMD_ICC_ACTIVE | PORT_CMD_FIS_RX |
PORT_CMD_POWER_ON | PORT_CMD_SPIN_UP |
PORT_CMD_START, port_mmio + PORT_CMD);
[snip]
OK.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 11/17] sunxi: video: Add support for VGA via external DACs connected to the LCD pins
Hi Hans, On Tue, Dec 30, 2014 at 3:25 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 29-12-14 14:51, Ian Campbell wrote: On Wed, 2014-12-24 at 20:06 +0100, Hans de Goede wrote: Add support for external DACs connected to the parallel LCD interface driving a VGA connector, such as found on the Olimex A13 boards. Signed-off-by: Hans de Goede hdego...@redhat.com Acked-by: Ian Campbell i...@hellion.org.uk --- board/sunxi/Kconfig | 9 + drivers/video/sunxi_display.c | 14 ++ 2 files changed, 23 insertions(+) diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig index 7a8503b..3e42866 100644 --- a/board/sunxi/Kconfig +++ b/board/sunxi/Kconfig @@ -253,6 +253,15 @@ config VIDEO_HDMI ---help--- Say Y here to add support for outputting video over HDMI. +config VIDEO_VGA_VIA_LCD + boolean VGA via LCD controller support + depends on VIDEO + default n + ---help--- + Say Y here to add support for external DACs connected to the parallel + LCD interface driving a VGA connector, such as found on the + Olimex A13 boards. But not unique to those boards I take it? Actually sofar it is unique to those boards, both the normal and the Micro variant (in theory we could see something similar on other boards one day). The Hummingbird A31 has the same setup, using an external DAC for the RGB signals, as it doesn't have the TV encoder. See: http://linux-sunxi.org/Merrii_Hummingbird_A31#VGA_out ChenYu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-usb/master
On Thu, Dec 18, 2014 at 12:49:47PM +0100, Marek Vasut wrote: Hi, please find a couple of more fixes for this release. The following changes since commit b9206e61f3d87535ac4f4b0b858e674fd1edfeaf: Merge git://git.denx.de/u-boot-x86 (2014-12-15 17:13:47 -0500) are available in the git repository at: git://git.denx.de/u-boot-usb.git master for you to fetch changes up to 0ff7e585df83470139739533bdbf41114f395470: fastboot: handle flash write to GPT partitions (2014-12-18 12:26:06 +0100) 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-x86.git branch misc
On Mon, Dec 29, 2014 at 03:07:41PM -0700, Simon Glass wrote: Hi Tom, Here are a few misc fixes and updates. Note that the branch is 'misc' (there is also a 'master' branch pull out there). The following changes since commit d8bec60c1b0de7770f9b56ad092ab9be801d99af: ARM: UniPhier: enable CONFIG_CMD_DM (2014-12-18 23:34:30 +0900) are available in the git repository at: git://git.denx.de/u-boot-x86.git for you to fetch changes up to 90f20e002e16c53f7857740a5e6baaa7183f584c: cros-ec-keyboard: Synchronize DT binding from linux (2014-12-29 15:02:02 -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] Pull request: u-boot-sh/rmolbile
On Fri, Dec 26, 2014 at 10:21:39AM +0900, Nobuhiro Iwamatsu wrote: Dear Tom Rini. Please pull u-boot-sh rmobile branch. The following changes since commit d8bec60c1b0de7770f9b56ad092ab9be801d99af: ARM: UniPhier: enable CONFIG_CMD_DM (2014-12-18 23:34:30 +0900) are available in the git repository at: git://git.denx.de/u-boot-sh rmobile for you to fetch changes up to 2a1d2a0351ac14390ccaad6433d27a1c58dab46f: arm: rmobile: kconfig: Remove '+S:' prefix from defconfig files (2014-12-26 10:21:17 +0900) 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-x86.git
On Thu, Dec 18, 2014 at 05:29:39PM -0700, Simon Glass wrote: Hi Tom, Here is the last of the Atom changes - we now have good support for one Atom variant (with a path to adding to it) and basic support for ivybridge. A good start. The following changes since commit d8bec60c1b0de7770f9b56ad092ab9be801d99af: ARM: UniPhier: enable CONFIG_CMD_DM (2014-12-18 23:34:30 +0900) are available in the git repository at: git://git.denx.de/u-boot-x86.git for you to fetch changes up to d2c6181d2d2afe00399cf0c8d9deafcb66b77330: x86: Add a script to process Intel microcode files (2014-12-18 17:26:08 -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] [U-Boot,v3] bcm281xx: add support for USB OTG clock
On Tue, Dec 09, 2014 at 11:40:11AM -0800, Steve Rae wrote: enable this clock with the following: clk_usb_otg_enable((void *)HSOTG_BASE_ADDR) Signed-off-by: Steve Rae s...@broadcom.com Reviewed-by: Felipe Balbi ba...@ti.com 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] common/board_f.c: fix compile error when tracing disabled
On Tue, Dec 09, 2014 at 03:03:58PM -0800, Kevin Hilman wrote: From: Kevin Hilman khil...@linaro.org When CONFIG_TRACE is disabled, linking fails with: common/built-in.o:(.data.init_sequence_f+0x8): undefined reference to `trace_early_init' To fix, wrap the call to trace_early_init() with #ifdef CONFIG_TRACE. Cc: Simon Glass s...@chromium.org Cc: Tom Rini tr...@ti.com Signed-off-by: Kevin Hilman khil...@linaro.org 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] ARM: rpi: only set usbethaddr on relevant systems
On Fri, Dec 05, 2014 at 08:56:46PM -0700, Stephen Warren wrote: Model A and CM RPis don't have an on-board USB Ethernet device. Hence, there's no point setting $usbethaddr based on the device fuses. Use the model detection code to gate this. Note that the fuses are actually programmed even on those devices though. Signed-off-by: Stephen Warren swar...@wwwdotorg.org 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] [U-Boot,2/3,v2] arm: semihosting: fix up compile bugs
On Mon, Dec 15, 2014 at 11:05:56AM +0100, Linus Walleij wrote: There is currently a regression when using newer ARM64 compilers for semihosting: the way long types are inferred from context is no longer the same. The semihosting runtime uses long and size_t, so use this explicitly in the semihosting code and interface, and voila: the code now works again. Tested with aarch64-linux-gnu-gcc: Linaro GCC 4.9-2014.09. Cc: Darwin Rambo dra...@broadcom.com Cc: AKASHI Takahiro takahiro.aka...@linaro.org Cc: Mark Hambleton mark.hamble...@arm.com Cc: Tom Rini tr...@ti.com Acked-by: Steve Rae s...@broadcom.com Suggested-by: Mark Hambleton mark.hamble...@arm.com Signed-off-by: Linus Walleij linus.wall...@linaro.org 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] [U-Boot, 1/3, v2] arm: semihosting: staticize internal functions
On Mon, Dec 15, 2014 at 11:05:43AM +0100, Linus Walleij wrote: The semihosting code exposes internal file handle handling functions to read(), open(), close() and get the length of a certain file handle. However the code using it is only interested in either reading and entire named file into memory or getting the file length of a file referred by name. No file handles are used. Thus make the file handle code internal to this file by removing these functions from the semihosting header file and staticize them. This gives us some freedom to rearrange the semihosting code without affecting the external interface. Cc: Darwin Rambo dra...@broadcom.com Cc: AKASHI Takahiro takahiro.aka...@linaro.org Cc: Mark Hambleton mark.hamble...@arm.com Cc: Tom Rini tr...@ti.com Acked-by: Steve Rae s...@broadcom.com Signed-off-by: Linus Walleij linus.wall...@linaro.org 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] Fix hash verification
On Fri, Dec 12, 2014 at 08:01:23PM +0200, Nikolay Dimitrov wrote: From: Nikolay Dimitrov picmas...@mail.bg Fix issue in parse_verify_sum() which swaps handling of env-var and *address. Move hash_command() argc check earlier. Cosmetic change on do_hash() variable declaration. Improved help message for hash command. Signed-off-by: Nikolay Dimitrov picmas...@mail.bg Reviewed-by: Simon Glass s...@chromium.org 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] [U-Boot, 3/3, v2] arm: semihosting: get rid of forward declarations
On Mon, Dec 15, 2014 at 11:06:05AM +0100, Linus Walleij wrote: By rearranging the functions in the semihosting code we can avoid forward-declaration of the internal static functions. This puts the stuff in a logical order: read/open/close/len and then higher-order functions follow at the end. Cc: Darwin Rambo dra...@broadcom.com Cc: AKASHI Takahiro takahiro.aka...@linaro.org Cc: Mark Hambleton mark.hamble...@arm.com Cc: Tom Rini tr...@ti.com Acked-by: Steve Rae s...@broadcom.com Signed-off-by: Linus Walleij linus.wall...@linaro.org 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] [U-Boot, 1/4] vexpress64: take over maintenance of the semi vexpress64
On Wed, Dec 24, 2014 at 02:02:19AM +0100, Linus Walleij wrote: As agreed with Steve Rae I'm taking over maintenance of the semihosted, emulated FVP/foundation model Versatile Express 64 bit board variant. Signed-off-by: Linus Walleij linus.wall...@linaro.org Acked-by: Steve Rae s...@broadcom.com 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
