Open stffrdhrn opened 2 years ago
- Main Linux + GLIBC Math tests
The gist:
Other questions: By the way. Are your planning just to add marocchino for arty SoC or also to add atlys SoC to litex project?
I would use marocchino on arty as I do not have an atlys board. If you already have an SOC you should be good. You will need ethernet + NFS to run the glibc test suite.
@stffrdhrn I'm not familiar with buildroot too. Perhaps I will need to study it in a future. But I build glibc-based tool-chain and currently I'm trying to compile busybox and linux. Mine glibc and linux haven't got hard float support yet, but I just try to get a working stuff. By the way, I've created an issue: https://github.com/openrisc/or1k-glibc/issues/11#issue-1097017579 Please, have a look.
As long as your busybox environment can connect to NFS and has and SSH server you should be good. You should not need to build busybox with glibc. Though, to run the full glibc test suite some tests expect gnu coreutils and bash is installed. But I think for the math tests it should not be an issue.
FYI, this is what I run to run just the math tests.
SSH=10.0.0.5 ../scripts/glibc.test math
Where 10.0.0.5
is the IP address of my or1k development board/environment. And glibc.test is from my scripts here: https://github.com/stffrdhrn/or1k-utils/blob/master/glibc/glibc.test
It basically will run:
# BUILDDIR is my directory containing glibc source and build-glibc (the binary build directory) setup with glibc.build
cd $BUILDDIR/build-glibc
make -r -C $BUILDDIR/glibc/math \
test-wrapper="$BUILDDIR/glibc/scripts/cross-test-ssh.sh 10.0.0.5" objdir=`pwd` check
The environment is also described here: https://sourceware.org/glibc/wiki/Testing/Testsuite#Testing_with_a_cross-compiler
@stffrdhrn Stafford, I've implemented write access to FPCSR if SR[SUMRA] is raised. Please, find fpcsr_sumra
branch.
@stffrdhrn
Ok. We done a quick workaround (fix_mmu
branch) to run Linux on MAROCCHINO.
Unfortunately, it looks my next problem is ethernet on my Atlys SoC. In fact I have never used ethernet from Linux till now.
On my Atlys SoC the ETHOC (https://opencores.org/projects/ethmac) is installed. While it works perfectly from U-boot (I use a very old U-boot), it is unstable under Linux. If I try to transfer a file by tftp from my PC to Atlys SoC I receive the following:
# tftp -g -r hello_t.ubi 192.168.2.5
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
hello_t.ubi 20% |****** | 7680 0:00:03 ETAnet eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
hello_t.ubi 20% |****** | 7680 0:00:07 ETAnet eth0: TX: carrier sense lost
net eth0: TX: carrier sense lost
hello_t.ubi 20% |****** | 7680 0:00:11 ETAnet eth0: TX: carrier sense lost
hello_t.ubi 22% |******* | 8192 0:00:13 ETAnet eth0: TX: carrier sense lost
Nevertheless it could complete the transfer.
I am not sure that I could run GLibc tests till resolving ethernet behavior.
That's interesting, I'm not using ethoc, I'm using liteEth from the litex project. I use ethoc on qemu but I haven't seen this before.
The log comes from the ethoc driver.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/ethoc.c
if (bd->stat & TX_BD_CS) {
dev_err(&netdev->dev, "TX: carrier sense lost\n");
netdev->stats.tx_carrier_errors++;
}
The bd
struct is the buffer descriptor , a 32bit status register read from the ethoc dma buffer pool. The TX_BD_CS
bit is set at bit position 0. It indicates carrier sense issue, the cable was disconnected?
From there it is all hardware. So it seems ethoc core hardware is setting that bit on dma transfers. I don't think it's a endian problem due to the transfer working.
We can just suppress the kernel log if you can't figure it out.
Creating this item as work to discuss how to setup the FPU test environment for the marocchino FPU.
Other questions: By the way. Are your planning just to add marocchino for arty SoC or also to add atlys SoC to litex project?