[U-Boot] Altera Arria10 socfpga image usage
Hi, Is there a document somewhere describing how to program the Arria10 dev kit with the u-boot-with-spl.sfp image? This is the image built from the 'next' branch from http://git.denx.de/?p=u-boot/u-boot-socfpga.git using: $ make socfpga_arria10_defconfig $ make The image is too large to be wrapped up using the Altera mkpimage tool: $ mkpimage -hv 1 -o u-boot-mkpimage.bin u-boot-with-spl.sfp Image size must not be more than alignment value of 256 kilobytes So are the raw u-boot.bin or u-boot-dtb.bin I've tried writing it either directly into the QSPI flash, onto the base of an SD card, or into a partition tagged with type 'a2' on an SD card, starting at sector 2048. None of these seem to work properly. I am able to build & run the Altera supplied u-boot from https:// github.com/altera-opensource/u-boot-socfpga , branch socfpga_v2014.10_arria10_bringup. Thanks, Andre ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] MX6: Correct calculation of PLL_SYS
DIV_SELECT is used as Fout = Fin * div_select / 2.0, so we should do the shift after the multiply to avoid rounding errors Signed-off-by: Andre Renaud --- arch/arm/cpu/armv7/mx6/clock.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c index bd65a08..7dd83ec 100644 --- a/arch/arm/cpu/armv7/mx6/clock.c +++ b/arch/arm/cpu/armv7/mx6/clock.c @@ -80,7 +80,7 @@ static u32 decode_pll(enum pll_clocks pll, u32 infreq) div = __raw_readl(&imx_ccm->analog_pll_sys); div &= BM_ANADIG_PLL_SYS_DIV_SELECT; - return infreq * (div >> 1); + return (infreq * div) >> 1; case PLL_BUS: div = __raw_readl(&imx_ccm->analog_pll_528); div &= BM_ANADIG_PLL_528_DIV_SELECT; -- 1.7.9.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v4 11/15] dm: Fix printf() strings in the 'dm' command
On 7 June 2014 07:13, Simon Glass wrote:
> The values here are int, but the map_to_sysmem() call can return a long.
> Add a cast to deal with this.
...
> - printf("%s- %s @ %08x", buf, in->name, map_to_sysmem(in));
> + printf("%s- %s @ %08x", buf, in->name, (uint)map_to_sysmem(in));
If the argument is a long, shouldn't it be printed as long, rather
than possibly truncated to an int?
printf("%s- %s @ %08lx", buf, in->name, map_to_sysmem(in));
Regards,
Andre
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] fdt performance
Hi Wolfgang, On 18 October 2013 07:55, Wolfgang Denk wrote: > In message <525f8284.4000...@caviumnetworks.com> you wrote: >> Some of the checks in fdt_offset_ptr also look useless, such as if >> ((offset + len) < offset) which will always be false, or >> if (p + len < p) > > What happens if the "offset" or "p" point to addresses close to the > upper end of the address space, and adding "len" makes it wrap around? I'm not sure how particular U-Boot is about this, but the C standard doesn't specify what to do in the situation of signed overflow, so it's possible that these checks could be simply optimised away. The portable way to write it (I believe) is: if (INT_MAX - len < offset). I don't know what GCC does in this situation specifically though. Regards, Andre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] imximage on the MX50
Hi Stefano, >> Specifically, the dcd_ptr in the v2 imx header points to an address in >> DDR, however I would have thought that on power-up the DCD is loaded >> somewhere in iRAM (since the DDR isn't running at this stage), and >> then only once this has been interpreted is the full image loaded into >> DDR. The tools/imximage.c code appears to only work with DDR >> addresses, and I'm assuming that this same system works fine on the >> MX53. >> >> Can anyone shed any light on this? > > The bootROM copies the DCD data into an area that is not specified, but > we can assume is in the IRAM. As part of the boot process, the bootROM > copies the image into a DEST memory - this is as it is called in the > manuals, and this after the DCD table is parsed and executed. That means > that is possible to set dcd_ptr pointint to DDR if the DCD table is > programmed to set up the DDR controller, as it is actually done for > i.MX51/i.MX53/i.MX6 in u-boot. Can you recommend any mechanism for debugging the boot rom execution? I can see on the SPI bus that it is trying to read from the boot flash, and it is getting the correct data (ie, the u-boot.imx image is programmed properly). However it is still failing and ending up in USB fall-back mode. Given your comments about the dcd_ptr, I can assume that isn't the problem, which leaves me at a bit of a dead end. Regards, Andre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] imximage on the MX50
Hi, I'm trying to port u-boot 2013.10-rc2 to the i.MX50 (which is very similar to the i.MX53). However I'm not having much luck with the imximage, and have so far not managed to make the unit run stand-alone. Specifically, the dcd_ptr in the v2 imx header points to an address in DDR, however I would have thought that on power-up the DCD is loaded somewhere in iRAM (since the DDR isn't running at this stage), and then only once this has been interpreted is the full image loaded into DDR. The tools/imximage.c code appears to only work with DDR addresses, and I'm assuming that this same system works fine on the MX53. Can anyone shed any light on this? Regards, Andre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Fix bitmap offsets for non 8-bit LCDs
Currently bitmap logos don't interpret the X coordinate correctly if the bpp
is anything other than 8.
Signed-off-by: Andre Renaud
---
common/lcd.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/common/lcd.c b/common/lcd.c
index 66d4f94..ee47712 100644
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -589,15 +589,16 @@ void bitmap_plot(int x, int y)
immap_t *immr = (immap_t *) CONFIG_SYS_IMMR;
cpm8xx_t *cp = &(immr->im_cpm);
#endif
+ unsigned bpix = NBITS(panel_info.vl_bpix);
debug("Logo: width %d height %d colors %d cmap %d\n",
BMP_LOGO_WIDTH, BMP_LOGO_HEIGHT, BMP_LOGO_COLORS,
ARRAY_SIZE(bmp_logo_palette));
bmap = &bmp_logo_bitmap[0];
- fb = (uchar *)(lcd_base + y * lcd_line_length + x);
+ fb = (uchar *)(lcd_base + y * lcd_line_length + x * bpix / 8);
- if (NBITS(panel_info.vl_bpix) < 12) {
+ if (bpix < 12) {
/* Leave room for default color map
* default case: generic system with no cmap (most likely 16bpp)
* cmap was set to the source palette, so no change is done.
@@ -648,7 +649,7 @@ void bitmap_plot(int x, int y)
}
else { /* true color mode */
u16 col16;
- fb16 = (ushort *)(lcd_base + y * lcd_line_length + x);
+ fb16 = (ushort *)fb;
for (i = 0; i < BMP_LOGO_HEIGHT; ++i) {
for (j = 0; j < BMP_LOGO_WIDTH; j++) {
col16 = bmp_logo_palette[(bmap[j]-16)];
--
1.7.9.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-Boot Graphics Library?
Hi Simon, On 17 January 2013 04:17, Simon Glass wrote: > If we do this, rather than re-invent the wheel, does anyone have any > suggestions on a very small and simple existing library that we could > bring in to do this? If what you want is a small graphics/font system then I'd recommend the work stb libraries from http://nothings.org. He's got an image loader that comes in at around 40k of x86 binary, which supports PNG, JPEG, GIF etc... and a .ttf render of around 2,000 lines of code (not sure of the compiled size). They're all public domain licensed, well maintained, and have no external dependencies. They're not the fastest, but they are the smallest that I've seen. Whether it's a good idea to load such additional features into U-Boot or not, I don't really know. Regards, Andre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] at91: Add support for Bluewater Systems Snapper 9G45 module
Hi Simon, On 02/11/11 04:22, Simon Glass wrote: > + /* Need to reset PHY -> 500ms reset */ > + erstl = readl(&rstc->mr) & AT91_RSTC_MR_ERSTL_MASK; > + writel(AT91_RSTC_KEY | AT91_RSTC_MR_ERSTL(13) | > +AT91_RSTC_MR_URSTEN, &rstc->mr); > + writel(AT91_RSTC_KEY | AT91_RSTC_CR_EXTRST, &rstc->cr); You don't actually need to reset the PHY for 500ms, only 100us, so the AT91_RSTC_MR_ERSTL(13) can be replaced with AT91_RSTC_MR_ERSTL(0), which give you the minimum delay (62ms I think). Regards, Andre -- Bluewater Systems - An Aiotec Company Andre Renaud an...@bluewatersys.com 5 Amuri Park, 404 Barbadoes St www.bluewatersys.comPO Box 13 889, Christchurch 8013 www.aiotec.co.nzNew Zealand Phone: +64 3 3779127Freecall: Australia 1800 148 751 Fax: +64 3 3779135USA 1800 261 2934 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cpu/arm926ejs/start.S question
Hi Fabio, On 08/07/11 12:54, Fabio Estevam wrote: > Just to make sure I understand: you want to boot MX25 from internal > mode (from ROM), correct? > > We currently do this on the MX51 and we pass the DDR timings, IOMUX, > etc via the DCD (Device Configuration Data) mechanism. > > You can refer to: board/freescale/mx51evk/imximage.cfg > > I plan to work on adding support for MX25PDK board and I would like to > get it to boot from internal mode (NAND and SD card), but this will > take some time as I will be out for one month. > > Would be interested to know whether you get any progress on this side. I have basically got this working, but I have to put the final u-boot.imx image into the SPI flash at address 0x400, not the base (the image that I had essentially padded it out to 0x400). Is there any reason that imximage doesn't do this? As far as I can tell from the i.MX25 datasheet the image has a fixed offset, and there doesn't seem much point in not rolling this into the final image. Am I missing something about this? Regards, Andre -- Bluewater Systems - An Aiotec Company Andre Renaud an...@bluewatersys.com 5 Amuri Park, 404 Barbadoes St www.bluewatersys.comPO Box 13 889, Christchurch 8013 www.aiotec.co.nzNew Zealand Phone: +64 3 3779127Freecall: Australia 1800 148 751 Fax: +64 3 3779135USA 1800 261 2934 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cpu/arm926ejs/start.S question
Hi Fabio, > Please check doc/README.imximage file for details regarding the > generation of the u-boot.imx image. > > I think that it would be nice if you include such file for your board > so that the same approach as in MX51/MX53 can be used. This is basically exactly what I was after. Thanks for that, once I get some other things finalised I'll shift over to using this system. Regards, Andre -- Bluewater Systems - An Aiotec Company Andre Renaud an...@bluewatersys.com 5 Amuri Park, 404 Barbadoes St www.bluewatersys.comPO Box 13 889, Christchurch 8013 www.aiotec.co.nzNew Zealand Phone: +64 3 3779127Freecall: Australia 1800 148 751 Fax: +64 3 3779135USA 1800 261 2934 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cpu/arm926ejs/start.S question
Hi Fabio, On 08/07/11 12:54, Fabio Estevam wrote: > Just to make sure I understand: you want to boot MX25 from internal > mode (from ROM), correct? Yes, I am booting in internal mode, so that I can load U-Boot from NAND (or SPI flash). > We currently do this on the MX51 and we pass the DDR timings, IOMUX, > etc via the DCD (Device Configuration Data) mechanism. > > You can refer to: board/freescale/mx51evk/imximage.cfg > > I plan to work on adding support for MX25PDK board and I would like to > get it to boot from internal mode (NAND and SD card), but this will > take some time as I will be out for one month. > > Would be interested to know whether you get any progress on this side. I essentially have it working on 2011.06 from NAND. However I wouldn't guarantee that the code is necessarily suitable for the main tree. I have done it via the #include method previously mentioned. Just out of interest, how does the imximage.cfg file work? I can't see any reference to that file in any of the build system, so how do you get it prepended to the image? Regards, Andre -- Bluewater Systems - An Aiotec Company Andre Renaud an...@bluewatersys.com 5 Amuri Park, 404 Barbadoes St www.bluewatersys.comPO Box 13 889, Christchurch 8013 www.aiotec.co.nzNew Zealand Phone: +64 3 3779127Freecall: Australia 1800 148 751 Fax: +64 3 3779135USA 1800 261 2934 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cpu/arm926ejs/start.S question
Hi Simon, > We have a similar thing with Tegra, and have built something into the > USB download script which prepends the needed data. In this case it > needs to be signed so it isn't possible to just include it in the U-Boot > source, anyway. > > I suppose > > cat preload.bin u-boot.bin >u-boot.out I can't think of a particularly good reason why that wouldn't work. It is nice to use the U-Boot build system to take care of it though, and there is less chance of someone accidentally flashing the original u-boot.bin, rather than u-boot.out. I also take advantage of some information available in the linker in my 'preload.bin', (such as image size, boot address etc...). I guess its a question of which is less horrible - maintaining a preload outside of u-boot, and having a build process which combines them, or the dodgy #include that I suggested. I'm in favour of the #include, partly because I've already done it & got it working, but also because it makes the build system less complex, so less chance of someone making a mistake. I'm sure I'd feel differently if I'd thought of the preload.bin first however. Regards, Andre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] cpu/arm926ejs/start.S question
Hello, I am working on an i.MX25 board, and would like to know the recommended mechanism for putting code in before the first instruction in the executable, but outside the *_spl system. Basically, the i.MX25 has a smart boot rom in the CPU, which will extract the first block, and interpret it (as data, rather than instructions). However, if I just use the linker script to put this block before start.S, then U-Boot relocation gets messed up, as _start is now not the beginning of the image, and a lot of the calculated offsets are wrong. At the moment I have this working with the following change in start.S: --- cpu/arm926ejs/start.S (revision 36) +++ cpu/arm926ejs/start.S (working copy) @@ -53,6 +53,9 @@ .globl _start _start: +#ifdef CONFIG_PRE_START_INCLUDE +#include CONFIG_PRE_START_INCLUDE +#endif b reset #ifdef CONFIG_PRELOADER /* No exception handlers in preloader */ and I then #define CONFIG_PRE_START_INCLUDE to be the assembler for the i.MX25 specific boot code. Is there a nicer way to go about this? Regards, Andre ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [Patch 1/1] Spi Flash: Allow auto-booting of images from spi flash load
This allows intelligent booting of FIT (& the legacy style) images from
SPI flash. Basically it means that you don't have to guess at the image
length, so data reads are more optimal (& hopefully faster).
Signed-off-by: Andre Renaud
---
Index: common/cmd_sf.c
===
--- common/cmd_sf.c (revision 31)
+++ common/cmd_sf.c (working copy)
@@ -109,6 +109,96 @@
return 0;
}
+static int do_spi_flash_boot(cmd_tbl_t *cmdtp, int argc, char * const argv[])
+{
+ char *ep;
+ size_t cnt;
+ image_header_t *hdr;
+#if defined(CONFIG_FIT)
+ const void *fit_hdr = NULL;
+#endif
+ unsigned long addr;
+ unsigned long offset;
+ char *endp;
+ int ret;
+
+ if (argc < 3)
+ return -1;
+
+ addr = simple_strtoul(argv[1], &endp, 16);
+ if (*argv[1] == 0 || *endp != 0)
+ return -1;
+ offset = simple_strtoul(argv[2], &endp, 16);
+ if (*argv[2] == 0 || *endp != 0)
+ return -1;
+
+ printf("\nLoading from offset 0x%lx\n", offset);
+
+ ret = spi_flash_read(flash, offset, 1024, (u_char *)addr);
+ if (ret) {
+ printf("SPI flash boot failed\n");
+ return 1;
+ }
+
+ switch (genimg_get_format((void *)addr)) {
+ case IMAGE_FORMAT_LEGACY:
+ hdr = (image_header_t *)addr;
+
+ image_print_contents(hdr);
+
+ cnt = image_get_image_size(hdr);
+ break;
+#if defined(CONFIG_FIT)
+ case IMAGE_FORMAT_FIT:
+ fit_hdr = (const void *)addr;
+ puts("Fit image detected...\n");
+
+ cnt = fit_get_size(fit_hdr);
+ break;
+#endif
+ default:
+ puts("** Unknown image type\n");
+ return 1;
+ }
+
+ ret = spi_flash_read(flash, offset, cnt, (u_char *)addr);
+ if (ret) {
+ printf("SPI flash boot failed\n");
+ return 1;
+ }
+
+#if defined(CONFIG_FIT)
+ /* This cannot be done earlier,
+* we need complete FIT image in RAM first */
+ if (genimg_get_format((void *)addr) == IMAGE_FORMAT_FIT) {
+ if (!fit_check_format(fit_hdr)) {
+ puts("** Bad FIT image format\n");
+ return 1;
+ }
+ fit_print_contents(fit_hdr);
+ }
+#endif
+
+ /* Loading ok, update default load address */
+
+ load_addr = addr;
+
+ /* Check if we should attempt an auto-start */
+ if (((ep = getenv("autostart")) != NULL) && (strcmp(ep, "yes") == 0)) {
+ char *local_args[2];
+
+ local_args[0] = "bootm";
+ local_args[1] = NULL;
+
+ printf("Automatic boot of image at addr 0x%08lx ...\n", addr);
+
+ do_bootm(cmdtp, 0, 1, local_args);
+ return 1;
+ }
+ return 0;
+}
+
+
static int do_spi_flash_read_write(int argc, char * const argv[])
{
unsigned long addr;
@@ -207,6 +297,8 @@
ret = do_spi_flash_read_write(argc, argv);
else if (strcmp(cmd, "erase") == 0)
ret = do_spi_flash_erase(argc, argv);
+ else if (strcmp(cmd, "boot") == 0)
+ ret = do_spi_flash_boot(cmdtp, argc, argv);
else
ret = -1;
@@ -229,4 +321,7 @@
" at `addr' to flash at `offset'\n"
"sf erase offset [+]len - erase `len' bytes from `offset'\n"
" `+len' round up `len' to block size"
+ "sf boot addr offset- read a boot image starting at\n"
+ " `offset' to memory at `addr' and\n"
+ " execute it\n"
);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
