Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Le 02/11/2010 07:29, Heiko Schocher a écrit : - preloader copies first page of nand (nand_spl code) to 0xbb00 (some cpu internal mem) and jumps to this address - nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl code) - from there, it copies u-boot code from nand to CONFIG_SYS_NAND_U_BOOT_DST and jumps to CONFIG_SYS_NAND_U_BOOT_START - u-boot run into board_init_f, calculates new relocation address and relocates ... But there is a possibility to prevent one copy, if TEXT_BASE = relocation address = CONFIG_SYS_NAND_U_BOOT_DST In this case nand_spl code copies u-boot from nand to CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address, no need to copy code in relocate_code(). But as codesize changes (and with it relocation address) this is not a perfect solution. bye, Heiko Heiko, Since SPL is loaded in internal RAM, and since U-BOOT itself is loaded only in DRAM, why does SPL need to relocate itself? Can it not run entirely from IRAM and then jump to U-BOOT? If SPL needs to relocate, then why does it run only the copy loop but not the fixups loop? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Add flexibility to mx51 video support
On 11/02/2010 06:15 AM, Frias Renato-B13784 wrote: This patch adds flexibility to mxc_ipuv3_fb.c by allowing the display interface and pixel format to be passed to mx51_fb_init. Signed-off-by: Renato Frias renato.fr...@freescale.com Hi Renato, you patch seems to be corrupted and does not apply. It seems your mailer is responsible for this. It puts html code in the mail, too: nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; pixfmt =3D = IPU_PIX_FMT_RGB565;BR +nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; = nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; break;BR Consider using git send-mail to post your patches to the list. This avoid mail corruption. - strcpy(fbi-fix.id, DISP3 BG); + if (ipu_di == 0) + strcpy(fbi-fix.id, DISP3 BG); + else if (ipu_di == 1) + strcpy(fbi-fix.id, DISP3 BG - DI1); I admit that I took the fix.id string from the linux driver, but it is not used at all in the code. If we do not find a useful reason for it, it should be probably better to get rid of it to avoid confusion. @@ -593,7 +596,7 @@ static int mxcfb_probe(u32 interface_pix_fmt, struct fb_videomode *mode) XRES = %d YRES = %d BitsXpixel = %d\n, panel_info.vl_col, panel_info.vl_row, - panel_info.vl_bpix); + NBITS(panel_info.vl_bpix)); This is only a debug output to check the values in the panel_info structure and prints them without doing any computation. If you want to add the NBITS value (that in any case can be computed), please leave the original output of vl_bpix, too. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Add video support to mx51evk board
On 11/02/2010 06:16 AM, Frias Renato-B13784 wrote:
Adds video support to mx51evk board, this board allows different displays.
This patch enables the WVGA TFT LCD panel only, remove comments from
include/configs/mx51evk.h to use it.
This patch is corrupted as the first one by your mailer.
+#ifdef CONFIG_LCD
+static struct fb_videomode claa_wvga = {
+ CLAA07LC0ACW,
+ 57, /* Refresh */+
+ 800,/* xres */
+ 480,/* yres */
+ 37037, /* pixclock = 27Mhz */
+ 40, /* left margin */
+ 60, /* right margin */
+ 10, /* upper margin */
+ 10, /* lower margin */
+ 20, /* hsync-len */
+ 10, /* vsync-len */
+ 0, /* sync */
+ FB_VMODE_NONINTERLACED, /* vmode */
+ 0, /* flag */
+};
It seems you start with trailing whitespaces instead of tabs
+#ifdef CONFIG_LCD
+void setup_iomux_ipu(void)
+{
+ /* DISP2_DAT [0:15] are configured by default */
+ mxc_request_iomux(MX51_PIN_DI1_D1_CS, IOMUX_CONFIG_ALT4);
+ mxc_iomux_set_pad(MX51_PIN_DI1_D1_CS, 0x85);
With the vision2 I introduced constants to set pads (PAD_CTL_*). At
least for new values, you should use it.
+ /* DISP2_DRDY pin */
+ mxc_request_iomux(MX51_PIN_DI_GP4, IOMUX_CONFIG_ALT4);
+ mxc_iomux_set_pad(MX51_PIN_DI_GP4, 0x80);
Ditto
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index f98438d..cd931ea 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -211,6 +211,17 @@
#define CONFIG_SYS_DDR_CLKSEL 0
#define CONFIG_SYS_CLKTL_CBCDR 0x59E35100
+/*
+ * Framebuffer and LCD
+ */
+/*
Are the new defines inside a comment ?
+#define CONFIG_LCD
+#define CONFIG_VIDEO_MX5
+#define LCD_BPPLCD_COLOR16
+#define CONFIG_CMD_BMP
+#define CONFIG_BMP_16BPP
+*/
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Hello Albert,
Albert ARIBAUD wrote:
Le 02/11/2010 07:29, Heiko Schocher a écrit :
- preloader copies first page of nand (nand_spl code) to
0xbb00 (some cpu internal mem) and jumps to this address
- nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl
code)
- from there, it copies u-boot code from nand to
CONFIG_SYS_NAND_U_BOOT_DST
and jumps to CONFIG_SYS_NAND_U_BOOT_START
- u-boot run into board_init_f, calculates new relocation address
and relocates ...
But there is a possibility to prevent one copy, if TEXT_BASE =
relocation address = CONFIG_SYS_NAND_U_BOOT_DST
In this case nand_spl code copies u-boot from nand to
CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address,
no need to copy code in relocate_code().
But as codesize changes (and with it relocation address) this
is not a perfect solution.
bye,
Heiko
Heiko,
Since SPL is loaded in internal RAM, and since U-BOOT itself is loaded
only in DRAM, why does SPL need to relocate itself? Can it not run
entirely from IRAM and then jump to U-BOOT?
Good question. This was the old behaviour. Check this, if we can
prevent it.
If SPL needs to relocate, then why does it run only the copy loop but
not the fixups loop?
in nand_spl//nand_boot_fsl_nfc.c:
void board_init_f (ulong bootflag)
{
relocate_code (CONFIG_SYS_TEXT_BASE - TOTAL_MALLOC_LEN, NULL,
CONFIG_SYS_TEXT_BASE);
}
- nand_spl code gets copied where it is compiled for ... no need
for fixups.
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] tx25: fix linker file for newer ld support
Le 01/11/2010 23:11, Wolfgang Denk a écrit :
__got_start = .;
. = ALIGN(4);
.got : { *(.got) }
Do we still need this GOT entry?
Indeed no, and we do not need the datarel entries either. I'm reposting
a V2 patch set with these plus minor fixes to the arm926ejs linker file too.
Best regards,
Wolfgang Denk
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] tx25: fix linker file for newer ld support
Hello Albert,
Albert ARIBAUD wrote:
Le 01/11/2010 23:11, Wolfgang Denk a écrit :
__got_start = .;
. = ALIGN(4);
.got : { *(.got) }
Do we still need this GOT entry?
Indeed no, and we do not need the datarel entries either. I'm reposting
a V2 patch set with these plus minor fixes to the arm926ejs linker file too.
Acked, thanks.
thought this was long time ago gone ...
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: wrong Relocation and not cleared BSS
Le 02/11/2010 08:18, V, Aneesh a écrit : Thanks. This helps. I did the .lds change and it seems to be booting now. Good! However, I can't still explain my earlier observation because even in the absence of this fix .rel.dyn had some content and the offsets should have been different if I were to believe objdump. Do you have any clue? There were two issues: First, older linkers always emitted input relocation sections with the name .rel.dyn whereas newer linkers emitted them with names of the form .rel*. As our linker files only took .rel.dyn to form the output section, using newer linkers would produce empty .rel.dyn sections. Second, a fix to the first issue was RFCed to the list which worked on several boards but tx25 would not boot completely. The root cause of this second issue is that CONFIG_SYS_NAND_U_BOOT_SIZE in the board config file hard-codes the size of the u-boot binary that will be read from NAND and put in RAM. When/if u-boot grows in size, this constant must be adjusted, and it was not. What hit you was the first issue for sure, and this explains why _rel_dyn_start_ofs and _rel_dyn_end_ofs are identical. What *could* have hit you was the second issue *if* your board boots from NAND *and* if u-boot grew beyond your CONFIG_SYS_NAND_U_BOOT_SIZE. BTW, Wolfgang, couldn't this 'constant' be generated once objcopy has produced u-boot.bin? A script could 'du' its size, round it up as required, and generate a .h with the result so that the SPL would always compile with a correct value. Best regards, Aneesh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad page state in process 'swapper'
Le 02/11/2010 08:37, sywang a écrit : While U-boot loads the Linux image, I have the following error. Do you have any suggestions on this? detected lzma initramfs initramfs: LZMA lc=3,lp=0,pb=2,dictSize=8388608,origSize=12677632 Bad page state in process 'swapper' page:a87b3418 flags:0x mapping: mapcount:-16711680 count:0 Trying to fix it up, but a reboot is needed Backtrace: Unwound Call Trace: [80211dc8] dump_stack+0x8/0x48 [80265c98] bad_page+0x78/0xb0 [80266988] get_page_from_freelist+0x230/0x488 [80266c44] __alloc_pages+0x64/0x348 [8027b4ac] __vmalloc_area_node+0x10c/0x230 [804741cc] populate_rootfs+0x974/0xae0 [802007e4] init+0x84/0x530 [8020db58] kernel_thread_helper+0x10/0x18 Thanks! Shuyou Hi Shuyou, This is not 'while u-boot loads Linux', this is 'while Linux boots after it was loaded by u-boot', because these messages are from Linux. I'd say these messages typically occur when the image (kernel+ramfs) is corrupted. What does u-boot display before jumping to the Linux kernel? Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: fix linker file for newer ld support
Le 02/11/2010 05:05, Steve Sakoman a écrit : I've been using gcc 4.3.3, so I haven't run into the issue that this patch is attempting to fix. I tested this patch using gcc 4.3.3, and while it produces a usable image, it causes the size of the image to grow from 227K to 433K! So perhaps we need a patch that uses a more restrictive wildcard. Steve Thanks for pointing this out, Steve. That'll go into V3 of my patch set I guess, as Alexander's patch derives from mine and I most probably hit the same size increase issue as he does. Wolfgang: that may mean the tx25 config file patch is unneeded. Stay tuned. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad page state in process 'swapper'
Albert, Thanks for your reply. My log is shown below. What you say is right. The error information is from Linux. I guess that what parameters passed to Linux by u-boot may be not right. However, I don't know how to identify? TFTP from server 192.168.5.101; our IP address is 192.168.5.22 Filename 'mips.ari'. Load address: 0x9f0 Loading: # done Bytes transferred = 2917360 (2c83f0 hex) Image is not signed; verifying checksum... passed do_tftpboot, Linux image has been verified: pass do_tftpboot, going to do_bootoctlinux octeon_phy_mem_block_free addr: 0x10, size: 0x800 ELF file is 64 bit block alloc called: req_size: 0x2b25e0, min_addr: 0xa0, max_addr: 0x0, align: 0x0 Allocated memory for ELF segment: addr: 0xa0, size 0x2b25e0 block alloc called: req_size: 0xd0, min_addr: 0xcb25e0, max_addr: 0x0, align: 0x0 Allocated memory for ELF segment: addr: 0xcb25e0, size 0xd0 Loading .text @ 0x80a0 (0x2b25b8 bytes) Clearing .bss @ 0x80cb25c0 (0x20 bytes) Loading .data @ 0x80cb25e0 (0x30 bytes) Loading .MIPS.options @ 0x80cb2610 (0xa0 bytes) naddr 2 addr vec 0, 0x2b25e0 @ 0xa0 addr vec 1, 0xd0 @ 0xcb25e0 ## Loading OS kernel with entry point: 0x80a0 ... block alloc called: req_size: 0x77, min_addr: 0x0, max_addr: 0x7fff, align: 0x0 block alloc called: req_size: 0x190, min_addr: 0x0, max_addr: 0x7fff, align: 0x0 block alloc called: req_size: 0x98, min_addr: 0x0, max_addr: 0x7fff, align: 0x0 board type is: 11, CN3010_EVB_HS5 stack expected: 0x0, actual: 0x0 heap_base expected: 0x0, actual: 0x0 heap_top expected: 0x0, actual: 0x0 Entry point (virt): 0x80a0 Address of start app: 0x80096d90 Bootloader: Done loading app on coremask: 0x1 octeon_phy_mem_block_free addr: 0x9f0, size: 0x600 octeon_phy_mem_block_free addr: 0x810, size: 0x3200 octeon_phy_mem_block_free addr: 0x8103200, size: 0x2 octeon_phy_mem_block_free addr: 0x8123200, size: 0x32000 do_bootoctlinux, going to start_cores Bringing coremask: 0x1 out of reset! Address of start app: 0x80070914 block alloc called: req_size: 0x330, min_addr: 0x0, max_addr: 0x4000, align: 0x0 Bootloader: Starting app at cycle: 0 Welcome to start_cores. (octeon_boot.c:1547) start_cores, going to BOOT_VECTOR_BASE app_start_func_addr 80096d90 start_linux printf_boot_init_vector stack_addr:0x80062f58 code_addr: 0x80070568 k0_val:0x8003ff44 flags:0x0 boot_info_addr:0x800c2440 pad:0x0 pad2:0x0 printf_boot_info_block entry_point:0x80a0 boot_desc_addr: 0x100080 stack_top:0x0 exception_base:0x1000 cvmx_desc_addr:0x0 flags:0x0 Welcome to start_linux. (cmd_octeon_linux.c:596) Uncompressing.. Welcome to start_kernel. (init/main.c:458) Networks OS Version (build / label #wan...@-eng.) Built by wan...@localhost on 2010-11-02 at 15:09:36 CST (gcc version 3.4.5 Cavium Networks Version: 1.4.0, build 58) Welcome to start_kernel. (init/main.c:472) prom_init(arch/mips/cavium-octeon/setup.c:783) arcs_cmdline: console=ttyS0,9600 prom_init(arch/mips/cavium-octeon/setup.c:790) para[0]: bootoctlinux prom_init(arch/mips/cavium-octeon/setup.c:790) para[1]: 9f00200 prom_init(arch/mips/cavium-octeon/setup.c:790) para[2]: bootver= 1.1.4.0/wan...@-eng. CVMSEG size: 2 cache lines (256 bytes) Setting flash physical map for 4MB flash at 0x1f80 Determined physical RAM map: Welcome to start_kernel. (init/main.c:474) Kernel command line: console=ttyS0,9600 rdinit=/sbin/init Welcome to start_kernel. (init/main.c:505) Primary instruction cache 32kB, virtually tagged, 4 way, 64 sets, linesize 128 bytes. Primary data cache 16kB, 64-way, 2 sets, linesize 128 bytes. Welcome to start_kernel. (init/main.c:518) Using 500.000 MHz high precision timer. cycles_per_jiffy=100 Welcome to start_kernel. (init/main.c:532) Memory: 57344k/65536k available (1918k kernel code, 8144k reserved, 561k data, 2172k init, 0k highmem) Calibrating delay using timer specific routine.. 1000.32 BogoMIPS (lpj=1000323) available. Checking for the multiply/shift bug... no. Checking for the daddi bug... no. Checking for the daddiu bug... no. Welcome to start_kernel. (init/main.c:616) Welcome to rest_init. (init/main.c:396) Welcome to schedule. (kernel/sched.c:2889) Welcome to schedule. (kernel/sched.c:3065) detected lzma initramfs initramfs: LZMA lc=3,lp=0,pb=2,dictSize=8388608,origSize=12677632 Bad page state in process 'swapper' page:a87b3418 flags:0x mapping: mapcount:-16711680 count:0 Trying to fix it up, but a reboot is needed Backtrace: Unwound Call Trace: [80211dc8] dump_stack+0x8/0x48 [80265c98] bad_page+0x78/0xb0 [80266988] get_page_from_freelist+0x230/0x488 [80266c44] __alloc_pages+0x64/0x348 [8027b4ac] __vmalloc_area_node+0x10c/0x230 [804741cc] populate_rootfs+0x974/0xae0 [802007e4] init+0x84/0x530 [8020db58] kernel_thread_helper+0x10/0x18 Thanks! Shuyou
Re: [U-Boot] Add video support for mx51evk
Dear Stefano Babic, In message 4ccfb244.2000...@denx.de you wrote: Consider this, I do not think the actual computation in lcd_setmem() is correct. We need to compute the maximum amount of memory to be reserved to the framebuffer, not the value requested by the current display interface. We could add a CONFIG_SYS_VIDEO_SIZE that contains the maximum amount of memory needed, because the value is strictly board-dependent, and change lcd_setmem to use it. Anatolij, what do you think about this ? Why cannot you determine the exact amount needed at runtime? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de GUIs are virtually useless. Learn tools. They're configurable, scriptable, automatable, cron-able, interoperable, etc. We don't need no brain-dead winslurping monolithic claptrap. -- Tom Christiansen in 37114...@csnews ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad page state in process 'swapper'
Dear sywang, In message 20101102073757.0c5e828...@theia.denx.de you wrote: While U-boot loads the Linux image, I have the following error. Do you have any suggestions on this? detected lzma initramfs initramfs: LZMA lc=3,lp=0,pb=2,dictSize=8388608,origSize=12677632 Bad page state in process 'swapper' page:a87b3418 flags:0x mapping: mapcount:-16711680 count:0 Trying to fix it up, but a reboot is needed Backtrace: Unwound Call Trace: [80211dc8] dump_stack+0x8/0x48 [80265c98] bad_page+0x78/0xb0 [80266988] get_page_from_freelist+0x230/0x488 [80266c44] __alloc_pages+0x64/0x348 [8027b4ac] __vmalloc_area_node+0x10c/0x230 [804741cc] populate_rootfs+0x974/0xae0 [802007e4] init+0x84/0x530 [8020db58] kernel_thread_helper+0x10/0x18 These are Linux error messages. This is the U-Boot mailing list. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Those who will be able to conquer software will be able to conquer the world. - Tadahiro Sekimoto, president, NEC Corp. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad page state in process 'swapper'
Dear sywang, In message 20101102081321.0571d28...@theia.denx.de you wrote: Image is not signed; verifying checksum... passed do_tftpboot, Linux image has been verified: pass do_tftpboot, going to do_bootoctlinux octeon_phy_mem_block_free addr: 0x10, size: 0x800 ELF file is 64 bit block alloc called: req_size: 0x2b25e0, min_addr: 0xa0, max_addr: ... You are using a proprietary version of U-Boot, where the source code is not available to the public. We have no idea what Cavium might have changed in U-Boot (obviously they have changed a lot), of what their interface requirements are. Please take all Cavium / Octon related questions to Cavium technical support. The U-Boot community CANNOT help you with that as we don not have ANY informations about that code. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Bus error -- driver executed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm: wrong Relocation and not cleared BSS
Albert, -Original Message- From: Albert ARIBAUD [mailto:albert.arib...@free.fr] Sent: Tuesday, November 02, 2010 1:11 PM To: V, Aneesh Cc: dar...@theia.denx.de; h...@denx.de; u-boot@lists.denx.de; Augulis Subject: Re: arm: wrong Relocation and not cleared BSS Le 02/11/2010 08:18, V, Aneesh a écrit : Thanks. This helps. I did the .lds change and it seems to be booting now. Good! However, I can't still explain my earlier observation because even in the absence of this fix .rel.dyn had some content and the offsets should have been different if I were to believe objdump. Do you have any clue? There were two issues: First, older linkers always emitted input relocation sections with the name .rel.dyn whereas newer linkers emitted them with names of the form .rel*. As our linker files only took .rel.dyn to form the output section, using newer linkers would produce empty .rel.dyn sections. My .rel.dyn was not empty even before taking your fix. This is what puzzled me. When I dumped the ELF headers with 'objdump -h' .rel.dyn seemed to have some content: Please see the diff of objdump's output before and after applying your patch. Please note that .rel.dyn was there even without the patch having the same size but at a different offset. So, this is what it looks like to me: Even when our rule in .lds was not correct the linker generated .rel.dyn section by default putting together the 'rel*' sections that were not covered by any rules. But since it didn't use our rule for this, the labels associated with our rule indicated zero size. @@ -9,7 +9,7 @@ Idx Name Size VMA LMA File off Algn CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .interp 0011 80e9e6d0 80e9e6d0 000266d0 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA - 3 .dynamic 0080 80ea343c 80ea343c 0002b43c 2**2 + 3 .dynamic 0080 80e9f7ec 80e9f7ec 000277ec 2**2 CONTENTS, ALLOC, LOAD, DATA 4 .dynsym 0100 80ea34c8 80ea34c8 0002b4c8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA @@ -17,12 +17,12 @@ Idx Name Size VMA LMA File off Algn CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .hash 0054 80e9e7a4 80e9e7a4 000267a4 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA - 7 .rel.dyn 3c50 80e9e7f8 80e9e7f8 000267f8 2**2 - CONTENTS, ALLOC, LOAD, READONLY, DATA - 8 .data 0ff4 80ea2448 80ea2448 0002a448 2**2 + 7 .data 0ff4 80e9e7f8 80e9e7f8 000267f8 2**2 CONTENTS, ALLOC, LOAD, DATA - 9 .got.plt 000c 80ea34bc 80ea34bc 0002b4bc 2**2 + 8 .got.plt 000c 80e9f86c 80e9f86c 0002786c 2**2 CONTENTS, ALLOC, LOAD, DATA + 9 .rel.dyn 3c50 80e9f878 80e9f878 00027878 2**2 + CONTENTS, ALLOC, LOAD, READONLY, DATA 10 .u_boot_cmd 0540 80ea35c8 80ea35c8 0002b5c8 2**2 CONTENTS, ALLOC, LOAD, DATA 11 .bss 00031210 80ea3b08 80ea3b08 0002bb08 2**3 Second, a fix to the first issue was RFCed to the list which worked on several boards but tx25 would not boot completely. The root cause of this second issue is that CONFIG_SYS_NAND_U_BOOT_SIZE in the board config file hard-codes the size of the u-boot binary that will be read from NAND and put in RAM. When/if u-boot grows in size, this constant must be adjusted, and it was not. What hit you was the first issue for sure, and this explains why _rel_dyn_start_ofs and _rel_dyn_end_ofs are identical. What *could* have hit you was the second issue *if* your board boots from NAND *and* if u-boot grew beyond your CONFIG_SYS_NAND_U_BOOT_SIZE. We did not face the second issue because we are loading the entire u-boot.bin using a separate preloader. BTW, Wolfgang, couldn't this 'constant' be generated once objcopy has produced u-boot.bin? A script could 'du' its size, round it up as required, and generate a .h with the result so that the SPL would always compile with a correct value. Best regards, Aneesh Amicalement, -- Albert. Best regards, Aneesh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Hello Wolfgang, Wolfgang Denk wrote: Dear Heiko Schocher, In message 4ccfafe4.3000...@denx.de you wrote: - preloader copies first page of nand (nand_spl code) to 0xbb00 (some cpu internal mem) and jumps to this address - nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl code) Why is this relocation needed? I understand that this 0xbb00 Thats the question to solve ... don;t know, why nand_spl code on arm (and other architectures?) do this ... I try to have a look to find out, if we can run the nand_spl code complete from this address, and immedietaly copy u-boot from nand to ram ... address is determined by the given hardware ans as such always fix? Yep. But as codesize changes (and with it relocation address) this is not a perfect solution. Indeed. CONFIG_SYS_NAND_U_BOOT_SIZE should be dropped, and the avtual value should be derived from the actual U-Boot image building process. Yep. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Dear Heiko Schocher, But there is a possibility to prevent one copy, if TEXT_BASE = relocation address = CONFIG_SYS_NAND_U_BOOT_DST In this case nand_spl code copies u-boot from nand to CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address, no need to copy code in relocate_code(). But as codesize changes (and with it relocation address) this is not a perfect solution. Worse: it would certainly crash since the original and relocated memory areas must not overlap - they sure would with even the slightest size change. That idea should not be promoted any further. I would recommend that we add code to check for overlapping relocation into board.c and print a panic message if an overlap is detected. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add video support for mx51evk
On 11/02/2010 09:35 AM, Wolfgang Denk wrote: Dear Stefano Babic, In message 4ccfb244.2000...@denx.de you wrote: Consider this, I do not think the actual computation in lcd_setmem() is correct. We need to compute the maximum amount of memory to be reserved to the framebuffer, not the value requested by the current display interface. We could add a CONFIG_SYS_VIDEO_SIZE that contains the maximum amount of memory needed, because the value is strictly board-dependent, and change lcd_setmem to use it. Anatolij, what do you think about this ? Why cannot you determine the exact amount needed at runtime? Agree, we can do it, and it is better - I do not think we need really to change dinamically (I mean, in the same u-boot session) the LCD connected to the framebuffer, reason that requires to reserve the maximum amount of memory. We could introduce a weak function, that a board maintainer can decide to implement or not. This maintains the compatibility with the most drivers where vpanel is static initialized. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] arm920t: implement elf relocation
Hello all,
I am trying to get the ELF relocation working with the arm920t, and I
have applied the patch recently posted to the list by Andreas
Bießmann.
I found that adding these two sections to the linker script gets rid
of both assert failures:
.plt : { *(.plt) }
.rel.plt : { *(.rel.plt) }
The .plt section of the resulting ELF binary contains a single entry.
I am not sure how to interpret the contents of these sections to find
the source of the problem.
Disassembly of section .plt:
100191c8 .plt:
100191c8: e52de004push{lr}; (str lr, [sp, #-4]!)
100191cc: e59fe004ldr lr, [pc, #4]; 100191d8 __div0+0x24
100191d0: e08fe00eadd lr, pc, lr
100191d4: e5bef008ldr pc, [lr, #8]!
100191d8: 8df8.word 0x8df8 ; references .got.plt
100191dc: e28fc600add ip, pc, #0
100191e0: e28cca08add ip, ip, #32768 ; 0x8000
100191e4: e5bcfdf8ldr pc, [ip, #3576]!; 0xdf8
Contents of section .got.plt:
10021fd0 c8910110
Contents of section .rel.plt:
1001c610 dc1f0210 1605
Relocation section '.rel.plt' at offset 0x24610 contains 1 entries:
Offset InfoTypeSym.Value Sym. Name
10021fdc 0516 R_ARM_JUMP_SLOT string table index: 94
Does this shed any light on the issue?
I have not yet tested the binary output.
--
Sébastien
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Le 02/11/2010 09:57, Reinhard Meyer a écrit : Dear Heiko Schocher, But there is a possibility to prevent one copy, if TEXT_BASE = relocation address = CONFIG_SYS_NAND_U_BOOT_DST In this case nand_spl code copies u-boot from nand to CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address, no need to copy code in relocate_code(). But as codesize changes (and with it relocation address) this is not a perfect solution. Worse: it would certainly crash since the original and relocated memory areas must not overlap - they sure would with even the slightest size change. I'm not sure I get you there. If u-boot was linked for a given address and happends to be loaded at that same address, then there is no need to relocate, right? I would recommend that we add code to check for overlapping relocation into board.c and print a panic message if an overlap is detected. I *think* overlap would be correctly handled if we modify the copy code to copy from top to bottom, because we know that the destination is higher than the source. The only tricky case would be when the target address is right in the middle of the source relocation code, because then the last iteratons of the copy code would corrupt this code; that can be avoided by making sure the SPL loads u-boot low enough in RAM. Best Regards, Reinhard Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Hi Heiko, On Tuesday 02 November 2010 09:55:46 Heiko Schocher wrote: - preloader copies first page of nand (nand_spl code) to 0xbb00 (some cpu internal mem) and jumps to this address - nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl code) Why is this relocation needed? I understand that this 0xbb00 Thats the question to solve ... don;t know, why nand_spl code on arm (and other architectures?) do this ... I try to have a look to find out, if we can run the nand_spl code complete from this address, and immedietaly copy u-boot from nand to ram ... On PPC4xx we need to copy the code from the original location (4KiB loaded via the ROM IPL boot loader) to SDRAM and continue running it from there. This is necessary since we can't run from the original location (0xfxxx) and use the PPC4xx NAND controller at the same time. So there is no relocation to TEXT_BASE on 4xx but only a copy to CONFIG_SYS_NAND_BOOT_SPL_DST. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add video support for mx51evk
Hi, On Tue, 02 Nov 2010 07:40:04 +0100 Stefano Babic sba...@denx.de wrote: ... There is also a second issue where I would like to know your thoughts. Very early on system initialization, when LCD is enabled, there is a call to lcd_setmem from board.c. By that time, the video variables, panel_info, are not set yet. Thus U-Boot doesn't reserve the appropriate amount of memory for the display. I was going to set panel_info variable on mx51evk.c, but I would like to know how you solved it for vision2 first. Thanks for pointing out, I have already seen the point, but at the end I forget to fix it ;-). Probably because there is no side-effects on this board, but this does not mean that the issue should not fixed for vision2, too. The problem arises from the fact that the setup of the display parameters was static and everything was solved at compile time. With the framebuffer for the MX51, I needed the possibility to change dinamically the parameters, because the board can have different LCD displays. Consider this, I do not think the actual computation in lcd_setmem() is correct. We need to compute the maximum amount of memory to be reserved to the framebuffer, not the value requested by the current display interface. We could add a CONFIG_SYS_VIDEO_SIZE that contains the maximum amount of memory needed, because the value is strictly board-dependent, and change lcd_setmem to use it. Anatolij, what do you think about this ? We should reserve the amount of memory we actually need for the used display configuration, I think. Reserving the maximum amount would be needed if we have to support switching the display resolution at runtime, but I don't think that this is needed in your case. Therefore I prefer the solution that reserves the actually needed amount of memory. Best regards, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Dear Reinhard Meyer, In message 4ccfd27e.3080...@emk-elektronik.de you wrote: I would recommend that we add code to check for overlapping relocation into board.c and print a panic message if an overlap is detected. Why should we try to detect a problem when we can as well avoid the problem? The needed image isze if known when we build the image, we just have to use it instead of manually defining a constant value. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The faster I go, the behinder I get. -- Lewis Carroll ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Le 02/11/2010 10:34, Reinhard Meyer a écrit : My original message was: please to not give people the idea that they can avoid relocation by loading u-boot at the exact address the relocation would calculate. That is bound to *really* break at the slightest change to u-boot. Oh, I see. What you mean is if people force the loading of u-boot at a fixed address which happens to be its current relocated address, a change of size in u-boot will break because the relocated address will change but the forced address won't. I was talking about a different thing, which is if u-boot finds that the address at which it runs now is the address at which it should run, then it can skip relocation (copy and fixups). Best Regards, Reinhard Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add video support for mx51evk
Dear Stefano Babic, In message 4ccfd2fb.6060...@denx.de you wrote: Why cannot you determine the exact amount needed at runtime? Agree, we can do it, and it is better - I do not think we need really to change dinamically (I mean, in the same u-boot session) the LCD connected to the framebuffer, reason that requires to reserve the maximum amount of memory. Right. If we keep in mind the possibility to share the frame buffer with Linux (to allow for a flicker-free display of a splash screen loaded very early in U-Boot) we should stick with the memory map we have: pRAM on top, frame buffer below, U-Boot code below, etc. That means that size changes for the frame buffer (like for pRAM) take only effect after a reset. We could introduce a weak function, that a board maintainer can decide to implement or not. This maintains the compatibility with the most drivers where vpanel is static initialized. In which way is this board dependent? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Philosophy: A route of many roads leading from nowhere to nothing. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Le 02/11/2010 10:38, Wolfgang Denk a écrit : Dear Reinhard Meyer, In message4ccfd27e.3080...@emk-elektronik.de you wrote: I would recommend that we add code to check for overlapping relocation into board.c and print a panic message if an overlap is detected. Why should we try to detect a problem when we can as well avoid the problem? The needed image isze if known when we build the image, we just have to use it instead of manually defining a constant value. These is a valid point that the SPL isn't necessarily rebuilt and flashed every time u-boot itself is built and flashed, so whatever constant the SPL would carry would only be valid for the u-boot that was built alongside. Now a solution would be that the actual u-boot size be flashed along with it, for instance as a literal defined as '.word _end - _start' right after the vectors. The SPL could load a first NAND block, read the literal, round it to a multiple of NAND blocks by default, and then read this quantity. That would remove the dependency at the cost of extra code in the SPL, though, and not all boards might be able to afford it. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add video support for mx51evk
On 11/02/2010 10:42 AM, Wolfgang Denk wrote: Dear Stefano Babic, Hi Wolfgang, We could introduce a weak function, that a board maintainer can decide to implement or not. This maintains the compatibility with the most drivers where vpanel is static initialized. In which way is this board dependent? Because each board uses a different LCD with a different resolution, and this requires a different amount of memory. This is not different as we see in Linux, because the framebuffer properties are set in the board file before to be passed to the framebuffer driver. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 36-bit u-boot
Leif, I have managed to flashed a 36-bits u-boot to my p4080 board. I have put in two 4Gb dimm into the board but it doesn't work. I got the following from u-boot. [snip] DRAM: Initializing Error: DDR_SDRAM_CFG[RD_EN] and DDR_SDRAM_CFG[2T_EN] should not be set at the same time. RD_EN means registered DIMM enable which is read from PROM on memory module. Looks like you have CONFIG_DDR_2T_TIMING defined in your board header ... which is mutually exclusive with registered DIMM usage. 2T timing is only useful if you have AC timing violations regarding setup/hold on Addr/Cmd Bus. Error: DDR_SDRAM_CFG[RD_EN] and DDR_SDRAM_CFG[2T_EN] should not be set at the same time. 6144M left unmapped DDR: 8 GB It seams that it is something wrong with the DDR initiation. no. You can either use unregistered DIMM modules or simply undefine CONFIG_DDR_2T_TIMING. Cheers, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
hi Albert, On Tue Nov 02, 2010 at 10:47:49AM +0100, Albert ARIBAUD wrote: Now a solution would be that the actual u-boot size be flashed along with it, for instance as a literal defined as '.word _end - _start' right after the vectors. The SPL could load a first NAND block, read the literal, round it to a multiple of NAND blocks by default, and then read this quantity. That would remove the dependency at the cost of extra code in the SPL, though, and not all boards might be able to afford it. Another issue is that the nand_spl might be compiled and flashed to the NAND as a separate entity, using a separate flashing mechanism. If we use the dynamic calculation of the u-boot size, this would necessitate building and flashing the nand_spl each time along with u-boot. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: fix linker file for newer ld support
Hello, Am 02.11.2010 05:05, schrieb Steve Sakoman: I've been using gcc 4.3.3, so I haven't run into the issue that this patch is attempting to fix. just to correct this, the problem is a change in binutils and not, as I wrongly assumed earlier, gcc. Using ld from binutils 2.20.1 leads to problems with the relocation without a patch. gcc is unrelated, at least here. I'm unable to get working u-boot for the Beagleboard using gcc 4.5.1 (and binutils 2.20.1), but using gcc 4.3.5 (and binutils 2.20.1) u-boot runs. There seems to be an error with using mmc, but I assume this is unrelated to relocation (as the problem with gcc 4.5.1). Regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] usb: fix for USB_ST_STALLED status reporting in ehci_submit_async()
Checking the status field of the qTD token in the current code do not take into acount cases where endpoint stall (halted) bit is set together with XactErr status bit. As a result clearing stall on an endpoint won't be done if this status bit was also set. Check for halted bit and report USB_ST_STALLED status if the host controller also indicates endpoit stall condition. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/usb/host/ehci-hcd.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 982f96e..c7fba10 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -491,6 +491,8 @@ ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer, break; default: dev-status = USB_ST_CRC_ERR; + if ((token 0x40) == 0x40) + dev-status |= USB_ST_STALLED; break; } dev-act_len = length - ((token 16) 0x7fff); -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
'usb start' command often fails with Toshiba USB stick 0x930/0x6545 connected to the SMSC USB 2.0 hub 0x424/0x2514. Debugging the issue showed that while bulk IN transfers with length of 13 or 18 the status field of the qTD token sometimes indicates trans- action error (XactErr) and sometimes additionally endpoint halted state. In the latter case resetting the USB device in error handling code works after clearing stall request on the endpoint. In the case where only XactErr bit was set the resetting doesn't work properly and device not ready status will be finally reported. This patch adds reporting endpoint stall status in case of trans- action errors for this hub/stick combination so that the error handling code can reset the device after clearing stall request to the endpoint. However this fix is not enough to solve 'usb start' problem with hub/stick combination mentioned above. Running with lot of debug code in ehci_submit_async() I've never seen the problem with usb stick recognition. After removing this debug code the similar problem sometimes showed up again. Therefore the patch also adds delay in ehci_submit_async() for above-mentioned hub/stick combination. Even without this delay the fix is an improvement since it fixes the problem with board freezy after subsequent failed 'usb start/stop' cycles as it was observed on mpc5121ads board. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/usb/host/ehci-hcd.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index c7fba10..a001143 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -431,6 +431,12 @@ ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer, usbsts = ehci_readl(hcor-or_usbsts); ehci_writel(hcor-or_usbsts, (usbsts 0x3f)); + if (dev-descriptor.idVendor == 0x930 + dev-descriptor.idProduct == 0x6545 + dev-parent-descriptor.idVendor == 0x424 + dev-parent-descriptor.idProduct == 0x2514) + wait_ms(10); + /* Enable async. schedule. */ cmd = ehci_readl(hcor-or_usbcmd); cmd |= CMD_ASE; @@ -493,6 +499,12 @@ ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer, dev-status = USB_ST_CRC_ERR; if ((token 0x40) == 0x40) dev-status |= USB_ST_STALLED; + + if (dev-descriptor.idVendor == 0x930 + dev-descriptor.idProduct == 0x6545 + dev-parent-descriptor.idVendor == 0x424 + dev-parent-descriptor.idProduct == 0x2514) + dev-status |= USB_ST_STALLED; break; } dev-act_len = length - ((token 16) 0x7fff); -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] UBI/UBIFS: Prevent UBI partition change while UBIFS is mounted
Hi Wolfgang, On Monday 01 November 2010 20:06:31 Wolfgang Denk wrote: I'm a bit biased here - from standard Unix command usage it seems natural that you have to manually umount first, but then we have very smple device handling in U-Boot, with always only one device in access. Would it not make sense to auto-unmount in case the user switches the device? I can implement it this way if preferred. I'll prepare a new for this later. As mentioned - I am not sure what would be best here. What is your own position? I prefer the first approach, not automatically unmounting upon UBI device change. One plus for this version is that the user might have issued the 2nd ubi part by mistake and didn't really want to unmount the UBIFS filesystem in the first place. But I have no strong feeling here. So I'm open to suggestions from others which version is the preferred one. Thanks. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] common/cmd_bdinfo.c: fix do_bdinfo() for AVR32
There was a prototype change from do_bdinfo(.. char *) to do_bdinfo(.. char *
const). This patch respect this change for AVR32 architecture.
Signed-off-by: Andreas Bießmann biessm...@corscience.de
---
common/cmd_bdinfo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
index bba7374..1d76ffa 100644
--- a/common/cmd_bdinfo.c
+++ b/common/cmd_bdinfo.c
@@ -304,7 +304,7 @@ int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
#elif defined(CONFIG_AVR32)
-int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
bd_t *bd = gd-bd;
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Le 02/11/2010 10:56, Sughosh Ganu a écrit : hi Albert, On Tue Nov 02, 2010 at 10:47:49AM +0100, Albert ARIBAUD wrote: Now a solution would be that the actual u-boot size be flashed along with it, for instance as a literal defined as '.word _end - _start' right after the vectors. The SPL could load a first NAND block, read the literal, round it to a multiple of NAND blocks by default, and then read this quantity. That would remove the dependency at the cost of extra code in the SPL, though, and not all boards might be able to afford it. Another issue is that the nand_spl might be compiled and flashed to the NAND as a separate entity, using a separate flashing mechanism. If we use the dynamic calculation of the u-boot size, this would necessitate building and flashing the nand_spl each time along with u-boot. Not with the solution I describe, as the once-flashed SPL would fetch the actual size from the actual u-boot. -sughosh Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
On Tue Nov 02, 2010 at 12:16:55PM +0100, Albert ARIBAUD wrote: Le 02/11/2010 10:56, Sughosh Ganu a écrit : hi Albert, On Tue Nov 02, 2010 at 10:47:49AM +0100, Albert ARIBAUD wrote: Now a solution would be that the actual u-boot size be flashed along with it, for instance as a literal defined as '.word _end - _start' right after the vectors. The SPL could load a first NAND block, read the literal, round it to a multiple of NAND blocks by default, and then read this quantity. That would remove the dependency at the cost of extra code in the SPL, though, and not all boards might be able to afford it. Another issue is that the nand_spl might be compiled and flashed to the NAND as a separate entity, using a separate flashing mechanism. If we use the dynamic calculation of the u-boot size, this would necessitate building and flashing the nand_spl each time along with u-boot. Not with the solution I describe, as the once-flashed SPL would fetch the actual size from the actual u-boot. Yes that is correct. I was referring to the other solution of fixing the size through the script. -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: fix linker file for newer ld support
On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUD albert.arib...@free.fr wrote:
Le 02/11/2010 05:05, Steve Sakoman a écrit :
I've been using gcc 4.3.3, so I haven't run into the issue that this
patch is attempting to fix.
I tested this patch using gcc 4.3.3, and while it produces a usable
image, it causes the size of the image to grow from 227K to 433K!
So perhaps we need a patch that uses a more restrictive wildcard.
Steve
Thanks for pointing this out, Steve. That'll go into V3 of my patch set I
guess, as Alexander's patch derives from mine and I most probably hit the
same size increase issue as he does.
Wolfgang: that may mean the tx25 config file patch is unneeded. Stay tuned.
I should have stated that I was using gcc 4.3.3 and binutils 2.18.50,
since indeed it does seem to be binutils related.
I have had a couple of reports that the following patch works with
recent gcc/binutils without increasing the size of the binary.
Could others check and report results?
Steve
ARMV7: Fix build issue with recent versions of gcc/binutils
---
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds
index 88a0fec..e690b58 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -55,7 +55,7 @@ SECTIONS
}
. = ALIGN(4);
__rel_dyn_start = .;
- .rel.dyn : { *(.rel.dyn) }
+ .rel.dyn : { *(.rel.*) }
__rel_dyn_end = .;
__dynsym_start = .;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
Dear Albert ARIBAUD, In message 4ccfde45.3060...@free.fr you wrote: These is a valid point that the SPL isn't necessarily rebuilt and flashed every time u-boot itself is built and flashed, so whatever constant the SPL would carry would only be valid for the u-boot that was built alongside. I have to admit that I was not aware that there are systems were SPL and U-Boot itself are not bundled into a single image, but handled separately. [I have to admit that I don;t like such a setup; it cries for incompatibilities and other trouble.] Now a solution would be that the actual u-boot size be flashed along with it, for instance as a literal defined as '.word _end - _start' right after the vectors. The SPL could load a first NAND block, read the literal, round it to a multiple of NAND blocks by default, and then read this quantity. That would remove the dependency at the cost of extra code in the SPL, though, and not all boards might be able to afford it. Indeed. Maybe be can combine several approaches: - In case SPL and U-Boot are combined into a single image anyway, we can use a compile-time compution of the needed length, without additional code in the SPL. - Where this is not prossible (i. e. SPL and U-Boot are separate), we can try and optionally provide the solution you suggest. - Where memory is toot ight to allow for that code, the old style of a static #define will be used as a fallback. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Due to lack of disk space, this fortune database has been discontinued. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add video support for mx51evk
Dear Stefano Babic, In message 4ccfdeba.2070...@denx.de you wrote: We could introduce a weak function, that a board maintainer can decide to implement or not. This maintains the compatibility with the most drivers where vpanel is static initialized. In which way is this board dependent? Because each board uses a different LCD with a different resolution, and this requires a different amount of memory. This is not different as we see in Linux, because the framebuffer properties are set in the board file before to be passed to the framebuffer driver. Well, if _that_ was what we are using, the memory requirements were fixed, and we could use compile-time constants. But what you discussed before was the option to _switch_ resolutions, so there has to be a way to select the cosen resolution (in an environment variable?), and then this setting is used for the memory calculations. And then the calculation depends only on the current setting - which is _not_ board dependent. Boards would start with a (board dependent) default setting, though. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Steal five dollars and you were a petty thief. Steal thousands of dollars and you are either a government or a hero. - Terry Pratchett, _Going_Postal_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC] AT91 cleanup, was: Re: [PATCH 02/11] at91: Add USART DBGU base address defines
Reinhard Meyer schrieb: Dear All concerned, On Monday 01 November 2010, 11:57:14 Andreas Bießmann wrote: Am 01.11.2010 um 09:29 schrieb Alexander Stein: Signed-off-by: Alexander Steinalexander.st...@systec-electronic.com ... #define AT91_MATRIX_BASE 0xee00 can we just use one naming scheme here? I dunno whether it should be AT91_USx or AT91_USARTx but it should be the same in any case. Yes, sure. I justed copied the dfine and reworded it to match the AT91_$COMPONENT_BASE scheme. Always using USARTx is fine though. Hmm ... I just thought they have renamed their registers in spec, but all checked datasheets use US_xx for USART register names. I also prefer USART here but Reinhard can you please give a comment? Honestly I would prefer a much more thorough cleanup on the long run (or instantly): As was pointed out long ago and just now: a triple indirection of the defines until used in the driver is bad. Since only one of the at91sam.h files is included, all files should directly define the address of a component like follows: #define ATMEL_USART0_BASE 0x'something' Note: that I used ATMEL, not AT91, since the same components are used in AVR32 as well. The name should be descriptive enough, and preferably adhere to what the component is called in the datasheet(s). (Hopefully its consistent there...) Another note: even if currently there is only one incarnation of some peripherals like emac or mci we should try to number them starting from 0, e.g. ATMEL_EMAC0_BASE. As a way to go there I can offer to make a branch at91cleanup where I collect all work and which allows everyone to do incremental improvements which can be squashed into fewer patches later. Then we don't need to base all patch revisions on current master. If you see no other priority, I would delay build-fixing individual boards, but concentrate on cleanup work. Right now is the best opportunity for that since most boards are not building anyway and do not need to be utterly concerned with breaking them even more. After the cleanup is done, we can attend to fixing certain boards. Work could therefore start with cleaning up the at91sam.h files. I am also game with throwing out all LEGACY stuff and fix build problems that occur when they occur. If you agree, the cleanup in the *.h files should entail: 1. remove legacy parts 2. rename AT91_component_BASE consistently into ATMEL_component_BASE and make for example EMAC into EMAC0, I2C into I2C0. I am currently unsure if that needs to be done for SDRAMC, SMC. I think here we can live with SDRAMC and having SDRAMC1 _if_ there is a second one. 3. get rid of hardware.h and have a simple #if-elif-endif chain in memory_map.h instead. So that when memory_map.h is included and the proper #define AT91SAM is set we get exactly the defines valid for that SoC. memory_map.h is consistent with the AVR32 case. The common drivers all include memory_map.h. This *.h cleanup could be patch 1/n of a series. Each individual driver cleanup to remove legacy and adapt to the naming would be 2/n, 3/n, etc. I am willing to collect them in the above mentioned branch and also squash incremental improvements later to produce a clean patch series later. Another optical issue: We have ATxxx_ID_yyy consistently. but both ATxxx_BASE_yyy or ATxxx_yyy_BASE. ATxxx_BASE_yyy would be consistent with the ID variant and look better: ATMEL_BASE_USART0 ATMEL_BASE_SPI0 ... I leaped a bit ahead there, and did some cleanups already. Note that they are not complete and are up for discussion. In order to avoid flooding the list with patches, you can have a look at u-boot-atmel, at91cleanup branch. With best regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] usb: fix for USB_ST_STALLED status reporting in ehci_submit_async()
Hi, 2010/11/2 Anatolij Gustschin ag...@denx.de: Checking the status field of the qTD token in the current code do not take into acount cases where endpoint stall (halted) bit is set together with XactErr status bit. As a result clearing stall on an endpoint won't be done if this status bit was also set. Check for halted bit and report USB_ST_STALLED status if the host controller also indicates endpoit stall condition. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/usb/host/ehci-hcd.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index 982f96e..c7fba10 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -491,6 +491,8 @@ ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer, break; default: dev-status = USB_ST_CRC_ERR; + if ((token 0x40) == 0x40) + dev-status |= USB_ST_STALLED; break; } dev-act_len = length - ((token 16) 0x7fff); Applied to u-boot-usb Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Hi, 2010/11/2 Anatolij Gustschin ag...@denx.de: 'usb start' command often fails with Toshiba USB stick 0x930/0x6545 connected to the SMSC USB 2.0 hub 0x424/0x2514. Debugging the issue showed that while bulk IN transfers with length of 13 or 18 the status field of the qTD token sometimes indicates trans- action error (XactErr) and sometimes additionally endpoint halted state. In the latter case resetting the USB device in error handling code works after clearing stall request on the endpoint. In the case where only XactErr bit was set the resetting doesn't work properly and device not ready status will be finally reported. This patch adds reporting endpoint stall status in case of trans- action errors for this hub/stick combination so that the error handling code can reset the device after clearing stall request to the endpoint. However this fix is not enough to solve 'usb start' problem with hub/stick combination mentioned above. Running with lot of debug code in ehci_submit_async() I've never seen the problem with usb stick recognition. After removing this debug code the similar problem sometimes showed up again. Therefore the patch also adds delay in ehci_submit_async() for above-mentioned hub/stick combination. Even without this delay the fix is an improvement since it fixes the problem with board freezy after subsequent failed 'usb start/stop' cycles as it was observed on mpc5121ads board. Signed-off-by: Anatolij Gustschin ag...@denx.de --- drivers/usb/host/ehci-hcd.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c index c7fba10..a001143 100644 --- a/drivers/usb/host/ehci-hcd.c +++ b/drivers/usb/host/ehci-hcd.c @@ -431,6 +431,12 @@ ehci_submit_async(struct usb_device *dev, unsigned long pipe, void *buffer, usbsts = ehci_readl(hcor-or_usbsts); ehci_writel(hcor-or_usbsts, (usbsts 0x3f)); + if (dev-descriptor.idVendor == 0x930 + dev-descriptor.idProduct == 0x6545 + dev-parent-descriptor.idVendor == 0x424 + dev-parent-descriptor.idProduct == 0x2514) + wait_ms(10); + I have to say that I have a problem with this construction. This will solve only 1 particular situation where the user has exactly this USB stick and exactly this hub. If he uses another hub, he can have the same problem. If he use another USB-stick he also can run into this problem. What is the real cause of this issue, and can it be solved in a generic way? I feel the problem is still not understood. So, I NAK this patch.. Sorry... Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] UBI/UBIFS: Prevent UBI partition change while UBIFS is mounted
On Tue, Nov 2, 2010 at 6:49 AM, Stefan Roese s...@denx.de wrote: Hi Wolfgang, On Monday 01 November 2010 20:06:31 Wolfgang Denk wrote: I'm a bit biased here - from standard Unix command usage it seems natural that you have to manually umount first, but then we have very smple device handling in U-Boot, with always only one device in access. Would it not make sense to auto-unmount in case the user switches the device? I can implement it this way if preferred. I'll prepare a new for this later. As mentioned - I am not sure what would be best here. What is your own position? I prefer the first approach, not automatically unmounting upon UBI device change. One plus for this version is that the user might have issued the 2nd ubi part by mistake and didn't really want to unmount the UBIFS filesystem in the first place. But I have no strong feeling here. So I'm open to suggestions from others which version is the preferred one. FWIW: I prefer the option where the UBIFS is automatically unmounted. At first I was in favour of not automatically unmounting since it emulates more closely the interface of a unix environment, to which I am biased. However, automatically unmounting has an important advantage: the state resulting from a 'ubi part' command is the same regardless of the initial 'mounted state'. This make scripting boot sequences simpler. The alternative would be to provide a 'test mounted' command along with the option where ubi part does not automatically unmount. Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Dear Remy Bohmer, In message aanlktikqeftb=xeav1g6xyvoy3hw3imcpifild0kv...@mail.gmail.com you wrote: + if (dev-descriptor.idVendor == 0x930 + dev-descriptor.idProduct == 0x6545 + dev-parent-descriptor.idVendor == 0x424 + dev-parent-descriptor.idProduct == 0x2514) + wait_ms(10); + I have to say that I have a problem with this construction. This will solve only 1 particular situation where the user has exactly this USB stick and exactly this hub. If he uses another hub, he can have the same problem. If he use another USB-stick he also can run into this problem. What is the real cause of this issue, and can it be solved in a generic way? I feel the problem is still not understood. Indeed the problem is not exactly understood. Anatolij has tested a wide range of board / hub / stick combinations, and the problem happens only with this very combination. Yes, there is a chance that another hub / stick combination might show similar issues, but so far we have not been able to find such another combo. So, I NAK this patch.. Sorry... So what do you propose to solve the problem? Of course we could add the delay unconditionally, for all systems. But it brings with it a performance degradation which I would not like to see either. What do you suggest to provide a solution for this specific situation? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Wisdom is one of the few things that looks bigger the further away it is. - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RFC] ARMV7: OMAP: Fix build after introduction of GENERATED_GBL_DATA_SIZE
On Wed, Oct 27, 2010 at 10:32 AM, Paulraj, Sandeep s-paul...@ti.com wrote: On Wed, 2010-10-27 at 17:11 +0200, Wolfgang Denk wrote: Dear Paulraj, Sandeep, In message 0554bef07d437848af01b9c9b5f0bc5da9d89...@dlee01.ent.ti.com you wrote: Test this patch on my beagle board, works fine: Tested-by: Heiko Schocher h...@denx.de Should I consider this a bug fix and add it to my tree? I believe the patch itself came after the merge window ended Yes, all these are bug fixes needed to get the current code working as expected. Please apply. Thanks. Sandeep, there are a couple of other pending patches that are build fixers: ARMV7: OMAP3: IGEP: Rename TEXT_BASE ARMV7: Fix build for non-OMAP3 boards They've been posted to the list for a few days now, and are also sitting in my omap4-next-upstream branch. Steve Yes I have seen them. Pull request will be sent on Saturday or Sunday. Any update on this? It would be good to get mainline in a build-able state again. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add video support for mx51evk
On 11/02/2010 02:34 PM, Wolfgang Denk wrote: Because each board uses a different LCD with a different resolution, and this requires a different amount of memory. This is not different as we see in Linux, because the framebuffer properties are set in the board file before to be passed to the framebuffer driver. Well, if _that_ was what we are using, the memory requirements were fixed, and we could use compile-time constants. I was not complete: a single board can be connected to several LCDs, of course not at the same type. The decision which LCD must be used should be taken baing on an environment variable. But what you discussed before was the option to _switch_ resolutions, so there has to be a way to select the cosen resolution (in an environment variable?), Yes, this is what I meant and then this setting is used for the memory calculations. Correct. And then the calculation depends only on the current setting - which is _not_ board dependent. Yes, calculation is not board dependent and must remain in lcd_setmem(). What I meant as board dependent is really the LCD settings, in terms of display resolution and bits x pixel. The proposed wek function can set the panel_info structure, that lcd_setmem() uses for computation. Boards would start with a (board dependent) default setting, though. Yes. What we need is a way to get the board default setting to allow lcd_setmem() to compute the required memory. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Hi Wolfgang, 2010/11/2 Wolfgang Denk w...@denx.de: Dear Remy Bohmer, In message aanlktikqeftb=xeav1g6xyvoy3hw3imcpifild0kv...@mail.gmail.com you wrote: + if (dev-descriptor.idVendor == 0x930 + dev-descriptor.idProduct == 0x6545 + dev-parent-descriptor.idVendor == 0x424 + dev-parent-descriptor.idProduct == 0x2514) + wait_ms(10); + I have to say that I have a problem with this construction. This will solve only 1 particular situation where the user has exactly this USB stick and exactly this hub. If he uses another hub, he can have the same problem. If he use another USB-stick he also can run into this problem. What is the real cause of this issue, and can it be solved in a generic way? I feel the problem is still not understood. Indeed the problem is not exactly understood. Anatolij has tested a wide range of board / hub / stick combinations, and the problem happens only with this very combination. Yes, there is a chance that another hub / stick combination might show similar issues, but so far we have not been able to find such another combo. So, I NAK this patch.. Sorry... So what do you propose to solve the problem? Of course we could add the delay unconditionally, for all systems. But it brings with it a performance degradation which I would not like to see either. Agreed What do you suggest to provide a solution for this specific situation? I have no idea what has been done, and has not been done. I have not been debugging this issue. I have no idea if a USB protocol analyser has shown something weird or something we could work on. But anyway: You admit that the problem is not understood, so would the delay fix the problem, or just make it less obvious? If we would allow such workarounds to U-boot we would end up with endless lists of device-ids that are excluded in some situation all over the place. The code would just become fluttered with all kinds of exceptions to mask problems not being understood and not being debugged properly. And in this case: How big is the chance that any other user will have exact the same hardware combination and run into this problem? I guess that would be close to zero... My guts tells me that the chance that other combinations require the same 'fix' is bigger... If it is proven to be a bug of a specific device, that would change the situation, in that case we would work-around a certain device bug that really cannot be solved otherwise. In that case we would _know_ what problem we are working around, and that would be a limited of devices and situations. We at least could document it. So, I need more info to convince me that this is the right solution. Does, for example, Linux have similar issues? If not, why is it working there. Does a protocol analyser show different behaviour, different timing, different data? What is different? Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: fix linker file for newer ld support
Le 02/11/2010 14:08, Steve Sakoman a écrit :
On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUDalbert.arib...@free.fr
wrote:
Le 02/11/2010 05:05, Steve Sakoman a écrit :
I've been using gcc 4.3.3, so I haven't run into the issue that this
patch is attempting to fix.
I tested this patch using gcc 4.3.3, and while it produces a usable
image, it causes the size of the image to grow from 227K to 433K!
So perhaps we need a patch that uses a more restrictive wildcard.
Steve
Thanks for pointing this out, Steve. That'll go into V3 of my patch set I
guess, as Alexander's patch derives from mine and I most probably hit the
same size increase issue as he does.
Wolfgang: that may mean the tx25 config file patch is unneeded. Stay tuned.
I should have stated that I was using gcc 4.3.3 and binutils 2.18.50,
since indeed it does seem to be binutils related.
I have had a couple of reports that the following patch works with
recent gcc/binutils without increasing the size of the binary.
Could others check and report results?
Steve
ARMV7: Fix build issue with recent versions of gcc/binutils
---
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds
index 88a0fec..e690b58 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -55,7 +55,7 @@ SECTIONS
}
. = ALIGN(4);
__rel_dyn_start = .;
- .rel.dyn : { *(.rel.dyn) }
+ .rel.dyn : { *(.rel.*) }
__rel_dyn_end = .;
__dynsym_start = .;
Weird... This patch seems indeed more restrictive than mine, but the
input sections collected in .rel.dyn are actually the same for both.
We can gain a bit less than 60k by overlapping .bss and .rel.dyn, but
certainly not 200k!
OTOH, it happened during my 'cross-build' tests (using one chain's gcc
with another chain's ld) that the resulting u-boot was drastically
reduced; but I chalked that to my misusing of the build tools.
Steve, can you indicate which toolchain excatly exhibits the
230k-to-430k issue, and which board I should build?
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/cmd_bdinfo.c: fix do_bdinfo() for AVR32
Dear Andreas Bießmann,
Your e-Mail is:
Content-Transfer-Encoding: quoted-printable
That means ' ' comes as =20, '=' comes as =3D
There was a prototype change from do_bdinfo(.. char *) to do_bdinfo(.. char *
const). This patch respect this change for AVR32 architecture.
Signed-off-by: Andreas Bießmann biessm...@corscience.de
---
common/cmd_bdinfo.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/common/cmd_bdinfo.c b/common/cmd_bdinfo.c
index bba7374..1d76ffa 100644
--- a/common/cmd_bdinfo.c
+++ b/common/cmd_bdinfo.c
@@ -304,7 +304,7 @@ int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
#elif defined(CONFIG_AVR32)
-int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+int do_bdinfo ( cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
{
bd_t *bd = gd-bd;
I see that cmd_bdinfo.c has lots of coding style violations, but
some architectures have them fixed.
Could we at least fix them in the AVR32 part, if we touch it anyway?
See the BLACKFIN example ;)
Or is it OK to leave it as is? Wolfgang?
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: fix linker file for newer ld support
On Tue, Nov 2, 2010 at 9:28 AM, Albert ARIBAUD albert.arib...@free.fr wrote:
Le 02/11/2010 14:08, Steve Sakoman a écrit :
On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUDalbert.arib...@free.fr
wrote:
Le 02/11/2010 05:05, Steve Sakoman a écrit :
I've been using gcc 4.3.3, so I haven't run into the issue that this
patch is attempting to fix.
I tested this patch using gcc 4.3.3, and while it produces a usable
image, it causes the size of the image to grow from 227K to 433K!
So perhaps we need a patch that uses a more restrictive wildcard.
Steve
Thanks for pointing this out, Steve. That'll go into V3 of my patch set I
guess, as Alexander's patch derives from mine and I most probably hit the
same size increase issue as he does.
Wolfgang: that may mean the tx25 config file patch is unneeded. Stay
tuned.
I should have stated that I was using gcc 4.3.3 and binutils 2.18.50,
since indeed it does seem to be binutils related.
I have had a couple of reports that the following patch works with
recent gcc/binutils without increasing the size of the binary.
Could others check and report results?
Steve
ARMV7: Fix build issue with recent versions of gcc/binutils
---
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds
index 88a0fec..e690b58 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -55,7 +55,7 @@ SECTIONS
}
. = ALIGN(4);
__rel_dyn_start = .;
- .rel.dyn : { *(.rel.dyn) }
+ .rel.dyn : { *(.rel.*) }
__rel_dyn_end = .;
__dynsym_start = .;
Weird... This patch seems indeed more restrictive than mine, but the input
sections collected in .rel.dyn are actually the same for both.
We can gain a bit less than 60k by overlapping .bss and .rel.dyn, but
certainly not 200k!
OTOH, it happened during my 'cross-build' tests (using one chain's gcc with
another chain's ld) that the resulting u-boot was drastically reduced; but I
chalked that to my misusing of the build tools.
Steve, can you indicate which toolchain excatly exhibits the 230k-to-430k
issue, and which board I should build?
I used gcc 4.3.3 and binutils 2.18.50 and built beagle and overo.
Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: fix linker file for newer ld support
Albert ARIBAUD albert.arib...@free.fr writes:
Le 02/11/2010 14:08, Steve Sakoman a écrit :
On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUDalbert.arib...@free.fr
wrote:
Le 02/11/2010 05:05, Steve Sakoman a écrit :
I've been using gcc 4.3.3, so I haven't run into the issue that this
patch is attempting to fix.
I tested this patch using gcc 4.3.3, and while it produces a usable
image, it causes the size of the image to grow from 227K to 433K!
So perhaps we need a patch that uses a more restrictive wildcard.
Steve
Thanks for pointing this out, Steve. That'll go into V3 of my patch set I
guess, as Alexander's patch derives from mine and I most probably hit the
same size increase issue as he does.
Wolfgang: that may mean the tx25 config file patch is unneeded. Stay tuned.
I should have stated that I was using gcc 4.3.3 and binutils 2.18.50,
since indeed it does seem to be binutils related.
I have had a couple of reports that the following patch works with
recent gcc/binutils without increasing the size of the binary.
Could others check and report results?
Steve
ARMV7: Fix build issue with recent versions of gcc/binutils
---
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds
index 88a0fec..e690b58 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -55,7 +55,7 @@ SECTIONS
}
. = ALIGN(4);
__rel_dyn_start = .;
-.rel.dyn : { *(.rel.dyn) }
+.rel.dyn : { *(.rel.*) }
__rel_dyn_end = .;
__dynsym_start = .;
Weird... This patch seems indeed more restrictive than mine, but the
input sections collected in .rel.dyn are actually the same for both.
We can gain a bit less than 60k by overlapping .bss and .rel.dyn, but
certainly not 200k!
OTOH, it happened during my 'cross-build' tests (using one chain's gcc
with another chain's ld) that the resulting u-boot was drastically
reduced; but I chalked that to my misusing of the build tools.
Steve, can you indicate which toolchain excatly exhibits the
230k-to-430k issue, and which board I should build?
The problem is that the first patch posted here places .rel.dyn after
.bss, so when dumping u-boot.img, all of .bss is included in the file.
Keeping it before .bss allows the flat binary to omit .bss as usual.
Using the patch quoted above, I get a working u-boot from all
combinations of gcc and binutils I cared to try, including gcc
4.5-linaro with binutils 2.20.1.
--
Måns Rullgård
m...@mansr.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/cmd_bdinfo.c: fix do_bdinfo() for AVR32
Dear Reinhard Meyer, Am 02.11.2010 um 17:34 schrieb Reinhard Meyer: Dear Andreas Bießmann, Your e-Mail is: Content-Transfer-Encoding: quoted-printable That means ' ' comes as =20, '=' comes as =3D grr .. I wonder which part of the chain it was, will fix that. I see that cmd_bdinfo.c has lots of coding style violations, but some architectures have them fixed. Could we at least fix them in the AVR32 part, if we touch it anyway? See the BLACKFIN example ;) I see, will fix that too. I have one additional change (my board does not have network at all ;). Patch will follow tomorrow. regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] armv7: fix linker file for newer ld support
Le 02/11/2010 18:00, Måns Rullgård a écrit :
Albert ARIBAUDalbert.arib...@free.fr writes:
Le 02/11/2010 14:08, Steve Sakoman a écrit :
On Tue, Nov 2, 2010 at 12:48 AM, Albert ARIBAUDalbert.arib...@free.fr
wrote:
Le 02/11/2010 05:05, Steve Sakoman a écrit :
I've been using gcc 4.3.3, so I haven't run into the issue that this
patch is attempting to fix.
I tested this patch using gcc 4.3.3, and while it produces a usable
image, it causes the size of the image to grow from 227K to 433K!
So perhaps we need a patch that uses a more restrictive wildcard.
Steve
Thanks for pointing this out, Steve. That'll go into V3 of my patch set I
guess, as Alexander's patch derives from mine and I most probably hit the
same size increase issue as he does.
Wolfgang: that may mean the tx25 config file patch is unneeded. Stay tuned.
I should have stated that I was using gcc 4.3.3 and binutils 2.18.50,
since indeed it does seem to be binutils related.
I have had a couple of reports that the following patch works with
recent gcc/binutils without increasing the size of the binary.
Could others check and report results?
Steve
ARMV7: Fix build issue with recent versions of gcc/binutils
---
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds
index 88a0fec..e690b58 100644
--- a/arch/arm/cpu/armv7/u-boot.lds
+++ b/arch/arm/cpu/armv7/u-boot.lds
@@ -55,7 +55,7 @@ SECTIONS
}
. = ALIGN(4);
__rel_dyn_start = .;
- .rel.dyn : { *(.rel.dyn) }
+ .rel.dyn : { *(.rel.*) }
__rel_dyn_end = .;
__dynsym_start = .;
Weird... This patch seems indeed more restrictive than mine, but the
input sections collected in .rel.dyn are actually the same for both.
We can gain a bit less than 60k by overlapping .bss and .rel.dyn, but
certainly not 200k!
OTOH, it happened during my 'cross-build' tests (using one chain's gcc
with another chain's ld) that the resulting u-boot was drastically
reduced; but I chalked that to my misusing of the build tools.
Steve, can you indicate which toolchain excatly exhibits the
230k-to-430k issue, and which board I should build?
The problem is that the first patch posted here places .rel.dyn after
..bss, so when dumping u-boot.img, all of .bss is included in the file.
Keeping it before .bss allows the flat binary to omit .bss as usual.
Indeed, but that accounts only for about 60k, as I said. Steve talks
about a 200k delta; I can't find how this much can be added just by
moving the .rel.dyn section around.
The idea of having .text, .*data and .bss contiguous is that it will
reduce RAM footprint. In order to keep this and not increase FLASH/NAND
footprint, I think we can overlap .bss and .rel.dyn.
Using the patch quoted above, I get a working u-boot from all
combinations of gcc and binutils I cared to try, including gcc
4.5-linaro with binutils 2.20.1.
Thanks for the feedback.
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add video support for mx51evk
Dear Stefano Babic, In message 4cd035f7.9070...@denx.de you wrote: And then the calculation depends only on the current setting - which is _not_ board dependent. Yes, calculation is not board dependent and must remain in lcd_setmem(). What I meant as board dependent is really the LCD settings, in terms of display resolution and bits x pixel. The proposed wek function can set the panel_info structure, that lcd_setmem() uses for computation. Why do we need a board dependent function for that? We can adjust the setings by storing their value in an environment variable, say some- thing like 800x600...@60hz or copying what Linux does with the video- mode= boot argument (we already have drivers/video/videomodes.c). That should be precise enough, and is completely bosrd-independent. Boards would start with a (board dependent) default setting, though. Yes. What we need is a way to get the board default setting to allow lcd_setmem() to compute the required memory. Let's re-use existing interfaces (especially if we then can pass the very same variable as boot argument to Linux). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de CONSUMER NOTICE: Because of the Uncertainty Principle, It Is Impossible for the Consumer to Find Out at the Same Time Both Precisely Where This Product Is and How Fast It Is Moving. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Dear Remy, In message aanlktimtzosbtobm_og304gbrcpcm1wjet0xqo+mg...@mail.gmail.com you wrote: I have no idea what has been done, and has not been done. I have not been debugging this issue. I have no idea if a USB protocol analyser has shown something weird or something we could work on. Sorry - we don;t have a USB protocol analyzer that does high-speed. So our debugging is mostly limited to what we can see in the controller, and in the software levels above it. But anyway: You admit that the problem is not understood, so would the delay fix the problem, or just make it less obvious? You know that I cannot really answer this question. Without exact understanding what is going on it is just a pretty much dirty work around. It helps in this specific test case, but we have zero knowledge if it helps in opther cases, and what these cases may be. The interesting part of these tests was that the problem really sticks to one specific combination of hub and storage device. If we would allow such workarounds to U-boot we would end up with endless lists of device-ids that are excluded in some situation all over the place. The code would just become fluttered with all kinds of exceptions to mask problems not being understood and not being debugged properly. Agreed. And in this case: How big is the chance that any other user will have exact the same hardware combination and run into this problem? I guess that would be close to zero... My guts tells me that the chance that other combinations require the same 'fix' is bigger... I am positive sure that other uses with this hardware combination _will_ run into the same problem. This fix was developed for a customer who needed it pretty much urgently because he was using this combo in numbers where he preferred paying for the fix over throwing away the sticks and.or hubs and using other models. The problem was reliablew repeatable on all his devices. And we saw it on PowerPC (MPC5121) and ARM (Kirkwood). That's why I'm pretty sure that it whill hit if you run such a combo. If it is proven to be a bug of a specific device, that would change the situation, in that case we would work-around a certain device bug that really cannot be solved otherwise. In that case we would _know_ what problem we are working around, and that would be a limited of devices and situations. We at least could document it. Unfortunately we can only point at the combo of devices - each for itself appears to be working OK. So, I need more info to convince me that this is the right solution. Does, for example, Linux have similar issues? If not, why is it No, we did not observe such problems under Linux. We were not able to find out why. working there. Does a protocol analyser show different behaviour, different timing, different data? What is different? We don't have any such information, unfortunately. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Bugs are by far the largest and most successful class of entity, with nearly a million known species. In this res- pect they outnumber all the other known creatures about four to one. -- Professor Snope's Encyclopedia of Animal ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] common/cmd_bdinfo.c: fix do_bdinfo() for AVR32
Dear Reinhard Meyer, In message 4cd03d9c.6070...@emk-elektronik.de you wrote: I see that cmd_bdinfo.c has lots of coding style violations, but some architectures have them fixed. Could we at least fix them in the AVR32 part, if we touch it anyway? See the BLACKFIN example ;) Or is it OK to leave it as is? Wolfgang? Coding style fixes are OK, but should be done on file scope, and independent from changed to the actual content of the file. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Whenever people agree with me, I always think I must be wrong. - Oscar Wilde ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Hi, 2010/11/2 Wolfgang Denk w...@denx.de: Dear Remy, In message aanlktimtzosbtobm_og304gbrcpcm1wjet0xqo+mg...@mail.gmail.com you wrote: I have no idea what has been done, and has not been done. I have not been debugging this issue. I have no idea if a USB protocol analyser has shown something weird or something we could work on. Sorry - we don;t have a USB protocol analyzer that does high-speed. So our debugging is mostly limited to what we can see in the controller, and in the software levels above it. Hmm, then, unfortunately, you are quite blindfolded for debugging this problem... If we would allow such workarounds to U-boot we would end up with endless lists of device-ids that are excluded in some situation all over the place. The code would just become fluttered with all kinds of exceptions to mask problems not being understood and not being debugged properly. Agreed. As U-boot project-owner you know you have the last word in this. How do you think how to continue from here? And in this case: How big is the chance that any other user will have exact the same hardware combination and run into this problem? I guess that would be close to zero... My guts tells me that the chance that other combinations require the same 'fix' is bigger... I am positive sure that other uses with this hardware combination _will_ run into the same problem. This fix was developed for a customer who needed it pretty much urgently because he was using this combo in numbers where he preferred paying for the fix over throwing away the sticks and.or hubs and using other models. The problem was reliablew repeatable on all his devices. And we saw it on PowerPC (MPC5121) and ARM (Kirkwood). That's why I'm pretty sure that it whill hit if you run such a combo. Understood. If it is proven to be a bug of a specific device, that would change the situation, in that case we would work-around a certain device bug that really cannot be solved otherwise. In that case we would _know_ what problem we are working around, and that would be a limited of devices and situations. We at least could document it. Unfortunately we can only point at the combo of devices - each for itself appears to be working OK. OK So, I need more info to convince me that this is the right solution. Does, for example, Linux have similar issues? If not, why is it No, we did not observe such problems under Linux. We were not able to find out why. There should be a difference in controlling the devices triggering the bug, and without hispeed analyser it will be extremely hard to find. We have one here, but we do not have your boards, USB hub/devices and so on. (And... neither do I have the time to debug it for you...) working there. Does a protocol analyser show different behaviour, different timing, different data? What is different? We don't have any such information, unfortunately. Understood. Kind regards, Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Dear Remy Bohmer, In message aanlktik0bxxfe8d5+96gy_=+cu0h_fkeyutfyo=cr...@mail.gmail.com you wrote: As U-boot project-owner you know you have the last word in this. This is a pretty precious resource that should be used wisely, and not without real need. This topic is clearly in your domain, and while I'm trying to explain the situation to you, I will not try to influence your decision. How do you think how to continue from here? I don't really know. There should be a difference in controlling the devices triggering the bug, and without hispeed analyser it will be extremely hard to find. We have one here, but we do not have your boards, USB hub/devices and so on. (And... neither do I have the time to debug it for you...) Nobody expects that you spend time and resources (and for free) on such a pretty exotic issue. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Even if you aren't in doubt, consider the mental welfare of the per- son who has to maintain the code after you, and who will probably put parens in the wrong place. - Larry Wall in the perl man page ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] ARMV7: Fixing Vexpress build errors and warnings
From: Matt Waddel matt.wad...@linaro.org These patches fix several build errors and warnings. A successful build for this platform depends on Steve Sakoman's ARMV7: Fix build for non-OMAP3 boards patch. Matt Waddel (2): ARMV7: Vexpress build errors ARMV7: Vexpress compile warnings arch/arm/include/asm/arch-armv7/sys_proto.h | 29 board/armltd/vexpress/ca9x4_ct_vxp.c|9 +++- board/armltd/vexpress/config.mk |3 +- board/armltd/vexpress/u-boot.lds| 65 --- 4 files changed, 36 insertions(+), 70 deletions(-) create mode 100644 arch/arm/include/asm/arch-armv7/sys_proto.h delete mode 100644 board/armltd/vexpress/u-boot.lds ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARMV7: Vexpress build errors
From: Matt Waddel matt.wad...@linaro.org
This patch fixes build errors in the vexpress system:
- syslib.c requires sys_proto.h file, used the example from /arch-mx5/.
- The linker script was missing required sections. Found the default
armv7 linker script can be used by vexpress. Switched to that one.
- Renamed TEXT_BASE to CONFIG_SYS_TEXT_BASE.
Signed-off-by: Matt Waddel matt.wad...@linaro.org
---
arch/arm/include/asm/arch-armv7/sys_proto.h | 29
board/armltd/vexpress/config.mk |3 +-
board/armltd/vexpress/u-boot.lds| 65 ---
3 files changed, 30 insertions(+), 67 deletions(-)
create mode 100644 arch/arm/include/asm/arch-armv7/sys_proto.h
delete mode 100644 board/armltd/vexpress/u-boot.lds
diff --git a/arch/arm/include/asm/arch-armv7/sys_proto.h
b/arch/arm/include/asm/arch-armv7/sys_proto.h
new file mode 100644
index 000..f77446a
--- /dev/null
+++ b/arch/arm/include/asm/arch-armv7/sys_proto.h
@@ -0,0 +1,29 @@
+/*
+ * (C) Copyright 2009
+ * Stefano Babic, DENX Software Engineering, sba...@denx.de.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef _SYS_PROTO_H_
+#define _SYS_PROTO_H_
+
+void sdelay(unsigned long);
+
+#endif
diff --git a/board/armltd/vexpress/config.mk b/board/armltd/vexpress/config.mk
index 2d797d7..36395f2 100644
--- a/board/armltd/vexpress/config.mk
+++ b/board/armltd/vexpress/config.mk
@@ -19,5 +19,4 @@
#
# Linux-Kernel is expected to be at 0x60008000
#
-TEXT_BASE = 0x6080
-LDSCRIPT := $(SRCTREE)/board/armltd/vexpress/u-boot.lds
+CONFIG_SYS_TEXT_BASE = 0x6080
diff --git a/board/armltd/vexpress/u-boot.lds b/board/armltd/vexpress/u-boot.lds
deleted file mode 100644
index 5ac62f2..000
--- a/board/armltd/vexpress/u-boot.lds
+++ /dev/null
@@ -1,65 +0,0 @@
-/*
- * (C) Copyright 2002
- * Gary Jennejohn, DENX Software Engineering, g...@denx.de
- *
- * See file CREDITS for list of people who contributed to this
- * project.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation; either version 2 of
- * the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
- * MA 02111-1307 USA
- */
-OUTPUT_FORMAT(elf32-littlearm, elf32-littlearm, elf32-littlearm)
-OUTPUT_ARCH(arm)
-ENTRY(_start)
-SECTIONS
-{
- . = 0x;
- . = ALIGN(4);
- .text :
- {
- arch/arm/cpu/armv7/start.o (.text)
- *(.text)
- }
-
- . = ALIGN(4);
- .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata))) }
-
- . = ALIGN(4);
- .data : { *(.data)
- __datarel_start = .;
- *(.data.rel)
- __datarelrolocal_start = .;
- *(.data.rel.ro.local)
- __datarellocal_start = .;
- *(.data.rel.local)
- __datarelro_start = .;
- *(.data.rel.ro)
- }
-
- __got_start = .;
- . = ALIGN(4);
- .got : { *(.got) }
- __got_end = .;
-
- . = .;
- __u_boot_cmd_start = .;
- .u_boot_cmd : { *(.u_boot_cmd) }
- __u_boot_cmd_end = .;
-
- . = ALIGN(4);
- __bss_start = .;
- .bss : { *(.bss) }
- _end = .;
-}
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARMV7: Vexpress compile warnings
From: Matt Waddel matt.wad...@linaro.org
Fixed pointer from integer without a cast warnings in Vexpress.
Signed-off-by: Matt Waddel matt.wad...@linaro.org
---
board/armltd/vexpress/ca9x4_ct_vxp.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/board/armltd/vexpress/ca9x4_ct_vxp.c
b/board/armltd/vexpress/ca9x4_ct_vxp.c
index 48dfc8c..c1c4ea1 100644
--- a/board/armltd/vexpress/ca9x4_ct_vxp.c
+++ b/board/armltd/vexpress/ca9x4_ct_vxp.c
@@ -95,16 +95,19 @@ static void flash__init(void)
int dram_init(void)
{
- gd-ram_size = get_ram_size(CONFIG_SYS_SDRAM_BASE, PHYS_SDRAM_1_SIZE);
+ gd-ram_size =
+ get_ram_size((long *)CONFIG_SYS_SDRAM_BASE, PHYS_SDRAM_1_SIZE);
return 0;
}
void dram_init_banksize(void)
{
gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
- gd-bd-bi_dram[0].size = get_ram_size(PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
+ gd-bd-bi_dram[0].size =
+ get_ram_size((long *)PHYS_SDRAM_1, PHYS_SDRAM_1_SIZE);
gd-bd-bi_dram[1].start = PHYS_SDRAM_2;
- gd-bd-bi_dram[1].size = get_ram_size(PHYS_SDRAM_2, PHYS_SDRAM_2_SIZE);
+ gd-bd-bi_dram[1].size =
+ get_ram_size((long *)PHYS_SDRAM_2, PHYS_SDRAM_2_SIZE);
}
int timer_init(void)
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Add video support for mx51evk
Hello Stefano Babic, On Tue, Nov 2, 2010 at 4:40 AM, Stefano Babic sba...@denx.de wrote: However, it is really better to make the modification for the vision2 inside the same patchset. This guarantees that both boards work when your patches go to mainline. Ok! Should I send the patch for vision2, also? Thanks for pointing out, I have already seen the point, but at the end I forget to fix it ;-). Probably because there is no side-effects on this board, but this does not mean that the issue should not fixed for vision2, too. This issue affects the video mx51evk, at least for the patch I sent. If I don't edit lcd.c the board resets when writing to the framebuffer, upon boot. Best Regards, Renato ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] Add flexibility to mx51 video support
Hello Stefano B, On Tue, Nov 2, 2010 at 4:57 AM, Stefano Babic sba...@denx.de wrote: you patch seems to be corrupted and does not apply. It seems your mailer is responsible for this. It puts html code in the mail, too: Shame on me! I apologize for the mess, I configured Outlook for plain text. I'll submit again... I admit that I took the fix.id string from the linux driver, but it is not used at all in the code. If we do not find a useful reason for it, it should be probably better to get rid of it to avoid confusion. Agree! I can not see usage for this, will remove from the patch. This is only a debug output to check the values in the panel_info structure and prints them without doing any computation. If you want to add the NBITS value (that in any case can be computed), please leave the original output of vl_bpix, too. Agree! I will remove from the patch. Thanks, Renato ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Add video support to mx51evk board
Hello Stefano B, On Tue, Nov 2, 2010 at 5:05 AM, Stefano Babic sba...@denx.de wrote: This patch is corrupted as the first one by your mailer. I'm really sorry, I'll submit again. It seems you start with trailing whitespaces instead of tabs I will fix on the next patch. With the vision2 I introduced constants to set pads (PAD_CTL_*). At least for new values, you should use it. Ok!. Are the new defines inside a comment ? Yes, they are. Only those working with the WVGA display will benefit from it. There is no video support the LVDS or DVI output yet. Do you have any recommendation here? Best Regards, Renato ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot for mini6410
Dear Darius, I noticed that you’re also working on porting u-boot to FriendlyARM's mini6410. Can I know the status of porting? I met some problem, for which I bleive lies in nand_spl relocation support, after rebased my uboot patch for mini6410 to current u-boot master. Thank you very much! Best Regards, Alex ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad page state in process 'swapper'
Hi, I found that vmalloc is not able to allocate the memory. What parameters from u-boot are not right? Thanks! Shuyou -Original Message- From: sywang [mailto:syw...@dongniannetworks.com] Sent: 2010年11月2日 16:13 To: 'Albert ARIBAUD' Cc: 'u-boot@lists.denx.de' Subject: RE: Bad page state in process 'swapper' Albert, Thanks for your reply. My log is shown below. What you say is right. The error information is from Linux. I guess that what parameters passed to Linux by u-boot may be not right. However, I don't know how to identify? TFTP from server 192.168.5.101; our IP address is 192.168.5.22 Filename 'mips.ari'. Load address: 0x9f0 Loading: # done Bytes transferred = 2917360 (2c83f0 hex) Image is not signed; verifying checksum... passed do_tftpboot, Linux image has been verified: pass do_tftpboot, going to do_bootoctlinux octeon_phy_mem_block_free addr: 0x10, size: 0x800 ELF file is 64 bit block alloc called: req_size: 0x2b25e0, min_addr: 0xa0, max_addr: 0x0, align: 0x0 Allocated memory for ELF segment: addr: 0xa0, size 0x2b25e0 block alloc called: req_size: 0xd0, min_addr: 0xcb25e0, max_addr: 0x0, align: 0x0 Allocated memory for ELF segment: addr: 0xcb25e0, size 0xd0 Loading .text @ 0x80a0 (0x2b25b8 bytes) Clearing .bss @ 0x80cb25c0 (0x20 bytes) Loading .data @ 0x80cb25e0 (0x30 bytes) Loading .MIPS.options @ 0x80cb2610 (0xa0 bytes) naddr 2 addr vec 0, 0x2b25e0 @ 0xa0 addr vec 1, 0xd0 @ 0xcb25e0 ## Loading OS kernel with entry point: 0x80a0 ... block alloc called: req_size: 0x77, min_addr: 0x0, max_addr: 0x7fff, align: 0x0 block alloc called: req_size: 0x190, min_addr: 0x0, max_addr: 0x7fff, align: 0x0 block alloc called: req_size: 0x98, min_addr: 0x0, max_addr: 0x7fff, align: 0x0 board type is: 11, CN3010_EVB_HS5 stack expected: 0x0, actual: 0x0 heap_base expected: 0x0, actual: 0x0 heap_top expected: 0x0, actual: 0x0 Entry point (virt): 0x80a0 Address of start app: 0x80096d90 Bootloader: Done loading app on coremask: 0x1 octeon_phy_mem_block_free addr: 0x9f0, size: 0x600 octeon_phy_mem_block_free addr: 0x810, size: 0x3200 octeon_phy_mem_block_free addr: 0x8103200, size: 0x2 octeon_phy_mem_block_free addr: 0x8123200, size: 0x32000 do_bootoctlinux, going to start_cores Bringing coremask: 0x1 out of reset! Address of start app: 0x80070914 block alloc called: req_size: 0x330, min_addr: 0x0, max_addr: 0x4000, align: 0x0 Bootloader: Starting app at cycle: 0 Welcome to start_cores. (octeon_boot.c:1547) start_cores, going to BOOT_VECTOR_BASE app_start_func_addr 80096d90 start_linux printf_boot_init_vector stack_addr:0x80062f58 code_addr: 0x80070568 k0_val:0x8003ff44 flags:0x0 boot_info_addr:0x800c2440 pad:0x0 pad2:0x0 printf_boot_info_block entry_point:0x80a0 boot_desc_addr: 0x100080 stack_top:0x0 exception_base:0x1000 cvmx_desc_addr:0x0 flags:0x0 Welcome to start_linux. (cmd_octeon_linux.c:596) Uncompressing.. Welcome to start_kernel. (init/main.c:458) Networks OS Version (build / label #wan...@-eng.) Built by wan...@localhost on 2010-11-02 at 15:09:36 CST (gcc version 3.4.5 Cavium Networks Version: 1.4.0, build 58) Welcome to start_kernel. (init/main.c:472) prom_init(arch/mips/cavium-octeon/setup.c:783) arcs_cmdline: console=ttyS0,9600 prom_init(arch/mips/cavium-octeon/setup.c:790) para[0]: bootoctlinux prom_init(arch/mips/cavium-octeon/setup.c:790) para[1]: 9f00200 prom_init(arch/mips/cavium-octeon/setup.c:790) para[2]: bootver= 1.1.4.0/wan...@-eng. CVMSEG size: 2 cache lines (256 bytes) Setting flash physical map for 4MB flash at 0x1f80 Determined physical RAM map: Welcome to start_kernel. (init/main.c:474) Kernel command line: console=ttyS0,9600 rdinit=/sbin/init Welcome to start_kernel. (init/main.c:505) Primary instruction cache 32kB, virtually tagged, 4 way, 64 sets, linesize 128 bytes. Primary data cache 16kB, 64-way, 2 sets, linesize 128 bytes. Welcome to start_kernel. (init/main.c:518) Using 500.000 MHz high precision timer. cycles_per_jiffy=100 Welcome to start_kernel. (init/main.c:532) Memory: 57344k/65536k available (1918k kernel code, 8144k reserved, 561k data, 2172k init, 0k highmem) Calibrating delay using timer specific routine.. 1000.32 BogoMIPS (lpj=1000323) available. Checking for the multiply/shift bug... no. Checking for the daddi bug... no. Checking for the daddiu bug... no. Welcome to start_kernel. (init/main.c:616) Welcome to rest_init. (init/main.c:396) Welcome to schedule. (kernel/sched.c:2889) Welcome to schedule. (kernel/sched.c:3065) detected lzma initramfs initramfs: LZMA lc=3,lp=0,pb=2,dictSize=8388608,origSize=12677632 Bad page state in process 'swapper' page:a87b3418 flags:0x mapping: mapcount:-16711680 count:0 Trying to fix it up, but a reboot is needed Backtrace: Unwound Call Trace: [80211dc8] dump_stack+0x8/0x48
Re: [U-Boot] Bad page state in process 'swapper'
Hi Wolfgang, Although the error is reported by Linux, I think that the linux is booted by u-boot. Or the issue at least is the extension issue of u-boot. I believe that there are guys who fixed my issues in our community. So send the sos email. Thanks for your understanding. Thanks! Shuyou -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: 2010年11月2日 16:40 To: sywang Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Bad page state in process 'swapper' Dear sywang, In message 20101102073757.0c5e828...@theia.denx.de you wrote: While U-boot loads the Linux image, I have the following error. Do you have any suggestions on this? detected lzma initramfs initramfs: LZMA lc=3,lp=0,pb=2,dictSize=8388608,origSize=12677632 Bad page state in process 'swapper' page:a87b3418 flags:0x mapping: mapcount:-16711680 count:0 Trying to fix it up, but a reboot is needed Backtrace: Unwound Call Trace: [80211dc8] dump_stack+0x8/0x48 [80265c98] bad_page+0x78/0xb0 [80266988] get_page_from_freelist+0x230/0x488 [80266c44] __alloc_pages+0x64/0x348 [8027b4ac] __vmalloc_area_node+0x10c/0x230 [804741cc] populate_rootfs+0x974/0xae0 [802007e4] init+0x84/0x530 [8020db58] kernel_thread_helper+0x10/0x18 These are Linux error messages. This is the U-Boot mailing list. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Those who will be able to conquer software will be able to conquer the world. - Tadahiro Sekimoto, president, NEC Corp. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/3] Add flexibility to mx51 video support
From: Renato Frias renato.fr...@freescale.com
This patch adds flexibility to mxc_ipuv3_fb.c by allowing the display
interface and pixel format to be passed to mx51_fb_init.
Signed-off-by: Renato Frias renato.fr...@freescale.com
---
Changes for v2:
- Removed fix.id string
- Removed NBITS calculation from debug message
drivers/video/mxc_ipuv3_fb.c | 25 -
1 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/video/mxc_ipuv3_fb.c b/drivers/video/mxc_ipuv3_fb.c
index a66981c..b660d22 100644
--- a/drivers/video/mxc_ipuv3_fb.c
+++ b/drivers/video/mxc_ipuv3_fb.c
@@ -526,7 +526,7 @@ static struct fb_info *mxcfb_init_fbinfo(void)
*
* @return Appropriate error code to the kernel common code
*/
-static int mxcfb_probe(u32 interface_pix_fmt, struct fb_videomode *mode)
+static int mxcfb_probe(u32 interface_pix_fmt, struct fb_videomode *mode, u32
ipu_di)
{
struct fb_info *fbi;
struct mxcfb_info *mxcfbi;
@@ -550,11 +550,10 @@ static int mxcfb_probe(u32 interface_pix_fmt, struct
fb_videomode *mode)
mxcfbi-blank = FB_BLANK_POWERDOWN;
}
- mxcfbi-ipu_di = 0;
+ mxcfbi-ipu_di = ipu_di;
ipu_disp_set_global_alpha(mxcfbi-ipu_ch, 1, 0x80);
ipu_disp_set_color_key(mxcfbi-ipu_ch, 0, 0);
- strcpy(fbi-fix.id, DISP3 BG);
g_dp_in_use = 1;
@@ -625,9 +624,10 @@ void lcd_ctrl_init(void *lcdbase)
memset(lcdbase, 0, mem_len);
}
-int mx51_fb_init(struct fb_videomode *mode)
+int mx51_fb_init(struct fb_videomode *mode, u32 ipu_di, u32 bppix)
{
int ret;
+ uint32_t pixfmt = 0;
ret = ipu_probe();
if (ret)
@@ -635,8 +635,23 @@ int mx51_fb_init(struct fb_videomode *mode)
lcd_base += 56;
+ switch (bppix) {
+ case 32:
+ pixfmt = IPU_PIX_FMT_BGR32;
+ break;
+ case 24:
+ pixfmt = IPU_PIX_FMT_BGR24;
+ break;
+ case 18:
+ pixfmt = IPU_PIX_FMT_RGB666;
+ break;
+ case 16:
+ pixfmt = IPU_PIX_FMT_RGB565;
+ break;
+ }
+
debug(Framebuffer at 0x%x\n, (unsigned int)lcd_base);
- ret = mxcfb_probe(IPU_PIX_FMT_RGB666, mode);
+ ret = mxcfb_probe(pixfmt, mode, ipu_di);
return ret;
}
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/3] Add video support to mx51evk board
From: Renato Frias renato.fr...@freescale.com
Adds video support to mx51evk board, this board allows different displays.
This patch enables the WVGA TFT LCD panel only, on Display interface 1.
Remove comments from include/configs/mx51evk.h to use it.
Signed-off-by: Renato Frias renato.fr...@freescale.com
---
Changes for v2:
- Removed trailing whitespaces from struct fb_videomode
- Using PAD_CTL_* definitions
- Updated commit message
board/freescale/mx51evk/mx51evk.c | 60 -
include/configs/mx51evk.h | 11 +++
2 files changed, 70 insertions(+), 1 deletions(-)
diff --git a/board/freescale/mx51evk/mx51evk.c
b/board/freescale/mx51evk/mx51evk.c
index 2160d5a..3743121 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -34,9 +34,37 @@
#include fsl_pmic.h
#include mc13892.h
+#ifdef CONFIG_LCD
+#include linux/fb.h
+#include lcd.h
+#endif
+
DECLARE_GLOBAL_DATA_PTR;
static u32 system_rev;
+extern int mx51_fb_init(struct fb_videomode *mode, u32 ipu_di, u32 pix_fmt);
+
+#ifdef CONFIG_LCD
+static struct fb_videomode claa_wvga = {
+ CLAA07LC0ACW,
+ 57, /* Refresh */
+ 800,/* xres */
+ 480,/* yres */
+ 37037, /* pixclock = 27Mhz */
+ 40, /* left margin */
+ 60, /* right margin */
+ 10, /* upper margin */
+ 10, /* lower margin */
+ 20, /* hsync-len */
+ 10, /* vsync-len */
+ 0, /* sync */
+ FB_VMODE_NONINTERLACED, /* vmode */
+ 0, /* flag */
+};
+
+static int wvga_ipu_di = 1;
+static int wvga_bppix = 16;
+#endif
#ifdef CONFIG_FSL_ESDHC
struct fsl_esdhc_cfg esdhc_cfg[2] = {
@@ -148,6 +176,34 @@ static void setup_iomux_fec(void)
mxc_iomux_set_pad(MX51_PIN_NANDF_D11, 0x2180);
}
+#ifdef CONFIG_LCD
+void setup_iomux_ipu(void)
+{
+ /* DISP2_DAT [0:15] are configured by default */
+ mxc_request_iomux(MX51_PIN_DI1_D1_CS, IOMUX_CONFIG_ALT4);
+ mxc_iomux_set_pad(MX51_PIN_DI1_D1_CS,
+ PAD_CTL_PKE_ENABLE | PAD_CTL_DRV_HIGH | PAD_CTL_SRE_FAST);
+ mxc_request_iomux(MUX_IN_GPIO3_IPP_IND_G_IN_4_SELECT_INPUT,
+ INPUT_CTL_PATH1);
+
+ /* DISP2_DRDY pin */
+ mxc_request_iomux(MX51_PIN_DI_GP4, IOMUX_CONFIG_ALT4);
+ mxc_iomux_set_pad(MX51_PIN_DI_GP4, PAD_CTL_PKE_ENABLE |
+ PAD_CTL_PUE_KEEPER | PAD_CTL_DRV_LOW);
+}
+
+void lcd_enable(void)
+{
+ int ret;
+
+ ret = mx51_fb_init(claa_wvga, wvga_ipu_di, wvga_bppix);
+ if (ret) {
+ puts(LCD cannot be configured\n);
+ }
+
+}
+#endif
+
#ifdef CONFIG_MXC_SPI
static void setup_iomux_spi(void)
{
@@ -409,7 +465,9 @@ int board_init(void)
setup_iomux_uart();
setup_iomux_fec();
-
+#ifdef CONFIG_LCD
+ setup_iomux_ipu();
+#endif
return 0;
}
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index f98438d..cd931ea 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -211,6 +211,17 @@
#define CONFIG_SYS_DDR_CLKSEL 0
#define CONFIG_SYS_CLKTL_CBCDR 0x59E35100
+/*
+ * Framebuffer and LCD
+ */
+/*
+#define CONFIG_LCD
+#define CONFIG_VIDEO_MX5
+#define LCD_BPPLCD_COLOR16
+#define CONFIG_CMD_BMP
+#define CONFIG_BMP_16BPP
+*/
+
/*---
* FLASH and environment organization
*/
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/3] Fix video support for vision2 board
From: Renato Frias renato.fr...@freescale.com Adds arguments to the mx51_fb_init call. Signed-off-by: Renato Frias renato.fr...@freescale.com --- Changes for v2: - Includes fix to vision2 (this commit) on the patch set board/ttcontrol/vision2/vision2.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/board/ttcontrol/vision2/vision2.c b/board/ttcontrol/vision2/vision2.c index 071dad6..d818224 100644 --- a/board/ttcontrol/vision2/vision2.c +++ b/board/ttcontrol/vision2/vision2.c @@ -43,7 +43,7 @@ DECLARE_GLOBAL_DATA_PTR; static u32 system_rev; -extern int mx51_fb_init(struct fb_videomode *mode); +extern int mx51_fb_init(struct fb_videomode *mode, u32 ipu_di, u32 pix_fmt); #ifdef CONFIG_HW_WATCHDOG #include watchdog.h @@ -675,7 +675,7 @@ void lcd_enable(void) mxc_gpio_set(2, 1); mxc_request_iomux(MX51_PIN_GPIO1_2, IOMUX_CONFIG_ALT0); - ret = mx51_fb_init(nec_nl6448bc26_09c); + ret = mx51_fb_init(nec_nl6448bc26_09c, 0, 18); if (ret) puts(LCD cannot be configured\n); } -- 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFCv2 0/3] Add support for quick boot
-Original Message- From: Premi, Sanjeev Sent: Friday, October 29, 2010 9:35 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [RFCv2 0/3] Add support for quick boot This series attempts to address specific feedback[1] from Wolfgang Denk to my previous submission. Since this series is based on u-boot master, it is missing these patches for successful build: a) omap3evm: Support relocation http://marc.info/?l=u-bootm=128748423503307w=2 b) omap3evm: Move function to identify board revision http://marc.info/?l=u-bootm=128749414618147w=2 c) omap3evm: Fix mechanism to identify board revision http://marc.info/?l=u-bootm=128757192518074w=2 I am hoping this series illustrates exact changes done. However, my choice of filenames results in rather long config names for two new configurations. I plan to replace quick with simple q. Does it sound ok? References: [1] http://marc.info/?l=u-bootm=128828487429161w=2 [2] http://marc.info/?l=u-bootm=128818733126234w=2 [3] http://marc.info/?l=u-bootm=128818664024766w=2 Patch (a) is required for successful build for current configuration. Patches (b) and (c) were required for successful build of quick configurations. I am yet to test these on this patchset. Will do before final submission. Sanjeev Premi (3): omap3evm: Reorder related config options omap3evm: move common config options to new file omap3evm: Add quick boot configurations Hi Wolfgang, Did you get chance to look at this series? ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Fix mechanism to identify board revision
-Original Message- From: Premi, Sanjeev Sent: Wednesday, October 20, 2010 4:21 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH] omap3evm: Fix mechanism to identify board revision [snip] Sandeep, Pinging for status... ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Support relocation
-Original Message- From: Premi, Sanjeev Sent: Tuesday, October 19, 2010 4:00 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH] omap3evm: Support relocation This patch adds relocation support for omap3evm. Content of the patch is based on changes for Beagleboard. Signed-off-by: Sanjeev Premi pr...@ti.com --- Sandeep, Pinging for status... ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] omap3evm: Wrap function under CONFIG_USB_OMAP3
-Original Message- From: Premi, Sanjeev Sent: Tuesday, October 19, 2010 6:36 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH] omap3evm: Wrap function under CONFIG_USB_OMAP3 The function omap3_evm_need_extvbus() is required only when USB support is configured. Wrapped this function in #ifdef CONFIG_USB_OMAP3. Signed-off-by: Sanjeev Premi pr...@ti.com --- Sandeep, Pinging for status... ~sanjeev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Bad page state in process 'swapper'
Le 03/11/2010 02:00, sywang a écrit : Hi, I found that vmalloc is not able to allocate the memory. What parameters from u-boot are not right? Hi Shuyou, As Wolfgang said, we cannot tell because the code you're using as a bootloader is not mainline u-boot, but a version modified by Cavium. You should turn to the provider of this code for support. Thanks! Shuyou Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
