On Sun, Jul 22, 2012 at 12:03:25AM +0200, Wolfgang Denk wrote:
> Dear Markus Hubig,
>
> In message <20120720142655.gb20...@imko.de> you wrote:
> >
> > And the only setting I found in my board support code (stamp9g20.h)
> > that is obviously realated to this "malloc-thing" is:
> >
> > | #define CONFIG_SYS_MALLOC_LEN ROUND(3 * CONFIG_ENV_SIZE \
> > | + 128*1024, 0x1000)
> > | #define CONFIG_SYS_GBL_DATA_SIZE 128
>
> See commit 25ddd1f and get rid of CONFIG_SYS_GBL_DATA_SIZE
>
> > but this values are all copied from the original (and once working)
> > patch from taskit ...
>
> once working = now obsoleted.
Hmm OK. I got rid of this config setting. But I'm actually not a single
step further... I looked at every single commit of the at91sam9260ek code
to get a understanding what the problem is but didn't get a clue ...
Is it the nand? If I don't enable #DEBUG u-boot mostly stops at the
"NAND: "-Prompt. But the nand stuff in my stam9g20.c file is actually the
same as in at91sam9260ek.c:
| static void stamp9g20_nand_hw_init(void)
| {
| struct at91_smc *smc = (struct at91_smc *)ATMEL_BASE_SMC;
| struct at91_matrix *matrix = (struct at91_matrix *)ATMEL_BASE_MATRIX;
| unsigned long csa;
|
| /* Assign CS3 to NAND/SmartMedia Interface */
| csa = readl(&matrix->ebicsa);
| csa |= AT91_MATRIX_CS3A_SMC_SMARTMEDIA;
| writel(csa, &matrix->ebicsa);
|
| /* Configure SMC CS3 for NAND/SmartMedia */
| writel(AT91_SMC_SETUP_NWE(1) | AT91_SMC_SETUP_NCS_WR(0) |
| AT91_SMC_SETUP_NRD(1) | AT91_SMC_SETUP_NCS_RD(0),
| &smc->cs[3].setup);
| writel(AT91_SMC_PULSE_NWE(3) | AT91_SMC_PULSE_NCS_WR(3) |
| AT91_SMC_PULSE_NRD(3) | AT91_SMC_PULSE_NCS_RD(3),
| &smc->cs[3].pulse);
| writel(AT91_SMC_CYCLE_NWE(5) | AT91_SMC_CYCLE_NRD(5),
| &smc->cs[3].cycle);
| writel(AT91_SMC_MODE_RM_NRD | AT91_SMC_MODE_WM_NWE |
| AT91_SMC_MODE_EXNW_DISABLE |
| AT91_SMC_MODE_DBW_8 |
| AT91_SMC_MODE_TDF_CYCLE(2),
| &smc->cs[3].mode);
|
| /* Configure RDY/BSY */
| at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
|
| /* Enable NandFlash */
| at91_set_gpio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1);
|
| }
Is it a relocation problem? If I enable #DEBUG u-boot mostly stops at the
relocation prombt here:
| relocation Offset is: 0007c000
or here:
| relocation Offset is: 0007e000
| WARNING: Caches not enabled
| monitor flash len: 00035820
| Now running in RAM - U-Boot at: 23f7e000
I looked at every single byte on the internet an I found some information
that in order to get this bad-ass relocation to work, one needs to adapt
at91bootstrap to work with u-boot. Could this be my problem? At the moment
I'm using the original at91bootstrap from taskit.
Here is what I think the problem could, maybe, be:
1. Board gets powered on.
2. at91bootstrap magically starts.
3. It reads IMG_SIZE from IMG_ADDRESS and writes it to JUMP_ADDR in RAM.
- IMG_ADDRESS is where I write u-boot to inside NAND?
- IMG_SIZE should be the size of u-boot.bin? (exactly or is a bigger
size OK?)
- JUMP_ADDR is where u-boot is relocated to in RAM. Should be
CONFIG_SYS_TEXT_BASE?
4. at91bootstrap sets the PC to JUMP_ADDR and starts u-boot.
Since IMG_SIZE in at91bootstrap is not the size of my new u-boot.bin it
crashes after relocation!
I tried to build at91bootstrap_3.x from
https://github.com/linux4sam/at91bootstrap
but it didn't work. What is the preferred version to use? Orig from atmel? 3.x
2.x?
Cheers, Markus
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
