[U-Boot-Users] AMD dbau1550
Hi
I've been working on getting u-boot 1.1.1 up and running on <subject>, in little endian mode (which someone asked for a few days ago I believe).
I've been able to get as far as "Starting kernel ..." after downloading the kernel u-boot image through tftp.
I know this tecnically means u-boot is finished, however the same kernel (in srec format) boots fine from the original yamon loader on the board.
When I halt the processor through jtag (bdi2000), the PC is always at 0xbfc00424 (somewhere in ROM exception land?).
The loaded image has been configured using tools/mkimage -C gzip -a 0x80100000 -e 0x80246040 -A mips -O linux -T kernel -d vmlinux.gz vmlinux.u-boot
0x80246040 is the location of "kernel_entry".
Does anyone have any hints about how I could work my way past this problem?
regards / Leif
On May 24, 2004, at 11:22 AM, Leif Lindholm wrote:
Does anyone have any hints about how I could work my way past this problem?
The kernel expects lots of setup done by yamon for board configuration, environment and kernel start parameters. Without major changes to the kernel start up functions to extract similar information from a u-boot environment, the kernel isn't going to boot up.
-- Dan
The first thing I would check, is the parameters passed to kernel. E.g. wrong memory size will make things really bad.
Default behaviour for dbau1x00 u-boot is to pass mem size in bytes. Does your kernel expect that?
I suggest activating DEBUG macro in lib_mips/mips_linux.c
/Thomas
Leif Lindholm wrote:
Hi
I've been working on getting u-boot 1.1.1 up and running on <subject>, in little endian mode (which someone asked for a few days ago I believe).
I've been able to get as far as "Starting kernel ..." after downloading the kernel u-boot image through tftp.
I know this tecnically means u-boot is finished, however the same kernel (in srec format) boots fine from the original yamon loader on the board.
When I halt the processor through jtag (bdi2000), the PC is always at 0xbfc00424 (somewhere in ROM exception land?).
The loaded image has been configured using tools/mkimage -C gzip -a 0x80100000 -e 0x80246040 -A mips -O linux -T kernel -d vmlinux.gz vmlinux.u-boot
0x80246040 is the location of "kernel_entry".
Does anyone have any hints about how I could work my way past this problem?
regards / Leif
This SF.Net email is sponsored by: Oracle 10g Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE. http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Hi, and thanks for your suggestions.
It turned out, however, to be a simple RTFM problem. I was trying to load the ELF version of the kernel, which made my load address and entry point invalid.
Since I used the dbau1x00 code as base, the parameter/memory size passing was ok (after I changed the hard-coded 64Mb to hard coded 128Mb :)
Am looking into some way to integrate this stuff into mainline.
regards / Leif
In message 1085509772.19990.39.camel@callisto.smurfnet.se you wrote:
Am looking into some way to integrate this stuff into mainline.
See the README, section "Submitting Patches".
Best regards,
Wolfgang Denk
participants (4)
-
Dan Malek -
Leif Lindholm -
Thomas Lange -
Wolfgang Denk