Hi all,
To close out this thread, a fix is to add a "mem=" option to uboot's
bootargs variable ---
1. Connect a PC to the ROACH2's "FTDI USB" port using a usb A->B cable.
2. Open a serial console on the roach 2 using
minicom/picocom/your-favourite-serial-console. The interface settings
are 115200,N,8.
If you're using a linux PC and don't have other things connected, the
device will be ttyUSB2.
3. Reboot your roach. You should see the reboot in your serial console.
When prompted, hit any key to halt the boot sequence.
4. Manually add a mem option to your bootargs with:
setenv bootargs $bootargs mem=$mem
(This assumes you have a mem variable already set with the correct value.
Otherwise you could use mem=512M)
5. Save the new variable with:
saveenv
6. Reboot your roach. If you log in to the PowerPC and run top or look in
/proc/meminfo you should now see the correct quantity of ram.
Cheers,
Jack
On Wed, 24 Jun 2015 at 16:50 John Ford <jf...@nrao.edu> wrote:
> Hi all.
>
> We were having problems with multiple sequentail progdev calls failing on
> our ROACH-2 systems. We were testing multiple bof files in a loop, and
> the roach would fall over and crash completely, and after the kernel
> panic, it would reboot itself.
>
> After a great deal of concentrated debugging effort this afternoon by
> Jack, David, Justin, Ryan, Arindam, Randy, and me, the cause of the
> crashing upon multiple progdev calls was found. It turned out to have
> nothing to do with programming the chip, rather it was a problem with
> memory allocation by the operating system. Jack found that problem could
> also be caused by allocating a huge array in Python, using lots of memory.
>
> The problem was caused by the kernel thinking that the ROACH has 768 MB of
> memory on board, when in fact it has only 512 MB. The fix is to pass the
> real amount of memory to the kernel in the bootargs. the systems have
> been mostly working for a long time (Years!), so you may want to check
> that your systems know in fact how much memory they have. If you start up
> top you can see what it thinks, or look in /proc/meminfo.
>
> John
>
>
>
>
>
>
