Good morning all,
You'll have to forgive me because this isn't an area of expertise I have but I've been tasked with it none the less. I have several P2020RDB-PCA development kits, and as part of our needs they've been modified to have 2gb of ram rather than the factory 1gb. The problem I'm having now is that the boards hang on boot. Most times it'll get to the stage of uboot in which it reports "1 GiB (DDR3, 64-bit, CL=6, ECC off)" and then it'll just sit. Sometimes after it's been left unplugged long enough it'll get through to a stage where I can interrupt autoboot. Is there something I can edit through there that would reflect the additional ram and make the board stable again?
This was work previously accomplished at my company but it would seem that the instructions that we have are a bit dated and reflect a software we no longer have nor does that company support any longer. So I'm sort of a blank canvas here and hoping a kind soul out there might have some words of wisdom for me. I see the CodeWarror TAP referenced along with the CodeWarrior software, is that my only option to try and fix this?
For some more data, I am connected through a PuTTY terminal through UART0 and when I could get it to cancel autoboot I was able to type help and get a list of commands I could use, and before I crashed again by trying to run "bootvx" I ran this...
=> bdinfo
memstart = 0x00000000
memsize = 0x40000000
flashstart = 0xEF000000
flashsize = 0x01000000
flashoffset = 0x00000000
sramstart = 0x00000000
sramsize = 0x00000000
immr_base = 0xFFE00000
bootflags = 0x00000000
intfreq = 1200 MHz
busfreq = 600 MHz
ethaddr = 00:04:9F:02:7F:B4
eth1addr = 00:04:9F:02:7F:B3
eth2addr = 00:04:9F:02:7F:B2
IP addr = 192.168.1.1
baudrate = 115200 bps
relocaddr = 0x3FF30000
Any help is much appreciated, thank you in advance.
Hi,
After you were led to use the other distributors memory, what did you updated in the system or in the images?
Have you modified the device tree node changing the memory size?
Could you try this out in u-boot?
=> pri mcmemsize
=> setenv mcmemsize 0x40000000
=> saveenv
Later, boot and try this on linux.
root@TinyLinux:~# cat /proc/meminfo
I haven't done anything to a device tree node, when I tried what you recommended in u-boot I got
Saving Environment to Flash...
Un-Protected 1 sectors
Erasing Flash...
. done
Erased 1 sectors
Writing to Flash... 9....8....7....6....5....4....3....2....1....9....8....7....6....5....4....3....2....1....done
Protected 1 sectors
but upon boot it now hangs after saying 1 GiB (DDR3, 64-bit, CL=6 ECC off)
The stage I'm in now is we received the boards back from being upgraded and have made no other changes or modifications. I think the instructions that were used before that I can't use now was possibly making use of a script to change some values but I have no idea where to find that registry to change them myself. I have a copy of the .reg files that it wanted me to try and push through WindRiver OCD but since I can't do that I was trying to find the sort of manual way to accomplish the task.
I am sorry, I mixed the commands, what I wanted to do was the following:
=> pri memsize
=> setenv memsize 0x80000000
=> saveenv
The environment variable for the memory is memsize and the size you want it to be is 2GB
Sorry for the delay in trying that and getting back to you but thank you for your continued support!
I tried editing memsize instead of mcmemsize and using 0x80000000 but at first the pri command printed nothing, so there was no previously set variable I'm guessing? Which is the same that had happened with mcmemsize. I created the variable, saved the environment, and reset to try booting back up and it still says that there is 1 gb of ram and then hangs.
U-Boot 2011.12-00064-gbfb0c9a (Jun 15 2012 - 16:58:08)
CPU0: P2020E, Version: 2.1, (0x80ea0021)
Core: E500, Version: 5.1, (0x80211051)
Clock Configuration:
CPU0:1200 MHz, CPU1:1200 MHz,
CCB:600 MHz,
DDR:400 MHz (800 MT/s data rate) (Asynchronous), LBC:37.500 MHz
L1: D-cache 32 kB enabled
I-cache 32 kB enabled
Board: P2020RDB CPLD: V4.1 PCBA: V4.0
rom_loc: nor upper bank
SD/MMC : 4-bit Mode
eSPI : Enabled
I2C: ready
SPI: ready
DRAM: Detected UDIMM
1 GiB (DDR3, 64-bit, CL=6, ECC off)
As I was poking around the things I could access in help I saw a printenv command to see what variables are set.
=> printenv
baudrate=115200
bdev=sda1
bootargs=root=/dev/mmcblk0p1 rootfstype=ext2 rw rootdelay=3 console=ttyS0,115200
bootcmd=mmcinfo; ext2load mmc 0:1 0x1000000 /boot/uImage; ext2load mmc 0:1 0xc00000 /boot/dtb_file; bootm 0x1000000 - c00000
bootdelay=10
bootfile=uImage
consoledev=ttyS0
eth1addr=00:04:9F:02:7F:B3
eth2addr=00:04:9F:02:7F:B2
ethact=eTSEC1
ethaddr=00:04:9F:02:7F:B4
fdtaddr=c00000
hostname=unknown
hwconfig=usb1:dr_mode=host,phy_type=ulpi
ipaddr=192.168.1.1
jffs2nand=mtdblock9
jffs2nor=mtdblock3
loadaddr=1000000
map_lowernorbank=i2c dev 1; i2c mw 18 1 02 1; i2c mw 18 3 fd 1
map_uppernorbank=i2c dev 1; i2c mw 18 1 00 1; i2c mw 18 3 fd 1
mcmemsize=0x40000000
memsize=0x80000000
nandboot=i2c dev 1; i2c mw 18 1 0xe8 1; i2c mw 18 3 0x03 1; reset
nandbootaddr=100000
nandfdtaddr=80000
netdev=eth0
nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr
norboot=i2c dev 1; i2c mw 18 1 0xc8 1; i2c mw 18 3 0x03 1; reset
norbootaddr=ef080000
norfdtaddr=ef040000
pciboot=i2c dev 1; i2c mw 18 1 0xa8 1; i2c mw 18 3 0x03 1; reset
ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs ramdisk_size=$ramdisk_size;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr
ramdisk_size=120000
ramdiskaddr=2000000
ramdiskfile=rootfs.ext2.gz.uboot
rootpath=/opt/nfsroot
sataboot=setenv bootargs root=/dev/sda3 rw console=$consoledev,$baudrate $othbootargs;boot
sdboot=i2c dev 1; i2c mw 18 1 0x68 1; i2c mw 18 3 0x03 1; reset
serverip=192.168.1.54
spiboot=i2c dev 1; i2c mw 18 1 0x28 1; i2c mw 18 3 0x03 1; reset
stderr=serial
stdin=serial
stdout=serial
tftpflash=tftpboot $loadaddr $uboot; protect off 0xeff80000 +$filesize; erase 0xeff80000 +$filesize; cp.b $loadaddr 0xeff80000 $filesize; protect on 0xeff80000 +$filesize; cmp.b $loadaddr 0xeff80000 $filesize
uboot=u-boot.bin
Should I try removing the mcmemsize variable? Or is my only option something like the CodeWarrior TAP at this stage?
Hi, do not worry, thanks for trying the suggestions.
I looked into the reference manual of the board and states that the maximum size is just the gigabyte that includes. Please see the next picture.
Sorry for the delay and thank you for your preference in our products!
Best regards
Sorry for the delay, I was researching and you can use 2GB of memory, but the bootloader defines the env variable that we were trying to change, also the signals that the controller may also need, please, refer to the following thread where a memory upgrade is performed.
DDR shows 1GB instead of 4GB ls1021a - NXP Community
Also, here are the instructions to compile u-boot after changing the board.c
How to compile U-Boot binary | Layerscape Software Development Kit User Guide | NXP Semiconductors
Regards
Thank you! I'll start digging into those as soon as I can. I appreciate your continued help!