[U-Boot-Users] sam9263ek not booting uboot dataflash
Hi All, I made some changes to u-boot-1.1.5 atmel patch 1.5 and rebuild uboot. However, after rebuilding it would not run uboot. Has anyone had this problem before? If I rewrite the dataflash with the pre-built uboot image, then it boots so I guess I might be missing something. DataFlash is enabled and all the options looks good so I'm not sure why it's stuct at the RomBoot. I've rebuild both the dataflash bootstrap and uboot several time with no luck so far. Does anyone have any ideas? Thanks.
Hi,
Hi All, I made some changes to u-boot-1.1.5 atmel patch 1.5 and rebuild uboot. However, after rebuilding it would not run uboot. Has anyone had this problem before?
What type of changes?
If I rewrite the dataflash with the pre-built uboot image, then it boots so I guess I might be missing something. DataFlash is enabled and all the options looks good so I'm not sure why it's stuct at the RomBoot. I've rebuild both the dataflash bootstrap and uboot several time with no luck so far. Does anyone have any ideas? Thanks.
Michael
On 2/12/08, michael trimarchi@gandalf.sssup.it wrote:
Hi,
Hi All, I made some changes to u-boot-1.1.5 atmel patch 1.5 and rebuild uboot. However, after rebuilding it would not run uboot. Has anyone had this problem before?
What type of changes?
Makefile and config.mk files for my compiler. That's about it. Oh, I also edited the display properties for my display.
If I rewrite the dataflash with the pre-built uboot image, then it boots so I guess I might be missing something. DataFlash is enabled and all the options looks good so I'm not sure why it's stuct at the RomBoot. I've rebuild both the dataflash bootstrap and uboot several time with no luck so far. Does anyone have any ideas? Thanks.
Michael
E Robertson wrote:
On 2/12/08, michael trimarchi@gandalf.sssup.it wrote:
Hi,
Hi All, I made some changes to u-boot-1.1.5 atmel patch 1.5 and rebuild uboot. However, after rebuilding it would not run uboot. Has anyone had this problem before?
What type of changes?
Makefile and config.mk files for my compiler. That's about it. Oh, I also edited the display properties for my display.
So, do you change the text base? Michael
On 2/12/08, michael trimarchi@gandalf.sssup.it wrote:
E Robertson wrote:
On 2/12/08, michael trimarchi@gandalf.sssup.it wrote:
Hi,
Hi All, I made some changes to u-boot-1.1.5 atmel patch 1.5 and rebuild uboot. However, after rebuilding it would not run uboot. Has anyone had this problem before?
What type of changes?
Makefile and config.mk files for my compiler. That's about it. Oh, I also edited the display properties for my display.
So, do you change the text base?
No I did not. I don't have a reason to. Why?
On 2/12/08, michael trimarchi@gandalf.sssup.it wrote:
Hi,
So, do you change the text base?
No I did not. I don't have a reason to. Why?
Sorry I think that you talk about config.mk board/<your board>/config.mk
TEXT_BASE = 0x21f00000
On the 9263 it is 0x23F00000 and I believe I checked the bootstrap to correspond to the same address. So, no not that config.mk file. Thanks anyway.
On 2/12/08, michael trimarchi@gandalf.sssup.it wrote:
Hi, E Robertson wrote:
On 2/12/08, michael trimarchi@gandalf.sssup.it wrote:
Hi,
So, do you change the text base?
No I did not. I don't have a reason to. Why?
Is the new size compatible with the armboot? Do you skip LOW_LEVEL_INIT?
Yes, it is skipped. From what I understood Bootstrap does the necessary boot init tasks (althought I would rather put it in uboot). Do I need to changs this?
Hi,
Yes, it is skipped. From what I understood Bootstrap does the necessary boot init tasks (althought I would rather put it in uboot). Do I need to changs this?
No,
I will try to help you. Do you check the new size, format, etc... The new size fit in you flash, do you write somenthing after the u-boot that overwrite it. Do you try to load with a jtag in memory and execute it?
Regards Michael
On 2/12/08, michael trimarchi@gandalf.sssup.it wrote:
Hi,
Yes, it is skipped. From what I understood Bootstrap does the necessary boot init tasks (althought I would rather put it in uboot). Do I need to changs this?
No,
I will try to help you. Do you check the new size, format, etc... The new size fit in you flash, do you write somenthing after the u-boot that overwrite it.
When you said new size, I take to mean the size of the binary images. In that case boot the Bootstrap and uboot image size are smaller that the prebuilt onces. Bootstrap is written @ 0 and uboot @ 0x8000 (a 32K size). Bootstrap is under 4K and uboot is under 185K. so I have lots of space. The fact that I can rewrite my build uboot with the prebuilt uboot image and this works ok leads me to believe their might be something with the build that may be compiler related, but I'm not sure. Or, it's something simple I'm missing.
I write my Bootstrap build @ 0 so that the only variable change is u-boot image.
Do you try to load with a jtag in memory and execute it?
I don't have a jtag fitted for this as yet. I'm using the sam7 util.
On 2/12/08, michael trimarchi@gandalf.sssup.it wrote:
Hi,
Do you try to load with a jtag in memory and execute it?
I don't have a jtag fitted for this as yet. I'm using the sam7 util.
Simple step:
- flash the work system
- loady <address>
put you version of u-boot and run go <address>
Once I start using sam7 util, the bootstrap code has not been executed which means the SDRAM has not been initialized. I'll have to added the lowlevel init to do that, which I might try if nothing else works.
E Robertson wrote:
On 2/12/08, michael trimarchi@gandalf.sssup.it wrote:
Hi,
Do you try to load with a jtag in memory and execute it?
I don't have a jtag fitted for this as yet. I'm using the sam7 util.
Simple step:
- flash the work system
- loady <address>
put you version of u-boot and run go <address>
Once I start using sam7 util, the bootstrap code has not been executed which means the SDRAM has not been initialized. I'll have to added the lowlevel init to do that, which I might try if nothing else works.
You don't understand:
- flash all arm9load & u-boot - loady <address> u-boot-mod - go <address>
Regards Michael
On 2/12/08, michael trimarchi@gandalf.sssup.it wrote:
E Robertson wrote:
On 2/12/08, michael trimarchi@gandalf.sssup.it wrote:
Hi,
Do you try to load with a jtag in memory and execute it?
I don't have a jtag fitted for this as yet. I'm using the sam7 util.
Simple step:
- flash the work system
- loady <address>
put you version of u-boot and run go <address>
Once I start using sam7 util, the bootstrap code has not been executed which means the SDRAM has not been initialized. I'll have to added the lowlevel init to do that, which I might try if nothing else works.
You don't understand:
- flash all arm9load & u-boot
- loady <address> u-boot-mod
- go <address>
I'm tying this method. I had to go to kermit because I never had suscess loading serially with minicom. I had problems with kermit in the past but couldn't remember what it was... until now. I've always had fatal errors after a few bytes are transmitted. I get some error, then it tries to resend but had too many errors. I'm not really sure how to get past this as I'm configured the serial line accordingly. Is this a common "user error" problem with ckermit? I've double checked my config option with uboot docs.
Once I start using sam7 util, the bootstrap code has not been executed which means the SDRAM has not been initialized. I'll have to added the lowlevel init to do that, which I might try if nothing else works.
You don't understand:
- flash all arm9load & u-boot
- loady <address> u-boot-mod
- go <address>
I'm tying this method. I had to go to kermit because I never had suscess loading serially with minicom. I had problems with kermit in the past but couldn't remember what it was... until now. I've always had fatal errors after a few bytes are transmitted. I get some error, then it tries to resend but had too many errors. I'm not really sure how to get past this as I'm configured the serial line accordingly. Is this a common "user error" problem with ckermit? I've double checked my config option with uboot docs.
I have used "minicom" a lot when downloading to the AT91RM9200, but I use the special downloading program which I found somewhere and included in the U-Boot-1.1.2 found on buildroot.uclibc.org.
Did you try programming from Windows using SAM-BA?
Best Regards Ulf Samuelsson
On 2/12/08, Ulf Samuelsson ulf.samuelsson@atmel.com wrote:
Once I start using sam7 util, the bootstrap code has not been executed which means the SDRAM has not been initialized. I'll have to added the lowlevel init to do that, which I might try if nothing else works.
You don't understand:
- flash all arm9load & u-boot
- loady <address> u-boot-mod
- go <address>
I'm tying this method. I had to go to kermit because I never had suscess loading serially with minicom. I had problems with kermit in the past but couldn't remember what it was... until now. I've always had fatal errors after a few bytes are transmitted. I get some error, then it tries to resend but had too many errors. I'm not really sure how to get past this as I'm configured the serial line accordingly. Is this a common "user error" problem with ckermit? I've double checked my config option with uboot docs.
I have used "minicom" a lot when downloading to the AT91RM9200, but I use the special downloading program which I found somewhere and included in the U-Boot-1.1.2 found on buildroot.uclibc.org.
Did you try programming from Windows using SAM-BA?
ckermit will work just fine and I rather stick to my linux system. Linux can do everything windows does... and more.
Thanks.
E Robertson ha scritto:
On 2/12/08, michael trimarchi@gandalf.sssup.it wrote:
E Robertson wrote:
On 2/12/08, michael trimarchi@gandalf.sssup.it wrote:
Hi,
Do you try to load with a jtag in memory and execute it?
I don't have a jtag fitted for this as yet. I'm using the sam7 util.
Simple step:
- flash the work system
- loady <address>
put you version of u-boot and run go <address>
Once I start using sam7 util, the bootstrap code has not been executed which means the SDRAM has not been initialized. I'll have to added the lowlevel init to do that, which I might try if nothing else works.
You don't understand:
- flash all arm9load & u-boot
- loady <address> u-boot-mod
- go <address>
I'm tying this method. I had to go to kermit because I never had suscess loading serially with minicom. I had problems with kermit in the past but couldn't remember what it was... until now. I've always had fatal errors after a few bytes are transmitted. I get some error, then it tries to resend but had too many errors. I'm not really sure how to get past this as I'm configured the serial line accordingly. Is this a common "user error" problem with ckermit? I've double checked my config option with uboot docs.
It's a long time since I used minicom to load code on an AT91, nowadays I'm using an ICE debugger (called PEEDI) BTW the most common error was caused by 55 NAK errors and the upload failed. Maybe this hint can help, amybe not. http://www.koansoftware.com/en/art.php?art=68
-- Marco Cavallini | KOAN sas | Bergamo - Italia embedded and real-time software engineering Atmel third party consultant Phone:+39-035-255.235 - Fax:+39-178-22.39.748 http://www.KoanSoftware.com
Meet us @ Embedded World 2008 - Nurenberg February 26-28, 2008 Hall 11 - 224
When you said new size, I take to mean the size of the binary images. In that case boot the Bootstrap and uboot image size are smaller that the prebuilt onces. Bootstrap is written @ 0 and uboot @ 0x8000 (a 32K size). Bootstrap is under 4K and uboot is under 185K. so I have lots of space.
How large is the previous binary?
How much code does at91bootstrap copy to the SDRAM?
Look at board/at91sam9263ek/dataflash/at91sam9263ek.h for the definition of IMG_SIZE I have 200 kB allocated. #define IMG_SIZE 0x32000 /* Image Size in DataFlash */
You need at least #define IMG_SIZE 0x2E400 for 185 kB.
Best Regards Ulf Samuelsson
Hi,
So, do you change the text base?
No I did not. I don't have a reason to. Why?
Is the new size compatible with the armboot? Do you skip LOW_LEVEL_INIT?
Yes, it is skipped. From what I understood Bootstrap does the necessary boot init tasks (althought I would rather put it in uboot). Do I need to changs this?
You will not be able to store U-Boot in the SDRAM until the SDRAM has been initialized, so that is not an option.
Do you use a dataflashcard? It is easy to mix the chip selects.
Recompile the original source and see if you can run that.
Otherwise play with LEDs. You can also try the SAM9263EK U-Boot-1.2.0 built by buildroot at "buildroot.uclibc.org".
Best Regards Ulf Samuelsson
On 2/12/08, Ulf Samuelsson ulf.samuelsson@atmel.com wrote:
Hi,
> So, do you change the text base? > > No I did not. I don't have a reason to. Why?
Is the new size compatible with the armboot? Do you skip LOW_LEVEL_INIT?
Yes, it is skipped. From what I understood Bootstrap does the necessary boot init tasks (althought I would rather put it in uboot). Do I need to changs this?
You will not be able to store U-Boot in the SDRAM until the SDRAM has been initialized, so that is not an option.
That's correct.
Do you use a dataflashcard? It is easy to mix the chip selects.
Recompile the original source and see if you can run that.
That's the first thing I did. I originaly started with 1.2.0 then I started with the original atmel_1.2 patch and later looked at 1.5 patch.
Otherwise play with LEDs. You can also try the SAM9263EK U-Boot-1.2.0 built by buildroot at "buildroot.uclibc.org".
Best Regards Ulf Samuelsson
Hi
Is the new size compatible with the armboot? Do you skip LOW_LEVEL_INIT?
Yes, it is skipped. From what I understood Bootstrap does the necessary boot init tasks (althought I would rather put it in uboot). Do I need to changs this?
You will not be able to store U-Boot in the SDRAM until the SDRAM has been initialized, so that is not an option.
If you start u-boot that works the sdram it initialized so you can using serial line of u-boot to load a code in memory and then execute it.
Regards Michael
participants (4)
-
E Robertson -
Marco Cavallini -
michael -
Ulf Samuelsson