verisimilitude: I may find myself writing Bittorrent software at some point, asciilifeform.
verisimilitude: I intend to implement SHA-256 next.
BingoBoingo: asciilifeform: That explains it though my vertical display toilets do not smush like that.
asciilifeform: BingoBoingo: nfi...
BingoBoingo: asciilifeform: Will look into it more later. Just a very odd thing.
asciilifeform: verisimilitude: is there something you specifically found questionable in the sha built into gnat ? or simply target practice w/ readily-avail. pairs of in/out
asciilifeform: BingoBoingo: a surprising # of wwwisms (and even x11 proggies) behave oddly on vertical display
asciilifeform: ( i'd naively imagine that testing on pnojes would cure the former case , but evidently not )
BingoBoingo: Npojes appear to handle their being a vertical display differently.
asciilifeform does not know. if ben were alive, perhaps could shed light
verisimilitude: I like owning the entirety of my programs, asciilifeform.
verisimilitude: If I'm going to implement Bittorrent software by myself, I may as well implement every component myself.
verisimilitude: That is, the more you intend to write on your own, the more you may as well.
verisimilitude: Also, it was good practice, yes.
verisimilitude: Anyway, what's your opinion on the design; I agonized over the package specification and think it's rather idealized by now, as I explain in the documentation.
feedbot: http://www.krankendenken.com/2019/12/paying-penance-for-walking-the-path-of-derealisation/ << Krankendenken -- Paying penance for walking the path of derealisation
fromloper1121: asciilifeform: Thank you very much for your reply. It will be really nice if you could provide the high res photo / xray of SmartProbe, and maybe share publicly at the same http://www.loper-os.org/?p=1667 article - so that, if not me (can't exclude a bus factor or other unexpected difficulties) then someone else can do this.
fromloper1121: asciilifeform: by "the microcontroller used in the original device is long out of print" (http://www.loper-os.org/?p=1887#selection-2.26-135.61), what controller you meant? The markings of ictel controller are unclear at your earlier photo, so I couldn't check its' availability, but I could see lm3s9b90 on AliExpress - and maybe some other required
fromloper1121: controllers are there too
fromloper1121: asciilifeform: also, please tell, what is a format of a pill found at your post http://www.loper-os.org/?p=1667 , does it include all the firmwares needed for SmartProbe to function? I see that lm3s9b90 has 256KB internal memory, while a sage_last_public_fw.bin is 2.8KB larger (maybe because of a header or something).
fromloper1121: asciilifeform: my concern is that SmartProbe could contain multiple controllers with internal memory, and - if even a single of them is not programmed, then a Smartprobe clone wouldn't be working even if it's a 1:1 correct clone by the hardware
fromloper1121: asciilifeform: hopefully this question could be clarified by the schematics and your knowledge of sage_last_public_fw.bin format . Thanks for your help, wish you a great weekends and coming holidays ;-)
feedbot: http://bingology.net/2019/conducting-a-job-search-in-2019-part-one-the-environment-inside-and-outside-the-republic/ << Bingology - BingoBoingo's Blog -- Conducting A Job Search In 2019: Part One - The Environment Inside And Outside The Republic
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2019-12-21#1004077 << i'ma include it next time i set up the darkroom, but can't promise re when
snsabot: Logged on 2019-12-21 08:30:36 fromloper1121: asciilifeform: Thank you very much for your reply. It will be really nice if you could provide the high res photo / xray of SmartProbe, and maybe share publicly at the same http://www.loper-os.org/?p=1667 article - so that, if not me (can't exclude a bus factor or other unexpected difficulties) then someone else can do this.
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2019-12-21#1004078 << it's EOL from the vendor. chinese ~might~ have some qty, but take their catalogues w/ grain of salt
snsabot: Logged on 2019-12-21 08:33:38 fromloper1121: asciilifeform: by "the microcontroller used in the original device is long out of print" (http://www.loper-os.org/?p=1887#selection-2.26-135.61), what controller you meant? The markings of ictel controller are unclear at your earlier photo, so I couldn't check its' availability, but I could see lm3s9b90 on AliExpress - and maybe some other required
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2019-12-21#1004080 << it's 100% of the fw. the extra space is fpga bitstream, there's an 'actel igloo' in there, and it gets flashed during the main fw upgrade from a turd in the latter. ( plus a header. read the sage_pill src if yer interested in the layout. )
snsabot: Logged on 2019-12-21 08:40:44 fromloper1121: asciilifeform: also, please tell, what is a format of a pill found at your post http://www.loper-os.org/?p=1667 , does it include all the firmwares needed for SmartProbe to function? I see that lm3s9b90 has 256KB internal memory, while a sage_last_public_fw.bin is 2.8KB larger (maybe because of a header or something).
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2019-12-21#1004081 << 2 flashables in there, afaik, the main uc, and the 'igloo' .
snsabot: Logged on 2019-12-21 08:43:20 fromloper1121: asciilifeform: my concern is that SmartProbe could contain multiple controllers with internal memory, and - if even a single of them is not programmed, then a Smartprobe clone wouldn't be working even if it's a 1:1 correct clone by the hardware
asciilifeform: fromloper1121: why dontcha show up some time when i'm actually awake, could have a realtime conv.
asciilifeform: http://logs.nosuchlabs.com/log/asciilifeform/2019-12-21#1004075 << the .ads is pretty well commented. but got tired of writing comments when wrote body ?
snsabot: Logged on 2019-12-21 04:00:07 verisimilitude: Anyway, what's your opinion on the design; I agonized over the package specification and think it's rather idealized by now, as I explain in the documentation.
asciilifeform: verisimilitude: aside from this cannot unfortunately comment re the design, i dun have sha1 in my head and in fact haven't used it for many yrs for anything
asciilifeform: verisimilitude: does it build with 'secondary stack' disabled ?
asciilifeform: http://logs.nosuchlabs.com/log/trilema/2019-12-21#1955870 << heh, BingoBoingo , i did warn : >> http://logs.nosuchlabs.com/log/asciilifeform/2019-12-19#1003977
snsabot: (trilema) 2019-12-21 mp_en_viaje: and otherwise, i'm not going to go through the rest of this drunken braying. start over, and start over like you know what the fuck you're doing.
snsabot: Logged on 2019-12-19 03:45:08 asciilifeform: ( was going to say, that imho it is a very long shot to persuade mp of anyffin; but this already i said before )
asciilifeform: fromloper1121: to add some detail from my ancient notes : the upgrade binary (i single-stepped the whole process via the jtag pins when i was curing the thing) gets loaded into the uc ram, and executes; then a packed copy of fw is flashed in, and packed copy of fpga bitstream ditto.
asciilifeform: fromloper1121: what the cure consisted of, was to modify 2 bytes of the image , that represent expected last 2 bytes of the internal nic's mac addr, to match the particular unit's. this was the entirety of their copyprotection nonsense. (if they don't match, the thing falls back to backup 'demo' fw on reboot)
asciilifeform: fromloper1121: after the 2 bytes fixed, the checksum is adjusted. this was all. the fw image itself was taken from their public update server in the last days when it was alive.
asciilifeform: fromloper1121: the thing 100% won't run on anything but lm3s9b90 'stellaris' obsolete micro -- it makes calls to various internal rom routines of that chip, to e.g. operate the nic.
asciilifeform: fromloper1121: last thing -- amd's 'hdt' protocol, which is what the thing speaks, is standard jtag, but the commands are 'vendor commands' i.e. not documented afaik anywhere. imho your best shot to make clone would be to get hold of 1 working unit and properly capture the traffic on the hdt connector pins, and actually determine the format. then replicate with a standard jtag probe (tho iirc the amd speaks 1.2v, which most sta
asciilifeform: ndard probes do not, you'd need a level shifter.)
asciilifeform: the main difficulty remains -- getting hold of amd boards which actually have hdt header and where not crippled (on all post-2014 chipsets, crippled.) i was able to locate only 3 working examples on open market : 'gizmo 1', 'gizmo 2', and 'pcengines apu1' .
asciilifeform: 'gizmo 1' was a kit which included the probe (time-crippled to '300 hours' iirc. this is where i got my probes, bought a number of kits)
asciilifeform: 'gizmo 2' was slightly improved version, had the connector but did not include probe
asciilifeform: 'apu1' had an unpopulated pad for connector (solder with own hands) and of course not included probe
asciilifeform: 'apu2' later from same vendor had the pad, but probe will not function, amd locked the hdt module and can only be unlocked with their rsa key
asciilifeform: this afaik is all that's publicly known re the subj.
asciilifeform: 'gizmo 1' is pictured in the orig. article.
asciilifeform: the 'igloo' fpga, as far as i could tell, was used simply to run the jtag state machine at reasonable speed (instead of 'bit bang' via the uc).
asciilifeform: hdt connector pinout is known, it includes jtag, and coupla extra pins for serial console, forced reset, and powerdown.
asciilifeform: fromloper1121: the hdt pinout datashit can be seen here.
asciilifeform: fromloper1121: here is how to attach the testpoints to 'busblaster' jtag instrument.
asciilifeform: fromloper1121: test points listed in txt
asciilifeform: fromloper1121: test points magnification pic.
asciilifeform: to run openocd w/ the thing, openocd -s ./tcl -f tcl/interface/dp_busblaster.cfg -f tcl/target/stellaris.cfg and then arm-none-linux-gnueabi-gdb -x stellaris_gdb_init
asciilifeform: this is all i have readily available re the thing, there are some ida turds but would have to pull off tape.
asciilifeform bbl.
verisimilitude: I appreciate your thoughts, asciilifeform. The specification is commented by purpose and thinking, whereas the body comments are more concerned with just the implementation and there's less need to explain purpose, since the implementation itself reveals plenty on its own.
verisimilitude: As for the secondary stack, I've not yet gone through a list of restriction pragmas to apply to the body; my conversion functions return indefinite results, but they'll always have the same bounds, so I figured people deeply concerned with efficiency should have the bounds explicitly stated where necessary, although I may later change this by defining some subtypes to have these functions return instead.