May 2005 - U-Boot

[U-Boot-Users] Use of LCD as console
by Pankaj GOYAL 24 May '05

24 May '05

Hi, I have board in which UART is not present,so I can not get the console using the UART.But I have LCD panel present on the borad.Is is possible to use the LCD panel to act as console of the u-boot ?.If yes then can any one please tell me what changes I have to do in the u-boot to provide the console on LCD.Also please tell me if there is any interface for LCD already present in the u-boot Regards Pankaj

2 1

[U-Boot-Users] About to U-Boot Logbuffer..
by yongdae,shin 24 May '05

24 May '05

I will try the logbuffer. Can i assign the logbuffer into SDRAM? I think that it's not mean because of SDRAM is volatile memory. How to use the Logbuffer? and which memory device?

2 1

[U-Boot-Users] [PATCH 1/2] add Kendein/Micrel KS8695P CPU support
by Greg Ungerer 24 May '05

24 May '05

Hi All, Attached is a patch that adds support to u-boot for the Kendin/Micrel KS8695P CPU. It is an ARM9 based SoC type device, used in a lot of little routers. This patch was originally generated against u-boot 1.1.1. I am following up this patch with a couple of more patches that add support for the OpenGear CM4008 and CM4116/CM4148 console manager boards (that use the KS8695P CPU). Regards Greg

3 9

[U-Boot-Users] u-boot for H4-OMAP242x fix.
by Woodruff, Richard 24 May '05

24 May '05

Hello, This is not a full patch but a spot fix for those who are interested. I'd post a patch to the tree, but I'm still waiting on Wolfgang to post my last patch to the tree. So, Newer version of OMAP242x are starting to encode their production id field (current ES2.1). The code which was generated for get_cpu_type() was non-PIC and will cause a crash on newer chips which use non-zero encoding. At present the failing sequence was being used in a SRAM stack only situation where being PIC is required. Regards, Richard W.

1 0

[U-Boot-Users] MPC8548CDS pre-eTSEC 3 and 4 patch
by Jon Loeliger 23 May '05

23 May '05

Guys, So, before Andy can put the PHYs of eTSEC 3 and 4 into RGMII mode on 8548CDS systems, you have to add them to the port first. This patch must be applied _before_ Andy Flemings patch posted just a couple hours ago with no subject line. Thanks, jdl * Patch by Jon Loeliger, 23-May-2005 Add eTSEC 3 and 4 to MPC8548CDS board. Index: include/configs/MPC8548CDS.h =================================================================== RCS file: /cm/vault/u-boot/u-boot/include/configs/MPC8548CDS.h,v retrieving revision 1.1.4.2 retrieving revision 1.1.4.3 diff -u -r1.1.4.2 -r1.1.4.3 --- include/configs/MPC8548CDS.h 6 May 2005 19:47:20 -0000 1.1.4.2 +++ include/configs/MPC8548CDS.h 12 May 2005 19:57:14 -0000 1.1.4.3 @@ -370,13 +370,22 @@ #define CONFIG_MII 1 /* MII PHY management */ #define CONFIG_MPC85XX_TSEC1 1 #define CONFIG_MPC85XX_TSEC2 1 +#define CONFIG_MPC85XX_TSEC3 1 +#define CONFIG_MPC85XX_TSEC4 1 #undef CONFIG_MPC85XX_FEC + #define TSEC1_PHY_ADDR 0 #define TSEC2_PHY_ADDR 1 +#define TSEC3_PHY_ADDR 2 +#define TSEC4_PHY_ADDR 3 #define FEC_PHY_ADDR 3 + #define TSEC1_PHYIDX 0 #define TSEC2_PHYIDX 0 +#define TSEC3_PHYIDX 0 +#define TSEC4_PHYIDX 0 #define FEC_PHYIDX 0 + #define CONFIG_ETHPRIME "MOTO ENET0" #endif /* CONFIG_TSEC_ENET */ Index: net/eth.c =================================================================== RCS file: /cm/vault/u-boot/u-boot/net/eth.c,v retrieving revision 1.1.1.2.2.4 retrieving revision 1.1.1.2.2.5 diff -u -r1.1.1.2.2.4 -r1.1.1.2.2.5 --- net/eth.c 1 Feb 2005 19:17:25 -0000 1.1.1.2.2.4 +++ net/eth.c 12 May 2005 19:57:14 -0000 1.1.1.2.2.5 @@ -162,6 +162,13 @@ #endif #if defined(CONFIG_MPC85XX_FEC) tsec_initialize(bis, 2); +#else +# if defined(CONFIG_MPC85XX_TSEC3) + tsec_initialize(bis, 2); +# endif +# if defined(CONFIG_MPC85XX_TSEC4) + tsec_initialize(bis, 3); +# endif #endif #if defined(CONFIG_AU1X00) au1x00_enet_initialize(bis); Index: cpu/mpc85xx/tsec.c =================================================================== RCS file: /cm/vault/u-boot/u-boot/cpu/mpc85xx/tsec.c,v retrieving revision 1.1.1.2.2.10 retrieving revision 1.1.1.2.2.11 diff -u -r1.1.1.2.2.10 -r1.1.1.2.2.11 --- cpu/mpc85xx/tsec.c 5 May 2005 21:33:52 -0000 1.1.1.2.2.10 +++ cpu/mpc85xx/tsec.c 12 May 2005 19:57:13 -0000 1.1.1.2.2.11 @@ -82,11 +82,20 @@ #ifdef CONFIG_MPC85XX_FEC {FEC_PHY_ADDR, 0, FEC_PHYIDX}, #else +# ifdef CONFIG_MPC85XX_TSEC3 + {TSEC3_PHY_ADDR, 1, TSEC3_PHYIDX}, +# else { 0, 0, 0}, +# endif +# ifdef CONFIG_MPC85XX_TSEC4 + {TSEC4_PHY_ADDR, 1, TSEC4_PHYIDX}, +# else + { 0, 0, 0}, +# endif #endif }; -#define MAXCONTROLLERS 3 +#define MAXCONTROLLERS (4) static int relocated = 0;

1 0

[U-Boot-Users] Compiling a debug version of U-boot
by Armand Ciejak 23 May '05

23 May '05

What should I do to build a debug version of U-boot. I currently add ¨#define DEBUG¨ to the u-boot_1.1.2/include/configs/board_name.h file. Is it the right method? I building U-boot for a custom board derived from the MPC8540ADS, and when I start gdb I get a strange warning. If someone has any idea it would help! linuxcompiler:~/u-boot/u-boot_1.1.2$ ppc-linux-gdb u-boot Warning: Cannot initialize solib-absolute-prefix GNU gdb Yellow Dog Linux (5.2.1-4b_8) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux"... 0xfffffffc in ?? () (gdb) Thanks Armand Environment: - ELDK3.1 (gcc and gdb) - CROSS_COMPILE = ppc_6xx-

2 1

[U-Boot-Users] RE: Booting the Linux/ppc64 kernel without Open Firmware HOWTO(#2)
by Tzachi Perelstein 23 May '05

23 May '05

Seems like it was a *hot* weekend... Ben, I agree with Wolfgang that while taking footprint and simplicity into account we should "try to think about the whole system, including boot loader, kernel, and any data that might need to get passed between these two". My ppc64 Linux is booted from U-Boot on Marvell platform and it uses the simple board_info instead of the device-tree. There are only some minor hacks in arch files that by-pass the whole device-tree usage in head.S and setup.c, e.g. [1] early_init_board_info() instead of early_init_devtree(), and [2] skipping on unflatten_device_tree() and finish_device_tree(). As you know, the majority of these functions and sub-functions just parse and handle the device-tree. Frankly, although I'm willing to give device-tree a try, I think it is not the wise thing to do. It is simple and effective, and it can be nicer with minor _general_ support in arch files to non-OF loaders. A slightly different loading for embedded systems is not necessarily a mess. I'm sure that the ppc experience will make it be nice and structured even this way. Imagine emerging ppc64 Linux embedded systems living outside the kernel due to embedded incompatibilities; this might make much more mess in the long run... Best Regards, Tzachi

3 2

[U-Boot-Users] Unable to store environment variables
by v.sudeep＠exgate.tek.com 23 May '05

23 May '05

Hello, I am a newbie to U-Boot. I am in the process of trying to load linux on the MPC8266ADS-PCI board. I compiled the u-boot code and flashed it in. The U-Boot comes up. But I am unable to save any of the environmental variables. What should I be looking for ?? And what are the changes that I should be doing. Please suggest. Details are as below. - S u d e e p V A system of morality which is based on relative emotional values is a mere illusion, a thoroughly vulgar conception which has nothing sound in it and nothing true. -Socrates. After power on the initial u-boot prompt looks like this: => reset U-Boot 1.1.2 (May 23 2005 - 14:24:36) MPC8260 Reset Status: Check Stop, External Soft, External Hard MPC8260 Clock Configuration - Bus-to-Core Mult 3x, VCO Div 2, 60x Bus Freq 33-100, Core Freq 100-300 - dfbrg 0, corecnf 0x08, busdf 3, cpmdf 1, plldf 0, pllmf 1 - vco_out 264000000, scc_clk 66000000, brg_clk 66000000 - cpu_clk 198000000, cpm_clk 132000000, bus_clk 66000000 - pci_clk 66000000 CPU: MPC8260 (HiP4 Rev 14, Mask A.0(A) 2K25A) at 198 MHz Board: Motorola MPC8266ADS I2C: ready DRAM: SDRAM configuration read from SPD Size per side = 16MB Organization: 1 sides, 2 banks, 9 Columns, 11 Rows, Data width = 64 bits Refresh rate = 33, CAS latency = 2, Using Bank Based Interleave Total size: 16 MB FLASH: 8 MB *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Net: FCC2 ETHERNET Hit any key to stop autoboot: 0 U-Boot 1.1.2 (May 23 2005 - 14:24:36) *** ERROR: `ethaddr' not set ## Booting image at 00100000 ... Bad Magic Number Now => bdinfo memstart = 0x00000000 memsize = 0x01000000 flashstart = 0xFE000000 flashsize = 0x00800000 flashoffset = 0x00000000 sramstart = 0x00000000 sramsize = 0x00000000 immr_base = 0xF0000000 bootflags = 0x00000001 vco = 264 MHz sccfreq = 66 MHz brgfreq = 66 MHz intfreq = 198 MHz cpmfreq = 132 MHz busfreq = 66 MHz ethaddr = 00:00:00:00:00:00 IP addr = 0.0.0.0 baudrate = 115200 bps => flinfo Bank # 1: Sharp 28F016SC (16 Mbit, 32 x 64K) Size: 8 MB in 32 Sectors Sector Start Addresses: FE000000 FE040000 FE080000 FE0C0000 FE100000 FE140000 FE180000 FE1C0000 FE200000 FE240000 FE280000 FE2C0000 FE300000 FE340000 FE380000 FE3C0000 FE400000 FE440000 FE480000 FE4C0000 FE500000 FE540000 FE580000 FE5C0000 FE600000 FE640000 FE680000 FE6C0000 FE700000 FE740000 FE780000 FE7C0000 => printenv bootcmd=version;echo;bootp;setenv bootargs root=/dev/nfs rw nfsroot=$(serverip)mbootdelay=5 baudrate=115200 stdin=serial stdout=serial stderr=serial ethact=FCC2 ETHERNET Environment size: 254/262140 bytes => saveenv Saving Environment to Flash... Error: start and/or end address not on sector boundary

2 1

[U-Boot-Users] Microcode patches for mpc8xx
by Vladimir A. Gurevich 23 May '05

23 May '05

Hello, I have a couple of questions about RAM microcode patches for MPC8xx CPUs: 1. What is EXACTLY the patch in cpu/mpc8xx/upatch.c. Specifically, which CPU(s) it is applicable to? I looked at a couple of recent patches available at Freescale website and none of them resembles the stuff in upatch.c 2. My impression is that different CPUs need different patches. I can at least see patches for MPC823, MPC850, MPC860 and MPC862. That means that we probably need to check not only CFG_*_UCODE_PATCH, but also the corresponding CONFIG_ variable for the CPU. I am about to add the appropriate patch for my board, and thus I have to #ifdef the older one and I'd better do it right. 3. I noticed that there is special handling for SPI and I2C, but how about SMC? I use SCC3 in the ethernet mode and SMC1 as a console and definitely have a problem. (A simple change to scc.c seems to have fixed the problem for now, but I'd like to have a cleaner solution). 4. Finally, what is the assumption about Linux. Is it supposed to reset the CP and reload the patches? Thanks, Vladimir

4 7

[U-Boot-Users] Can MPC processors boot though the IMMR is at 0x0 (default configuration)?
by Peter Asemann 22 May '05

22 May '05

I'm going to try booting u-boot on a custom MPC875 board. It has flash at the boot memory bank (bank 0). It has no circuit to pull up pin 7/8 of the MPC data bus at processor start, so (the manual says) the IMMR/the internal memory is configured to reside at 0x0. I think this causes the internal memory to shadow the boot flash, which should prevent the board from booting. At least the internal memory shadows the boot memory bank in the debugger. That's why I was planning to solder some circuit to the board to configure the internal memory to be somewhere else at startup. The board designer says he can't believe the MPC875 default configuration is like that boards which use it can't boot. So - does someone incidentally know something about MPC default configurations and if MPCs can boot though the IMMR is at 0x0? And if they can't, why the IMMR is at 0x0 by default? Thanks for reading, Peter Asemann

4 3

[U-Boot-Users] [Newbie]: mpc8260ads and u-boot
by eagle keeper 21 May '05

21 May '05

Sorry for a so newbie question. I tried to search trough the docs about u-boot and did not found any problem similar to mine. Then, since i am moving just first steps in this kind of projects, i tried to send a mail to get help. The problem is simple: i compiled u-boot for my target, i erased all the flash, i downloaded the bin image on the target flash, i disconnected the lauterbach t32, turned off the board, connected the serial, and turned on again the board. I expected to see uboot menu, instead just nothing. "Run" led is always turned on, while "RS232" led is always off. Since i don't know what to think, what should i investigate to find out the problem? How can it be solved? Txn in advance, Lele

2 1

[U-Boot-Users] Newbie: gdb and BDI2000
by Armand Ciejak 20 May '05

20 May '05

Hello, Here my problem: I want to debug u-boot for a custom board based on the MPC8540 CPU. The board I'm working on is actually from Metrowerks (EVAL8540), which is similar to the MPC8540ADS. I got the source of u-boot 1.1.2 and modified the MPC8540ADS configuration (Memory size, ...). I compiled uboot with the debug option (I add a defined in the u-boot_1.1.2/include/configs/board_name.h file). Obviously after copying the u-boot.bin to the flash memory via the BDI2000, the sytem doesn't start: no output on the serial port!!! My problem is that I can't really debug, here a typical session: armand@linuxcompiler:~/u-boot/u-boot_1.1.2$ ppc-linux-gdb u-boot Warning: Cannot initialize solib-absolute-prefix GNU gdb Yellow Dog Linux (5.2.1-4b_8) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i386-redhat-linux --target=ppc-linux"... 0xfffffffc in ?? () (gdb) si 0xfffff000 65 blr (gdb) 0xfffff004 65 blr (gdb) 0xfffff008 in _start_e500 () at /home/armand/u-boot/u-boot_1.1.2/lib_ppc/ticks.S:65 65 blr (gdb) 0xfffff00c in _start_e500 () at /home/armand/u-boot/u-boot_1.1.2/lib_ppc/ticks.S:65 65 blr (gdb) 0xfffff010 65 blr . . . (gdb) 0xfffff140 65 blr (gdb) 0xfffff144 in _start_e500 () at /home/armand/u-boot/u-boot_1.1.2/lib_ppc/ticks.S:65 65 blr (gdb) 0xfffff148 65 blr (gdb) 0xfffff14c 65 blr (gdb) 0xfffff150 65 blr (gdb) Program received signal SIGSTOP, Stopped (signal). 0x00000000 in ?? () (gdb) I think I'm doing something wrong but what ??? thanks Armand More info: - ppc-linux-gdb installed from the ELDK 3.1 - BDI2000 for MPC85xx rev C with the latest firmware - cross compiler from ELDK 3.1

2 2

[U-Boot-Users] U-boot hello_world won't link.
by Goedde Kirby (TTE) 20 May '05

20 May '05

I'm new to the group; I am sure someone has asked this question before, but I can't find an answer. I am using the ARM9 based TVP9000 processor. When I try to make the /examples directory of u-boot I get the following errors. I assume I am missing some dependencies in my make file. Has anyone else gotten this to work on the ARM processor? ______________________________________________________________________________________________ make[1]: Entering directory `/cygdrive/c/cygwin/opt/u-boot-1.1.1/examples' armv4tb-softfloat-linux-gnu-ld -g -Ttext 0xc100000 \ -o hello_world -e hello_world hello_world.o libstubs.a \ -L/opt/toolchain/armv4tb-softfloat-linux-gnu/gcc-3.4.0-glibc-2.3.2/bin/../lib/gcc/armv4tb-softfloat-linux-gnu/3.4.0 -lgcc hello_world.o(.text+0x1c): In function 'hello_world': /cygdrive/c/cygwin/opt/u-boot-1.1.1/examples/hello_world.c:33: undefined reference to 'printf' hello_world.o(.text+0x20):/cygdrive/c/cygwin/opt/u-boot-1.1.1/examples/hello_world.c:34: undefined reference to 'get_version' hello_world.o(.text+0x2c):/cygdrive/c/cygwin/opt/u-boot-1.1.1/examples/hello_world.c:34: undefined reference to 'printf' hello_world.o(.text+0x34):/cygdrive/c/cygwin/opt/u-boot-1.1.1/examples/hello_world.c:36: undefined reference to 'printf' hello_world.o(.text+0x44):/cygdrive/c/cygwin/opt/u-boot-1.1.1/examples/hello_world.c:38: undefined reference to 'printf' hello_world.o(.text+0x6c):/cygdrive/c/cygwin/opt/u-boot-1.1.1/examples/hello_world.c:41: undefined reference to 'printf' hello_world.o(.text+0x78):/cygdrive/c/cygwin/opt/u-boot-1.1.1/examples/hello_world.c:46: undefined reference to 'printf' hello_world.o(.text+0x7c):/cygdrive/c/cygwin/opt/u-boot-1.1.1/examples/hello_world.c:47: undefined reference to 'tstc' hello_world.o(.text+0x88):/cygdrive/c/cygwin/opt/u-boot-1.1.1/examples/hello_world.c:50: undefined reference to 'getc' hello_world.o(.text+0x90):/cygdrive/c/cygwin/opt/u-boot-1.1.1/examples/hello_world.c:52: undefined reference to 'printf' make[1]: ***[hello_world] Error 1 make[1]: Leaving directory '/cygdrive/c/cygwin/opt/u-boot-1.1.1/examples' make: *** [examples] Error 2

1 0

[U-Boot-Users] RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO
by Benjamin Herrenschmidt 20 May '05

20 May '05

Hi ! Here's the very first draft of my HOWTO about booting the linux/ppc64 kernel without open firmware. It's still incomplete, the main chapter describing which nodes & properties are required and their format is still missing (though it will basically be a subset of the Open Firmware specification & bindings). The format of the flattened device-tree is documented. It's a first draft, so please, don't be too harsh :) Comments are welcome. Booting the Linux/ppc64 kernel without Open Firmware ---------------------------------------------------- (c) 2005 Benjamin Herrenschmidt <benh(a)kernel.crashing.org>, IBM Corp. May 18, 2005: Rev 0.1 - Initial draft, no chapter III yet. I- Introduction =============== During the recent developpements of the Linux/ppc64 kernel, and more specifically, the addition of new platform types outside of the old IBM pSeries/iSeries pair, it was decided to enforce some strict rules regarding the kernel entry and bootloader <-> kernel interfaces, in order to avoid the degeneration that has become the ppc32 kernel entry point and the way a new platform should be added to the kernel. The legacy iSeries platform breaks those rules as it predates this scheme, but no new board support will be accepted in the main tree that doesn't follows them properly. 1) Entry point -------------- There is one and one single entry point to the kernel, at the start of the kernel image. That entry point support two calling conventions: a) Boot from Open Firmware. If your firmware is compatible with Open Firmware (IEEE 1275) or provides an OF compatible client interface API (support for "interpret" callback of forth words isn't required), you can enter the kernel with: r5 : OF callback pointer as defined by IEEE 1275 bindings to powerpc. Only the 32 bits client interface is currently supported r3, r4 : address & lenght of an initrd if any or 0 MMU is either on or off, the kernel will run the trampoline located in arch/ppc64/kernel/prom_init.c to extract the device-tree and other informations from open firmware and build a flattened device-tree as described in b). prom_init() will then re-enter the kernel using the second method. This trampoline code runs in the context of the firmware, which is supposed to handle all exceptions during that time. b) Direct entry with a flattened device-tree block. This entry point is called by a) after the OF trampoline and can also be called directly by a bootloader that does not support the Open Firmware client interface. It is also used by "kexec" to implement "hot" booting of a new kernel from a previous running one. This method is what I will describe in more details in this document, as method a) is simply standard Open Firmware, and thus should be implemented according to the various standard documents defining it and it's binding to the PowerPC platform. The entry point definition then becomes: r3 : physical pointer to the device-tree block (defined in chapter II) r4 : physical pointer to the kernel itself. This is used by the assembly code to properly disable the MMU in case you are entering the kernel with MMU enabled and a non-1:1 mapping. r5 : NULL (as to differenciate with method a) 2) Board support ---------------- Board supports (platforms) are not exclusive config options. An arbitrary set of board supports can be built in a single kernel image. The kernel will "known" what set of functions to use for a given platform based on the content of the device-tree. Thus, you should: a) add your platform support as a _boolean_ option in arch/ppc64/Kconfig, following the example of PPC_PSERIES, PPC_PMAC and PPC_MAPLE. The later is probably a good example of a board support to start from. b) create your main platform file as "arch/ppc64/kernel/myboard_setup.c" and add it to the Makefile under the condition of your CONFIG_ option. This file will define a structure of type "ppc_md" containing the various callbacks that the generic code will use to get to your platform specific code c) Add a reference to your "ppc_md" structure in the "machines" table in arch/ppc64/kernel/setup.c d) request and get assigned a platform number (see PLATFORM_* constants in include/asm-ppc64/processor.h I will describe later the boot process and various callbacks that your platform should implement. II - The DT block format =========================== This chapter defines the actual format of the flattened device-tree passed to the kernel. The actual content of it and kernel requirements are described later. You can find example of code manipulating that format in various places, including arch/ppc64/kernel/prom_init.c which will generate a flattened device-tree from the Open Firmware representation, or the fs2dt utility which is part of the kexec tools which will generate one from a filesystem representation. It is expected that a bootloader like uboot provides a bit more support, that will be discussed later as well. 1) Header --------- The kernel is entered with r3 pointing to an area of memory that is roughtly described in include/asm-ppc64/prom.h by the structure boot_param_header: struct boot_param_header { u32 magic; /* magic word OF_DT_HEADER */ u32 totalsize; /* total size of DT block */ u32 off_dt_struct; /* offset to structure */ u32 off_dt_strings; /* offset to strings */ u32 off_mem_rsvmap; /* offset to memory reserve map */ u32 version; /* format version */ u32 last_comp_version; /* last compatible version */ /* version 2 fields below */ u32 boot_cpuid_phys; /* Which physical CPU id we're booting on */ }; Along with the constants: /* Definitions used by the flattened device tree */ #define OF_DT_HEADER 0xd00dfeed /* 4: version, 4: total size */ #define OF_DT_BEGIN_NODE 0x1 /* Start node: full name */ #define OF_DT_END_NODE 0x2 /* End node */ #define OF_DT_PROP 0x3 /* Property: name off, size, content */ #define OF_DT_END 0x9 All values in this header are in big endian format, the various fields in this header are defined more precisely below. All "offsets" values are in bytes from the start of the header, that is from r3 value. - magic This is a magic value that "marks" the beginning of the device-tree block header. It contains the value 0xd00dfeed and is defined by the constant OF_DT_HEADER - totalsize This is the total size of the DT block including the header. The "DT" block should enclose all data structures defined in this chapter (who are pointed to by offsets in this header). That is, the device-tree structure, strings, and the memory reserve map. - off_dt_struct This is an offset from the beginning of the header to the start of the "structure" part the device tree. (see 2) device tree) - off_dt_strings This is an offset from the beginning of the header to the start of the "strings" part of the device-tree - off_mem_rsvmap This is an offset from the beginning of the header to the start of the reserved memory map. This map is a list of pairs of 64 bits integers. Each pair is a physical address and a size. The list is terminated by an entry of size 0. This map provides the kernel with a list of physical memory areas that are "reserved" and thus not to be used for memory allocations, especially during early initialisation. The kernel needs to allocate memory during boot for things like un-flattening the device-tree, allocating an MMU hash table, etc... Those allocations must be done in such a way to avoid overriding critical things like, on Open Firmware capable machines, the RTAS instance, or on some pSeries, the TCE tables used for the iommu. Typically, the reserve map should contain _at least_ this DT block itself (header,total_size). If you are passing an initrd to the kernel, you should reserve it as well. You do not need to reserve the kernel image itself. The map should be 64 bits aligned. - version This is the version of this structure. Version 1 stops here. Version 2 adds an additional field boot_cpuid_phys. You should always generate a structure of the highest version defined at the time of your implementation. That is version 2. - last_comp_version Last compatible version. This indicates down to what version of the DT block you are backward compatible with. For example, version 2 is backward compatible with version 1 (that is, a kernel build for version 1 will be able to boot with a version 2 format). You should put a 1 in this field unless a new incompatible version of the DT block is defined. - boot_cpuid_phys This field only exist on version 2 headers. It indicate which physical CPU ID is calling the kernel entry point. This is used, among others, by kexec. If you are on an SMP system, this value should match the content of the "reg" property of the CPU node in the device-tree corresponding to the CPU calling the kernel entry point (see further chapters for more informations on the required device-tree contents) So the typical layout of a DT block (though the various parts don't need to be in that order) looks like (addresses go from top to bottom): ------------------------------ r3 -> | struct boot_param_header | ------------------------------ | (alignment gap) (*) | ------------------------------ | memory reserve map | ------------------------------ | (alignment gap) | ------------------------------ | | | device-tree structure | | | ------------------------------ | (alignment gap) | ------------------------------ | | | device-tree strings | | | -----> ------------------------------ | | --- (r3 + totalsize) (*) The alignment gaps are not necessarily present, their presence and size are dependent on the various alignment requirements of the individual data blocks. 2) Device tree generalities --------------------------- This device-tree itself is separated in two different blocks, a structure block and a strings block. Both need to be page aligned. First, let's quickly describe the device-tree concept before detailing the storage format. This chapter does _not_ describe the detail of the required types of nodes & properties for the kernel, this is done later in chapter III. The device-tree layout is strongly inherited from the definition of the Open Firmware IEEE 1275 device-tree. It's basically a tree of nodes, each node having two or more named properties. A property can have a value or not. It is a tree, so each node has one and only one parent except for the root node who has no parent. A node has 2 names. The actual node name is contained in a property of type "name" in the node property list whose value is a zero terminated string and is mandatory. There is also a "unit name" that is used to differenciate nodes with the same name at the same level, it is usually made of the node name's, the "@" sign, and a "unit address", which definition is specific to the bus type the node sits on. The unit name doesn't exist as a property per-se but is included in the device-tree structure. It is typically used to represent "path" in the device-tree. More details about these will be provided later. The kernel ppc64 generic code does not make any formal use of the unit address though (though some board support code may do) so the only real requirement here for the unit address is to ensure uniqueness of the node unit name at a given level. Nodes with no notion of address and no possible sibling of the same name (like /memory or /cpus) may ommit the unit address in the context of this specification, or use the "@0" default unit address. The unit name is used to define a node "full path", which is the concatenation of all parent nodes unit names separated with "/". The root node is defined as beeing named "device-tree" and has no unit address (no @ symbol followed by a unit address). When manipulating device-tree "path", the root of the tree is generally represented by a simple slash sign "/". Every node who actually represents an actual device (that is who isn't only a virtual "container" for more nodes, like "/cpus" is) is also required to have a "device_type" property indicating the type of node Finally, every node is required to have a "linux,phandle" property. Real open firmware implementations don't provide it as it's generated on the fly by the prom_init.c trampoline from the Open Firmware "phandle". Implementations providing a flattened device-tree directly should provide this property. This propery is a 32 bits value that uniquely identify a node. You are free to use whatever values or system of values, internal pointers, or whatever to genrate these, the only requirement is that every single node of the tree you are passing to the kernel has a unique value in this property. This can be used in some cases for nodes to reference other nodes. Here is an example of a simple device-tree. In this example, a "o" designates a node followed by the node unit name. Properties are presented with their name followed by their content. "content" represent an ASCII string (zero terminated) value, while <content> represent a 32 bits hexadecimal value. The various nodes in this example will be discusse in a later chapter. At this point, it is only meant to give you a idea of what a device-tree looks like / o device-tree |- name = "device-tree" |- model = "MyBoardName" |- compatible = "MyBoardFamilyName" |- #address-cells = <2> |- #size-cells = <2> |- linux,phandle = <0> | o cpus | | - name = "cpus" | | - linux,phandle = <1> | | | o PowerPC,970@0 | |- name = "PowerPC,970" | |- device_type = "cpu" | |- reg = <0> | |- clock-frequency = <5f5e1000> | |- linux,boot-cpu | |- linux,phandle = <2> | o memory@0 | |- name = "memory" | |- device_type = "memory" | |- reg = <00000000 00000000 00000000 20000000> | |- linux,phandle = <3> | o chosen |- name = "chosen" |- bootargs = "root=/dev/sda2" |- linux,platform = <00000600> |- linux,phandle = <4> This tree is an example of a minimal tree. It pretty much contains the minimal set of required nodes and properties to boot a linux kernel, that is some basic model informations at the root, the CPUs, the physical memory layout, and misc informations passed through /chosen like in this example, the platform type (mandatory) and the kernel command line arguments (optional). The /cpus/PowerPC,970@0/linux,boot-cpu property is an example of a property without a value. All other properties have a value. The signification of the #address-cells and #size-cells properties will be explained in chapter IV which defines precisely the required nodes and properties and their content. 3) Device tree "structure" block The structure of the device tree is a linearized tree structure. The "OF_DT_BEGIN_NODE" token starts a new node, and the "OF_DT_END" ends that node definition. Child nodes are simply defined before "OF_DT_END" (that is nodes within the node). A 'token' is a 32 bits value. Here's the basic structure of a single node: * token OF_DT_BEGIN_NODE (that is 0x00000001) * node full path as a zero terminated string * [align gap to next 4 bytes boundary] * for each property: * token OF_DT_PROP (that is 0x00000003) * 32 bits value of property value size in bytes (or 0 of no value) * 32 bits value of offset in string block of property name * [align gap to either next 4 bytes boundary if the property value size is less or equal to 4 bytes, or to next 8 bytes boundary if the property value size is larger than 4 bytes] * property value data if any * [align gap to next 4 bytes boundary] * [child nodes if any] * token OF_DT_END (that is 0x00000002) So the node content can be summmarised as a start token, a full path, a list of properties, a list of child node and an end token. Every child node is a full node structure itself as defined above 4) Device tree 'strings" block In order to save space, property names, which are generally redundant, are stored separately in the "strings" block. This block is simply the whole bunch of zero terminated strings for all property names concatenated together. The device-tree property definitions in the structure block will contain offset values from the beginning of the strings block. III - Required content of the device tree ========================================= < to be written > IV - Recommendation for a bootloader ==================================== Here are some various ideas/recommendations that have been proposed while all this has been defined and implemented. - It should be possible to write a parser that turns an ASCII representation of a device-tree (or even XML though I find that less readable) into a device-tree block. This would allow to basically build the device-tree structure and strings "blobs" at bootloader build time, and have the bootloader just pass-them as-is to the kernel. In fact, the device-tree blob could be then separate from the bootloader itself, an be placed in a separate portion of the flash that can be "personalized" for different board types by flashing a different device-tree - A very The bootloader may want to be able to use the device-tree itself and may want to manipulate it (to add/edit some properties, like physical memory size or kernel arguments). At this point, 2 choices can be made. Either the bootloader works directly on the flattened format, or the bootloader has it's own internal tree representation with pointers (similar to the kernel one) and re-flattens the tree when booting the kernel. The former is a bit more difficult to edit/modify, the later requires probably a bit more code to handle the tree structure. Note that the structure format has been designed so it's relatively easy to "insert" properties or nodes or delete them by just memmovin'g things around. It contains no internal offsets or pointers for this purpose. - An example of code for iterating nodes & retreiving properties directly from the flattened tree format can be found in the kernel file arch/ppc64/kernel/prom.c, look at scan_flat_dt() function, it's usage in early_init_devtree(), and the corresponding various early_init_dt_scan_*() callbacks. That code can be re-used in a GPL device-tree, and as the author of that code, I would be happy do discuss possible free licencing to any vendor who wishes to integrate all or part of this code into a non-GPL bootloader.

12 31

[U-Boot-Users] Marking the bad blocks in nand
by Pankaj GOYAL 20 May '05

20 May '05

HI, I m using the u-boot for my arm926-ejs processor based board.And I m using the 32MB NAND flash of STMicroelectronics on my board.When I use the "nand erase" command to erase the content of the NAND flash I observe that during the erasing if u-boot is unable to erase one of the block ( the error is genrated by uboot "Error erasing at " )it immidiatly comes out of the while loop and do not try to erase further blocks(Reffering to nand_erase function of the u-boot/common/cmd_nand.c file).Isn't u-boot should mark this block as badblock (Because u-boot is getting error in erasing the block) and instead of going out of the while loop it should try to erase the futher blocks.Please provide ur feedback. Regards Pankaj

1 0

[U-Boot-Users] [PATCH] support for CONFIG_SERIAL_TAG on ARM boards
by Steven Scholz 20 May '05

20 May '05

Hi, please consider this: * Patch by Steven Scholz, 19 May 2005: Add support for CONFIG_SERIAL_TAG on ARM baords If someone wants to pass the board's serial number to the ARM linux kernel using the ATAG_SERIAL mechanism, all she has to do is #define CONFIG_REVISION_TAG in the board config file and implement a trivial, board specific #ifdef CONFIG_SERIAL_TAG void get_board_serial(struct tag_serialnr *serialnr) { serialnr->low = (u32) sernum; serialnr->high= (u32) 0; } #endif Same goes for CONFIG_REVISION_TAG. Thanks a million! -- Steven Scholz imc Measurement & Control Index: u-boot/lib_arm/armlinux.c =================================================================== RCS file: /cvsroot/u-boot/u-boot/lib_arm/armlinux.c,v retrieving revision 1.16 diff -u -r1.16 armlinux.c --- u-boot/lib_arm/armlinux.c 12 Jan 2005 00:15:17 -0000 1.16 +++ u-boot/lib_arm/armlinux.c 19 May 2005 14:12:07 -0000 @@ -377,15 +377,30 @@ } #endif /* CONFIG_VFD || CONFIG_LCD */ +#ifdef CONFIG_SERIAL_TAG +void setup_serial_tag (struct tag **tmp) +{ + struct tag *params = *tmp; + struct tag_serialnr serialnr; + void get_board_serial(struct tag_serialnr *serialnr); + + get_board_serial(&serialnr); + params->hdr.tag = ATAG_SERIAL; + params->hdr.size = tag_size (tag_serialnr); + params->u.serialnr.low = serialnr.low; + params->u.serialnr.high= serialnr.high; + params = tag_next (params); + *tmp = params; +} +#endif + #ifdef CONFIG_REVISION_TAG void setup_revision_tag(struct tag **in_params) { u32 rev = 0; -#ifdef CONFIG_OMAP2420H4 u32 get_board_rev(void); rev = get_board_rev(); -#endif params->hdr.tag = ATAG_REVISION; params->hdr.size = tag_size (tag_revision); params->u.revision.rev = rev;

2 1

[U-Boot-Users] Some (minor?) SDRAM problems
by Peter Asemann 19 May '05

19 May '05

I'm having problems with the SDRAM of my custom board. I'm not yet running u-boot but testing the SDRAM setup with a debugger. Basically it works. The problem also seems not to be a refresh problem: 1) If something is in the memory, the memory contents don't fade or change 2) Writing to memory seems to flip some bits, the faster the clock is, the more, it seems 3) Reading from memory also faciliates bit errors from time to time, but much less than writing to memory I've tested this by writing a few KByte of text into the SDRAM and then reading it back, comparing the two files and counting the number of changed bytes with cmp -b -l <file1> <file2> | wc The result is that about 15% of the bytes are corrupted after writing the file two memory and reading it back. If I read out the data from memory multiple times and compare the results of the reads, there is only a minor difference of about 1%. That's why I think the writing is the main problem. I don't use burst reads/writes, only single reads/writes. Any suggestions what is the probable reason for this behaviour? I'm using an MPC875, programmed with microcode from a Micron SDRAM interfacing example + self-made SDRAM setup code. Best regards, Peter Asemann

1 0

[U-Boot-Users] [PATCH] add OpenGear CM4116/CM4148 board support
by Greg Ungerer 19 May '05

19 May '05

Hi All, Attached is a patch that adds support to u-boot for the OpenGear CM4116 and CM4148 serial port console manager boards. They are built around the KS8695P CPU, with 16 or 48 serial ports, 32MB RAM, and 16MB NOR flash. This patch was originally generated against u-boot 1.1.1. Regards Greg diff -Naur --exclude=CVS u-boot-1.1.1/board/cm41xx/cm41xx.c u-boot/board/cm41xx/cm41xx.c --- u-boot-1.1.1/board/cm41xx/cm41xx.c 1970-01-01 10:00:00.000000000 +1000 +++ u-boot/board/cm41xx/cm41xx.c 2005-05-04 22:47:17.230315856 +1000 @@ -0,0 +1,101 @@ +/* + * (C) Copyright 2005 + * Greg Ungerer, OpenGear Inc, <greg.ungerer(a)opengear.com> + * + * (C) Copyright 2002 + * Kyle Harris, Nexus Technologies, Inc. kharris(a)nexus-tech.net + * + * (C) Copyright 2002 + * Sysgo Real-Time Solutions, GmbH <www.elinos.com> + * Marius Groeger <mgroeger(a)sysgo.de> + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include <common.h> +#include <asm/arch/platform.h> + +/* ------------------------------------------------------------------------- */ + +#define ks8695_read(a) *((volatile unsigned int *) (KS8695_IO_BASE+(a))) +#define ks8695_write(a,b) *((volatile unsigned int *) (KS8695_IO_BASE+(a))) = (b) + +/* ------------------------------------------------------------------------- */ + + +/* + * Miscelaneous platform dependent initialisations + */ +int env_flash_cmdline (void) +{ + unsigned char *sp = (unsigned char *) 0x0201c020; + unsigned char *ep; + int len; + + /* Check if "erase" push button is depressed */ + if ((ks8695_read(KS8695_GPIO_DATA) & 0x8) == 0) { + printf("### Entering network recovery mode...\n"); + setenv("bootargs", "console=ttyAM0,115200 mem=32M initrd=0x400000,8M root=/dev/ram0"); + setenv("bootcmd", "bootp 0x400000; gofsk 0x400000"); + setenv("bootdelay", "2"); + return 0; + } + + /* Check for flash based kernel boot args to use as default */ + for (ep = sp, len = 0; ((len < 1024) && (*ep != 0)); ep++, len++) + ; + + if ((len > 0) && (len <1024)) + setenv("bootargs", sp); + + return 0; +} + +int board_late_init (void) +{ + return 0; +} + + +int board_init (void) +{ + DECLARE_GLOBAL_DATA_PTR; + + /* arch number of CM41xx */ + gd->bd->bi_arch_number = 672; + + /* adress of boot parameters */ + gd->bd->bi_boot_params = 0x00000100; + + /* power down all but port 0 on the switch */ + ks8695_write(KS8695_SWITCH_LPPM12, 0x00000005); + ks8695_write(KS8695_SWITCH_LPPM34, 0x00050005); + + return 0; +} + +int dram_init (void) +{ + DECLARE_GLOBAL_DATA_PTR; + + gd->bd->bi_dram[0].start = PHYS_SDRAM_1; + gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE; + + return (0); +} diff -Naur --exclude=CVS u-boot-1.1.1/board/cm41xx/config.mk u-boot/board/cm41xx/config.mk --- u-boot-1.1.1/board/cm41xx/config.mk 1970-01-01 10:00:00.000000000 +1000 +++ u-boot/board/cm41xx/config.mk 2005-01-19 23:54:55.000000000 +1000 @@ -0,0 +1 @@ +TEXT_BASE = 0x00f00000 diff -Naur --exclude=CVS u-boot-1.1.1/board/cm41xx/flash.c u-boot/board/cm41xx/flash.c --- u-boot-1.1.1/board/cm41xx/flash.c 1970-01-01 10:00:00.000000000 +1000 +++ u-boot/board/cm41xx/flash.c 2005-01-19 23:54:55.000000000 +1000 @@ -0,0 +1,409 @@ +/* + * (C) Copyright 2005 + * Greg Ungerer, OpenGear Inc, greg.ungerer(a)opengear.com + * + * (C) Copyright 2001 + * Kyle Harris, Nexus Technologies, Inc. kharris(a)nexus-tech.net + * + * (C) Copyright 2001 + * Wolfgang Denk, DENX Software Engineering, wd(a)denx.de. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include <common.h> +#include <linux/byteorder/swab.h> + + +flash_info_t flash_info[CFG_MAX_FLASH_BANKS]; /* info for FLASH chips */ + +#define mb() __asm__ __volatile__ ("" : : : "memory") + +/*----------------------------------------------------------------------- + * Functions + */ +static ulong flash_get_size (unsigned char * addr, flash_info_t * info); +static int write_data (flash_info_t * info, ulong dest, unsigned char data); +static void flash_get_offsets (ulong base, flash_info_t * info); +void inline spin_wheel (void); + +/*----------------------------------------------------------------------- + */ + +unsigned long flash_init (void) +{ + int i; + ulong size = 0; + + for (i = 0; i < CFG_MAX_FLASH_BANKS; i++) { + switch (i) { + case 0: + flash_get_size ((unsigned char *) PHYS_FLASH_1, &flash_info[i]); + flash_get_offsets (PHYS_FLASH_1, &flash_info[i]); + break; + case 1: + /* ignore for now */ + flash_info[i].flash_id = FLASH_UNKNOWN; + break; + default: + panic ("configured too many flash banks!\n"); + break; + } + size += flash_info[i].size; + } + + /* Protect monitor and environment sectors + */ + flash_protect (FLAG_PROTECT_SET, + CFG_FLASH_BASE, + CFG_FLASH_BASE + _bss_start - _armboot_start, + &flash_info[0]); + + return size; +} + +/*----------------------------------------------------------------------- + */ +static void flash_get_offsets (ulong base, flash_info_t * info) +{ + int i; + + if (info->flash_id == FLASH_UNKNOWN) + return; + + if ((info->flash_id & FLASH_VENDMASK) == FLASH_MAN_INTEL) { + for (i = 0; i < info->sector_count; i++) { + info->start[i] = base + (i * PHYS_FLASH_SECT_SIZE); + info->protect[i] = 0; + } + } +} + +/*----------------------------------------------------------------------- + */ +void flash_print_info (flash_info_t * info) +{ + int i; + + if (info->flash_id == FLASH_UNKNOWN) { + printf ("missing or unknown FLASH type\n"); + return; + } + + switch (info->flash_id & FLASH_VENDMASK) { + case FLASH_MAN_INTEL: + printf ("INTEL "); + break; + default: + printf ("Unknown Vendor "); + break; + } + + switch (info->flash_id & FLASH_TYPEMASK) { + case FLASH_28F128J3A: + printf ("28F128J3A\n"); + break; + default: + printf ("Unknown Chip Type\n"); + break; + } + + printf (" Size: %ld MB in %d Sectors\n", + info->size >> 20, info->sector_count); + + printf (" Sector Start Addresses:"); + for (i = 0; i < info->sector_count; ++i) { + if ((i % 5) == 0) + printf ("\n "); + printf (" %08lX%s", + info->start[i], info->protect[i] ? " (RO)" : " "); + } + printf ("\n"); + return; +} + +/* + * The following code cannot be run from FLASH! + */ +static ulong flash_get_size (unsigned char * addr, flash_info_t * info) +{ + volatile unsigned char value; + + /* Write auto select command: read Manufacturer ID */ + addr[0x5555] = 0xAA; + addr[0x2AAA] = 0x55; + addr[0x5555] = 0x90; + + mb (); + value = addr[0]; + + switch (value) { + + case (unsigned char)INTEL_MANUFACT: + info->flash_id = FLASH_MAN_INTEL; + break; + + default: + info->flash_id = FLASH_UNKNOWN; + info->sector_count = 0; + info->size = 0; + addr[0] = 0xFF; /* restore read mode */ + return (0); /* no or unknown flash */ + } + + mb (); + value = addr[2]; /* device ID */ + + switch (value) { + + case (unsigned char)INTEL_ID_28F640J3A: + info->flash_id += FLASH_28F640J3A; + info->sector_count = 64; + info->size = 0x00800000; + break; /* => 8 MB */ + + case (unsigned char)INTEL_ID_28F128J3A: + info->flash_id += FLASH_28F128J3A; + info->sector_count = 128; + info->size = 0x01000000; + break; /* => 16 MB */ + + default: + info->flash_id = FLASH_UNKNOWN; + break; + } + + if (info->sector_count > CFG_MAX_FLASH_SECT) { + printf ("** ERROR: sector count %d > max (%d) **\n", + info->sector_count, CFG_MAX_FLASH_SECT); + info->sector_count = CFG_MAX_FLASH_SECT; + } + + addr[0] = 0xFF; /* restore read mode */ + + return (info->size); +} + + +/*----------------------------------------------------------------------- + */ + +int flash_erase (flash_info_t * info, int s_first, int s_last) +{ + int flag, prot, sect; + ulong type; + int rcode = 0; + + if ((s_first < 0) || (s_first > s_last)) { + if (info->flash_id == FLASH_UNKNOWN) { + printf ("- missing\n"); + } else { + printf ("- no sectors to erase\n"); + } + return 1; + } + + type = (info->flash_id & FLASH_VENDMASK); + if ((type != FLASH_MAN_INTEL)) { + printf ("Can't erase unknown flash type %08lx - aborted\n", + info->flash_id); + return 1; + } + + prot = 0; + for (sect = s_first; sect <= s_last; ++sect) { + if (info->protect[sect]) { + prot++; + } + } + + if (prot) + printf ("- Warning: %d protected sectors will not be erased!\n", prot); + else + printf ("\n"); + + /* Disable interrupts which might cause a timeout here */ + flag = disable_interrupts (); + + /* Start erase on unprotected sectors */ + for (sect = s_first; sect <= s_last; sect++) { + if (info->protect[sect] == 0) { /* not protected */ + volatile unsigned char *addr; + unsigned char status; + + printf ("Erasing sector %2d ... ", sect); + + /* arm simple, non interrupt dependent timer */ + reset_timer_masked (); + + addr = (volatile unsigned char *) (info->start[sect]); + *addr = 0x50; /* clear status register */ + *addr = 0x20; /* erase setup */ + *addr = 0xD0; /* erase confirm */ + + while (((status = *addr) & 0x80) != 0x80) { + if (get_timer_masked () > + CFG_FLASH_ERASE_TOUT) { + printf ("Timeout\n"); + *addr = 0xB0; /* suspend erase */ + *addr = 0xFF; /* reset to read mode */ + rcode = 1; + break; + } + } + + *addr = 0x50; /* clear status register cmd */ + *addr = 0xFF; /* resest to read mode */ + + printf (" done\n"); + } + } + return rcode; +} + +/*----------------------------------------------------------------------- + * Copy memory to flash, returns: + * 0 - OK + * 1 - write timeout + * 2 - Flash not erased + * 4 - Flash not identified + */ + +int write_buff (flash_info_t * info, uchar * src, ulong addr, ulong cnt) +{ + ulong cp, wp; + unsigned char data; + int count, i, l, rc, port_width; + + if (info->flash_id == FLASH_UNKNOWN) + return 4; + + wp = addr; + port_width = 1; + + /* + * handle unaligned start bytes + */ + if ((l = addr - wp) != 0) { + data = 0; + for (i = 0, cp = wp; i < l; ++i, ++cp) { + data = (data << 8) | (*(uchar *) cp); + } + for (; i < port_width && cnt > 0; ++i) { + data = (data << 8) | *src++; + --cnt; + ++cp; + } + for (; cnt == 0 && i < port_width; ++i, ++cp) { + data = (data << 8) | (*(uchar *) cp); + } + + if ((rc = write_data (info, wp, data)) != 0) { + return (rc); + } + wp += port_width; + } + + /* + * handle word aligned part + */ + count = 0; + while (cnt >= port_width) { + data = 0; + for (i = 0; i < port_width; ++i) { + data = (data << 8) | *src++; + } + if ((rc = write_data (info, wp, data)) != 0) { + return (rc); + } + wp += port_width; + cnt -= port_width; + if (count++ > 0x800) { + spin_wheel (); + count = 0; + } + } + + if (cnt == 0) { + return (0); + } + + /* + * handle unaligned tail bytes + */ + data = 0; + for (i = 0, cp = wp; i < port_width && cnt > 0; ++i, ++cp) { + data = (data << 8) | *src++; + --cnt; + } + for (; i < port_width; ++i, ++cp) { + data = (data << 8) | (*(uchar *) cp); + } + + return (write_data (info, wp, data)); +} + +/*----------------------------------------------------------------------- + * Write a word or halfword to Flash, returns: + * 0 - OK + * 1 - write timeout + * 2 - Flash not erased + */ +static int write_data (flash_info_t * info, ulong dest, unsigned char data) +{ + volatile unsigned char *addr = (volatile unsigned char *) dest; + ulong status; + int flag; + + /* Check if Flash is (sufficiently) erased */ + if ((*addr & data) != data) { + printf ("not erased at %08lx (%lx)\n", (ulong) addr, + (ulong) * addr); + return (2); + } + /* Disable interrupts which might cause a timeout here */ + flag = disable_interrupts (); + + *addr = 0x40; /* write setup */ + *addr = data; + + /* arm simple, non interrupt dependent timer */ + reset_timer_masked (); + + /* wait while polling the status register */ + while (((status = *addr) & 0x80) != 0x80) { + if (get_timer_masked () > CFG_FLASH_WRITE_TOUT) { + *addr = 0xFF; /* restore read mode */ + return (1); + } + } + + *addr = 0xFF; /* restore read mode */ + + return (0); +} + +void inline spin_wheel (void) +{ + static int p = 0; + static char w[] = "\\/-"; + + printf ("\010%c", w[p]); + (++p == 3) ? (p = 0) : 0; +} diff -Naur --exclude=CVS u-boot-1.1.1/board/cm41xx/Makefile u-boot/board/cm41xx/Makefile --- u-boot-1.1.1/board/cm41xx/Makefile 1970-01-01 10:00:00.000000000 +1000 +++ u-boot/board/cm41xx/Makefile 2005-01-20 00:05:10.000000000 +1000 @@ -0,0 +1,46 @@ +# +# (C) Copyright 2000, 2002 +# Wolfgang Denk, DENX Software Engineering, wd(a)denx.de. +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB = lib$(BOARD).a + +OBJS := cm41xx.o flash.o + +$(LIB): $(OBJS) $(SOBJS) + $(AR) crv $@ $^ + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +######################################################################### + +.depend: Makefile $(SOBJS:.o=.S) $(OBJS:.o=.c) + $(CC) -M $(CPPFLAGS) $(SOBJS:.o=.S) $(OBJS:.o=.c) > $@ + +-include .depend + +######################################################################### diff -Naur --exclude=CVS u-boot-1.1.1/board/cm41xx/u-boot.lds u-boot/board/cm41xx/u-boot.lds --- u-boot-1.1.1/board/cm41xx/u-boot.lds 1970-01-01 10:00:00.000000000 +1000 +++ u-boot/board/cm41xx/u-boot.lds 2005-01-19 23:54:55.000000000 +1000 @@ -0,0 +1,55 @@ +/* + * (C) Copyright 2000 + * Wolfgang Denk, DENX Software Engineering, wd(a)denx.de. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") +OUTPUT_ARCH(arm) +ENTRY(_start) +SECTIONS +{ + . = 0x00000000; + + . = ALIGN(4); + .text : + { + cpu/ks8695/start.o (.text) + *(.text) + } + + . = ALIGN(4); + .rodata : { *(.rodata) } + + . = ALIGN(4); + .data : { *(.data) } + + . = ALIGN(4); + .got : { *(.got) } + + __u_boot_cmd_start = .; + .u_boot_cmd : { *(.u_boot_cmd) } + __u_boot_cmd_end = .; + + . = ALIGN(4); + __bss_start = .; + .bss : { *(.bss) } + _end = .; +} diff -Naur --exclude=CVS u-boot-1.1.1/include/configs/cm41xx.h u-boot/include/configs/cm41xx.h --- u-boot-1.1.1/include/configs/cm41xx.h 1970-01-01 10:00:00.000000000 +1000 +++ u-boot/include/configs/cm41xx.h 2005-03-17 22:39:02.000000000 +1000 @@ -0,0 +1,127 @@ +/* + * (C) Copyright 2005 + * Greg Ungerer <greg.ungerer(a)opengear.com>. + * Wolfgang Denk, DENX Software Engineering, wd(a)denx.de. + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ +#ifndef __CONFIG_H +#define __CONFIG_H + +/* + * If we are developing, we might want to start armboot from ram + * so we MUST NOT initialize critical regs like mem-timing ... + */ +#define CONFIG_INIT_CRITICAL /* undef for developing */ + +/* + * High Level Configuration Options + * (easy to change) + */ +#define CONFIG_KS8695 1 /* it is a KS8695 CPU */ +#define CONFIG_CM41xx 1 /* it is an OpenGear CM41xx boad */ + +#undef CONFIG_USE_IRQ /* we don't need IRQ/FIQ stuff */ + +#define CONFIG_CMDLINE_TAG 1 /* enable passing of ATAGs */ +#define CONFIG_SETUP_MEMORY_TAGS 1 +#define CONFIG_INITRD_TAG 1 + +/* + * Size of malloc() pool + */ +#define CFG_MALLOC_LEN (CFG_ENV_SIZE + 128*1024) +#define CFG_GBL_DATA_SIZE 128 /* size in bytes reserved for initial data */ + +/* + * Hardware drivers + */ + +/* + * select serial console configuration + */ +#define CFG_ENV_IS_NOWHERE +#define CONFIG_SERIAL1 +#define CONFIG_CONS_INDEX 1 +#define CONFIG_BAUDRATE 115200 +#define CFG_BAUDRATE_TABLE { 9600, 19200, 38400, 57600, 115200 } + +/* this must be included AFTER the definition of CONFIG_COMMANDS (if any) */ +#include <cmd_confdefs.h> +#undef CONFIG_COMMANDS +#define CONFIG_COMMANDS (CONFIG_CMD_DFL & ~(CFG_CMD_NONSTD | CFG_CMD_ENV)) + +#define CONFIG_BOOTDELAY 0 +#define CONFIG_BOOTARGS "mem=32M console=ttyAM0,115200" +#define CONFIG_BOOTCOMMAND "gofsk 0x02200000" + +/* + * Miscellaneous configurable options + */ +#define CFG_LONGHELP /* undef to save memory */ +#define CFG_PROMPT "boot > " /* Monitor Command Prompt */ +#define CFG_CBSIZE 256 /* Console I/O Buffer Size */ +#define CFG_PBSIZE (CFG_CBSIZE+sizeof(CFG_PROMPT)+16) /* Print Buffer Size */ +#define CFG_MAXARGS 16 /* max number of command args */ +#define CFG_BARGSIZE CFG_CBSIZE /* Boot Argument Buffer Size */ + +#define CFG_MEMTEST_START 0x00800000 /* memtest works on */ +#define CFG_MEMTEST_END 0x01000000 /* 16 MB in DRAM */ + +#undef CFG_CLKS_IN_HZ /* everything, incl board info, in Hz */ + +#define CFG_LOAD_ADDR 0x00008000 /* default load address */ + +#define CFG_HZ (1000) /* 1ms resolution ticks */ + +/*----------------------------------------------------------------------- + * Stack sizes + * + * The stack sizes are set up in start.S using the settings below + */ +#define CONFIG_STACKSIZE (128*1024) /* regular stack */ +#ifdef CONFIG_USE_IRQ +#define CONFIG_STACKSIZE_IRQ (4*1024) /* IRQ stack */ +#define CONFIG_STACKSIZE_FIQ (4*1024) /* FIQ stack */ +#endif + +/*----------------------------------------------------------------------- + * Physical Memory Map + */ +#define CONFIG_NR_DRAM_BANKS 1 /* we have 1 bank of DRAM */ +#define PHYS_SDRAM_1 0x00000000 /* SDRAM Bank #1 */ +#define PHYS_SDRAM_1_SIZE 0x02000000 /* 32 MB */ + +#define PHYS_FLASH_1 0x02000000 /* Flash Bank #1 */ +#define PHYS_FLASH_SECT_SIZE 0x00020000 /* 128 KB sectors (x1) */ +#define CFG_FLASH_BASE PHYS_FLASH_1 + +/*----------------------------------------------------------------------- + * FLASH and environment organization + */ +#define CFG_MAX_FLASH_BANKS 2 /* max number of flash banks */ +#define CFG_MAX_FLASH_SECT (128) /* max number of sectors on one chip */ + +/* timeout values are in ticks */ +#define CFG_FLASH_ERASE_TOUT (20*CFG_HZ) /* Timeout for Flash Erase */ +#define CFG_FLASH_WRITE_TOUT (20*CFG_HZ) /* Timeout for Flash Write */ + +#define CFG_ENV_SIZE 0x20000 /* Total Size of Environment */ + +#endif /* __CONFIG_H */

2 2

Re: [U-Boot-Users] 'Syslog implementation in u-boot'
by Wolfgang Denk 19 May '05

19 May '05

[Please keep this discussion on the mailing list so it gets archived and others can benefit from it, too.] In message <36446.202.62.67.130.1116316510.squirrel(a)202.62.67.130> you wrote: > > Suppose if any currepted image exists in server,u-boot downloads this > currepted file into embedded system flash. If it's a corruption that happened on the way of copying and transferring images, then the CRC32 checksum mechanism can be used to prevent you from storing corrupted images in the flash at all. Just use the "imi" command before storing the image to flash, somthing like tftp ... && imi && cp.b ... [assuming you have the hish shell enabled, which you should have for such purposes.] > Once we reset the embdded system kernel may not comeup. > To overcome this we have made some changes to u-boot to get images from > externel server when it finds kernel is not OK. > But this is contineous loop . There is no need for this. U-Boot supports a boot counter which can be used to break out of tsuch a loop. It was implemented EXACTLY for this purpose. See the "bootcnt", "bootlimit" and "altbootcmd" environment variables. > With this we can solve problem, but we may complete FALSH write cycles(if > it works contineously for day/two). Don't do it, then ;-) > It it does not get, then it should send a log message to external > system(where the syslog server is running).so that user can see the > message and plase the correct iamge in tftp server. You can use simple console redirection in U-Boot for this purpose. We support console over network. Summarizing: there is no need to implement anything at all: all features you might need are already in place. The only exception is that the CPU dependent part of the bootcount feature is not available on all processors yet, but it is trivial to implement. Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de Wenn das dann in die Hose geht, nehme ich es auf meine Kappe. -- Rudi Völler, 15. Nov 2003

2 4

[U-Boot-Users] Error in erasing the nand flash
by Pankaj GOYAL 19 May '05

19 May '05

HI, I m using the u-boot for my arm926-ejs processor based board.And I m using the 32MB NAND flash of STMicroelectronics on my board.When I use the "nand erase" command to erase the content of the NAND flash I observe that during the erasing if u-boot is unable to erase one of the block ( the error is genrated by uboot "Error erasing at " )it immidiatly comes out of the while loop and do not try to erase further blocks(Reffering to nand_erase function of the u-boot/common/cmd_nand.c file).Isn't u-boot should mark this block as badblock (Because u-boot is getting error in erasing the block) and instead of going out of the while loop it should try to erase the futher blocks.Please provide ur feedback. Regards Pankaj

1 0

[U-Boot-Users] Not primarily u-boot related problem with Flash-RAM
by Peter Asemann 18 May '05

18 May '05

Hi there! I've a problem that is not really u-boot specific; in fact it rather stands in my way to be able to use the U-Boot at all. I'm sorry for the off-topic post, but as this list's topic is the one most close to "bringing up boards" I hope you can help me a bit though: I have a prototype board which has an MPC875 with 4 AM29LV320DB flash chips on the bus (there also are 2 SDRAMs and an FPGA on the bus). The board had a design flaw which made some buffers/level converters which should convert the bus signal level to the signal level of a PCMCIA adapter kind of burn out or at least disturb bus operations on the data- as well as address-bus. We've therefore removed the buffers/level converters, and now the busses work, as we can see with a test program running on the FPGA (which monitors the busses and draws block graphics of the last non-identical 32 bus states on a VGA display). That means, the MPC and the FPGA seem to have survived what ever was wrong with the busses. But though the busses seem to be okay now, the flash doesn't react to the ident command sequence as it should, though I tried very defensive clocking and stuff. So the question is if you know typical mistakes which can cause accessing flash to fail, or if you know that flash chips are well known to go into pieces if there is something wrong with the busses connected to them. Any hint will be appreciated. Thanks for reading, Peter Asemann

5 7

[U-Boot-Users] DELIVERY FAILURE: User haurakimaori.co.nzhoneyr (haurakimaori.co.nzhoneyr@haurakimaori.co.nz) not listed in Domino Directory
by Postmaster＠haurakimaori.co.nz 18 May '05

18 May '05

Your message Subject: Schily ueber Deutschland was not delivered to: haurakimaori.co.nzhoneyr(a)haurakimaori.co.nz because: User haurakimaori.co.nzhoneyr (haurakimaori.co.nzhoneyr(a)haurakimaori.co.nz) not listed in Domino Directory

1 0

[U-Boot-Users] Delivery Status Notification (Failure)
by postmaster＠mysterycreek.co.nz 18 May '05

18 May '05

This is an automatically generated Delivery Status Notification. Delivery to the following recipients failed. mysterycreek.co.nznicolag(a)mysterycreek.co.nz

1 0

[U-Boot-Users] Timer interrupt in MPC8555
by Helio Fujimoto 17 May '05

17 May '05

Hi, there, I am working to porting u-boot v1.1.2 to a MPC8555-based board. I've seen that the timer interrupt is not working and, because of that, the timeout handlers for pings, tftp, arp requests, etc. are not working. For me it seems it was not implemented, but I am not sure of that. Is there anyone working in this issue? Thanks, Helio Fujimoto

2 1

[U-Boot-Users] Makefile problems
by Detlef Vollmann 17 May '05

17 May '05

Hello, as the command constants in cmd_confdefs.h are long longs, the programs in tools that include a board configuration file dont't compile with GCC 2.x. But on a number of workstations the 'gcc' command is still 2.95.x, while the 3.x version is named gcc3, gcc-3 or similar. One way to solve this is to add a line to tools/Makefile like HOSTCC=gcc-3 But now I need a different makefile on different machines. To avoid this, I tried things like $ HOSTCC=gcc-3 make or even $ HOSTCC=gcc-3 make -e but none of these worked. The most elegant version would be to give the HOSTCC at configuration time, i.e. $ HOSTCC=gcc-3 make xyz_config But I have no idea whether this is possible and if so how to implement it. Any ideas? Detlef -- Detlef Vollmann vollmann engineering gmbh Linux and C++ for Embedded Systems http://www.vollmann.ch/

3 6