1

I’ve ported uboot and uclinux on my DISCO board (stm32f429-disco) using robotest files on github recently. Now I’m trying to port them on my custom board which uses:

  • UART6 instead of UART3
  • a 12 MHz oscillator instead of the 8 MHz usedin DISCO
  • a 128 Mb SDRAM instead of the one used in DISCO
  • uses SDRAM bank 1 instead of bank2(start address is 0xC0000000 instead of 0xD0000000).

So I made some changes on uboot tree:

  • u-boot-master\board\stm\stm32429-disco\board.c
  • u-boot-master\cpu\arm_cortexm3\stm32\clock.c
  • u-boot-master\cpu\arm_cortexm3\stm32\fmc.c
  • u-boot-master\include\asm-arm\arch-stm32\fmc.h
  • u-boot-master\include\configs\stm32429-disco.h

And also I made some changes on ucliux tree:

  • uclinux-master\config.rubotest
  • uclinux-master\arch\arm\mach-stm32

when I make images and load them on my board I got the following result:

     U-Boot 2010.03 (Jun 09 2017 - 06:48:57)

CPU  : STM32F4 (Cortex-M4)
Freqs: SYSCLK=180MHz,HCLK=180MHz,PCLK1=45MHz,PCLK2=90MHz
Board: STM32F429II-SADR board,Rev 1.0
DRAM:   8 MB
Using default environment

Hit any key to stop autoboot:  0
## Booting kernel from Legacy Image at 08020000 ...
   Image Name:   Linux-2.6.33-arm1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    889248 Bytes = 868.4 kB
   Load Address: 08020040
   Entry Point:  08020041
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

And the kernel stucks in here and then nothing happens. I wonder if the problem is related to uboot or the kernel and what it is!!! guys it’s been more than a month I’m working on this project and I’ really exhausted. Any helps would be appreciated. best regards.

I changed the load address and entery point to 0x08008000 and 0x08008001 and this is the result:

    `U-Boot 2010.03 (Jun 09 2017 - 06:48:57)

CPU  : STM32F4 (Cortex-M4)
Freqs: SYSCLK=180MHz,HCLK=180MHz,PCLK1=45MHz,PCLK2=90MHz
Board: STM32F429II-SADR board,Rev 1.0
DRAM:   8 MB
Using default environment

Hit any key to stop autoboot:  0
## Booting kernel from Legacy Image at 08020000 ...
   Image Name:   Linux-2.6.33-arm1
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    889312 Bytes = 868.5 kB
   Load Address: 08008000
   Entry Point:  08008001
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

UNHANDLED EXCEPTION: HARD FAULT
  R0    = 00000000  R1  = 0002ec05
  R2    = 0002ec04  R3  = 1ffec3bd
  R12   = 00000030  LR  = 0800c67b
  PC    = 08008074  PSR = 21000000`

And this is the result of printenv :

    STM32429-DISCO> printenv
bootcmd=run flashboot
bootdelay=0
baudrate=115200
hostname=stm32429-disco
loadaddr=0xC0000000
addip=setenv bootargs ${bootargs}
flashaddr=08020000
flashboot=run addip;bootm ${flashaddr}
image=uImage
stdin=serial
stdout=serial
stderr=serial
bootargs=stm32_platform=stm32429-disco mem=7M console=ttyS2,115200n8 
consoleblan
k=0 root=/dev/mtdblock0 rdinit=/sbin/init 
video=vfb:enable,fbmem:0x90700000,fbsi
ze:0x100000

Environment size: 412/1020 bytes
STM32429-DISCO>

loadaddr was 0x90000000 at first, and the hacker had used memrmp register to remap it in to 0xD000000 (at DISCO board 0xD0000000 is the start of SDRAM bank). I commented the memrmp line in fmc.c and there was no any remap anymore. I also changed the #define CONFIG_SYS_RAM_BASE from 0x90000000 to 0xC0000000 at include/config/stm32f429 file. I changed SDRAM bank address from 0xD0000000 to 0xC0000000 at fmc.h file ,too.

mehdi_sd
  • 49
  • 6
  • What did you do to check where it stacks? HF, DF or in some kind of dead loop? It shows wrong RAM size anyway (8 instead of 12MB). Your question is so brad and complicated, and I afraid there is no way to help you remotely. You will need to set breakpoints, connect your debugger and attach it to the running target or at least use some kind of signals (like LED) to show some debug information. – 0___________ Jun 13 '17 at 13:28
  • Looks like the bootloader got stuck, maybe you edited it and added some line that prevented it from continuing the boot process. – DarkCygnus Jun 13 '17 at 16:20
  • *"start address is 0xC0000000"* -- Then the **mkimage** wrapper has bogus information, and has the kernel in nonexistent memory, i.e. *"Load Address: 08020040"*. What is in the U-Boot environment (i.e. `printenv` command)? Have you performed any comprehensive memory tests on this board? – sawdust Jun 13 '17 at 19:42
  • @GrayCygnus As I mentioned above I DID some editions on the listed files, are you sure it's because of u-boot? what about if it is because of wrong UART cofiguratin in uclinux?which I dont know how to fix! I mean what makes you sure about u-boot hanging? – mehdi_sd Jun 13 '17 at 20:05
  • @sawdust this is the contents of image wrapper which worked properly on my DISCO board: `#!/bin/sh rm xipuImage.bin cat tempfile xipImage > xipImage.bin mkimage -x -A arm -O linux -T kernel -C none -a 0x08020040 -e 0x08020041 -n "Linux-2.6.33-arm1" -d xipImage.bin xipuImage.bin rm xipImage.bin ` the board works with no problem without OS! In my my DISCO board I used to load the xipuimage.bin to the 0x08020000 and the entery point and load address were as you can see. – mehdi_sd Jun 13 '17 at 20:11
  • @mehdi_sd I suspect it is hanging as it looks almost exactly the same as the problems I have had when doing similar stuff (Mostly on Raspberry Pi). I edited some lines, adding some operations before kernel loading, and sometimes those operations did not return anything or got into an infinite loop, preventing the booting process to continue – DarkCygnus Jun 13 '17 at 20:19
  • @sawdust By the way I changed load address in the config and wrapper files to 0xC0000000 but this time I got hard fault after starting kernel... – mehdi_sd Jun 13 '17 at 20:21
  • @GrayCygnus thanks for your quick answers dude, could you mention clearly what kind of changes you made?on which files? – mehdi_sd Jun 13 '17 at 20:24
  • @mehdi_sd No problem ;) I was working with the `rc.local` and also the `init.d` files. Take a look at [this](https://www.raspberrypi.org/documentation/linux/usage/rc-local.md) RPi Doc and [this](https://raspberrypi.stackexchange.com/questions/8734/execute-script-on-start-up) RPi Stack Exchange Question. Basically, as the first link warns, I forgot to add the `&` at the end of the line I added, which caused that, for whatever reason It was, my program did not return or looped, preventing the boot process to continue. Hope this sheds some light on your problem – DarkCygnus Jun 13 '17 at 20:40
  • @GrayCygnus You know, as I've heared uc-linux has some differences with linux and I think because of those differences I don't have such files in my tree, actually I'm using [link](https://github.com/robutest) files to make bootloader and kernel images. – mehdi_sd Jun 13 '17 at 21:22
  • You still have not posted your U-Boot environment. Add this info to your post, not in the comments. If the DISCO board booted as you claimed with goofy addresses, then you need to provide actual evidence. See https://stackoverflow.com/questions/30488942/how-to-boot-linux-kernel-from-u-boot/30491932#30491932 *"By the way I changed load address ..."* -- Well that is still wrong, because a proper load address and entry point would be the start of physical memory plus 0x8000 for ARM. See https://stackoverflow.com/questions/39767332/embedded-linux-arm-booting-address/39779338#39779338 – sawdust Jun 13 '17 at 21:37
  • @sawdust I posted the outputs you've asked about. – mehdi_sd Jun 13 '17 at 22:36
  • Looks like you have an XIP kernel, so that explains why the the goofy 0x0802... addresses works. Since you want to use *"UART6 instead of UART3"*, then `console=ttyS2,115200n8` in variable **bootargs** probably needs to change. Why is the value of **bootargs** chopped up and displayed on 5 lines? If you've enabled CONFIG_EARLY_PRINTK in the kernel (you probably should), then you should activate it in **bootargs** also. – sawdust Jun 13 '17 at 23:35
  • @sawdust My board sends some garbage data via serial port and I can not use it to show printenv thats why I used DISCO board output and because of that, UART3 was shown instead of 6. How can I enable CONFIG_PRINTK in kernel and uboot? On which path that exists? – mehdi_sd Jun 14 '17 at 00:06
  • @sawdust I think the problem is related to SDRAM bank change but I dont know how to fix it,I've already changed SDCMR,SDCR,SDTR, sdram_bank_address, but still it doesn't work. Maybe it's because of that memrmp which I disabled! Config_ram_base was 0x90000000 and I made it 0xC0000000,maybe thats because of this one,I'm not even sure if its because of uboot or kernel! Maybe it works and the problem is just because of wrong UART config in kernel ... . It really drives me crazy. – mehdi_sd Jun 14 '17 at 00:17
  • *"My board sends some garbage data via serial port ... I used DISCO board output ...."* -- **So you've posted bogus output instead of of the actual information used by the board?** So exactly what is the real information that indicates what is actually going on? If you're going to make up stuff, then you deserve to be driven crazy. Previously you claimed that *"the board works with no problem without OS!"* Well, obviously that's not true if you cannot get `printenv` to output. – sawdust Jun 14 '17 at 02:09
  • @sawdust NO man!! I havnt edited or changed anything, the board works right with no OS and no boot loader! When I load uboot on it,after I hit reset button, uboot works properly,but after it finishes the board sends garbage data like: >>>>>>>>>>>>>>>>...and when I reset the board, the same thing happens, why should I makeup anything?! – mehdi_sd Jun 14 '17 at 04:20

0 Answers0