_This is a Question_
I have
/DocumentationWhat is the current behavior?
I've tried to build ts100 for Pinecil (both master and the commit that Pinecil shipped with, which is a6edc9b), but after flashing it to the Pinecil through dfu it doesn't boot.
Command I've used to flash firmware:
dfu-util -d 28e9:0189 -a 0 -D ./ci/artifacts/Pinecil_EN.bin -s 0x08000000:mass-erase:force
And I've built the firmware using build.sh script supplied (basically docker path, where it fetched ubuntu 20.04 container, installed a compiler and built all the firmwares there are).
Interesting enough that I've compared checksum of the stock firmware (made a dump of it and extracted firmware with dd, I assume it got shipped with _EN version, but I've also ran the same checks for first 10 KB of firmware which I hope will be similar even if it got shipped not with _EN version) and it's different from what is manually built.
I expect to be able to build a flashable firmware out of the repository.
Steps to reproduce the bug:
https://wiki.pine64.org/wiki/Pinecil#How_to_update_a_firmware - I've tried to document the process for re-flash that I've used there
dfu-util -l to detect PinecilFlash firmware with dfu-util -d 28e9:0189 -a 0 -D ./ci/artifacts/Pinecil_EN.bin -s 0x08000000:mass-erase:force
What are you running:
On the idle screen, you can hold the settings button and it will show you the firmware & PCB version.
If using a USB-C supply please note model number
Hello,
So this comes down to some funky tooling that I'm still figuring out.
If you run the build under Windows, via the windows compilers it works fine.
If you run the build under WSL, using the Linux binaries, it _usually_ compiles and works fine.
If you run the build under Linux, it does _not_ work.
I've been working on this from two different sides:
-> Moving the NMSIS that is now published for these chips (Thats mostly working, in a branch)
-> Running a binary bisect on the binary to figure this out.
What appears to happen on the binaries that do not work, is that the chip at boot is loading the start of ram into PC at boot rather than start of flash. Which to me indicates that it is failing the "blank flash" test. However, I have not yet spotted _why_ this is occurring.
This is the main reason I have not yet made a release with Pinecil firmware in it, as building on only Windows is not acceptable.
Unfortunately I didn't spot this until I was going to make a release because at the time I was only near my windows machine.
Definitely having a not fun time figuring this one out, as getting similar binaries out of both Linux vs WSL is even being a bit annoying.
It's not dfu-util related as have confirmed that can flash "known good" under it so far and that has worked
On a sort-of-unrelated note: could it be possible for you to upload the binary for the Pinecil that you got working? (I mean in a release section there are binaries only for TS80/TS100). I mean for a test release.
And yeah, I understand that it's not fun to debug, but maybe other people can help.
I've also noticed in one of the commit messages, that you've changed a compiler for riscv at some point. What were the problems with previous one?
I've also noticed in one of the commit messages, that you've changed a compiler for riscv at some point. What were the problems with previous one?
I just changed to one that is hosted on a githup repo as the other host has a really slow download speed.
(Gitub > 10MB/sec, their host ~1MB/sec)
On a sort-of-unrelated note: could it be possible for you to upload the binary for the Pinecil that you got working? (I mean in a release section there are binaries only for TS80/TS100). I mean for a test release.
And yeah, I understand that it's not fun to debug, but maybe other people can help.
Ah yes absolutely can upload the file 👍🏼
Do I understand this right, you will post the entire flash binary in the test release which can be flashed on linux or windows, right?
Like, the compilation on Linux is broken, but the flashing works, or do I need to get a windows just to flash too?
Just the compilation is broken.
Basically at the point of compiling with same arguments in makefile and use gives very different results. And as such going to try hard coding order to be sure if that's the issue or not.
I'm expecting this to be something dumb in the end but it's frustrating to trace.
Flashing under Linux has always worked for me.
Yes I know those bugs, thanks for all your effort (and this clarification).
I once had a similar case where at the end I found out the bug was in a widely used library and when I reported it I got the answer "yeah you're right, but we've been doing this the wrong way for almost 9 years so we're not changing it because someone else might depend on the bugged behavior" 🤦♂️
Have tagged this in the PR ^
If you get a chance, you could test the CI builds from the PR and let me know if that all works ❤️
Also here is the production firmware file (I believe) for safety
Most helpful comment
Hello,
So this comes down to some funky tooling that I'm still figuring out.
If you run the build under Windows, via the windows compilers it works fine.
If you run the build under WSL, using the Linux binaries, it _usually_ compiles and works fine.
If you run the build under Linux, it does _not_ work.
I've been working on this from two different sides:
-> Moving the NMSIS that is now published for these chips (Thats mostly working, in a branch)
-> Running a binary bisect on the binary to figure this out.
What appears to happen on the binaries that do not work, is that the chip at boot is loading the start of ram into PC at boot rather than start of flash. Which to me indicates that it is failing the "blank flash" test. However, I have not yet spotted _why_ this is occurring.
This is the main reason I have not yet made a release with Pinecil firmware in it, as building on only Windows is not acceptable.
Unfortunately I didn't spot this until I was going to make a release because at the time I was only near my windows machine.