45eceaaf61
I got bitten again, I've over-designed my solution. The last time it happened, it was that memory mapping thing I was wanting to add. The indirect memory access feature I was adding was to solve a specific problem: Allow Collapse OS to cross-compile directly on a AT28 EEPROM. It began well. As long as we were staying in the assembler realm, things were looking good. However, when we got into the xcomp realm (B260), things became ugly, and I had to creep up indirection where I didn't want to. All of this because I wanted to solve my initial problem in a slightly more generalized way. The broad idea was that these indirect memory access could allow xcomp into a broad kind of memory-like devices. This idea broke on the "@" part of the equation. If I want indirections to be two-way and allow xcomp to work properly, I have to add this indirection to FIND (and possibly others) and this just isn't practical or elegant. So, I'm taking a step back and accepting that the solution I design for now is exclusively for the AT28. What I'm thinking is to add a low-level hook for memory writing, at the assembly level. |
||
---|---|---|
.. | ||
.gitignore | ||
blkpack.c | ||
blkunpack.c | ||
blkup.c | ||
common.c | ||
common.h | ||
exec.c | ||
Makefile | ||
memdump.c | ||
pingpong.c | ||
README.md | ||
ttysafe.c | ||
upload.c |
Tools
This folder contains tools to communicate to Collapse OS machines from a modern environment or to manipulate a blkfs.
Communication tools all take a device path as a first argument. That device is
the serial device that connects you to your machine. It's often a USB-to-TTL
dongle. When -
is specified, stdin
is used as the device.
Note that for these tools to work well, you need the serial device to be
properly set up, TTY-wise. You'll probably want to do that with stty
. The tool
itself takes care of setting the regular stuff (cs8
, -parenb
, etc), but you
need to set the speed. Here's an example working on OpenBSD:
$ ( stty 115200 raw ; sleep 2 ; ./upload - a000 os.bin ) <> /dev/cuaU0
To be honest, I'm having a bit of troubles making these tools work as well on OpenBSD as they do in Linux. But it does work. Here are some advices:
- Use
cuaXX
instead ofttyXX
. - Run
cu -l /dev/cuaXX
before running your tool and run a dummy command to make sure that the output buffer is flushed. - Use the "raw" option to avoid TTY-processing options to mess with data.
- If you experience random failures in your command, try inserting a "sleep 2" between your "stty" invocation and the command. In my experience, these tend to help.
On Linux, it's generally easier:
- Run screen on the device (often
/dev/ttyUSBX
) - Quit with
CTRL+A :quit
- Run the tool on the same device