2010-03-03 18:14:38 ACK! on kernel 2009 R1 startup.
Matt Gilg (UNITED STATES)
Message: 86766
Anybody seen this? (Early Printk option is turned on)
## Booting image at 02000000 ...
Image Name: uClinux Kernel and ext2
Created: 2010-03-03 23:09:12 UTC
Image Type: Blackfin Linux Kernel Image (gzip compressed)
Data Size: 8454108 Bytes = 8.1 MB
Load Address: 00001000
Entry Point: 001d4d40
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting Kernel at = 1d4d40
Ack! Something bad happened to the Blackfin!
SEQUENCER STATUS:
SEQSTAT: 00000021 IPEND: 3fc00b2 SYSCFG: 0032
HWERRCAUSE: 0x0
EXCAUSE : 0x21
physical IVG7 asserted : <0x03fc0470> { _evt_default + 0x0 }
RETE: <0x00000000> /* Maybe null pointer? */
RETN: <0x00aee000> /* unknown address */
RETX: <0x002a5114> /* unknown address */
RETS: <0x03fc7608> { _do_bootm + 0x344 }
PC : <0x03fc00b2> { _start + 0xb2 }
DCPLB_FAULT_ADDR: <0x03f5b74c> /* unknown address */
ICPLB_FAULT_ADDR: <0x002a5114> /* unknown address */
PROCESSOR STATE:
R0 : ffb00000 R1 : ffffeff1 R2 : 00000fd4 R3 : fffffff7
R4 : 00000002 R5 : 02000000 R6 : 02000040 R7 : 00000001
P0 : ffb00000 P1 : 03f60042 P2 : 001d4d40 P3 : 03f5bb40
P4 : 03fe3efc P5 : 03f5c000 FP : 03fd5528 SP : 03f5b67c
LB0: 03fd3a64 LT0: 03fd3a58 LC0: 00000000
LB1: 03fcdfea LT1: 03fcdfe4 LC1: 00000000
B0 : 00000008 L0 : 00000000 M0 : 0000003f I0 : 00000007
B1 : 03f6a750 L1 : 00000000 M1 : 0000000f I1 : 03f64f7c
B2 : 03f6c098 L2 : 00000000 M2 : ff807ffc I2 : 00000c2c
B3 : 000001ff L3 : 00000000 M3 : 03fd8c04 I3 : 00000000
A0.w: fffb337b A0.x: ffffffff A1.w: ffffea58 A1.x: ffffffff
USP : 019ffd0c ASTAT: 00002000
Hardware Trace:
0 Target : <0x03fc0940> { _bfin_panic + 0x0 }
Source : <0x03fc0b14> { _trap_c + 0x198 }
1 Target : <0x03fc0b0a> { _trap_c + 0x18e }
Source : <0x03fc0996> { _trap_c + 0x1a }
2 Target : <0x03fc097c> { _trap_c + 0x0 }
Source : <0x03fc0416> { _trap + 0x56 }
3 Target : <0x03fc03c0> { _trap + 0x0 }
Source : <0x002a5112> /* unknown address */
4 Target : <0x001d4d40> /* unknown address */
Source : <0x03fd1ce2> { _do_bootm_linux + 0x92 }
5 Target : <0x03fd1cd8> { _do_bootm_linux + 0x88 }
Source : <0x03fc01e2> { _dcache_disable + 0x1e }
6 Target : <0x03fc01c4> { _dcache_disable + 0x0 }
Source : <0x03fd1cd4> { _do_bootm_linux + 0x84 }
7 Target : <0x03fd1cd0> { _do_bootm_linux + 0x80 }
Source : <0x03fc0104> { _dcache_status + 0x10 }
8 Target : <0x03fc00f4> { _dcache_status + 0x0 }
Source : <0x03fd1ccc> { _do_bootm_linux + 0x7c }
9 Target : <0x03fd1ccc> { _do_bootm_linux + 0x7c }
Source : <0x03fc00dc> { _icache_disable + 0x1c }
10 Target : <0x03fc00c0> { _icache_disable + 0x0 }
Source : <0x03fd1cc8> { _do_bootm_linux + 0x78 }
11 Target : <0x03fd1cc4> { _do_bootm_linux + 0x74 }
Source : <0x03fc00f0> { _icache_status + 0x10 }
12 Target : <0x03fc00e0> { _icache_status + 0x0 }
Source : <0x03fd1cc0> { _do_bootm_linux + 0x70 }
13 Target : <0x03fd1cb0> { _do_bootm_linux + 0x60 }
Source : <0x03fc11b8> { _strncpy + 0x1c }
14 Target : <0x03fc11b6> { _strncpy + 0x1a }
Source : <0x03fc11ae> { _strncpy + 0x12 }
15 Target : <0x03fc11a8> { _strncpy + 0xc }
Source : <0x03fc11b4> { _strncpy + 0x18 }
Please reset the board
### ERROR ### Please RESET the board ###
QuoteReplyEditDelete
2010-03-03 19:30:16 Re: ACK! on kernel 2009 R1 startup.
Mike Frysinger (UNITED STATES)
Message: 86767
use 2009R1.1 kernel and u-boot
QuoteReplyEditDelete
2010-03-05 13:09:32 Re: ACK! on kernel 2009 R1 startup.
Matt Gilg (UNITED STATES)
Message: 86879
Hi Mike,
We have many units in the field, and end-user boot-loader updates are a bit scary. Is there any simple way to work around this issue through kernel configuration or modification? (Obviously it can be done, but my question is more directed toward the complexity of the operation)
-Matt
QuoteReplyEditDelete
2010-03-05 13:19:27 Re: ACK! on kernel 2009 R1 startup.
Mike Frysinger (UNITED STATES)
Message: 86880
i recall this sort of issue in the <=2008R1.5 releases, but seems to be resolved with 2009R1+. i dont recall what exactly fixed the problem or if we just stopped seeing it.
the error output is coming from u-boot, but the actual error (the "unknown address") is coming from the booted code (i.e. linux). seqstat 0x21 means undefined instruction. that might be due to i/d cache desync.
you could try modifying do_bootm_linux in lib_blackfin/boot.c to i/d cache flush the entire range before jumping into it.
i'm of course assuming your u-boot version ... you never said what you're using.
QuoteReplyEditDelete
2010-03-15 12:11:30 Re: ACK! on kernel 2009 R1 startup.
Matt Gilg (UNITED STATES)
Message: 87208
Hi Mike,
I'd really like to correct the problem without updating/modifying uboot, and isn't it true that do_bootm_linux is a part of the uboot distribution? IOW, I'd like to modify the kernel (rather than uboot) and correct whatever is causing this issue. (It is much safer to update the kernel in the field)
Uboot version is: U-Boot 1.1.6-svn77 (ADI-2008R2-pre) (Jul 2 2009 - 12:41:43)
Thanks again for the help.
-Matt
QuoteReplyEditDelete
2010-03-15 12:56:02 Re: ACK! on kernel 2009 R1 startup.
Mike Frysinger (UNITED STATES)
Message: 87211
the problem was with u-boot, not linux. you could disable caches before booting linux (icache off ; dcache off), but it's going to make booting slow. feel free to hack the kernel in a similar way.
QuoteReplyEditDelete
2010-03-15 14:18:01 Re: ACK! on kernel 2009 R1 startup.
Matt Gilg (UNITED STATES)
Message: 87212
Hi Mike, thanks for the reply.
Hi Mike, here are my results with the instruction and disk cache turned off in the kernel:
===========================================================
SEQUENCER STATUS:
SEQSTAT: 00000021 IPEND: 3fc00b2 SYSCFG: 0032
HWERRCAUSE: 0x0
EXCAUSE : 0x21
physical IVG7 asserted : <0x03fc0470> { _evt_default + 0x0 }
RETE: <0x00000000> /* Maybe null pointer? */
RETN: <0x01c08000> /* unknown address */
RETX: <0x002b3130> /* unknown address */
RETS: <0x03fc7608> { _do_bootm + 0x344 }
PC : <0x03fc00b2> { _start + 0xb2 }
DCPLB_FAULT_ADDR: <0x03f5b74c> /* unknown address */
ICPLB_FAULT_ADDR: <0x002b3130> /* unknown address */
PROCESSOR STATE:
R0 : ffb00000 R1 : ffffeff1 R2 : 00000fd4 R3 : fffffff7
R4 : 00000002 R5 : 02000000 R6 : 02000040 R7 : 00000001
P0 : ffb00000 P1 : 03f60042 P2 : 001e2754 P3 : 03f5bb40
P4 : 03fe3efc P5 : 03f5c000 FP : 03fd5518 SP : 03f5b67c
LB0: 03fd3a54 LT0: 03fd3a48 LC0: 00000000
LB1: 03fcdfda LT1: 03fcdfd4 LC1: 00000000
B0 : 00000008 L0 : 00000000 M0 : 0000003f I0 : 00000007
B1 : 03f6a750 L1 : 00000000 M1 : 0000000f I1 : 03f62f98
B2 : 03f6c210 L2 : 00000000 M2 : ff807ffc I2 : 00001858
B3 : 000001ff L3 : 00000000 M3 : 03fd8bf4 I3 : 00000000
A0.w: fffb3376 A0.x: ffffffff A1.w: ffffea53 A1.x: ffffffff
USP : 01d3fdbc ASTAT: 00002000
Hardware Trace:
0 Target : <0x03fc0940> { _bfin_panic + 0x0 }
Source : <0x03fc0b14> { _trap_c + 0x198 }
1 Target : <0x03fc0b0a> { _trap_c + 0x18e }
Source : <0x03fc0996> { _trap_c + 0x1a }
2 Target : <0x03fc097c> { _trap_c + 0x0 }
Source : <0x03fc0416> { _trap + 0x56 }
3 Target : <0x03fc03c0> { _trap + 0x0 }
Source : <0x002b312e> /* unknown address */
4 Target : <0x001e2754> /* unknown address */
Source : <0x03fd1cd2> { _do_bootm_linux + 0x92 }
5 Target : <0x03fd1cc8> { _do_bootm_linux + 0x88 }
Source : <0x03fc01e2> { _dcache_disable + 0x1e }
6 Target : <0x03fc01c4> { _dcache_disable + 0x0 }
Source : <0x03fd1cc4> { _do_bootm_linux + 0x84 }
7 Target : <0x03fd1cc0> { _do_bootm_linux + 0x80 }
Source : <0x03fc0104> { _dcache_status + 0x10 }
8 Target : <0x03fc00f4> { _dcache_status + 0x0 }
Source : <0x03fd1cbc> { _do_bootm_linux + 0x7c }
9 Target : <0x03fd1cbc> { _do_bootm_linux + 0x7c }
Source : <0x03fc00dc> { _icache_disable + 0x1c }
10 Target : <0x03fc00c0> { _icache_disable + 0x0 }
Source : <0x03fd1cb8> { _do_bootm_linux + 0x78 }
11 Target : <0x03fd1cb4> { _do_bootm_linux + 0x74 }
Source : <0x03fc00f0> { _icache_status + 0x10 }
12 Target : <0x03fc00e0> { _icache_status + 0x0 }
Source : <0x03fd1cb0> { _do_bootm_linux + 0x70 }
13 Target : <0x03fd1ca0> { _do_bootm_linux + 0x60 }
Source : <0x03fc11b8> { _strncpy + 0x1c }
14 Target : <0x03fc11b6> { _strncpy + 0x1a }
Source : <0x03fc11ae> { _strncpy + 0x12 }
15 Target : <0x03fc11a8> { _strncpy + 0xc }
Source : <0x03fc11b4> { _strncpy + 0x18 }
Please reset the board
### ERROR ### Please RESET the board ###
============================================================
They look identical, am I missing something?
-Matt
QuoteReplyEditDelete
2010-03-15 14:24:52 Re: ACK! on kernel 2009 R1 startup.
Mike Frysinger (UNITED STATES)
Message: 87213
i dont mean the cache in the kernel. i mean literally type the commands 'icache off' into the u-boot prompt.
QuoteReplyEditDelete
2010-03-15 14:34:49 Re: ACK! on kernel 2009 R1 startup.
Matt Gilg (UNITED STATES)
Message: 87214
ah, thanks. here is the output:
==========================================
## Booting image at 02000000 ...
Image Name: uClinux Kernel and ext2
Created: 2010-03-15 18:07:15 UTC
Image Type: Blackfin Linux Kernel Image (gzip compressed)
Data Size: 8485617 Bytes = 8.1 MB
Load Address: 00001000
Entry Point: 001e2754
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting Kernel at = 1e2754
Ack! Something bad happened to the Blackfin!
SEQUENCER STATUS:
SEQSTAT: 00000021 IPEND: 3fc00b2 SYSCFG: 0032
HWERRCAUSE: 0x0
EXCAUSE : 0x21
physical IVG7 asserted : <0x03fc0470> { _evt_default + 0x0 }
RETE: <0x00000000> /* Maybe null pointer? */
RETN: <0x01c08000> /* unknown address */
RETX: <0x002b3130> /* unknown address */
RETS: <0x03fc7608> { _do_bootm + 0x344 }
PC : <0x03fc00b2> { _start + 0xb2 }
DCPLB_FAULT_ADDR: <0x03f5b74c> /* unknown address */
ICPLB_FAULT_ADDR: <0x002b3130> /* unknown address */
PROCESSOR STATE:
R0 : ffb00000 R1 : ffffeff1 R2 : 00000fd4 R3 : fffffff7
R4 : 00000002 R5 : 02000000 R6 : 02000040 R7 : 00000001
P0 : ffb00000 P1 : 03f60042 P2 : 001e2754 P3 : 03f5bb40
P4 : 03fe3efc P5 : 03f5c000 FP : 03fd5518 SP : 03f5b67c
LB0: 03fd3a54 LT0: 03fd3a48 LC0: 00000000
LB1: 03fcdfda LT1: 03fcdfd4 LC1: 00000000
B0 : 00000008 L0 : 00000000 M0 : 0000003f I0 : 00000007
B1 : 03f6a750 L1 : 00000000 M1 : 0000000f I1 : 03f62f98
B2 : 03f6c210 L2 : 00000000 M2 : ff807ffc I2 : 00001858
B3 : 000001ff L3 : 00000000 M3 : 03fd8bf4 I3 : 00000000
A0.w: fffb3376 A0.x: ffffffff A1.w: ffffea53 A1.x: ffffffff
USP : 01d3fdbc ASTAT: 00002000
Hardware Trace:
0 Target : <0x03fc0940> { _bfin_panic + 0x0 }
Source : <0x03fc0b14> { _trap_c + 0x198 }
1 Target : <0x03fc0b0a> { _trap_c + 0x18e }
Source : <0x03fc0996> { _trap_c + 0x1a }
2 Target : <0x03fc097c> { _trap_c + 0x0 }
Source : <0x03fc0416> { _trap + 0x56 }
3 Target : <0x03fc03c0> { _trap + 0x0 }
Source : <0x002b312e> /* unknown address */
4 Target : <0x001e2754> /* unknown address */
Source : <0x03fd1cd2> { _do_bootm_linux + 0x92 }
5 Target : <0x03fd1cc8> { _do_bootm_linux + 0x88 }
Source : <0x03fc01e2> { _dcache_disable + 0x1e }
6 Target : <0x03fc01c4> { _dcache_disable + 0x0 }
Source : <0x03fd1cc4> { _do_bootm_linux + 0x84 }
7 Target : <0x03fd1cc0> { _do_bootm_linux + 0x80 }
Source : <0x03fc0104> { _dcache_status + 0x10 }
8 Target : <0x03fc00f4> { _dcache_status + 0x0 }
Source : <0x03fd1cbc> { _do_bootm_linux + 0x7c }
9 Target : <0x03fd1cbc> { _do_bootm_linux + 0x7c }
Source : <0x03fd1cb6> { _do_bootm_linux + 0x76 }
10 Target : <0x03fd1cb4> { _do_bootm_linux + 0x74 }
Source : <0x03fc00f0> { _icache_status + 0x10 }
11 Target : <0x03fc00e0> { _icache_status + 0x0 }
Source : <0x03fd1cb0> { _do_bootm_linux + 0x70 }
12 Target : <0x03fd1ca0> { _do_bootm_linux + 0x60 }
Source : <0x03fc11b8> { _strncpy + 0x1c }
13 Target : <0x03fc11b6> { _strncpy + 0x1a }
Source : <0x03fc11ae> { _strncpy + 0x12 }
14 Target : <0x03fc11a8> { _strncpy + 0xc }
Source : <0x03fc11b4> { _strncpy + 0x18 }
15 Target : <0x03fc11a8> { _strncpy + 0xc }
Source : <0x03fc11b4> { _strncpy + 0x18 }
Please reset the board
### ERROR ### Please RESET the board ###
==========================================
Should I be seeing something different?
-Matt
QuoteReplyEditDelete
2010-03-15 14:38:24 Re: ACK! on kernel 2009 R1 startup.
Mike Frysinger (UNITED STATES)
Message: 87215
did you turn off both icache and dcache ?
unfortunately, if you arent booting on an ADI board like a BF537-STAMP and thus there's no way for me to take your binaries and boot/reproduce, then you're pretty much on your own. afaik, these issues are fixed in current releases and require changes in u-boot. anything else would require you custom hacking the kernel init code to disable CPLB checking.
QuoteReplyEditDelete
2010-03-15 20:02:17 Re: ACK! on kernel 2009 R1 startup.
Brent Kandetzki (UNITED STATES)
Message: 87223
I've been having the exact same problem on my board. I have an BF532-IP04. I've been trying to get the 2009R1 kernel running. I ported the 2009R1 u-boot to my board succefully, but all kernel images fail in the same way. It seems to be happening so early that there is no post mortem information to retrieve.
Hardware Trace:
0 Target : <0x03fc0b4c> { _bfin_panic + 0x0 }
Source : <0x03fc0cc8> { _trap_c + 0x140 }
1 Target : <0x03fc0cbc> { _trap_c + 0x134 }
Source : <0x03fc0ba4> { _trap_c + 0x1c }
2 Target : <0x03fc0b88> { _trap_c + 0x0 }
Source : <0x03fc0508> { _trap + 0x60 }
3 Target : <0x03fc04a8> { _trap + 0x0 }
Source : <0x00222002> /* unknown address */
4 Target : <0x001b7260> /* unknown address */
Source : <0x03fd2ce8> { _do_bootm_linux + 0x74 }
5 Target : <0x03fd2cda> { _do_bootm_linux + 0x66 }
Source : <0x03fc12b4> { _dcache_disable + 0x18 }
6 Target : <0x03fc129c> { _dcache_disable + 0x0 }
Source : <0x03fd2cd6> { _do_bootm_linux + 0x62 }
7 Target : <0x03fd2cd6> { _do_bootm_linux + 0x62 }
If I'm using the 2009r1 of the kernel and u-boot, is there anything else to look at?
BTW I can boot older kernels succesfully.
QuoteReplyEditDelete
2010-03-16 10:08:34 Re: ACK! on kernel 2009 R1 startup.
Robin Getz (UNITED STATES)
Message: 87259
Brent:
As Mike suggested -- upgrade U-Boot. This is the only thing that we know will fix the issue.
-Robin
QuoteReplyEditDelete
2010-03-16 10:09:32 Re: ACK! on kernel 2009 R1 startup.
Robin Getz (UNITED STATES)
Message: 87260
Brent/Matt:
If you are worried about flashing U-Boot, use the old U-Boot to download and run a newer U-Boot from SDRAM.
-Robin
QuoteReplyEditDelete
2010-03-16 10:55:47 Re: ACK! on kernel 2009 R1 startup.
Brent Kandetzki (UNITED STATES)
Message: 87269
I believe I'm running the latest version of u-boot.
U-Boot 2008.10 (ADI-2009R1.1-rc1) (Mar 16 2010 - 09:37:24)
If it is not, I will be happy to rebuild.
QuoteReplyEditDelete
2010-03-16 14:54:16 Re: ACK! on kernel 2009 R1 startup.
Brent Kandetzki (UNITED STATES)
Message: 87286
I've looked at the memory using post mortem and a jtag emulator.
There doesn't seem to be any code at the entry point 0x1b7260. It's just nop's until it hits an invalid opcode at 0x222002.
Is this a cache issue or just some sort of unpacking problem in uboot?
QuoteReplyEditDelete
2010-03-16 15:32:47 Re: ACK! on kernel 2009 R1 startup.
Robin Getz (UNITED STATES)
Message: 87288
Brent:
Can you boot the default kernel? or is this something you have built?
-Robin
QuoteReplyEditDelete
2010-03-16 16:42:12 Re: ACK! on kernel 2009 R1 startup.
Mike Frysinger (UNITED STATES)
Message: 87292
you should post the u-boot patch to the u-boot mailing list so we can get it merged
we'll look at getting an IP04 to reproduce things, but it'll take some time ...
QuoteReplyEditDelete
2010-03-16 21:05:54 Re: ACK! on kernel 2009 R1 startup.
Brent Kandetzki (UNITED STATES)
Message: 87294
Robin - No kernel that I've built under the 2009R1 distribution has booted. I've tried a default build of the bf533-stamp with the same results. I'm currently working with a custom kernel, however, I don't think the kernel is to blame. Whatever is wrong is happening with the packaging of the kernel.
Mike - I will be happy to post the u-boot and kernel patches once things start to behave.
I've been working with the kernel images to try to narrow down the problem. If I bootelf images/linux (I must 'dcache off' or the load will throw an exception) itshows the same problem as the bootm of images/uImage. However, I just tried to bootelf linux-2.6.x/linux and it looked like there was code at the entry point. This would seem to indicate that there is some sort of compression/decompression issue in my build or in u-boot.
I'm accessing my system remotely and it needs to be manually reset, so I will have to wait to do more testing in the morning.
QuoteReplyEditDelete
2010-03-16 23:54:51 Re: ACK! on kernel 2009 R1 startup.
Mike Frysinger (UNITED STATES)
Message: 87298
you see the same problem with the bf533-stamp ? or you're trying to boot the bf533-stamp kernel on the IP04 ?
QuoteReplyEditDelete
2010-03-17 11:10:28 Re: ACK! on kernel 2009 R1 startup.
Brent Kandetzki (UNITED STATES)
Message: 87332
I'm starting to understand the problem a bit more.
First problem - I believe there I have legacy Makefile problem. When trying to upgrade to the new kernel, I used the older vendor configuration files. The Makefile in the vendor/myVendor/myBoard directories does the final image packaging. I believe this is causing code location problems. This may be what Matt Gilg is experiencing, as he is trying to upgrade to the new kernel with a legacy build. This caused my build to create a kernel, that when unpacked, has no code at the entry point. Eventually, there is a invalid opcode. Since no code was executed, the u-boot handlers are still in place and catch the exception.
Second problem - My kernel seems to be having a problem in bfin_relocate_l1_mem. During the call to early_dma_memcpy below the comment /* if necessary, copy _stext_l1 to _etext_l1 to L1 instruction SRAM */, the code for memset (which for my build is located at 0xffa09488) is corrupted. Curiosly, it seems to be in the area being copied, which is noted in the comments why memcpy can't be used. Later on, in init_pda, memset is called which results in an invalid opcode. The kernel has installed handlers, but no serial support, so no indication of the exception is possible. The result is that the kernel seems to hang after the u-boot kernel entry message.
Should memset be called after the relocation? I'll look into the DMA copy a bit more and see if anything looks odd.
QuoteReplyEditDelete
2010-03-17 11:30:12 Re: ACK! on kernel 2009 R1 startup.
Mike Frysinger (UNITED STATES)
Message: 87334
once bfin_relocate_l1_mem() has finished, all on-chip memory regions should be valid, and anyone is free to call memcpy() or memset()
QuoteReplyEditDelete
2010-03-17 12:07:26 Re: ACK! on kernel 2009 R1 startup.
Brent Kandetzki (UNITED STATES)
Message: 87336
So...
The data from __l1_lma_start is being copied into _stext_l1.
If this is the case, __l1_lma_start does not contain a valid copy of memset because what gets copied into that location is invalid opcodes.
QuoteReplyEditDelete
2010-03-17 12:37:18 Re: ACK! on kernel 2009 R1 startup.
Matt Gilg (UNITED STATES)
Message: 87338
Brent:
I believe you are exactly correct, yesterday I discovered that if I build for the 537 stamp, the image executes without error.
I also noticed that if I replace our own config.linux-2.6.x with the default for the stamp, the image executes correctly. (without my custom kernel changes included) Probably worth noting that I can get the kernel to build and execute without a change to our custom makefile...
That said, I suppose finding out which config option is causing this to break is my next step.
If this is indeed a problem with "legacy" configuration (even though our kernel was updated less than 1 year ago), is there any way around the configuration nightmare? That this was a big problem last time we did the update, however it never prevented our image from loading correctly.
Thanks again,
-Matt
QuoteReplyEditDelete
2010-03-17 13:34:03 Re: ACK! on kernel 2009 R1 startup.
Brent Kandetzki (UNITED STATES)
Message: 87340
Matt-
I was thinking that the problem was isolated to the Makefile in the vendors/myVendor/myBoard directory. You shouldn't need to reconfigure anything. I would try copying the vendors/AnalogDevices/BF537-STAMP/Makefile file to the directory where your Makefile is and try rebuilding.
QuoteReplyEditDelete
2010-03-17 14:19:36 Re: ACK! on kernel 2009 R1 startup.
Brent Kandetzki (UNITED STATES)
Message: 87341
Matt -
I followed my own advice. I copied the makefile from vendors/AnalogDevices/BF533-STAMP to vendors/Rowetel/IP04-2008. I also had to copy the vendors/AnalogDevices/common directory to vendors/Rowetel/common. I succesfully booted the kernel and image.
Mike - I'm assuming everything I was doing wrong had to do with this old Makefile. The kernel was getting packed differently than u-boot was expecting. This was causing the missing code at the entry point. My other mistake was trying to boot the unpacked elf kernel. I assume that the l1 area was being relocated to l1_lma_start during the packing, and then moved back by the kernel during boot. Now that I have the correct Makefile, it will pack the kernel as u-boot expects.
After I do some cleanup I'll post the u-boot and uClinux vendor patches.
QuoteReplyEditDelete
2010-03-17 21:51:20 Re: ACK! on kernel 2009 R1 startup.
Mike Frysinger (UNITED STATES)
Message: 87355
for u-boot, i'd post them to the list and i'll review + merge. for the uclinux-dist / linux-kernel, we could just give you commit access. once you post the changes to the list and get feedback, you'd be free to commit stuff and updates yourself ...
QuoteReplyEditDelete
2010-03-19 09:58:57 Re: ACK! on kernel 2009 R1 startup.
Brent Kandetzki (UNITED STATES)
Message: 87481
Mike -
I'm new to the linux community, so I'm not sure which list you wanted me to post to. All the mailing lists seem to be archived so I figured this must be the place. If this isn't the right place, just point me in the right direction.
FYI, I discoved a few dependency problems along the way.
'board/myBoard/u-boot.lds' doesn't get recompiled on changes to 'include/config/myBoard.h'. I had changed CFG_MONITOR_LEN and the .lds file didn't recompile. I know the Makefile for that is in 'board/myBoard/u-boot.lds', but I just copied from the bf533-stamp board, so I assume that the problem is universal.
'cpu/blackfin/initcode.o' doesn't get recompiled on changes to 'include/config/myBoard.h'. I changed the memory configuration, like CONFIG_EBIU_SDGCTL_VAL, and it didn't recompile.
My Makefile prowess isn't stellar yet, so I was going to leave that to the experts.
Thanks for the help.
u-boot-ip04.patch
QuoteReplyEditDelete
2010-03-19 12:31:25 Re: ACK! on kernel 2009 R1 startup.
Mike Frysinger (UNITED STATES)
Message: 87485
i'm referring to this mailing list for u-boot:
https://blackfin.uclinux.org/mailman/listinfo/u-boot-devel
reviewing patches on the mailing list is a lot easier
the u-boot.lds issue is a problem with all boards, not just Blackfin ones. it is known upstream, but no one really cares enough to tackle the problem.
i'll file a tracker item for the initcode.o issue