<stikonas>well, I'll try to run them manually one by one... <stikonas>hmm, all tests after test0000 fail with the same error Unknown type size_t... <oriansj>if you notice: test/test0000/run_test.sh <stikonas>I was actually running it with GET_MACHINE_FLAGS="--override riscv64" test/test0000/run_test.sh riscv64 <oriansj>hmm looks like an issue with M2libc that I need to fix <oriansj>I'll fix and update M2-Planet's tests for the latest M2libc commit <stikonas[m]>Oh I guess I saw this because I checked out m2libc master for better riscv support... <oriansj>well M2libc changes result in changes in the M2-Planet binaries produced; so auditing it is something that takes time. <oriansj>I guess it is finally time to update and provided the RISC-V support doesn't alter the shared libraries it wouldn't alter the other architectures binaries. <stikonas[m]>I think risc-v updates for m2libc would all be in riscv64 subdirectory <stikonas[m]>And at this stage everything just needs testing to catch all those remaining bugs <stikonas[m]>hex2 at this stage might be good enough, but everything above that might still need changes <stikonas>oh, some tests also need update to blood-elf flags <stikonas>at least test0008 needs, but probably more later <oriansj>I'll do the more correct audit tomorrow. <oriansj>well actually most of them will need a flag for blood-elf and I'd do it tonight if I didn't have to be in the office at 5am tomorrow morning. <oriansj>but if you can wait, I'll certainly get it done tomorrow <stikonas>if you need to be in the office so early, don't work on it tonight <oriansj>but you should be able to get RISC-V tests started by including it in: test/env.inc.sh <oriansj>and doing: ./test/test0001/run_test.sh riscv64 <stikonas>later at around 15 or many of them start crashing <stikonas>but might be my just written libc-full or other libc files in riscv64/Linux/ <oriansj>well lackd of M2libc/${ARCH}/Linux/unistd.h would certainly do that <oriansj>which are needed to build M2-Planet but needed by M2-Planet for its own self-host and the steps after <oriansj>but I figure you'll make a M2libc pull request for those when you feel they are ready ***ericonr- is now known as ericonr
***deesix_ is now known as deesix
<Irvise>If RV32 gets added, I could try bootstrapping from my FPGA... I do not know how far 32Mbits will take me however... <stikonas>yeah, riscv64 can now build up to first build of M1 (needs more PRs to get that) <stikonas>well, somebody needs to port stage0-posix to RV32 <stikonas>and if it's RV32I only, also write a couple of functions to do multiplication/division <Irvise>It used to be IMAC, but they improved it :D <Irvise>Used to boot linux in 100 seconds, now about 10s :D <Irvise>xentrac: well, it was not me :) I updated the fpga-toolchain (all is libre) and updated the FPGA SOC (SaxonSOC) and they had improved the low level code as well as adding a FPU :) <Irvise>That is how I got the speedup. I would expect that if I resynthesize everything, it would probably be faster. <stikonas>hmm, next problem is actually in M1-macro.c file... <stikonas>0xfff and other hex numbers there are unsupported by bootstrap tools (in particular M0) <stikonas>after that (hex2 C version shouldn't matter) as M1 should be able to deal with lowercase hex <stikonas>hitting way more issues than I expected after I got cc_riscv64 working...