[U-Boot] UEC phy not working on first try
Hi all- I am using u-boot.2010.09 on a MPC8568-based board. When trying to boot over one of the UEC network interfaces, it is not working instantly. The cable is connected from the beginning, but I have to issue a manual 'boot' command, sometimes even multiple times before the link is correct. This is the output: [- snip -] Net: UEC0, UEC1, UEC3 [PRIME], eTSEC0, eTSEC1 Hit any key to stop autoboot: 0 UEC: PHY is Generic MII (70431) UEC3: Full Duplex switching to rgmii 100 UEC3: Speed 100BT UEC3: Link is up UEC3: Link is down WARNING: adjusting available memory to 3000 Wrong Image Format for bootm command ERROR: can't get kernel image! => boot UEC3: Full Duplex switching to rgmii 100 UEC3: Speed 100BT UEC3: Link is up Using UEC3 device TFTP from server 10.169.15.10; our IP address is 10.169.15.9 Filename 'uImage'. Load address: 0x2000 Loading: T # # ### done [...] [- snip -] Booting over the TSEC interfaces works without problems. Any idea what might be the problem? Thanks Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UEC phy not working on first try
> > I am using u-boot.2010.09 on a MPC8568-based board. > > > > When trying to boot over one of the UEC network interfaces, it is not > > working instantly. The cable is connected from the beginning, but I > > have to issue a manual 'boot' command, sometimes even multiple times > > before the link is correct. This is the output: > > Do all the UEC interfaces show the same symptoms? Yes, this happens for all UECs. And I think it worked until we switched from u-boot 2009.11.1 to 2010.09 - but there's so much change that I didn't find the reason for it, yet. > The driver "thinks" the link went away again. When the cable is > connected all the time, then this is an indication of something going > wrong. You should try to diagnose, why the software gets this link > change and if it really is an information that the phy provides, if the > physical path to the phy is stable. Well, the software runs though uec_init (the_first_run is zero) and gets a positive link state in the do-while-loop instantly. Afterwards adjust_link is called - and there it fails. Strange thing - I guess I need to dig a little deeper... Code hints are very appreciated! ;-) > Best wishes > Detlev Zundel Thanks! Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] UEC phy not working on first try
Hi Detlef, > >> > I am using u-boot.2010.09 on a MPC8568-based board. > Ah! I didn't realize that you are in the excellent position to have > one > good and one bad commit. Simply use git bisect to find the problematic > commit and show that to us. so far I traced it down to the adjust_link call in uec_init from file uec.c (line 1234 in release 2011.03). This call wasn't there in release 2009.11.1 and removing that line solves the issue here. I don't know, why this went in and what the drawbacks are without it. Maybe someone on this list knows... (Sorry, I didn't search for a specific commit in git, yet. I just diffed pertinent files around the qe|uec|net drivers first.) Happy sunny Easter all! 8-) Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-Boot hangs when board is attached to BDI2000
Hi all, I am trying to debug u-boot following the instructions in DULG 10.1. As mentioned in 10.1.1. before relocation I connect to the target an get desired first output: Remote debugging using jtag: 0xfffc in ?? () Even without setting a breakpoint then, I just say gdb to continue: (gdb) c Continuing. The output in the console then is: U-Boot 2009.08 (Nov 25 2009 - 09:18:37) CPU: 8568E, Version: 1.1, (0x807d0011) Core: E500, Version: 2.2, (0x80210022) Clock Configuration: CPU0:1320 MHz, CCB:528 MHz, DDR:264 MHz (528 MT/s data rate), LBC:66 MHz QE:528 MHz L1:D-cache 32 kB enabled I-cache 32 kB enabled Board: 8568 MDS I2C: ready DRAM: Initializing SDRAM: 64 MB DDR: 512 MB (DDR2, 64-bit, CL=4, ECC off) ...and nothing further happens. After 30 secs or so, I simply hit Ctrl-C and get: ^C Program received signal SIGSTOP, Stopped (signal). 0x1ff70700 in ?? () (gdb) bt #0 0x1ff70700 in ?? () #1 0x1ff71574 in ?? () Cannot access memory at address 0xdeadbef3 (gdb) When I issue a "reset run" within the BDI shell, the target boots as expected, but when I start the target with "reset halt" to debug it from the first instruction it behaves at described above. I am using a BDI2000 on a Freescale MPC8568E-MDS board. U-boot 2009.08 is compiled with make CROSS_COMPILE=ppc_85xx- MPC8568MDS_config make CROSS_COMPILE=ppc_85xx- all Any ideas? Is there some watchdog issue to cope with, maybe? Cheers Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Debugging U-boot after relocation
Hi again, following up on my other message, I split them up into seperate messages, as I think there are different reasons. When I start the target from the BDI shell with "RESET RUN" and wait until the "Hit any key to stop autoboot" message appears, I can then attach to the target : Remote debugging using jtag: 0x1ff731ec in ?? () I then discard the symbols: (gdb) symb Discard symbol table from `...uboot/u-boot-2009.08/u-boot'? (y or n) y No symbol file now. Then, I calculate the RAM address for the symbols as described in DULG-10.1.2.: RAM is 512 MB --> 0x2000 Monitor Len according to board specific file is 256k --> 0x0004 This yields address 0x1FFC . (gdb) add-symbol-file u-boot 0x1FFC add symbol table from file "u-boot" at .text_addr = 0x1FFC (y or n) y Reading symbols from ...uboot/u-boot-2009.08/u-boot...done. I then apply a breakpoint to TftpStart, which is definitely up next: (gdb) b TftpStart Breakpoint 1 at 0x1ffc6314: file tftp.c, line 474. looks like an appropriate address, anyway saying (gdb) c Continuing. never stops in TftpStart. The kernel is loaded by TFTP and the target can only be halted by pressing Ctrl-C. On the other hand, calculating the address the other way yields (gdb) print/x ((gd_t *)$r2)->reloc_off $4 = 0x1fff adding this to TEXT_BASE which is ./board/freescale/mpc8568mds/config.mk:TEXT_BASE = 0xfff8 results in something above 32 bit. What am I doing wrong here? Cheers Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Adding a new board to the configuration
Hi all- I'd like to add a new custom board configuration to the u-boot build. Which files have to be created and/or patched to add a new board to build system? Our design uses the MPC8568E CPU, so I suppose, I can use a lot of present code coming from parameters like "ppc" and "mpc85xx". Of course I am taking a look at other configurations, but I'd like to know how to set it up from scratch, especially to getting to know the essentials. So, what is needed for that later I can give it a "make MYCOOLBOARD_config" followed by "make all"? Cheers Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Booting from ext2/ext3
Hi all, how does the implementation of the ext2 module work in u-boot? As I see, u-boot can load the kernel from an ext2 file system using ext2load. Unfortunately, this command is not included in my build of u-boot. Did I miss some compile-switch, or do I have to explicitly include ext2fs.h somewhere? How can I enable the ext2/ext3 functionality? Another related question is, if I can format an ext2/ext3 drive from u-boot or how I can bring up a new image to my internal device, once u-boot is running. Cheers Matthias Dunda ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting from ext2/ext3
> > Unfortunately, this command is not included in my build of > u-boot. Did > > I miss some compile-switch, or do I have to explicitly include > > ext2fs.h somewhere? How can I enable the ext2/ext3 functionality? > > This depends on CONFIG_CMD_EXT2 > Thanks, I added this along with CONFIG_DOS_PARTITION to my board configuration file - which so far is a copy of the MPC8568MDS.h During the final linking I get the following errors: common/libcommon.a(cmd_ext2.o): In function `do_ext2load': u-boot-2009.11.1/common/cmd_ext2.c:193: undefined reference to `get_partition_info' fs/ext2/libext2fs.a(dev.o): In function `ext2fs_set_blk_dev': u-boot-2009.11.1/fs/ext2/dev.c:45: undefined reference to `get_partition_info' make: *** [u-boot] Error 1 Full build output is attached. What's the issue here? Cheers Matthias uboot.log.gz Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting from ext2/ext3
Good Morning Wolfgang, > > > Dear Matthias, > > In message > <569685f045b85741820d0265e0d2999d019cf...@tddhh01.hh.thales-na > val.de> you wrote: > > > > `get_partition_info' > ... > > What's the issue here? > > Hm... this is U-Boot release v2009.11.1, correct? > Yes correct, but it happens in 2009.08, too. > > In your log you can see that the relevant source file, > disk/part.c, gets compiled: > > Try running "nm" on the object file; you should see something > like this: > The output of ppc_85xx-nm *.o in disk/ looks a little "weak": part_dos.o: part.o: T get_dev These are the sizes: total 108 -rw-r--r-- 1 dunda users 5428 2010-03-31 15:56 libdisk.a -rw-r--r-- 1 dunda users 1585 2010-02-02 15:59 Makefile -rw-r--r-- 1 dunda users 9756 2010-02-02 15:59 part_amiga.c -rw-r--r-- 1 dunda users 3524 2010-02-02 15:59 part_amiga.h -rw-r--r-- 1 dunda users 9470 2010-02-02 15:59 part.c -rw-r--r-- 1 dunda users 7369 2010-02-02 15:59 part_dos.c -rw-r--r-- 1 dunda users 1908 2010-02-02 15:59 part_dos.h -rw-r--r-- 1 dunda users 1632 2010-03-31 15:56 part_dos.o -rw-r--r-- 1 dunda users 11910 2010-02-02 15:59 part_efi.c -rw-r--r-- 1 dunda users 4650 2010-02-02 15:59 part_efi.h -rw-r--r-- 1 dunda users 8056 2010-02-02 15:59 part_iso.c -rw-r--r-- 1 dunda users 7771 2010-02-02 15:59 part_iso.h -rw-r--r-- 1 dunda users 6278 2010-02-02 15:59 part_mac.c -rw-r--r-- 1 dunda users 3517 2010-02-02 15:59 part_mac.h -rw-r--r-- 1 dunda users 3592 2010-03-31 15:56 part.o I did a fresh build after extracting the 2009.08 archive with make CROSS_COMPILE=ppc_85xx- MPC8568MDS_config make CROSS_COMPILE=ppc_85xx- all The only change I applied before is 419a420 > #define CONFIG_DOS_PARTITION 430a432,433 > #define CONFIG_CMD_EXT2 > #define CONFIG_CMD_FAT to include/configs/MPC8568MDS.h Cheers Matthias Dunda build-output.txt.gz Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Booting from ext2/ext3
Dear Wolfgang, > > > > to include/configs/MPC8568MDS.h > > It seems you are missing the device driver support. If you > check the code in "disk/part.c" you will see this: > > ... > 218 #if (defined(CONFIG_CMD_IDE) || \ > 219 defined(CONFIG_CMD_MG_DISK) || \ > 220 defined(CONFIG_CMD_SATA) || \ > 221 defined(CONFIG_CMD_SCSI) || \ > 222 defined(CONFIG_CMD_USB) || \ > 223 defined(CONFIG_MMC)|| \ > 224 defined(CONFIG_SYSTEMACE) ) Indeed, there was something missing! I added the configurations like described in doc/README.usb: CONFIG_CMD_USB CONFIG_USB_UHCI CONFIG_USB_STORAGE It seems, like these aren't sufficient - again at final linking stage I get missing references (see attachment). At least disk/part.o has some symbols now: d block_drvr 00dc T dev_print 031c T get_dev 02a0 T get_partition_info U get_partition_info_dos 02dc T init_part 0004 T print_part U print_part_dos U printf U puts U strlen U strncmp U test_part_dos U usb_stor_get_dev Anyhow, get_partition_info_dos and others are undefined :-( The goal is to boot from an USB Disk-on-Module, formatted either ext2/3 or maybe FAT. Happy Easter - all! Matthias common/libcommon.a(usb.o): In function `usb_submit_int_msg': /data/home/dunda/svn/DIU-Synchro/Bootloader/u-boot-2009.11.1/common/usb.c:163: undefined reference to `submit_int_msg' common/libcommon.a(usb.o): In function `usb_stop': /data/home/dunda/svn/DIU-Synchro/Bootloader/u-boot-2009.11.1/common/usb.c:137: undefined reference to `usb_lowlevel_stop' common/libcommon.a(usb.o): In function `usb_bulk_msg': /data/home/dunda/svn/DIU-Synchro/Bootloader/u-boot-2009.11.1/common/usb.c:223: undefined reference to `submit_bulk_msg' common/libcommon.a(usb.o): In function `usb_control_msg': /data/home/dunda/svn/DIU-Synchro/Bootloader/u-boot-2009.11.1/common/usb.c:196: undefined reference to `submit_control_msg' common/libcommon.a(usb.o): In function `usb_init': /data/home/dunda/svn/DIU-Synchro/Bootloader/u-boot-2009.11.1/common/usb.c:110: undefined reference to `usb_lowlevel_init' common/libcommon.a(usb_storage.o): In function `usb_stor_CBI_get_status': /data/home/dunda/svn/DIU-Synchro/Bootloader/u-boot-2009.11.1/common/usb_storage.c:586: undefined reference to `submit_int_msg' disk/libdisk.a(part.o): In function `print_part': /data/home/dunda/svn/DIU-Synchro/Bootloader/u-boot-2009.11.1/disk/part.c:372: undefined reference to `print_part_dos' disk/libdisk.a(part.o): In function `get_partition_info': /data/home/dunda/svn/DIU-Synchro/Bootloader/u-boot-2009.11.1/disk/part.c:287: undefined reference to `get_partition_info_dos' disk/libdisk.a(part.o): In function `init_part': /data/home/dunda/svn/DIU-Synchro/Bootloader/u-boot-2009.11.1/disk/part.c:257: undefined reference to `test_part_dos' make: *** [u-boot] Error 1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Debugging into the kernel from u-boot
Hi all- I - more or less - successfully got U-Boot up and running on our custom designed board. U-Boot leaves its premices in boot_jump_linux and this is the last I see on the console: ## Booting kernel from Legacy Image at 0200 ... Image Name: Linux-2.6.29.6-rt23 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1830522 Bytes = 1.7 MB Load Address: Entry Point: Verifying Checksum ... OK ## Flattened Device Tree blob at 0040 Booting using the fdt blob at 0x40 Uncompressing Kernel Image ... OK ## Transferring control to Linux (at address )... Booting using OF flat tree... When I halt the board using the BDI3000 debugger, I find the PC somewhere in 0xc000c96c in __delay. Accessing 0xc000 makes no sense, as we don't even have mapped memory there. Using HW breakpoints I can see the single instructions from 0x0 on, but I get no link to the source. Where can I get a meaningful starting point in the kernel? Why are all the symbols in vmlinux located at 0xc0... and how does the relocation take place? I saw some comment in arch/powerpc/kernel/setup_32.c but yet I have no clue where to start practically? Any help would be appreciated! Have a nice weekend! Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] available memory gets adjusted - why?
Hi all- after issuing the boot command I get WARNING: adjusting available memory to 300 I do have 2 Gig on my board and I set that in the appropriate configs. What's the reason why U-Boot adjusts the size and how can I fix this? I mean, U-Boot itself runs from 0x7ff3 so the memory is there! Thanks Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Debugging into the kernel from u-boot
Hi Stefan, > > You have all the equipment you need. Use the BDI3000 to debug > the Linux > kernel. is it correct, that I can only use HARD breakpoints? Because when I set BREAK SOFT, the gdb always says it cannot access memory at c000 And even with HW breakpoints I'm not able to do clean stepping thru the code. The pointer jumps more or less arbitrarily thru the file resulting in a crash after some steps. >From the BDI3000 documentation I assume, that using MMT XLAT and setting PTBASE is only important, if I load and start the kernel directly, without the initialization from U-Boot. Am I right? For information I attach the log I read out of memory at __log_buf location... although I already posted that on the linuxppc-dev list... Do you think, that there's maybe a hardware issue because of the timing errors in the call trace? Is this the reason for the strange behaviour of the gdb when trying to step thru the code? I mean - assuming that the hardware is correct - I should be able to do "state-of-the-art" code stepping even at early stage like in early_init_devtree, right? Thanks! Matthias kernel-log.008 Description: Binary data ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Force setting of ethact
Hi all- I've been struggeling with the ethact setting in U-Boot: I want U-Boot to load from eTSEC0 on our board, but it always comes up with ethact = UEC0 or FSL UEC0 in older versions. As ethact is not persistent, my only workaround so far was to change net/eth.c so that at all occasions, where ethact is set, it is set to eTSEC0 - during development, this was OK for me, but now I am cleaning up! What's the intended/desired function of ethact, and how should it be initialized? Even using CONFIG_ETHPRIME has no effect. >From my understanding of something named "ethact", I would expect, that it >finds the (first) active ethernet device - active in a sense of connected or >usable or whatever. Although eTSEC0 is the only connected port on our device, it comes up with UEC0 - so, even if this interface in "on" in some way, this does not help here. How can I force ethact to be eTSEC0 (or whichever I want), without tampering U-Boot base files? Thanks Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] 4 PiB left unmapped
Hi again, my current binary of U-Boot claims, that 4 petabyte of memory are unmapped: U-Boot 2010.09-svn314 (Nov 18 2010 - 15:09:16) CPU: 8568E, Version: 1.1, (0x807d0011) Core: E500, Version: 2.2, (0x80210022) ... DRAM: Initializing 4 PiB left unmapped DDR: 2 GiB (DDR2, 64-bit, CL=4, ECC off) FLASH: 256 MiB L2:512 KB enabled I wish, I had that much memory! ;-) The version 2009.11.1 we used so far does say that 0 Bytes are unmapped. What could that be? Cheers Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Force setting of ethact
> Why don't you use "ethprime" ? > > > What's the intended/desired function of ethact, and how should it be > initialized? Even using CONFIG_ETHPRIME has no effect. > > These variabes are documented in the README. Yes, I read that! That's why I used CONFIG_ETHPRIME in my board header file to do the trick - maybe my env was corrupted, or something - I don't know, why it didn't show up by default... I had to setenv it by hand. Thanks. Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 4 PiB left unmapped
> > CPU: 8568E, Version: 1.1, (0x807d0011) > > Core: E500, Version: 2.2, (0x80210022) > > ... > > DRAM: Initializing > > 4 PiB left unmapped > >DDR: 2 GiB (DDR2, 64-bit, CL=4, ECC off) > > FLASH: 256 MiB > > L2:512 KB enabled > > Pretty cool, how much memory do you actually have in the box? > Well, it's actually 2 Gig, just like u-boot recognizes above... - Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 4 PiB left unmapped
>>
>>> Well, it's actually 2 Gig, just like u-boot recognizes above...
>>
>> There's something wrong with the parameter you're passing to print_size().
>I'm guessing its -1 or something like that.
I used the board specific code of the MPC8568MDS and adapted it to our
configuration.
The code region of interest here is in mpc8568mds.c:
phys_size_t
initdram(int board_type)
{
long dram_size = 0;
...
dram_size = fsl_ddr_sdram();
dram_size = setup_ddr_tlbs(dram_size / 0x10);
...
}
The dram_size parameter is signed and thus gives a value of -1 when having 2
Gig installed (0x8000).
-1 devided by 0x10 gives 0xf800, which is the 4 PiB when interpreted as
unsigned again in setup_ddr_tlbs(...).
The MPC8568MDS has only 256 MB in default configuration, so it shouldn't occur
there.
Anyhow, I don't understand, why it worked in u-boot 2009.11.1... :-/
so long...
Matthias
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Power-on Self Test - is it working?
Hi all- I've got some issues with getting POST to work with my board (mpc85xx architecture): In my config I set #define CONFIG_POST (CONFIG_SYS_POST_MEMORY | ..._CPU | ..._UART | ..._ETHER) I also implemented the stubs for uart_post_test and ether_post_test, as these are not covered by default. I see no output from the tests - so I can't tell, if they were even run. From my understanding, post_output_backlog should dump some results like PASSED or FAILED right after running from relocated code, but I see nothing. Another thing is the POST word address. So far I left it at the default which should locate it at CONFIG_SYS_IMMR ( = CCSRBAR = E000_ ) + CPM_POST_WORD_ADDR (= 80FC) which results into an address at E000_80FC, which is a reserved area in PCI configuration space - according to PowerQUICC memory map. (???) The POST documentation (README.POST) seems a little outdated - even the struct post has eight fields in the meantime - and it describes more or less the framework itself. >From what I understood from that document, the steps I did should be >sufficient, but I am still missing/needing something. Cheers Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
