Re: [U-Boot] RFC: get_ticks() + get_tbclk()
might want to check out the thread i started over a year ago: [u-boot] core ticks/timer code it delves into these internals and may help you here -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] NET: add ENC28J60 driver using SPI framework
Dear Mike Frysinger, On Tuesday, September 21, 2010 01:21:46 Reinhard Meyer wrote: well, now i cant reproduce the issue, cold or warm booting :/. ... although, earlier i was testing when the sun was out and shining on the board but now it's night, so maybe it's a cold-blooded part :x. Reminds me of the good old times with UV-Eraseable EPROMs, where a lab setup intermittently and mysteriously failed until I noticed it was the sun shining into the EPROM's windows. That did not erase them, just disturbed the reading. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Config: Add board options column to boards.cfg
Dear Marek Vasut, please fix the mail addresses. My address is w...@denx.de In message 1285025204-8463-1-git-send-email-marek.va...@gmail.com you wrote: There are some boards where it's not currently possible to detect all board information at runtime, therefore I introduced a new column called options to boards.cfg . This column can contain multiple options, separated by comma [,] . This column is case sensitive. In case there's a simple options like 256M_U_BOOT, it's plain expanded to #define CONFIG_256M_U_BOOT in config.h . In case there's an assignment, like ram=8192, it's expanded to #define CONFIG_RAM 8192 in config.h . There can also be multiple such options, then each is expanded to separate #define CONFIG_xyz statement. I don't understand what you mean by is case sensitive when in the end you seem to convert everything to upper case? I would not make any statement about case sensistivity and copy the settings unchanged. It is up to the user to provide valid (upper case) macro names, and it leaves the option to deviate and use locer case identifiers in case this should ever be needed for some special purpose. Also, it makes the code simpler. And, as Mike pointed out, please reuse the -y option. 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 It is easier to write an incorrect program than understand a correct one. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick
Dear devz...@web.de, In message 899533205.349626.128509052.javamail.fm...@mwmweb063 you wrote: pardon, that was not my intention, nor was it my intention to infringe list rules. so, this is for developers/experts - not for users and bug-reporte rs? This list is for ALL discussions about U-Boot: users, bug-reporters, developers, etc. But we expect that everybody who posts here follows some basic Netiquette. You don't. For example, Netiquette says to keep your line length below some 70 characters or so. You don't even after being told. I asked you explicitly NOT to top post / full quote, and pointed you to rules for correct quoting. You ignore that. i`m spending more than half of this evening with this issue, trying to find a solution and trying to provide information for a problem affecting manyr people and which seems to exist in u-boot. I also pointed you to a document that explains how to ask smart questions, but it seems you ignored this hint as well. You completely fail to explain which exact version of U-Boot you are running - it seems to be a locally modified one, probably with out-of-tree patches to support that Dockstar board which is not known in the mainline U-Boot repository. How should we be able to comment on code we don't even know? 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 Have you lived in this village all your life?No, not yet. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: get_ticks() + get_tbclk()
Dear Mike Frysinger, might want to check out the thread i started over a year ago: [u-boot] core ticks/timer code it delves into these internals and may help you here -mike Thanks for the hint, and sorry to have started the topic again ;) However it seems no resolution has come up since then. For me it seems useful to keep both functions and have ticks increment at a hardware-convenient rate. If the hardware timer can be prescaled to increment at 1000 Hz that is fine, but I see no immediate need for that. If the hardware cannot be prescaled, and software would need to do a 64 bit multiply/divide on each timer read, that would really be overkill. timer_reset() prevents you to have nested timeouts (if that ever comes up) Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [STATUS] v2010.09-rc2 is out / next branch available
Dear Wolfgang, check if all your relevant patches have been included. I rebased against the master and resubmitted the POST Cleanup patch (http://lists.denx.de/pipermail/u-boot/2010-September/077467.html) as was promised in http://lists.denx.de/pipermail/u-boot/2010-August/075227.html. Should I resubmit it into the next branch or it can go into the current release? Best regards, Michael Zaidman ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: get_ticks() + get_tbclk()
Dear Reinhard Meyer, In message 4c98536c.6010...@emk-elektronik.de you wrote: For me it seems useful to keep both functions and have ticks increment at a hardware-convenient rate. If the hardware timer can be prescaled to increment at 1000 Hz that is fine, but I see no immediate need for that. If the hardware cannot be prescaled, and software would need to do a 64 bit multiply/divide on each timer read, that would really be overkill. Just FYI: the origin of these functions is (like usual) in the implementation for the Power Architecture. There we have a 64 bit timebase register (split into two 32 bit registers, the upper half in tbu and the lower half in tbl). The timebase register gets incremented at a pretty high rate, usually every 4 or 16 system clocks). get_ticks() just returns the content of the 64 bit timebase register. [See also wait_ticks(0 which delays for a number of ticks, cf. arch/powerpc/lib/ticks.S] get_tbclk() just returns the timebase clock (usually derived froom the system clock; see for exmaple arch/powerpc/cpu/mpc5xxx/cpu.c: tbclk = (gd-bus_clk + 3L) / 4L; ). 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 They weren't that important. They were merely at the top. The people who really run organizations are usually found several levels down, where it's still possible to get things done. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-cfi-flash/next (rebased against new next)
Dear Stefan Roese, In message 201009201612.14857...@denx.de you wrote: The following changes since commit ff377b1c0e891569b6da13629090aad7c38175e0: canmb board: Fix compiler warnings (2010-09-19 19:29:57 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-cfi-flash.git next Stefan Roese (4): cfi_flash: Simplify flash_get_info() cfi_flash: Add weak default for cfi_flash_bank_addr() cfi_flash: Simplify dynamic flash bank number detection cfi_flash: Remove uneccessary #ifdef CONFIG_SYS_MAX_FLASH_BANKS_DETECT board/esd/apc405/apc405.c |6 ++ board/tqc/tqm834x/tqm834x.c | 12 +--- common/cmd_bootm.c |1 + common/cmd_flash.c | 10 ++ common/flash.c |1 + drivers/mtd/cfi_flash.c | 32 +++- drivers/mtd/cfi_mtd.c | 10 +- include/configs/APC405.h|6 -- include/configs/IDS8247.h |3 +-- include/configs/TQM834x.h |4 include/flash.h |2 ++ include/mtd/cfi_flash.h | 18 ++ 12 files changed, 48 insertions(+), 57 deletions(-) Applied to next branch, thanks. 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 ... bacteriological warfare ... hard to believe we were once foolish enough to play around with that. -- McCoy, The Omega Glory, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Inclusion of GPLv3 code
Dear Graeme Russ, In message 4c8a1f2a.8020...@gmail.com you wrote: I know you are favouring a migration of U-Boot to GPLv3, but currently it is still licensed under v2 (although most code is v2 'or later') I have some v3 code I would like to bring in (from GRUB). Will that cause any issues? It is my understanding that you cannot downgrade GPLv3 code, i. e. you cannot link it into a GPLv2 project. But then, I'm not a license expert, and IANAL. 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 A meeting is an event at which the minutes are kept and the hours are lost. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-usb
Dear Remy Bohmer, In message aanlktinb0lq=pky-ksny4kgw1qab5xzu91zgd6awa...@mail.gmail.com you wrote: The following changes since commit ff377b1c0e891569b6da13629090aad7c38175e0: Wolfgang Denk (1): canmb board: Fix compiler warnings are available in the git repository at: git://git.denx.de/u-boot-usb.git next Mike Frysinger (1): usb: musb: stub out MUSB_TXCSR_MODE for Blackfin parts Remy Bohmer (1): Integrate USB gadget layer and USB CDC driver layer Stefano Babic (2): USB-CDC: correct wrong alignment in ether.c USB-CDC: called handle_interrupts inside usb_eth_send Vitaly Kuzmichev (9): USB-CDC: Restuct USB gadget Makefile USB-CDC: Add lost 'qmult' definition USB-CDC: Use native debug printout macros USB-CDC: Correct freeing usb requests USB-CDC: Replace 'strcpy' by 'strlcpy' USB-CDC: Correct stat_req initialization USB-CDC: ethernet error path potential oops fix USB-CDC: change simple_strtol to simple_strtoul USB-CDC: Fix coding style issues drivers/usb/gadget/Makefile |6 + drivers/usb/gadget/config.c | 119 +++ drivers/usb/gadget/epautoconf.c | 305 ++ drivers/usb/gadget/ether.c| 1976 + drivers/usb/gadget/gadget_chips.h | 220 drivers/usb/gadget/usbstring.c| 140 +++ drivers/usb/musb/musb_core.h |2 + include/linux/usb/cdc.h | 224 + include/linux/usb/ch9.h | 587 +++ include/linux/usb/gadget.h| 857 include/net.h | 17 +- 11 files changed, 4451 insertions(+), 2 deletions(-) create mode 100644 drivers/usb/gadget/config.c create mode 100644 drivers/usb/gadget/epautoconf.c create mode 100644 drivers/usb/gadget/ether.c create mode 100644 drivers/usb/gadget/gadget_chips.h create mode 100644 drivers/usb/gadget/usbstring.c create mode 100644 include/linux/usb/cdc.h create mode 100644 include/linux/usb/ch9.h create mode 100644 include/linux/usb/gadget.h Applied to next branch, thanks. 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 most difficult thing in the world is to know how to do a thing and to watch someone else doing it wrong, without commenting. -- T.H. White ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppx4xx: remove unused functionality for DU405 boards
Remove some unused functionality to make U-Boot build again. Especially PCI is not used on the board. Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu --- include/configs/DU405.h | 31 +-- 1 files changed, 5 insertions(+), 26 deletions(-) diff --git a/include/configs/DU405.h b/include/configs/DU405.h index 8f1fc78..ff56ac3 100644 --- a/include/configs/DU405.h +++ b/include/configs/DU405.h @@ -73,6 +73,11 @@ #include config_cmd_default.h #undef CONFIG_CMD_NFS +#undef CONFIG_CMD_EDITENV +#undef CONFIG_CMD_IMLS +#undef CONFIG_CMD_CONSOLE +#undef CONFIG_CMD_LOADB +#undef CONFIG_CMD_LOADS #define CONFIG_CMD_IDE #define CONFIG_CMD_ELF #define CONFIG_CMD_MII @@ -126,32 +131,6 @@ #define CONFIG_SYS_RX_ETH_BUFFER 16 /* use 16 rx buffer on 405 emac */ /*--- - * PCI stuff - *--- - */ -#define PCI_HOST_ADAPTER 0 /* configure ar pci adapter */ -#define PCI_HOST_FORCE 1 /* configure as pci host*/ -#define PCI_HOST_AUTO 2 /* detected via arbiter enable */ - -#define CONFIG_PCI /* include pci support */ -#define CONFIG_PCI_HOST PCI_HOST_AUTO /* select pci host function */ -#define CONFIG_PCI_PNP /* do pci plug-and-play */ - /* resource configuration */ - -#define CONFIG_PCI_SCAN_SHOW /* print pci devices @ startup */ - -#define CONFIG_PCI_BOOTDELAY 0 /* enable pci bootdelay variable*/ - -#define CONFIG_SYS_PCI_SUBSYS_VENDORID 0x12FE /* PCI Vendor ID: esd gmbh */ -#define CONFIG_SYS_PCI_SUBSYS_DEVICEID 0x0404 /* PCI Device ID: CPCI-ISER4 */ -#define CONFIG_SYS_PCI_PTM1LA 0x /* point to sdram */ -#define CONFIG_SYS_PCI_PTM1MS 0xff01 /* 16MB, enable hard-wired to 1 */ -#define CONFIG_SYS_PCI_PTM1PCI 0x /* Host: use this pci address */ -#define CONFIG_SYS_PCI_PTM2LA 0xffe0 /* point to flash */ -#define CONFIG_SYS_PCI_PTM2MS 0xffe1 /* 2MB, enable */ -#define CONFIG_SYS_PCI_PTM2PCI 0x0400 /* Host: use this pci address */ - -/*--- * IDE/ATA stuff *--- */ -- 1.6.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Inclusion of GPLv3 code
On Tuesday, September 21, 2010 03:33:37 Wolfgang Denk wrote: Graeme Russ wrote: I know you are favouring a migration of U-Boot to GPLv3, but currently it is still licensed under v2 (although most code is v2 'or later') I have some v3 code I would like to bring in (from GRUB). Will that cause any issues? It is my understanding that you cannot downgrade GPLv3 code, i. e. you cannot link it into a GPLv2 project. But then, I'm not a license expert, and IANAL. in-my-not-a-lawyer-opinion, i think introducing GPLv3 code makes the final output GPLv3 only if the build includes it. so if the imported GRUB code stays at GPLv3, and is only for x86, and all of the code Graeme is using from u-boot is GPLv2+, then the final result there is under GPLv3 only. but all his GPLv3 code, assuming it's specific to x86, wont affect other architectures. -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] kernel does not boot
I am using TI's davinci board (microprocessor is dm6446) and I both tried community u-boot build and I compiled myself. I try to boot kernel from tftp and fs from nfs but I cannot mount fs. Here is errors: IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.50 IP-Config: Complete: device=eth0, addr=192.168.2.50, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.50, domain=protel.local, nis-domain=(none), bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath= Looking up port of RPC 13/2 on 0.0.0.0 rpcbind: server 0.0.0.0 not responding, timed out Root-NFS: Unable to get nfsd port number from server, using default Looking up port of RPC 15/1 on 0.0.0.0 rpcbind: server 0.0.0.0 not responding, timed out Root-NFS: Unable to get mountd port number from server, using default Root-NFS: Server returned error -5 while mounting /tftpboot/ VFS: Unable to mount root fs via NFS, trying floppy. VFS: Cannot open root device nfs or unknown-block(2,0) Please append a correct root= boot option; here are the available partitions: 030039070080 hda driver: ide-gd Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0) Backtrace: [c002e5f4] (dump_backtrace+0x0/0x114) from [c02c886c] (dump_stack+0x18/0x1c) r7:8000 r6:c6012000 r5:c0024808 r4:c03cbd30 [c02c8854] (dump_stack+0x0/0x1c) from [c02c88c4] (panic+0x54/0x12c) [c02c8870] (panic+0x0/0x12c) from [c0008fbc] (mount_block_root+0x1e0/0x220) r3:0001 r2:c6023e98 r1:c6023f60 r0:c034e926 [c0008ddc] (mount_block_root+0x0/0x220) from [c00090c0] (mount_root+0xc4/0x) r8: r7: r6: r5: r4:0020 [c0008ffc] (mount_root+0x0/0xfc) from [c0009268] (prepare_namespace+0x170/0) r5:c0024808 r4:c03cb820 [c00090f8] (prepare_namespace+0x0/0x1c8) from [c00084bc] (kernel_init+0xe4/) r5: r4:c03cb5e0 [c00083d8] (kernel_init+0x0/0x118) from [c0043124] (do_exit+0x0/0x668) r5: r4: My u-boot config is also here: DaVinci EVM # printenv bootcmd=dhcp;tftpboot 0x8200 initrd.image;setenv addip setenv bootargs $(bo0 baudrate=115200 ipaddr=192.168.2.50 bootargs=mem=120M console=ttyS0,115200n8 root=/dev/nfs rw nfsroot= 192.168.2.48p rootpath=/home/yildirim/targetfs nfshost=192.168.2.48 serverip=192.168.2.48 bootdelay=10 bootfile=uImage stdin=serial stdout=serial stderr=serial ethaddr=00:0e:99:02:5d:47 videostd=pal Environment size: 562/16380 bytes Thank in advance. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Inclusion of GPLv3 code
Dear Mike Frysinger, In message 201009210351.16288.vap...@gentoo.org you wrote: It is my understanding that you cannot downgrade GPLv3 code, i. e. you cannot link it into a GPLv2 project. But then, I'm not a license expert, and IANAL. in-my-not-a-lawyer-opinion, i think introducing GPLv3 code makes the final output GPLv3 only if the build includes it. I guess this is correct. so if the imported GRUB code stays at GPLv3, and is only for x86, and all of the code Graeme is using from u-boot is GPLv2+, then the final result there is under GPLv3 only. but all his GPLv3 code, assuming it's specific to x86, wont affect other architectures. But Graeme would also have to make sure not topick up any partsof the U-Boot code that are GPLv2 (without the or later phrase). A license nightmare... 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 Just about every computer on the market today runs Unix, except the Mac (and nobody cares about it). - Bill Joy 6/21/85 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] kernel does not boot
Dear Mehmet Salih YILDIRIM, In message 4c98640a.1060...@protel.tv you wrote: I am using TI's davinci board (microprocessor is dm6446) and I both tried community u-boot build and I compiled myself. I try to boot kernel from tftp and fs from nfs but I cannot mount fs. Here is errors: IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.2.50 ==^^^ IP-Config: Complete: device=eth0, addr=192.168.2.50, mask=255.255.255.0, gw=192.168.2.1, host=192.168.2.50, domain=protel.local, nis-domain=(none), bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath= Looking up port of RPC 13/2 on 0.0.0.0 rpcbind: server 0.0.0.0 not responding, timed out ==^^^ Seems your DHCP server is muisconfigured. This is a Linux problem, not an U-Boot issue. You are off topic here. 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 What the gods would destroy they first submit to an IEEE standards committee. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Inclusion of GPLv3 code
On Tuesday, September 21, 2010 04:37:40 Wolfgang Denk wrote: Mike Frysinger wrote: so if the imported GRUB code stays at GPLv3, and is only for x86, and all of the code Graeme is using from u-boot is GPLv2+, then the final result there is under GPLv3 only. but all his GPLv3 code, assuming it's specific to x86, wont affect other architectures. But Graeme would also have to make sure not topick up any partsof the U-Boot code that are GPLv2 (without the or later phrase). A license nightmare... i agree, and i'm glad i dont have to deal with this ;) -mike signature.asc Description: This is a digitally signed message part. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Remove now unused CONFIG_UART1_CONSOLE
CONFIG_UART1_CONSOLE was a PPC4xx specific implementation and is now removed since the move from the 4xx UART driver to the common NS16550 UART driver. Let's remove all references to this define now. Signed-off-by: Stefan Roese s...@denx.de --- README |7 --- common/serial.c|5 + drivers/serial/serial_netarm.c |5 - 3 files changed, 1 insertions(+), 16 deletions(-) diff --git a/README b/README index aa11c37..c7a8e9d 100644 --- a/README +++ b/README @@ -544,13 +544,6 @@ The following options need to be configured: Leave undefined to disable this feature, including disable the buffer and hardware handshake. -- Console UART Number: - CONFIG_UART1_CONSOLE - - AMCC PPC4xx only. - If defined internal UART1 (and not UART0) is used - as default U-Boot console. - - Boot Delay: CONFIG_BOOTDELAY - in seconds Delay before automatically booting the default image; set to -1 to disable autoboot. diff --git a/common/serial.c b/common/serial.c index dbc74bd..25b235a 100644 --- a/common/serial.c +++ b/common/serial.c @@ -54,10 +54,7 @@ struct serial_device *__default_serial_console (void) #else #error Bad CONFIG_CONS_INDEX. #endif -#elif defined(CONFIG_UART1_CONSOLE) - return serial1_device; -#else - return serial0_device; + return serial0_device; #endif #elif defined(CONFIG_MPC512X) #if (CONFIG_PSC_CONSOLE == 3) diff --git a/drivers/serial/serial_netarm.c b/drivers/serial/serial_netarm.c index 2eb5393..d04790d 100644 --- a/drivers/serial/serial_netarm.c +++ b/drivers/serial/serial_netarm.c @@ -51,13 +51,8 @@ DECLARE_GLOBAL_DATA_PTR; } -#ifndef CONFIG_UART1_CONSOLE volatile netarm_serial_channel_t *serial_reg_ch1 = get_serial_channel(0); volatile netarm_serial_channel_t *serial_reg_ch2 = get_serial_channel(1); -#else -volatile netarm_serial_channel_t *serial_reg_ch1 = get_serial_channel(1); -volatile netarm_serial_channel_t *serial_reg_ch2 = get_serial_channel(0); -#endif extern void _netarm_led_FAIL1(void); -- 1.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Inclusion of GPLv3 code
On Tuesday, September 21, 2010, Mike Frysinger vap...@gentoo.org wrote: On Tuesday, September 21, 2010 04:37:40 Wolfgang Denk wrote: Mike Frysinger wrote: so if the imported GRUB code stays at GPLv3, and is only for x86, and all of the code Graeme is using from u-boot is GPLv2+, then the final result there is under GPLv3 only. but all his GPLv3 code, assuming it's specific to x86, wont affect other architectures. But Graeme would also have to make sure not topick up any partsof the U-Boot code that are GPLv2 (without the or later phrase). A license nightmare... i agree, and i'm glad i dont have to deal with this ;) -mike I plan on doing a complete GPLv3 audit to see if we can create a usable U-Boot build which is 100% GPLv3 compatible Regards Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Inclusion of GPLv3 code
On Tuesday, September 21, 2010, Mike Frysinger vap...@gentoo.org wrote: On Tuesday, September 21, 2010 04:37:40 Wolfgang Denk wrote: Mike Frysinger wrote: so if the imported GRUB code stays at GPLv3, and is only for x86, and all of the code Graeme is using from u-boot is GPLv2+, then the final result there is under GPLv3 only. but all his GPLv3 code, assuming it's specific to x86, wont affect other architectures. But Graeme would also have to make sure not topick up any partsof the U-Boot code that are GPLv2 (without the or later phrase). A license nightmare... i agree, and i'm glad i dont have to deal with this ;) -mike I plan on doing a complete GPLv3 audit to see if we can create a usable U-Boot build which is 100% GPLv3 compatible Regards Graeme ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] RFC: get_ticks() + get_tbclk()
Dear Wolfgang Denk, In message 4c98536c.6010...@emk-elektronik.de you wrote: For me it seems useful to keep both functions and have ticks increment at a hardware-convenient rate. If the hardware timer can be prescaled to increment at 1000 Hz that is fine, but I see no immediate need for that. If the hardware cannot be prescaled, and software would need to do a 64 bit multiply/divide on each timer read, that would really be overkill. Just FYI: the origin of these functions is (like usual) in the implementation for the Power Architecture. There we have a 64 bit timebase register (split into two 32 bit registers, the upper half in tbu and the lower half in tbl). The timebase register gets incremented at a pretty high rate, usually every 4 or 16 system clocks). get_ticks() just returns the content of the 64 bit timebase register. Yes, of course. So the current ARM926EJS/AT91 implementation is actually in the right direction, although not perfected yet. I am going to look into that. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] AT91: problems master vs. next
Just to report on preliminary findings I had: Rebasing my current TOP9000 port on u-boot/master compiles and works fine. Code size increased moderately from 223592 to 223976. Rebasing my current TOP9000 port on u-boot/next compiles after defining CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR. Code size increased heavyly from 223592 to 245544. And U-Boot crashes instantly (I know there is more to be done than just defining those two macros). What bothers me really here is the huge increase in code size. And, on almost all AT91 systems booting will be through a first boot loader, which sets up SDRAM, loads u-boot to the correct address and jumps to it. All low level init and relocation is not required in such cases. It should be always possible to #define relocation off! With Best Regards Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] [NEXT]arm: Make jadecpu use relocation
This patch modifies jadecpu board so that it is usable
with the relocation patches by Heiko Schocher
Signed-off-by: Matthias Weisser weiss...@arcor.de
---
board/syteco/jadecpu/config.mk |2 +-
board/syteco/jadecpu/jadecpu.c | 11 +--
include/configs/jadecpu.h |3 +++
3 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/board/syteco/jadecpu/config.mk b/board/syteco/jadecpu/config.mk
index c661f0b..91994b0 100644
--- a/board/syteco/jadecpu/config.mk
+++ b/board/syteco/jadecpu/config.mk
@@ -1 +1 @@
-TEXT_BASE = 0x4600
+TEXT_BASE = 0x1000
diff --git a/board/syteco/jadecpu/jadecpu.c b/board/syteco/jadecpu/jadecpu.c
index 04d2f9d..e11e686 100644
--- a/board/syteco/jadecpu/jadecpu.c
+++ b/board/syteco/jadecpu/jadecpu.c
@@ -154,12 +154,19 @@ int misc_init_r(void)
*/
int dram_init(void)
{
- gd-bd-bi_dram[0].start = PHYS_SDRAM;
- gd-bd-bi_dram[0].size = PHYS_SDRAM_SIZE;
+ /* dram_init must store complete ramsize in gd-ram_size */
+ gd-ram_size = get_ram_size((volatile void *)PHYS_SDRAM,
+ PHYS_SDRAM_SIZE);
return 0;
}
+void dram_init_banksize(void)
+{
+ gd-bd-bi_dram[0].start = PHYS_SDRAM;
+ gd-bd-bi_dram[0].size = gd-ram_size;
+}
+
int board_eth_init(bd_t *bis)
{
int rc = 0;
diff --git a/include/configs/jadecpu.h b/include/configs/jadecpu.h
index 29c534c..a5d8764 100644
--- a/include/configs/jadecpu.h
+++ b/include/configs/jadecpu.h
@@ -146,6 +146,9 @@
#define PHYS_SDRAM 0x4000 /* Start address of DDRRAM */
#define PHYS_SDRAM_SIZE0x0800 /* 128 megs */
+#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM
+#define CONFIG_SYS_INIT_SP_ADDR0x01008000
+
/*
* FLASH and environment organization
*/
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] NET: add ENC28J60 driver using SPI framework
Hi Mike,
On Mon, Sep 20, 2010 at 10:52 PM, Mike Frysinger vap...@gentoo.org wrote:
On Tuesday, September 21, 2010 01:21:46 Reinhard Meyer wrote:
On Monday, September 20, 2010 17:44:38 Mike Frysinger wrote:
finally got around to testing this. seems like the init needs some
work. if i power on the system (cold boot), boot Linux over the
on-chip
mac, and let Linux program the enc part, it works fine under Linux.
then i do a software reset back into u-boot, it can use the enc fine
too.
but if i cold boot u-boot and try to use the enc part, i get:
timeout waiting for CLKRDY
enabling DEBUG doesnt show any additional output though.
comparing the linux and u-boot drivers leads me to this fix:
--- a/drivers/net/enc28j60.c
+++ b/drivers/net/enc28j60.c
@@ -632,6 +632,8 @@ static int enc_clock_wait(enc_dev_t *enc)
{
uint64_t etime;
+ enc_bclr(enc, CTL_REG_ECON2, ENC_ECON2_PWRSV);
+
/* one second timeout */
etime = get_ticks() + get_tbclk();
The Bit PWRSV is cleared (according to data sheet) on every Reset.
If that patch really helps in your case either the data sheet is wrong
(for your mask of the chip) OR there is another reason while the timeout
occurs in your case (I never had this timeout).
I don't mind explicitly clearing this bit, but I suspect that this just
covers another problem.
Could you read and print ECON2 in your case and see if PWRSV is really
set?
well, now i cant reproduce the issue, cold or warm booting :/. so i guess
ignore this change until i can reproduce things and get a register dump.
although, earlier i was testing when the sun was out and shining on the
board
but now it's night, so maybe it's a cold-blooded part :x.
i looked at the linux driver again and i think i misread it. it isnt
clearing
ECON2 at reset, just when leaving low power mode. it clears ECON1 after
doing
a soft reset.
If you change your mind later, let me know and I'll squash this into the
earlier one.
Or, does the timeout really come to be 1 second - does get_tbclk()
really return the timer increments per second? On many architectures
get_tblck() simply returns CONFIG_SYS_HZ and not the number of timer
increments per second (which can be a different and much higher value).
the Blackfin timer is just fine thanks :P. it was pausing about 1 second
between display of enc0.18 and CLKRDY timeout. it wasnt an
instantaneous
display of the two lines.
-mike
regards,
Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91: problems master vs. next
Le 21/09/2010 14:39, Reinhard Meyer a écrit : Just to report on preliminary findings I had: Rebasing my current TOP9000 port on u-boot/master compiles and works fine. Code size increased moderately from 223592 to 223976. Rebasing my current TOP9000 port on u-boot/next compiles after defining CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR. Code size increased heavyly from 223592 to 245544. And U-Boot crashes instantly (I know there is more to be done than just defining those two macros). What bothers me really here is the huge increase in code size. I see numbers similar for orion5x based net5big, where non relocating build is 117252 bytes while relocating build is 127120, a 8.4% increase (yours is 9.8%). This is due to the fact that each routine has to recompute the PIC register. As a test, I tried adding -msingle-pic-base to -fPIC (this computes the PIC register once for the whole code) and the code size falls back to 123764 bytes, 'only' 5.5% more than the non relocating case. Using -fPIE -pie -msingle-pic-base lowers this again to 5.2%. Of course you cannot just turn -msingle-pic-base on; you've got to have the code in start.S that computes the register. Also, switching from PIC to PIE needs to be verified. I've got the code in my local tree, but it's not tested yet. I'll test it tonight and post it if it works. And, on almost all AT91 systems booting will be through a first boot loader, which sets up SDRAM, loads u-boot to the correct address and jumps to it. All low level init and relocation is not required in such cases. It should be always possible to #define relocation off! On arm926ejs this is controlled by CONFIG_SKIP_LOWLEVEL_INIT and CONFIG_SKIP_RELOCATE_UBOOT. For instance, openrd_base, a kirkwood board, always skips lowlevel inits. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91: problems master vs. next
Dear Albert ARIBAUD, Le 21/09/2010 14:39, Reinhard Meyer a écrit : Rebasing my current TOP9000 port on u-boot/next compiles after defining CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR. Code size increased heavyly from 223592 to 245544. And U-Boot crashes instantly (I know there is more to be done than just defining those two macros). What bothers me really here is the huge increase in code size. I see numbers similar for orion5x based net5big, where non relocating build is 117252 bytes while relocating build is 127120, a 8.4% increase (yours is 9.8%). This is due to the fact that each routine has to recompute the PIC register. As a test, I tried adding -msingle-pic-base to -fPIC (this computes the PIC register once for the whole code) and the code size falls back to 123764 bytes, 'only' 5.5% more than the non relocating case. Using -fPIE -pie -msingle-pic-base lowers this again to 5.2%. Of course you cannot just turn -msingle-pic-base on; you've got to have the code in start.S that computes the register. Also, switching from PIC to PIE needs to be verified. I've got the code in my local tree, but it's not tested yet. I'll test it tonight and post it if it works. And, on almost all AT91 systems booting will be through a first boot loader, which sets up SDRAM, loads u-boot to the correct address and jumps to it. All low level init and relocation is not required in such cases. It should be always possible to #define relocation off! On arm926ejs this is controlled by CONFIG_SKIP_LOWLEVEL_INIT and CONFIG_SKIP_RELOCATE_UBOOT. For instance, openrd_base, a kirkwood board, always skips lowlevel inits. Yep, those are set and work well with master. However the extra almost 10% of code increase (with next) will not go away with that. Therefore I strongly suggest that all extras (PIC) needed solely for relocation should be switchable OFF by a configuration option. Who does need that relocation in the first place? For years ARM did work without it; why now blowing up the code? Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91: problems master vs. next
Reinhard Meyer schrieb: Therefore I strongly suggest that all extras (PIC) needed solely for relocation should be switchable OFF by a configuration option. Who does need that relocation in the first place? For years ARM did work without it; why now blowing up the code? Sorry, to be precise: the option CONFIG_SYS_ARM_WITHOUT_RELOC should stay as a permanent feature. However, when I compile with that option defined in my board-config.h I get the following warnings for EVERY file: /home/reinhard/embedded/u-boot/include/configs/top9000_9xe.h:74:1: warning: CONFIG_SYS_ARM_WITHOUT_RELOC redefined command-line: warning: this is the location of the previous definition In file included from /home/reinhard/embedded/u-boot/include/config.h:4, from /home/reinhard/embedded/u-boot/include/common.h:37, from stmicro.c:30: because of that recursion: +ifdef CONFIG_SYS_ARM_WITHOUT_RELOC +PLATFORM_CPPFLAGS += -DCONFIG_SYS_ARM_WITHOUT_RELOC +endif The code size changes from 223592 to 229792 which is more acceptable, but I still does crash (I will look into that soon). Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91: problems master vs. next
Hi Reinhard, On Tuesday 21 September 2010 14:39:41 Reinhard Meyer wrote: Rebasing my current TOP9000 port on u-boot/next compiles after defining CONFIG_SYS_SDRAM_BASE and CONFIG_SYS_INIT_SP_ADDR. Code size increased heavyly from 223592 to 245544. Please note that this increase is not only because of the new ARM relocation support, but the environment rework done by Wolfgang: http://lists.denx.de/pipermail/u-boot/2010-July/074125.html As stated in this mail, the code size increase is typically 5...7KiB. 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] [PATCH] mmc: fix capacity calculation with high capacity mmc
On Sat, Sep 18, 2010 at 3:49 PM, Wolfgang Denk w...@denx.de wrote: Dear Lei Wen, In message aanlktimaqttcjf52djf-ahdeffqbhfwyejd3024vw...@mail.gmail.com you wrote: How about merge this patch? :-) I will wait for a pull request from the responsible custodian. Maybe you should have put him on cc: ... (done now). I pinged Andy about some mmc patches that he replied Applied to back in May but never made it into the repo. I see no emails from him to the u-boot list for sometime. Andy, are you still around? Freescalers, any info? Thanks John ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91: problems master vs. next
Stefan Roese schrieb: Please note that this increase is not only because of the new ARM relocation support, but the environment rework done by Wolfgang: Yes, that, too. About 5.5k next w/o relocation (#define CONFIG_SYS_ARM_WITHOUT_RELOC) and w/o cache (#define CONFIG_SYS_NO_[DI]CACHE): 229440 master: 223976 delta: 5464. Cache on costs 352 bytes. Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] RE : RE : Davinci DM365 custom design : Problem when reading uBoot environment variables
Some news to my problem. I found the source of the problem : The flags as explicited in uBoot 1.3.4 induces some problem. I had to undef the HW_ECC_4BIT flag since when using it the oob is overwritten. Since it looks at the oob to determine if a block is bad there was a problem. The unknown here is to understand why it did not use the BBT instead. By removing this flag and adding the nand_large_page flag it worked ! I however fixed the environment size issue so that it is no more a weird config. Thank you to all for your ideas and help. reda De : Scott Wood [scottw...@freescale.com] Date d'envoi : vendredi 17 septembre 2010 20:01 À : Wolfgang Denk Cc : Reda MIMOUNE; u-boot@lists.denx.de Objet : Re: [U-Boot] RE : Davinci DM365 custom design : Problem when reading uBoot environment variables On Fri, 17 Sep 2010 16:32:04 +0200 Wolfgang Denk w...@denx.de wrote: Dear Reda MIMOUNE, In message 1918f436c366b34bb245dd28389e039453adfaa...@mars.easii.fr you wrote: reading the README file, here is what I read: Note: CFG_ENV_OFFSET and CFG_ENV_OFFSET_REDUND must be aligned to a block boundary, and CFG_ENV_SIZE must be a multiple of the NAND devices block size. I think that should be CONFIG_ENV_SECT_SIZE CONFIG_ENV_SECT_SIZE isn't used by env_nand.c -- it uses the dynamically-read block size in nand_info. Since my sectors/blocks are 128KB, I must be at least 128KB! Is the README file wrong ? Seems so. Unless Davinci has messed up this. Yes, the README is wrong. It used to be that way until commit c3db8c649c6ab3da2f1411c4c6d61aecea054aa4, and README wasn't updated. The current requirement is that CONFIG_ENV_SIZE be a multiple of the page size. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] ppc4xx/fdt/flash: Change fdt_fixup_nor_flash_node() to not rely on cs size
This patch changes the behaviour of the fdt_fixup_nor_flash_node()
function. Now it doesn't patch the size of the reg property with the
chip-select size, but with the size returned from the new function
flash_get_bank_size(). This function will return per weak default the
flash size of the bank (bank = chip-select numer) detected by the flash
driver. If this does not fit your needs, this function may be overridden
by a board specific one.
For this the parameters needed to be changed. So I intentionally squashed
the PPC4xx stuff using this routine into this patch. Otherwise it would
not be git-bisectable anymore.
The board specific function for the AMCC/APM Ebony eval board is now
included in this patch version.
Signed-off-by: Stefan Roese s...@denx.de
Cc: Gerald Van Baren vanba...@cideas.com
Cc: Wolfgang Denk w...@denx.de
ppc4xx: Add board specific function to return the detected flash size
This function will be called to fixup size of the reg property of the
NOR flash device tree nodes. Ebony can't use the weak default, since
it has a special chip-select to bank-number binding.
Signed-off-by: Stefan Roese s...@denx.de
---
v3:
- Removed CONFIG_FDT_FIXUP_NOR_FLASH_SIZE from acadia_nand target
since it has no NOR flash at all and compiling fails with
flash_info undefined.
v2:
- Ebony's board specific function squashed into this patch
arch/powerpc/cpu/ppc4xx/fdt.c | 10
board/amcc/ebony/flash.c | 31 +
common/fdt_support.c | 51 +
include/configs/acadia.h |8 +-
include/fdt_support.h |2 +-
5 files changed, 85 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/cpu/ppc4xx/fdt.c b/arch/powerpc/cpu/ppc4xx/fdt.c
index 15a184b..e99b2b0 100644
--- a/arch/powerpc/cpu/ppc4xx/fdt.c
+++ b/arch/powerpc/cpu/ppc4xx/fdt.c
@@ -59,14 +59,14 @@ void __ft_board_setup(void *blob, bd_t *bd)
*p++ = 0;
*p++ = bxcr EBC_BXCR_BAS_MASK;
*p++ = EBC_BXCR_BANK_SIZE(bxcr);
+ }
+ }
+
#ifdef CONFIG_FDT_FIXUP_NOR_FLASH_SIZE
- /* Try to update reg property in nor flash node too */
- fdt_fixup_nor_flash_size(blob, i,
-EBC_BXCR_BANK_SIZE(bxcr));
+ /* Update reg property in all nor flash nodes too */
+ fdt_fixup_nor_flash_size(blob);
#endif
- }
- }
/* Some 405 PPC's have EBC as direct PLB child in the dts */
if (fdt_path_offset(blob, ebc_path) 0)
diff --git a/board/amcc/ebony/flash.c b/board/amcc/ebony/flash.c
index 8fe3ba1..79d2c4c 100644
--- a/board/amcc/ebony/flash.c
+++ b/board/amcc/ebony/flash.c
@@ -34,6 +34,7 @@
#include common.h
#include ppc4xx.h
#include asm/processor.h
+#include asm/io.h
#undef DEBUG
#ifdef DEBUG
@@ -71,6 +72,36 @@ static unsigned long
flash_addr_table[8][CONFIG_SYS_MAX_FLASH_BANKS] = {
*/
static ulong flash_get_size(vu_long * addr, flash_info_t * info);
+/*
+ * Override the weak default mapping function with a board specific one
+ */
+u32 flash_get_bank_size(int cs, int idx)
+{
+ u8 reg = in_8((void *)CONFIG_SYS_FPGA_BASE);
+
+ if ((reg BOOT_SMALL_FLASH) !(reg FLASH_ONBD_N)) {
+ /*
+* cs0: small flash (512KiB)
+* cs2: 2 * big flash (2 * 2MiB)
+*/
+ if (cs == 0)
+ return flash_info[2].size;
+ if (cs == 2)
+ return flash_info[0].size + flash_info[1].size;
+ } else {
+ /*
+* cs0: 2 * big flash (2 * 2MiB)
+* cs2: small flash (512KiB)
+*/
+ if (cs == 0)
+ return flash_info[0].size + flash_info[1].size;
+ if (cs == 2)
+ return flash_info[2].size;
+ }
+
+ return 0;
+}
+
unsigned long flash_init(void)
{
unsigned long total_b = 0;
diff --git a/common/fdt_support.c b/common/fdt_support.c
index aef4fe2..6f32e3f 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -591,11 +591,30 @@ int fdt_pci_dma_ranges(void *blob, int phb_off, struct
pci_controller *hose) {
#ifdef CONFIG_FDT_FIXUP_NOR_FLASH_SIZE
/*
+ * Provide a weak default function to return the flash bank size.
+ * There might be multiple non-identical flash chips connected to one
+ * chip-select, so we need to pass an index as well.
+ */
+u32 __flash_get_bank_size(int cs, int idx)
+{
+ extern flash_info_t flash_info[];
+
+ /*
+* As default, a simple 1:1 mapping is provided. Boards with
+* a different mapping need to supply a board specific mapping
+* routine.
+*/
+ return flash_info[cs].size;
+}
+u32 flash_get_bank_size(int cs, int idx)
+ __attribute__((weak, alias(__flash_get_bank_size)));
+
+/*
* This
Re: [U-Boot] AT91: problems master vs. next
Dear Reinhard Meyer, In message 4c98bec7.9090...@emk-elektronik.de you wrote: should be switchable OFF by a configuration option. Who does need that relocation in the first place? For years ARM did work without it; why now blowing up the code? Maintenancewise, the relocation is needed to allow to merge the ARM code back into a common source tree with other architectures. Technically, it is needed to be able to run a single U-Boot binary image on systems where you don;t know the exact RAM size at compile time (say on boards that come with more than one RAM size configurations), or to dynamically adapt to things like PRAM, frame buffer memory, syslog buffer, etc. Yes, ARM kind of worked without that for years, but it has always been a PITA for many of us. 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 rule on staying alive as a program manager is to give 'em a num- ber or give 'em a date, but never give 'em both at once. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91: problems master vs. next
Dear Albert ARIBAUD, In message 4c98ba84.9040...@free.fr you wrote: It should be always possible to #define relocation off! On arm926ejs this is controlled by CONFIG_SKIP_LOWLEVEL_INIT and CONFIG_SKIP_RELOCATE_UBOOT. For instance, openrd_base, a kirkwood board, always skips lowlevel inits. You cannot use CONFIG_SKIP_RELOCATE_UBOOT they way you used to do it. 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 How many QA engineers does it take to screw in a lightbulb? 3: 1 to screw it in and 2 to say I told you so when it doesn't work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] AT91: problems master vs. next
Dear Reinhard Meyer, In message 4c98a78d.7070...@emk-elektronik.de you wrote: What bothers me really here is the huge increase in code size. As has been pointed out by others, there are several factors that contribute to that code. And, on almost all AT91 systems booting will be through a first boot loader, which sets up SDRAM, loads u-boot to the correct address and jumps to it. When you have to support multiple memory configurations that correct address is typically right in the middle of your RAM. Assume you have a system with 64 or 128 MB of RAM. In the old way, U-Boot will probably sit somewhere at offset 63 MB or so, close to the end of the small configuration. On the big board this is neatly splitting the RAM into two small chunks - please explain to a customer why he cannot load a 64 MB image to RAM when there are 128 MB of RAM on his board, 127 MB of these actually unused? r why you need multiple binary images of U-Boot if you want to initialize and pass some memory at the end of RAM for further use in Linux, say frame buffer, or PRAM, or a log buffer? All low level init and relocation is not required in such cases. Relocation is still needed. 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 May your future be limited only by your dreams. - Christa McAuliffe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] Remove unused CONFIG_SERIAL_SOFTWARE_FIFO feature
This patch removes the completely unused CONFIG_SERIAL_SOFTWARE_FIFO feature from U-Boot. It has only been implemented for PPC4xx and was not used at all. So let's remove it and make the code smaller and cleaner. Signed-off-by: Stefan Roese s...@denx.de Acked-by: Detlev Zundel d...@denx.de --- v2: Rebased with patches to switch to common NS16550 UART driver README| 12 arch/i386/lib/board.c |7 --- arch/m68k/lib/board.c |4 arch/powerpc/lib/board.c |7 --- arch/sparc/lib/board.c|4 common/stdio.c|8 doc/README.ppc440 |6 -- include/common.h |8 include/configs/AP1000.h |6 -- include/configs/ATUM8548.h|1 - include/configs/JSE.h |6 -- include/configs/KAREF.h |1 - include/configs/METROBOX.h|1 - include/configs/ML2.h | 10 -- include/configs/MPC8308RDB.h |1 - include/configs/MPC8315ERDB.h |1 - include/configs/MPC8323ERDB.h |1 - include/configs/MPC832XEMDS.h |1 - include/configs/MPC8349EMDS.h |1 - include/configs/MPC8349ITX.h |1 - include/configs/MPC8360EMDS.h |1 - include/configs/MPC8360ERDK.h |1 - include/configs/MPC837XEMDS.h |1 - include/configs/MPC837XERDB.h |1 - include/configs/MPC8536DS.h |1 - include/configs/MPC8540ADS.h |1 - include/configs/MPC8540EVAL.h |1 - include/configs/MPC8541CDS.h |1 - include/configs/MPC8544DS.h |1 - include/configs/MPC8548CDS.h |1 - include/configs/MPC8555CDS.h |1 - include/configs/MPC8568MDS.h |1 - include/configs/MPC8569MDS.h |1 - include/configs/MPC8572DS.h |1 - include/configs/MPC8610HPCD.h |1 - include/configs/MPC8641HPCN.h |1 - include/configs/MVBLM7.h |1 - include/configs/P1_P2_RDB.h |1 - include/configs/P2020DS.h |1 - include/configs/PM854.h |1 - include/configs/SBC8540.h |1 - include/configs/TQM834x.h |1 - include/configs/TQM85xx.h |1 - include/configs/aria.h|1 - include/configs/bubinga.h |1 - include/configs/dlvision.h|1 - include/configs/eNET.h|1 - include/configs/ebony.h |1 - include/configs/hcu5.h|1 - include/configs/kmeter1.h |1 - include/configs/mcu25.h |7 --- include/configs/mecp5123.h|1 - include/configs/mpc5121ads.h |1 - include/configs/neo.h |1 - include/configs/ocotea.h |1 - include/configs/sbc8349.h |1 - include/configs/sbc8548.h |1 - include/configs/sbc8560.h |1 - include/configs/sbc8641d.h|1 - include/configs/sc3.h |8 include/configs/socrates.h|1 - include/configs/stxssa.h |1 - include/configs/taihu.h |1 - include/configs/vme8349.h |1 - include/configs/walnut.h |1 - include/configs/yucca.h |1 - 66 files changed, 0 insertions(+), 146 deletions(-) diff --git a/README b/README index c7a8e9d..feb51ab 100644 --- a/README +++ b/README @@ -532,18 +532,6 @@ The following options need to be configured: must be defined, to setup the maximum idle timeout for the SMC. -- Interrupt driven serial port input: - CONFIG_SERIAL_SOFTWARE_FIFO - - PPC405GP only. - Use an interrupt handler for receiving data on the - serial port. It also enables using hardware handshake - (RTS/CTS) and UART's built-in FIFO. Set the number of - bytes the interrupt driven input buffer should have. - - Leave undefined to disable this feature, including - disable the buffer and hardware handshake. - - Boot Delay: CONFIG_BOOTDELAY - in seconds Delay before automatically booting the default image; set to -1 to disable autoboot. diff --git a/arch/i386/lib/board.c b/arch/i386/lib/board.c index 93f910b..5002203 100644 --- a/arch/i386/lib/board.c +++ b/arch/i386/lib/board.c @@ -335,13 +335,6 @@ void board_init_r(gd_t *id, ulong dest_addr) enable_interrupts(); show_boot_progress(0x28); - /* Must happen after interrupts are initialized since -* an irq handler gets installed -*/ -#ifdef CONFIG_SERIAL_SOFTWARE_FIFO - serial_buffered_init(); -#endif - #ifdef CONFIG_STATUS_LED status_led_set (STATUS_LED_BOOT, STATUS_LED_BLINKING); #endif diff --git a/arch/m68k/lib/board.c b/arch/m68k/lib/board.c index ae9478a..c29f577 100644 --- a/arch/m68k/lib/board.c +++ b/arch/m68k/lib/board.c @@ -569,10 +569,6 @@ void board_init_r (gd_t *id, ulong dest_addr) */ timer_init(); -#ifdef CONFIG_SERIAL_SOFTWARE_FIFO - serial_buffered_init(); -#endif - #ifdef CONFIG_STATUS_LED
Re: [U-Boot] cuImage and multi image?
On Tue, 21 Sep 2010 03:03:22 +0200 Chen, Tiejun tiejun.c...@windriver.com wrote: -Original Message- From: Shawn Jin [mailto:shawnx...@gmail.com] Sent: Tuesday, September 21, 2010 1:53 AM To: Chen, Tiejun Cc: ppcdev; uboot Subject: Re: cuImage and multi image? I have a cuImage kernel in order to support legacy u-boot and a ramdisk image. Kernel boots fine if these two images are separate and bootm $kernel $ramdisk is used. But I can not make it to work using a single multi image that contains the kernel and ramdisk images. Is it even technically possible to boot a multi-image with cuboot wrapper? Try the following steps: -- 1. cp your ramdisk.gz arch/powerpc/boot/ramdisk.image.gz 2. make cuImage.initrd.your target You can get one Image, cuImage.initrd.your target, including kernel and ramdisk. A follow up question. With this method, the total image size (uncompressed) is limited to the 4MB (the link address of the boot wrapper)? No. Yes, unless you change the link address, or provide a vmlinux_alloc callback (which currently only happens on true OF, not cuImage). Unless you're talking about the (uncompressed)? The limit applies to the uncompressed boot image -- anything that the bootwrapper itself is decompressing. It does not apply to any further uncompression of the ramdisk itself. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] setlocalversion: add some more fallbacks for git describe
Dear Mike Frysinger, In message 1285007778-22418-1-git-send-email-vap...@gentoo.org you wrote: If working out of a custom git tree that lacks annotated tags, the 'git describe' operation spews fatal: cannot describe errors all over the place. So add some fallback code in case the best naming was unable to locate something useful. Signed-off-by: Mike Frysinger vap...@gentoo.org --- tools/setlocalversion |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) Applied, thanks. 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 Who alone has reason to *lie himself out* of actuality? He who *suffers* from it. - Friedrich Nietzsche ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] [NEXT] orion5x: fix relocation-incompatible code
Signed-off-by: Albert Aribaud albert.arib...@free.fr --- Device address window mapping code would not run from FLASH due to cutting access to BOOTCS. Fixed by reordering code. Timer initialization would write globals, thus would not run correctly from FLASH. Fixed by moving the writes to a later phase in RAM. arch/arm/cpu/arm926ejs/orion5x/cpu.c| 80 +++ arch/arm/cpu/arm926ejs/orion5x/timer.c |8 ++- arch/arm/include/asm/arch-orion5x/cpu.h |1 + 3 files changed, 56 insertions(+), 33 deletions(-) diff --git a/arch/arm/cpu/arm926ejs/orion5x/cpu.c b/arch/arm/cpu/arm926ejs/orion5x/cpu.c index 260f88b..5cffa86 100644 --- a/arch/arm/cpu/arm926ejs/orion5x/cpu.c +++ b/arch/arm/cpu/arm926ejs/orion5x/cpu.c @@ -77,6 +77,17 @@ unsigned int orion5x_winctrl_calcsize(unsigned int sizeval) * * If remap function not used, remap_lo must be set as base * + * NOTES: + * + * 1) in order to avoid windows with inconsistent control and base values + *(which could prevent access to BOOTCS and hence execution from FLASH) + *always disable window before writing the base value then reenable it + *by writing the control value. + * + * 2) in order to avoid losing access to BOOTCS when disabling window 7, + *first configure window 6 for BOOTCS, then configure window 7 for BOOTCS, + *then configure windows 0 to 6 for their own target. + * * Reference Documentation: * Mbus-L to Mbus Bridge Registers Configuration. * (Sec 25.1 and 25.3 of Datasheet) @@ -86,57 +97,64 @@ int orion5x_config_adr_windows(void) struct orion5x_win_registers *winregs = (struct orion5x_win_registers *)ORION5X_CPU_WIN_BASE; - /* Window 0: PCIE MEM address space */ +/* Disable window 6, configure it for FLASH, enable it. */ + writel(0, winregs[6].ctrl); + writel(ORION5X_ADR_BOOTROM, winregs[6].base); + writel(ORION5X_CPU_WIN_CTRL_DATA(ORION5X_SZ_BOOTROM, + ORION5X_TARGET_DEVICE, ORION5X_ATTR_BOOTROM, + ORION5X_WIN_ENABLE), winregs[6].ctrl); +/* Disable window 7, configure it for FLASH, enable it. */ + writel(0, winregs[7].ctrl); + writel(ORION5X_ADR_BOOTROM, winregs[7].base); + writel(ORION5X_CPU_WIN_CTRL_DATA(ORION5X_SZ_BOOTROM, + ORION5X_TARGET_DEVICE, ORION5X_ATTR_BOOTROM, + ORION5X_WIN_ENABLE), winregs[7].ctrl); +/* Disable window 0, configure it for its intended target, enable it. */ + writel(0, winregs[0].ctrl); + writel(ORION5X_ADR_PCIE_MEM, winregs[0].base); + writel(ORION5X_ADR_PCIE_MEM_REMAP_LO, winregs[0].remap_lo); + writel(ORION5X_ADR_PCIE_MEM_REMAP_HI, winregs[0].remap_hi); writel(ORION5X_CPU_WIN_CTRL_DATA(ORION5X_SZ_PCIE_MEM, ORION5X_TARGET_PCIE, ORION5X_ATTR_PCIE_MEM, ORION5X_WIN_ENABLE), winregs[0].ctrl); - writel(ORION5X_ADR_PCIE_MEM, winregs[0].base); - writel(ORION5X_ADR_PCIE_MEM_REMAP_LO, winregs[0].remap_lo); - writel(ORION5X_ADR_PCIE_MEM_REMAP_HI, winregs[0].remap_hi); - - /* Window 1: PCIE IO address space */ - writel(ORION5X_CPU_WIN_CTRL_DATA(ORION5X_SZ_PCIE_IO, - ORION5X_TARGET_PCIE, ORION5X_ATTR_PCIE_IO, - ORION5X_WIN_ENABLE), winregs[1].ctrl); +/* Disable window 1, configure it for its intended target, enable it. */ + writel(0, winregs[1].ctrl); writel(ORION5X_ADR_PCIE_IO, winregs[1].base); writel(ORION5X_ADR_PCIE_IO_REMAP_LO, winregs[1].remap_lo); writel(ORION5X_ADR_PCIE_IO_REMAP_HI, winregs[1].remap_hi); - - /* Window 2: PCI MEM address space */ + writel(ORION5X_CPU_WIN_CTRL_DATA(ORION5X_SZ_PCIE_IO, + ORION5X_TARGET_PCIE, ORION5X_ATTR_PCIE_IO, + ORION5X_WIN_ENABLE), winregs[1].ctrl); +/* Disable window 2, configure it for its intended target, enable it. */ + writel(0, winregs[2].ctrl); + writel(ORION5X_ADR_PCI_MEM, winregs[2].base); writel(ORION5X_CPU_WIN_CTRL_DATA(ORION5X_SZ_PCI_MEM, ORION5X_TARGET_PCI, ORION5X_ATTR_PCI_MEM, ORION5X_WIN_ENABLE), winregs[2].ctrl); - writel(ORION5X_ADR_PCI_MEM, winregs[2].base); - - /* Window 3: PCI IO address space */ +/* Disable window 3, configure it for its intended target, enable it. */ + writel(0, winregs[3].ctrl); + writel(ORION5X_ADR_PCI_IO, winregs[3].base); writel(ORION5X_CPU_WIN_CTRL_DATA(ORION5X_SZ_PCI_IO, ORION5X_TARGET_PCI, ORION5X_ATTR_PCI_IO, ORION5X_WIN_ENABLE), winregs[3].ctrl); - writel(ORION5X_ADR_PCI_IO, winregs[3].base); - - /* Window 4: DEV_CS0 address space */ +/* Disable window 4, configure it for its intended target, enable it. */ + writel(0, winregs[4].ctrl); + writel(ORION5X_ADR_DEV_CS0, winregs[4].base); writel(ORION5X_CPU_WIN_CTRL_DATA(ORION5X_SZ_DEV_CS0, ORION5X_TARGET_DEVICE, ORION5X_ATTR_DEV_CS0,
[U-Boot] [PATCH 2/2] [NEXT] edminiv2: enable relocation
Signed-off-by: Albert Aribaud albert.arib...@free.fr --- board/LaCie/edminiv2/config.mk |4 +++- include/configs/edminiv2.h |6 ++ 2 files changed, 9 insertions(+), 1 deletions(-) diff --git a/board/LaCie/edminiv2/config.mk b/board/LaCie/edminiv2/config.mk index 3dec1aa..b4845ad 100644 --- a/board/LaCie/edminiv2/config.mk +++ b/board/LaCie/edminiv2/config.mk @@ -24,4 +24,6 @@ # MA 02110-1301 USA # -TEXT_BASE = 0x0010 +# with relocation TEXT_BASE now *must* be in FLASH + +TEXT_BASE = 0xfff9 diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h index ccfc660..a61e225 100644 --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h @@ -223,4 +223,10 @@ #define CONFIG_SYS_RESET_ADDRESS 0x #define CONFIG_SYS_MAXARGS 16 +/* additions for new relocation code, must added to all boards */ +#undef CONFIG_SYS_ARM_WITHOUT_RELOC +#define CONFIG_SYS_SDRAM_BASE 0 +#define CONFIG_SYS_INIT_SP_ADDR\ + (CONFIG_SYS_SDRAM_BASE + 0x1000 - CONFIG_SYS_GBL_DATA_SIZE) + #endif /* _CONFIG_EDMINIV2_H */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2010.09-rc2 is out / next branch available
Dear Mike Frysinger, In message 201009201447.34016.vap...@gentoo.org you wrote: Please help testing Blackfin looks sane Thanks. check if all your relevant patches have been included. could you merge this change: 29.07.2010[PATCH v2] cmd_mmc: use common usage function Will do. Thanks for the reminder. 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 Intel told us the Pentium would have RISK features... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] cmd_mmc: use common usage function
Dear Mike Frysinger, In message 1280425243-25290-1-git-send-email-vap...@gentoo.org you wrote: Rather than using a custom Usage:, use the common cmd_usage() function, and tail into it now that it returns 1 for us. Signed-off-by: Mike Frysinger vap...@gentoo.org --- v2 - tail into cmd_usage() as pointed out by Detlev Zundel common/cmd_mmc.c |9 +++-- 1 files changed, 3 insertions(+), 6 deletions(-) Applied, thanks. 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 Prof:So the American government went to IBM to come up with a data encryption standard and they came up with ... Student: EBCDIC! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [STATUS] v2010.09-rc2 is out / next branch available
Dear Michael Zaidman, In message aanlktinkcf-uzgfdnoc0ckvdkwgu8gf47jfe=draf...@mail.gmail.com you wrote: check if all your relevant patches have been included. I rebased against the master and resubmitted the POST Cleanup patch (http://lists.denx.de/pipermail/u-boot/2010-September/077467.html) as was promised in http://lists.denx.de/pipermail/u-boot/2010-August/075227.html. Should I resubmit it into the next branch or it can go into the current release? Thanks for the reminder. Goes in now. 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 Man is the best computer we can put aboard a spacecraft ... and the only one that can be mass produced with unskilled labor. - Wernher von Braun ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] POST cleanup.
Dear Michael Zaidman,
In message
d520c6ef298416a03789ebfa4e05e257b5331693.1284965175.git.michael.zaid...@gmail.com
you wrote:
- Revives POST for blackfin arch;
- Removes redundant code:
arch/blackfin/lib/post.c
arch/powerpc/cpu/ppc4xx/commproc.c
arch/powerpc/cpu/mpc512x/common.c
- fixes up the post_word_{load|store} usage.
Signed-off-by: Michael Zaidman michael.zaid...@gmail.com
Acked-by: Detlev Zundel d...@denx.de
Tested-by: Anatolij Gustschin ag...@denx.de
List of the maintainers of the affected by patch boards:
Cc: Stephan Linz l...@li-pro.net
Cc: Denis Peter d.pe...@mpl.ch
Cc: Matthias Fuchs matthias.fu...@esd-electronics.com
Cc: Peter Tyser pty...@xes-inc.com
Cc: Stefan Roese s...@denx.de
Cc: Mike Frysinger vap...@gentoo.org
Cc: Niklaus Giger niklaus.gi...@netstal.com
Cc: Larry Johnson l...@acm.org
Cc: Feng Kan f...@amcc.com
---
arch/blackfin/lib/Makefile |2 +-
arch/blackfin/lib/board.c |1 -
arch/blackfin/lib/post.c| 421
---
arch/powerpc/cpu/mpc512x/common.c | 25 --
arch/powerpc/cpu/mpc8260/commproc.c | 20 --
arch/powerpc/cpu/mpc85xx/commproc.c | 20 --
arch/powerpc/cpu/mpc8xx/commproc.c | 20 --
arch/powerpc/cpu/ppc4xx/Makefile|1 -
arch/powerpc/cpu/ppc4xx/commproc.c | 53 -
board/barco/barco.c |9 -
board/bc3450/bc3450.c | 20 --
board/bf537-stamp/Makefile |2 +-
board/bf537-stamp/post.c| 14 --
board/cm5200/cm5200.c | 16 --
board/tqc/tqm5200/tqm5200.c | 19 --
board/xes/xpedite1000/xpedite1000.c | 16 --
include/common.h|5 +-
include/configs/KAREF.h |3 +-
include/configs/METROBOX.h |3 +-
include/configs/MIP405.h|4 -
include/configs/PMC440.h|3 +-
include/configs/TB5200.h|2 +-
include/configs/XPEDITE1000.h |3 +-
include/configs/alpr.h |3 +-
include/configs/barco.h |2 +
include/configs/bf537-stamp.h |1 +
include/configs/bfin_adi_common.h |1 +
include/configs/hcu4.h |3 +-
include/configs/hcu5.h |5 +-
include/configs/hmi1001.h |6 +-
include/configs/icon.h |3 +-
include/configs/inka4x0.h |6 +-
include/configs/katmai.h|3 +-
include/configs/kilauea.h |3 +-
include/configs/korat.h |3 +-
include/configs/lwmon5.h|2 +-
include/configs/makalu.h|3 +-
include/configs/mcu25.h |3 +-
include/configs/mpc5121-common.h|3 +-
include/configs/ocotea.h|3 +-
include/configs/redwood.h |3 +-
include/configs/sequoia.h |3 +-
include/configs/taishan.h |3 +-
include/configs/yucca.h |3 +-
include/configs/zeus.h |7 +-
include/post.h | 57 +-
post/Makefile |3 +-
47 files changed, 101 insertions(+), 713 deletions(-)
delete mode 100644 arch/blackfin/lib/post.c
delete mode 100644 arch/powerpc/cpu/mpc512x/common.c
delete mode 100644 arch/powerpc/cpu/ppc4xx/commproc.c
Applied, thanks.
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
Software entities are more complex for their size than perhaps any
other human construct because no two parts are alike. If they are, we
make the two similar parts into a subroutine -- open or closed. In
this respect, software systems differ profoundly from computers,
buildings, or automobiles, where repeated elements abound.
- Fred Brooks, Jr.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] [NEXT]arm: Make jadecpu use relocation
Dear Matthias Weisser, In message 1285076264-13219-1-git-send-email-weiss...@arcor.de you wrote: This patch modifies jadecpu board so that it is usable with the relocation patches by Heiko Schocher Signed-off-by: Matthias Weisser weiss...@arcor.de --- board/syteco/jadecpu/config.mk |2 +- board/syteco/jadecpu/jadecpu.c | 11 +-- include/configs/jadecpu.h |3 +++ 3 files changed, 13 insertions(+), 3 deletions(-) Applied to next branch, thanks. 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 Actual war is a very messy business. Very, very messy business. -- Kirk, A Taste of Armageddon, stardate 3193.0 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH next v2] silence config step commands display during MAKEALL builds
Dear Kim Phillips,
In message 20100914144816.177602d5.kim.phill...@freescale.com you wrote:
[u-boot next]$ ./MAKEALL 83xx
awk '(NF $1 !~ /^#/) { print $1 : $1 _config; $(MAKE) }' boards.cfg
.boards.depend
Configuring for ve8313 board...
Signed-off-by: Kim Phillips kim.phill...@freescale.com
---
applies to u-boot.git's next branch.
MAKEALL |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Applied to next branch, thanks.
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
You get a wonderful view from the point of no return.
- Terry Pratchett, _Making_Money_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot on dockstar problem - ** Bad partition 1 **
Wolfgang, to be honest, it`s not my problem that some people on the net seem to be on a personal crusade to tell other people how to post to mailinglists or how to write email. My life does not depend on u-boot. I did not only ask for help, but i also offered help (giving valuable end-user input to make u-boot run better on pogoplug/dockstar - Mind that dockstar is currently on sale at Atelco for Eur 24,90. That is a killer price for 1,2Ghz ARM Kirkwood SoC with 128M) If you don`t like me or like my mail style - no problem, i can go away and switch to another bootloader or maybe even other hardware platform. What I got from you for my postings was nothing but negative. I was being accused that I did not this or I did not that. In other words, you even told me to be an idiot, as I should go read a document how to ask SMART questions. So, if this list is also for users, I would recommend to be more tolerant on how users write mails! I`m no C-coder and there are people in this world that give not that much attention to make their Ascii look perfect on screen. Don`t you think that those two mails from you were a little bit more offensive than my laxly dealing with mail formatting was offensive to all the list members alltogether ? I don`t even know how to limit chars in my webmailer, and even Linus Torvalds is fine with more than 80 chars per line (http://lkml.org/lkml/2009/12/17/229 ) So, we either can say a friendly Hello now, or you may kick me off this list and scare me away from u-boot for the rest of my life. Sorry if that have been harsh words now, but i was really pissed and it is a very long time ago that is got such negative response from a project`s owner to initial postings on a mailing list. If we can be above such things now, i suggest we concentrate on the issue. If you`re ok with that, here we go (otherwise: please ignore!): You completely fail to explain which exact version of U-Boot you are running - it seems to be a locally modified one, probably with out-of-tree patches to support that Dockstar board which is not known in the mainline U-Boot repository. How should we be able to comment on code we don't even know? Apparently you are right. I did not realize that this is a modified version ( http://jeff.doozan.com/debian/uboot/build_uboot.htm ) and apparently the changes (add pogoplug/dockstar, seems much LED stuff) have never been sent upstream. Anyway,the patch at http://jeff.doozan.com/debian/uboot/uboot.mtd3.patch does not seem to poke into the u-boot usb code, so i wonder if the changes can be source of the problem. I have seen posts from sheevaplug users which report similar issue, and as it seems, official support for sheevaplug is already in u-boot. Maybe there is a way to add official support for pogoplug and dockstar, as this out-of-tree stuff sucks big So, if this is not for the u-boot list, please somebody give an advice on how to proceed for resolving this issue. regards Roland ps: reference to the initial post, unintentionally hijacking another thread: http://lists.denx.de/pipermail/u-boot/2010-September/077489.html From: Wolfgang Denk w...@denx.de Sent: Tuesday, September 21, 2010 8:40 AM To: devz...@web.de Cc: Subject: Re: [U-Boot] [PATCH] usb: fix usb start problem with SMSC USB hub and Toshiba USB stick Dear devz...@web.de, In message 899533205.349626.128509052.javamail.fm...@mwmweb063 you wrote: pardon, that was not my intention, nor was it my intention to infringe list rules. so, this is for developers/experts - not for users and bug-reporte rs? This list is for ALL discussions about U-Boot: users, bug-reporters, developers, etc. But we expect that everybody who posts here follows some basic Netiquette. You don't. For example, Netiquette says to keep your line length below some 70 characters or so. You don't even after being told. I asked you explicitly NOT to top post / full quote, and pointed you to rules for correct quoting. You ignore that. i`m spending more than half of this evening with this issue, trying to find a solution and trying to provide information for a problem affecting manyr people and which seems to exist in u-boot. I also pointed you to a document that explains how to ask smart questions, but it seems you ignored this hint as well. You completely fail to explain which exact version of U-Boot you are running - it seems to be a locally modified one, probably with out-of-tree patches to support that Dockstar board which is not known in the mainline U-Boot repository. How should we be able to comment on code we don't even know? 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 Have you lived in this village all your life?No, not yet.
Re: [U-Boot] [PATCH] [v3] fsl: refactor MPC8610 and MPC5121 DIU code to use existing bitmap and logo features
Hi Timur, On Tue, 31 Aug 2010 19:56:43 -0500 Timur Tabi ti...@freescale.com wrote: The Freescale MPC8610 and MPC5121 DIU code had re-implement two features that already existed in U-Boot: bitmap drawing and top-of-screen logo (CONFIG_VIDEO_LOGO). So delete the 8610-specific code and use the built-in features instead. Signed-off-by: Timur Tabi ti...@freescale.com --- This patch depends on the patch, logos: add Freescale logo This patch supersedes these two patches: [v2] mpc8610: refactor DIU initialization code to use existing bitmap and logo features mpc8610: refactor DIU initialization code to use existing bitmap function arch/powerpc/cpu/mpc512x/Makefile |1 - arch/powerpc/cpu/mpc512x/diu.c| 68 +-- board/freescale/common/Makefile |2 +- board/freescale/common/fsl_diu_fb.c | 132 + board/freescale/common/fsl_diu_fb.h | 12 +- board/freescale/common/fsl_logo_bmp.c | 878 - board/freescale/mpc5121ads/mpc5121ads.c |5 - board/freescale/mpc8610hpcd/mpc8610hpcd.c |6 +- board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c | 78 +-- include/configs/MPC8610HPCD.h |5 +- include/configs/mpc5121ads.h |6 +- 11 files changed, 37 insertions(+), 1156 deletions(-) delete mode 100644 board/freescale/common/fsl_logo_bmp.c Applied to u-boot-video/next. Thanks! Best regards, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: add video support
Hi Timur, On Thu, 2 Sep 2010 15:35:19 -0500 Timur Tabi ti...@freescale.com wrote: ... +#include common.h +#include command.h +#include asm/io.h + +#ifdef CONFIG_FSL_DIU_FB Please drop the #ifdef above. Conditional compilation is already handled by Makefile. ... +#define PX_BRDCFG1_DDCEN 0x10 This one is not used, please drop. ... +#define AD_BYTE_F0x1000 +#define AD_ALPHA_C_MASK 0x0E00 +#define AD_ALPHA_C_SHIFT 25 +#define AD_BLUE_C_MASK 0x0180 +#define AD_BLUE_C_SHIFT 23 +#define AD_GREEN_C_MASK 0x0060 +#define AD_GREEN_C_SHIFT 21 +#define AD_RED_C_MASK0x0018 +#define AD_RED_C_SHIFT 19 +#define AD_PALETTE 0x0004 +#define AD_PIXEL_S_MASK 0x0003 +#define AD_PIXEL_S_SHIFT 16 +#define AD_COMP_3_MASK 0xF000 +#define AD_COMP_3_SHIFT 12 +#define AD_COMP_2_MASK 0x0F00 +#define AD_COMP_2_SHIFT 8 +#define AD_COMP_1_MASK 0x00F0 +#define AD_COMP_1_SHIFT 4 +#define AD_COMP_0_MASK 0x000F +#define AD_COMP_0_SHIFT 0 + +#define AD_DEFAULT Some of the defines above are not used (*_MASK, AD_PALETTE, AD_DEFAULT), please drop them, too. ... diff --git a/include/configs/P1022DS.h b/include/configs/P1022DS.h index dcaca2b..d518c69 100644 --- a/include/configs/P1022DS.h +++ b/include/configs/P1022DS.h @@ -31,6 +31,7 @@ #define CONFIG_FSL_PCIE_RESET/* need PCIe reset errata */ #define CONFIG_SYS_PCI_64BIT /* enable 64-bit PCI resources */ #define CONFIG_SYS_HAS_SERDES/* has SERDES */ +#define CONFIG_FSL_DIU_FB/* Has a DIU video controller */ Drop this CONFIG_FSL_DIU_FB define, too. It is already present in the board config file. #define CONFIG_PHYS_64BIT #define CONFIG_ENABLE_36BIT_PHYS @@ -181,10 +182,14 @@ #define CONFIG_SYS_DIU_ADDR (CONFIG_SYS_CCSRBAR + 0x1) /* Video */ -/* #define CONFIG_VIDEO */ +#undef CONFIG_VIDEO + #ifdef CONFIG_VIDEO +#define CONFIG_CMD_BMP #define CONFIG_CFB_CONSOLE #define CONFIG_VGA_AS_SINGLE_DEVICE +#define CONFIG_VIDEO_LOGO +#define CONFIG_VIDEO_BMP_LOGO #endif CONFIG_VIDEO definition should depend on CONFIG_FSL_DIU_FB, I think. Otherwise the building won't succeed if CONFIG_FSL_DIU_FB is not defined (due to absence of video_hw_init()). Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: add video support
Anatolij Gustschin wrote: +#define AD_BYTE_F 0x1000 +#define AD_ALPHA_C_MASK 0x0E00 +#define AD_ALPHA_C_SHIFT25 +#define AD_BLUE_C_MASK 0x0180 +#define AD_BLUE_C_SHIFT 23 +#define AD_GREEN_C_MASK 0x0060 +#define AD_GREEN_C_SHIFT21 +#define AD_RED_C_MASK 0x0018 +#define AD_RED_C_SHIFT 19 +#define AD_PALETTE 0x0004 +#define AD_PIXEL_S_MASK 0x0003 +#define AD_PIXEL_S_SHIFT16 +#define AD_COMP_3_MASK 0xF000 +#define AD_COMP_3_SHIFT 12 +#define AD_COMP_2_MASK 0x0F00 +#define AD_COMP_2_SHIFT 8 +#define AD_COMP_1_MASK 0x00F0 +#define AD_COMP_1_SHIFT 4 +#define AD_COMP_0_MASK 0x000F +#define AD_COMP_0_SHIFT 0 + +#define AD_DEFAULT Some of the defines above are not used (*_MASK, AD_PALETTE, AD_DEFAULT), please drop them, too. Does it really matter? These are all in a .c file, so it's not like I'm polluting the name space. Also, I thought it would be better to provide some sort of completeness for the bits I am using. CONFIG_VIDEO definition should depend on CONFIG_FSL_DIU_FB, I think. Otherwise the building won't succeed if CONFIG_FSL_DIU_FB is not defined (due to absence of video_hw_init()). We need the DIU initialized, even if U-Boot doesn't use it. This is what CONFIG_FSL_DIU_FB does. CONFIG_VIDEO then tells U-Boot to actually use the DIU. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request u-boot-blackfin.git
The following changes since commit 800eb09641ae67c707b65acff112684a954b7f44: POST cleanup. (2010-09-21 21:39:31 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-blackfin.git master Mike Frysinger (2): Blackfin: update some missed board config.mk files Blackfin: bfin_spi: use same gpio cs define as Linux arch/blackfin/include/asm/config-pre.h |3 +++ board/bf527-ad7160-eval/config.mk |4 ++-- board/ip04/config.mk |4 ++-- drivers/spi/bfin_spi.c |2 -- 4 files changed, 7 insertions(+), 6 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-video/master
Dear Wolfgang, On Sat, 18 Sep 2010 23:26:30 +0200 Wolfgang Denk w...@denx.de wrote: ... In message 20100916005042.62575...@wker you wrote: Dear Wolfgang, The following changes since commit a12555c02d716f62aa1ec4764cf1c42bfeecf07d: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-nand-flash are available in the git repository at: git://git.denx.de/u-boot-video.git master Timur Tabi (1): video: cfb_console: fix definition and usage of CURSOR_xxx macros drivers/video/cfb_console.c | 24 ++-- 1 files changed, 14 insertions(+), 10 deletions(-) Applied, thanks. I don't see this patch in the current master branch. Can you please pull again: The following changes since commit 800eb09641ae67c707b65acff112684a954b7f44: Michael Zaidman (1): POST cleanup. are available in the git repository at: git://git.denx.de/u-boot-video.git master Timur Tabi (1): video: cfb_console: fix definition and usage of CURSOR_xxx macros drivers/video/cfb_console.c | 24 ++-- 1 files changed, 14 insertions(+), 10 deletions(-) Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-video/next
Dear Wolfgang, The following changes since commit d70d8ccc200db8c16a6654cb726c3d74b6640b32: Kim Phillips (1): silence config step commands display during MAKEALL builds are available in the git repository at: git://git.denx.de/u-boot-video.git next Timur Tabi (3): logos: add Freescale logo video: cfb_console: add support for 4bpp bitmaps with GDF_32BIT_X888RGB fsl: refactor MPC8610 and MPC5121 DIU code to use existing bitmap and logo features arch/powerpc/cpu/mpc512x/Makefile |1 - arch/powerpc/cpu/mpc512x/diu.c| 68 +-- board/freescale/common/Makefile |2 +- board/freescale/common/fsl_diu_fb.c | 132 + board/freescale/common/fsl_diu_fb.h | 12 +- board/freescale/common/fsl_logo_bmp.c | 878 - board/freescale/mpc5121ads/mpc5121ads.c |5 - board/freescale/mpc8610hpcd/mpc8610hpcd.c |6 +- board/freescale/mpc8610hpcd/mpc8610hpcd_diu.c | 78 +-- drivers/video/cfb_console.c | 38 +- include/configs/MPC8610HPCD.h |5 +- include/configs/mpc5121ads.h |6 +- tools/Makefile|3 + tools/logos/freescale.bmp | Bin 0 - 46738 bytes 14 files changed, 77 insertions(+), 1157 deletions(-) delete mode 100644 board/freescale/common/fsl_logo_bmp.c create mode 100644 tools/logos/freescale.bmp Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: add video support
On Tue, 21 Sep 2010 17:00:19 -0500 Timur Tabi ti...@freescale.com wrote: Anatolij Gustschin wrote: +#define AD_BYTE_F 0x1000 +#define AD_ALPHA_C_MASK 0x0E00 +#define AD_ALPHA_C_SHIFT 25 +#define AD_BLUE_C_MASK0x0180 +#define AD_BLUE_C_SHIFT 23 +#define AD_GREEN_C_MASK 0x0060 +#define AD_GREEN_C_SHIFT 21 +#define AD_RED_C_MASK 0x0018 +#define AD_RED_C_SHIFT19 +#define AD_PALETTE0x0004 +#define AD_PIXEL_S_MASK 0x0003 +#define AD_PIXEL_S_SHIFT 16 +#define AD_COMP_3_MASK0xF000 +#define AD_COMP_3_SHIFT 12 +#define AD_COMP_2_MASK0x0F00 +#define AD_COMP_2_SHIFT 8 +#define AD_COMP_1_MASK0x00F0 +#define AD_COMP_1_SHIFT 4 +#define AD_COMP_0_MASK0x000F +#define AD_COMP_0_SHIFT 0 + +#define AD_DEFAULT Some of the defines above are not used (*_MASK, AD_PALETTE, AD_DEFAULT), please drop them, too. Does it really matter? These are all in a .c file, so it's not like I'm polluting the name space. Also, I thought it would be better to provide some sort of completeness for the bits I am using. We do not add unused code. CONFIG_VIDEO definition should depend on CONFIG_FSL_DIU_FB, I think. Otherwise the building won't succeed if CONFIG_FSL_DIU_FB is not defined (due to absence of video_hw_init()). We need the DIU initialized, even if U-Boot doesn't use it. This is what CONFIG_FSL_DIU_FB does. CONFIG_VIDEO then tells U-Boot to actually use the DIU. I understand it. I didn't say you should make CONFIG_FSL_DIU_FB dependent on CONFIG_VIDEO, but the opposite. On the other site, one of the design principles states: initialize devices only when they are needed within U-Boot. Thanks, Anatolij ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] p1022ds: add video support
Anatolij Gustschin wrote: Also, I thought it would be better to provide some sort of completeness for the bits I am using. We do not add unused code. Well, I don't see how macros are unused code, but I'll delete those lines. CONFIG_VIDEO definition should depend on CONFIG_FSL_DIU_FB, I think. Otherwise the building won't succeed if CONFIG_FSL_DIU_FB is not defined (due to absence of video_hw_init()). We need the DIU initialized, even if U-Boot doesn't use it. This is what CONFIG_FSL_DIU_FB does. CONFIG_VIDEO then tells U-Boot to actually use the DIU. I understand it. I didn't say you should make CONFIG_FSL_DIU_FB dependent on CONFIG_VIDEO, but the opposite. Ok. On the other site, one of the design principles states: initialize devices only when they are needed within U-Boot. Well, I'll try to work toward that, but I'm pretty sure there are plenty of devices that are initialized but not used in U-Boot already. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Hello Dear
Hello My Dear, How are you? Hope you are fine? Well, I don't know how to start... well, am Miss Precious Boko, I am single and never been married. i will like to know you more and we can exchange photo and know each other more thanks and hoping to hear from you soon___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH 1/2] nand: allow delayed initialization
Many people like the current nand_init() behavior where it is always
initialized during boot and the flash size shown, but there are cases
where we are willing to forgo this niceness for speed/functionality.
So rather than change the default, introduce a delayed config option
people may enable. This way the nand is only poked when someone tries
to actually use it.
Signed-off-by: Mike Frysinger vap...@gentoo.org
---
note: i havent documented this in the README yet as i want to get
feedback on the approach first
common/cmd_nand.c |2 ++
common/env_nand.c |8
drivers/mtd/nand/nand.c |9 +
include/nand.h |5 +
4 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index f611fd7..ed3ca54 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -222,6 +222,8 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
if (argc 2)
goto usage;
+ nand_delayed_init();
+
if (quiet_str)
quiet = simple_strtoul(quiet_str, NULL, 0) != 0;
diff --git a/common/env_nand.c b/common/env_nand.c
index 99f661e..e8be67b 100644
--- a/common/env_nand.c
+++ b/common/env_nand.c
@@ -307,6 +307,8 @@ void env_relocate_spec (void)
return use_default();
}
+ nand_delayed_init();
+
if (readenv(CONFIG_ENV_OFFSET, (u_char *) tmp_env1))
puts(No Valid Environment Area Found\n);
if (readenv(CONFIG_ENV_OFFSET_REDUND, (u_char *) tmp_env2))
@@ -347,6 +349,8 @@ void env_relocate_spec (void)
free(tmp_env1);
}
+#else
+ nand_delayed_init();
#endif /* ! ENV_IS_EMBEDDED */
}
#else /* ! CONFIG_ENV_OFFSET_REDUND */
@@ -359,12 +363,16 @@ void env_relocate_spec (void)
#if !defined(ENV_IS_EMBEDDED)
int ret;
+ nand_delayed_init();
+
ret = readenv(CONFIG_ENV_OFFSET, (u_char *) env_ptr);
if (ret)
return use_default();
if (crc32(0, env_ptr-data, ENV_SIZE) != env_ptr-crc)
return use_default();
+#else
+ nand_delayed_init();
#endif /* ! ENV_IS_EMBEDDED */
}
#endif /* CONFIG_ENV_OFFSET_REDUND */
diff --git a/drivers/mtd/nand/nand.c b/drivers/mtd/nand/nand.c
index 47d6872..42ec40a 100644
--- a/drivers/mtd/nand/nand.c
+++ b/drivers/mtd/nand/nand.c
@@ -81,6 +81,15 @@ void nand_init(void)
{
int i;
unsigned int size = 0;
+
+#ifdef CONFIG_SYS_NAND_DELAYED_INIT
+ static uint8_t initialized;
+ if (initialized)
+ return;
+ initialized = 1;
+ printf(Delayed NAND init: );
+#endif
+
for (i = 0; i CONFIG_SYS_MAX_NAND_DEVICE; i++) {
nand_init_chip(nand_info[i], nand_chip[i], base_address[i]);
size += nand_info[i].size / 1024;
diff --git a/include/nand.h b/include/nand.h
index 2a81597..939b8e7 100644
--- a/include/nand.h
+++ b/include/nand.h
@@ -25,6 +25,11 @@
#define _NAND_H_
extern void nand_init(void);
+#ifdef CONFIG_SYS_NAND_DELAYED_INIT
+# define nand_delayed_init() nand_init()
+#else
+# define nand_delayed_init() do { } while (0)
+#endif
#include linux/mtd/compat.h
#include linux/mtd/mtd.h
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] Blackfin: nand: support delayed initialization
Signed-off-by: Mike Frysinger vap...@gentoo.org --- arch/blackfin/lib/board.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/blackfin/lib/board.c b/arch/blackfin/lib/board.c index 7649f9a..02a5ee9 100644 --- a/arch/blackfin/lib/board.c +++ b/arch/blackfin/lib/board.c @@ -346,7 +346,7 @@ void board_init_r(gd_t * id, ulong dest_addr) bd-bi_flashoffset = 0; #endif -#ifdef CONFIG_CMD_NAND +#if defined(CONFIG_CMD_NAND) !defined(CONFIG_SYS_NAND_DELAYED_INIT) puts(NAND: ); nand_init();/* go init the NAND */ #endif -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cuImage and multi image?
-Original Message- From: linuxppc-dev-bounces+tiejun.chen=windriver@lists.ozlabs.or g [mailto:linuxppc-dev-bounces+tiejun.chen=windriver@lists.o zlabs.org] On Behalf Of Scott Wood Sent: Wednesday, September 22, 2010 1:53 AM To: Chen, Tiejun Cc: ppcdev; uboot Subject: Re: [U-Boot] cuImage and multi image? On Tue, 21 Sep 2010 03:03:22 +0200 Chen, Tiejun tiejun.c...@windriver.com wrote: -Original Message- From: Shawn Jin [mailto:shawnx...@gmail.com] Sent: Tuesday, September 21, 2010 1:53 AM To: Chen, Tiejun Cc: ppcdev; uboot Subject: Re: cuImage and multi image? I have a cuImage kernel in order to support legacy u-boot and a ramdisk image. Kernel boots fine if these two images are separate and bootm $kernel $ramdisk is used. But I can not make it to work using a single multi image that contains the kernel and ramdisk images. Is it even technically possible to boot a multi-image with cuboot wrapper? Try the following steps: -- 1. cp your ramdisk.gz arch/powerpc/boot/ramdisk.image.gz 2. make cuImage.initrd.your target You can get one Image, cuImage.initrd.your target, including kernel and ramdisk. A follow up question. With this method, the total image size (uncompressed) is limited to the 4MB (the link address of the boot wrapper)? No. Yes, unless you change the link address, or provide a vmlinux_alloc callback (which currently only happens on true OF, not cuImage). Unless you're talking about the (uncompressed)? The limit applies to the uncompressed boot image -- anything that the bootwrapper itself is decompressing. It does not apply to any further uncompression of the ramdisk itself. He should point the latter, the total image size, including ramdisk. But the link address should be limited for the boot Image, not for the attached ramdisk. Tiejun -Scott ___ Linuxppc-dev mailing list linuxppc-...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cmd_nand: document scrub options
The current documentation for the scrub option implies it takes no options at all. This can be annoying when you only want to scrub a few blocks and not an entire device. Good thing the code already supports this though since it takes the same arguments as the erase option. Inform people! Signed-off-by: Mike Frysinger vap...@gentoo.org --- common/cmd_nand.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/common/cmd_nand.c b/common/cmd_nand.c index 3f1d077..7c77983 100644 --- a/common/cmd_nand.c +++ b/common/cmd_nand.c @@ -593,6 +593,7 @@ U_BOOT_CMD( nand bad - show bad blocks\n nand dump[.oob] off - dump page\n nand scrub - really clean NAND erasing bad blocks (UNSAFE)\n + takes the same options as erase\n nand markbad off [...] - mark bad block(s) at offset (UNSAFE)\n nand biterr off - make a bit error at offset (UNSAFE) #ifdef CONFIG_CMD_NAND_LOCK_UNLOCK -- 1.7.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] cuImage and multi image?
A follow up question. With this method, the total image size (uncompressed) is limited to the 4MB (the link address of the boot wrapper)? No. Yes, unless you change the link address, or provide a vmlinux_alloc callback (which currently only happens on true OF, not cuImage). Unless you're talking about the (uncompressed)? The limit applies to the uncompressed boot image -- anything that the bootwrapper itself is decompressing. It does not apply to any further uncompression of the ramdisk itself. He should point the latter, the total image size, including ramdisk. But the link address should be limited for the boot Image, not for the attached ramdisk. Thanks for the clarification. Scott, so what are the things that the bootwrapper is decompressing? The kernel for sure. And anything else? I understand that the ramdisk image will be decompressed later when trying to boot it. I have a large ramdisk image. The size of the image itself (i.e. the *.gz) is about 4MB. When the ramdisk was being decompressed in the later stage. It had the following errors. It seems to me that the ramdisk image somehow was corrupted. Did the script wrapper mess up the image? Is there any known bug in the wrapper? My kernel is 2.6.33. BTW the ramdisk image can be mounted properly if it's separated from the kernel image. RAMDISK: gzip image found at block 0 uncompression error VFS: Mounted root (ext2 filesystem) readonly on device 1:0. Freeing unused kernel memory: 104k init EXT2-fs (ram0): error: ext2_check_page: bad entry in directory #336: : rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 EXT2-fs (ram0): error: remounting filesystem read-only Kernel panic - not syncing: No init found. Try passing init= option to kernel. Call Trace: [c7821f30] [c0006cd8] show_stack+0x40/0x168 (unreliable) [c7821f70] [c001cefc] panic+0x8c/0x178 [c7821fc0] [c00026d4] init_post+0xe4/0xf4 [c7821fd0] [c01ee224] kernel_init+0x108/0x130 [c7821ff0] [c000dcc0] kernel_thread+0x4c/0x68 Rebooting in 180 seconds.. Thanks, -Shawn. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
