64DD is something we would like to support fully eventually. Since the cart code is all written in C (+PIO), it opens up a lot of flexibility for implementations like this. Not everyone is well-versed in verilog/HDL, but there's plenty of C-coders out there, and iteration time is really fast (build-depoly-test cycle).
The project has just started. I made the proof of concept, and now I am building the full project. There's tons of work left to do. We are building a small community around this and any help is appreciated, be it programming, testing or just ideas/discussion. If you're interested to join in, just come by and say hi in the discord. Everything is, and will stay, open source (BSD-2-Clause).
You could swap the flash to 16MB, or use a third party (almost) pin compatible clone with 16MB flash if you really want. I implemented a very simple compression scheme as well so you can load 16MB ROMs that compress to a few kilobytes less than that, leaving room for the firmware.
In the e-mail reply that you get when following the guide you get something to copy paste that looks like this:
git send-email -v2 ...
I tried to find documentation regarding the -v[0-9]+ parameter but couldn't find it at all. What am I missing in the docs? Seems a lot of guides recommend people to use this feature, however there is not a word regarding it in the git docs. It seems that it takes a positive integer as a parameter and adds it to the [PATCH v1] prefix in the subject.
Aha! Makes sense. The docs are usually great for git, but it wasn't clear to me that the args were passed on to git format-patch, where the -v parameter indeed is properly documented.
Great guide but there seems to be a typo/mistake regarding how to save the smtp password in step 2/gmail: should use sendemail.smtpPass instead of the non existing sendemail.password.
Good catch! Want a chance to try out your email skills and send a fix to ~sircmpwn/public-inbox@lists.sr.ht? The git repo is here: https://git.sr.ht/~sircmpwn/git-send-email.io. If you're not interested, I'll push the fix, but figured I'd give you a chance to get credit for it.
This is awesome! I wish you all the best and hope that this takes off.
I am curious about how you use AFL under the hood - how do you scale? Do you use a shared kernel and run a worker process for each physical core, or do you do some virtualization or perhaps run with a kernel patch such as https://github.com/sslab-gatech/perf-fuzz/ ? My experience is that you will hit a wall pretty quickly unless you start multiple kernels by using virtualization, or simply having a very slow binary so you don't get a high number of execs/s to start with.
We actually distribute the fuzzing workload across physical machines, for precisely that reason. Each instance of AFL gets its own kernel & physical core, and we use a staged synchronization algorithm to make sure all of the machines' corpuses stay up to date.
All of this was done to try and keep the scaling as linear as possible, so that when you double your CPU count you're doubling your execs/second as well.
This sounds like a good solution. I was trying to solve this problem on my own as well and ended up making a minimal kernel+afl image that I then boot multiple times using deduplication features in order to save RAM (I don't have 256 gig ram like you do in a proper server). Each instance ends up eating quite a lot of RAM even with a limited root filesystem so that's why I wanted to keep it low. I'm on a 2990wx rig which was kind of a disappointment from a fuzzing perspective because of the limited memory bandwidth, but that's for another discussion.
Do think it would be worth trying out that snapshot approach that I linked in the parent comment or it might not be worth it? I was thinking of rebasing their patch onto the latest master and getting it to work again - sadly the authors seem to have abandoned the project, at least there hasn't been any public changes since a year back.
I miss this. I'm working with embedded C and we always end up nitpicking formatting in review. Using checkpatch helps, but is there something like Prettier for C? I'm aware of the tool called indent but it seems a bit arcane.
