Parallella Community

shogunx,
This is really great news! Somewhere along the way, I forgot how inefficient our micro-SD solution is in terms of power.(Doesn't help that it's being powered from a linear regulator...). Like finding a $20 in your pocket!
Andreas

Hi All,

I noticed when setting up an nfs server on ArchLinux that I needed to append nfsvers=3 to the variables passed to the kernel in devicetree.dtb, as such

root=/dev/nfs rw nfsroot=192.168.23.3:/srv/nfsroot,nfsvers=3

This was not necessary on a Debian based system, but I scraped the fix from a RedHat forum, so I must assume that it will effect a wide range of other systems with nfs version 4 compiled into the kernel and treated as default by the server.



Cheers,
Scott

GreyTery,

Finally got a chance to implement the workaround you pointed me to on the network reset issue. I get the same results as you... the nodes just boot now. Terrific! I also discovered something interesting. I inadvertantly transposed two characters on one node, leaving the board in a non-bootable state. It would boot the kernel, but hang. I pulled the network cable, booted again, thereby giving no fpga image, dtb, or kernel to the board. With that method, it would go into an endless loop of searching for network, but never dropped me to a u-boot shell. Given that it was essentially bricked anyway, I set the appropriate values in /etc/fw_env.config, and ran a fwsetenv despite the CRC check error warning. This indeed overwrote the factory u-boot paramaters at 0x4E0000, and upon reboot, the device dropped to a u-boot prompt again. I manually rebuilt the environment variables with setenv, referencing a working nodes configuration, and now it boots as normal. This bring another issue though... why won't fw_setenv and fw_printenv work correctly, despite the correct values in /etc/fw_env.config? Is there a bug in the CRC check as well?

Cheers
Scott

Good Morning Scott,

If anybody else is following the tftp boot approach then they will also need to exercise that patch, identified by . I use the same patch text file when automatically building the bootscript for each board so it's just as well it worked for me first time - otherwise I'd have 4 bricks!! You've proved that it's a messy, tricky, dangerous patch - but it is necessary for tftp load.
Hopefully, there are enough CAVEATs and WARNINGs in the posts and wiki guide to keep the Lawyers off my back!

It's not clear why the gigabit interface change was made to the U-Boot source in the first place. From some of Fred's posts, I understand that the U-Boot probably needs to be re-built and re-issued - in part because it's not compatible with the Vivado rebuild of the FPGA (??). Hopefully, the bug(?) will be fixed.

As for /etc/fw_env.config, fw_setenv, etc., Whoa! You're too many pages ahead of me again. But it's very useful to know that there's a way to get at a partially bricked board from the UART console. Briefly searching around forums this morning, it looks like if you get a bad CRC error, then U-Boot somehow ends up using the default, built-in variables. (But don't take my word for that).

Cheers,

I apologize if this was duplicated elsewhere and/or self-obvious but for anyone trying to tftp boot using the new parallella-linux kernel from GitHub (https://github.com/parallella/parallella-linux) note that kernel IP autoconfig and nsfv4 are off by default.

I needed to enable these along with mount network file system options with menuconfig when compiling it. Attached is my working .config file