Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12600 Discussions

Arria 10 GSRD board - unable to write reg or mem via Linux

Altera_Forum
Honored Contributor II
1,316 Views

I've got the Arria 10 GSRD board. I'm running from a pre-built SD card image created by following instructions on the rocketboards site for the A10 GSRD, which I can't link here. 

The page here shows where some things are mapped in memory: 

 

https://rocketboards.org/foswiki/view/documentation/a10gsrd150ghrdoverview#cortex_45a9_mpu_address_maps 

 

I tried to write memory at 0xc0000000, but I got the following error: 

 

Unhandled fault: external abort on non-linefetch (0x818) at 0x76fcb000 

Bus error 

 

I did some searching and found this: 

 

https://lists.rocketboards.org/pipermail/rfi/2015-august/003271.html 

 

This guy got around a similar problem by rebooting, stopping in uboot, and doing what he called "Setting privilege filter at U-Boot and non-privilege access from Linux App". This is done by writing 0xffffffff to location 0xffd11004 while in uboot, then booting Linux. I copied more or less what he did: 

 

mw.l 0xFFD11004 0xFFFFFFF 

run bootcmd 

 

I tried this, and it worked one time only. I can't make this work again, and I can't find any reliable way to write either some area of memory or a register without the exception noted above. 

What am I missing? Thanks. 

 

 

0 Kudos
2 Replies
Altera_Forum
Honored Contributor II
369 Views

Follow up: I have a rev A board, and I'm building the Linux kernel and root filesystem using the instructions that correspond to the rev A board. I'm told that the build process for rev A is not the same as that for later revisions, so this is something to keep in mind. The instructions for building on new HW don't work with old HW, and vice versa. We have a couple more of these boards on order, so I may need to learn more about this when they arrive. 

 

The problem turns out to be with the default behavior of a privilege filter register. Newer releases of kernel or uboot environment may allow user space accesses to various resources by default, but not with this release. To enable such access, I modified my uboot environment thusly: 

 

setenv gopoke 'mw.l 0xffd11000 0xefffffff' 

setenv bootcmd 'run gopoke; run callscript; run mmcload; run mmcboot' 

saveenv 

run bootcmd 

 

With this change, accesses work normally. 

 

-Mark 

 

PS: I would encourage other forum users to post similar follow-up when a problem resolution is found. Thanks.
0 Kudos
Altera_Forum
Honored Contributor II
369 Views

That one register poke is not enough. Here's a link to the post from Dalon Westergreen that shows the whole sequence: 

 

https://lists.rocketboards.org/pipermail/rfi/2015-august/003259.html 

 

And in this post he gives links to the register definitions: 

 

https://lists.rocketboards.org/pipermail/rfi/2015-august/003260.html
0 Kudos
Reply