<lain>
tried looking at the gcc patches for avr32, but I'm pretty sure it just summons demons to do the actual patching
<azonenberg>
no, i think it uses daemons
<azonenberg>
:p
<lain>
haha
<lain>
one of the uc3 revisions was missing the multiply instructions
<lain>
like, they were totally missing from impl
<lain>
atmel are pros at testing
<lain>
the errata is like "workaround: use software multiply"
<lain>
it's unclear if that was ES silicon or if it was pre-silicon, but since it has an errata in the public datasheet, and a revision letter... I'm guessing that was silicon of some kind :/
<lain>
anyway, sounds like I have my work cut out for me if I want to target avr32 with rust heh
<lain>
or I could accept my C++ fate
<whitequark>
lain: sure you don't want me to write the avr32 backend? :p
<lain>
whitequark: I have $5, a stale taco, and some pocket lint. is that enough?
<whitequark>
that's not a lot
<lain>
I may be able to upgrade that to a fresh taco
<whitequark>
lol
<whitequark>
well... idk
<lain>
does rust have bitfields?
<whitequark>
if you write all the boilerplate i may write the instruction selector for you
<whitequark>
aka the hard part
<whitequark>
I just really hate writing twenty files of LLVM target where you hvae to replace its name in slightly different ways
<whitequark>
bitfields: not in the core language
<whitequark>
but I'm sure someone wrote a crate for it
<lain>
"Unlike in C, the position of each bytes and bits in the underling bytes array is specifed. The bytes are in network order, and the bits are MSB first. No padding is added."
<lain>
this person gets it.
<azonenberg>
lain: whitequark has pretty much convinced me to write the next-gen antikernel userland in rus
<azonenberg>
rust*
<lain>
ok yeah, this is actually pretty similar to what I was doing with macros in C
<lain>
azonenberg: yeah, rust seems interesting. I'm going to rewrite this code, regardless of target language... might be a good test case for rust
<azonenberg>
lain: well my dream is
<azonenberg>
memory-safe userland
<azonenberg>
running on top of a formally verified cpu
<azonenberg>
on an antikernel soc
<lain>
I just know
<lain>
if I have to interact with one more fucking header file
<lain>
I'm going to throw my computers out the window and take up knitting or something
* lain
pokes the C++ standards peeps, asks what's taking so long with the "module" stuff
<lain>
not that it matters. atmel won't update avr32-gcc, so I can't take advantage of such space-age technology when it finally happens
<rqou>
eh, I don't really get why modules are important
<rqou>
i guess I haven't hit the footguns
<lain>
rqou: mostly that header files are an annoying relic of the past, and totally unnecessary
<rqou>
I'd rather have the ABI stuff fixed
<rqou>
especially on Winblows
<qu1j0t3>
lain | I'm going to throw my computers out the window and take up knitting or something || yeah, fighting systemd yesterday and today makes me feel the same
<lain>
I haven't had the (mis)fortune of encountering systemd yet
<qu1j0t3>
it's waiting for you
<lain>
as long as freebsd doesn't move to it, I probably never will :3
<cr1901_modern>
lain: Rust has an alternate backend (MIR) so you don't have to go the LLVM route. It might be even more work tho. But LLVM is so intractible to me that it's tempting
<lain>
hehe
<lain>
llvm is neat, I've been meaning to poke it
<lain>
they have some nice-looking tutorials on adding a new backend... I'll... try it...
<cr1901_modern>
Look at the cpu0 backend
<clifford>
felix_, it is completely unrelated to carry chains. The bits in question are related to interconnect tiles, not logic tiles. E.g. INT_R_X15Y135/INT_R.NR1END0->>NR1BEG0 and INT_R_X15Y135/INT_R.NE2END0->>NR1BEG0 seem to share the same bits.
<felix_>
clifford: ah, ok. i'll try to look into that later
<azonenberg>
clifford: which device are you looking at?
<clifford>
azonenberg, xc7a50t
<azonenberg>
oooh shiny :D
<azonenberg>
color me very interested
<lain>
:D
<azonenberg>
like, VERY interested
<azonenberg>
lol
<azonenberg>
clifford: a f/oss flow for 7 series has been on my wishlist for a very long time, as you probably know
<clifford>
azonenberg, all of us
TGILITO has quit [Quit: Saliendo]
* cr1901_modern
would rather have a 6 series backend, but that's b/c of BGA lol
<cr1901_modern>
Even the Spartan 7 is going to be BGA only now
<lain>
mmmm
<lain>
I heard s7 will have the tqfp
<cr1901_modern>
I keep hearing conflicting reports, tbh. The 7-series datasheet mentions a QFP, but doesn't actually give dimensions for it
<lain>
huh, it's not in ds180 though
<lain>
yeah
<cr1901_modern>
So it's an error. But which way?
<felix_>
compared to a7 (or probably even s7), s6 is meh
* felix_
isn't afraid of bga parts though
<lain>
at least one s7 is a nerfed a7
<lain>
but there seem to be smaller s7's that are a different die
<lain>
sadly no s7 will have transceivers
<lain>
clifford: your 33c3 talk is making me want to consider verilog (instead of vhdl, which I use currently)
<felix_>
lain: do i remember correctly that you're working on a usb3 core which uses the a7 transceivers and an external usb2 phy? if so, are you planning to open source the fpga design?
<felix_>
clifford: hmm, does every bit correspond to exactly one pip or are there also pips which need two bits to be set?
<clifford>
most of them require more than one bit
<felix_>
i probably should try to dig out the patent on the xilinx switch bozes
<felix_>
*bexes
<felix_>
*boxes
<lain>
felix_: yes, I am working on that. but no, it is not going to be open source.
<felix_>
ok
<felix_>
then it would probably the easiest way to take the existing usb3 fpga design for that really expensive ti transceiver and make it use the transceiver for the usb3 part
<openfpga-github>
openfpga/master 784bf6b Andrew Zonenberg: tests: Fixed pin numbering to be more sane, corrected another numbering error
<azonenberg>
Ok, less errors...
* azonenberg
looks
<azonenberg>
LOL
<azonenberg>
ok, legitimate error
<azonenberg>
i had an error in the gp4par example code
<azonenberg>
that i copied into my test case
<openfpga-github>
[openfpga] azonenberg pushed 1 new commit to master: https://git.io/vMtgh
<openfpga-github>
openfpga/master 691962d Andrew Zonenberg: tests: Fixed incorrect truth table in Luts HiL test. Fixed incorrect LUT truth table in GP_2LUT example code
<azonenberg>
well we know the lfosc test was borked
<azonenberg>
let's see if the ring osc worked
<azonenberg>
um...
<azonenberg>
clearly i'm doing something wrong
<azonenberg>
now this is interesting
<azonenberg>
if you ignore the 6* at the start
<azonenberg>
the measured ring osc freq looks sane
<azonenberg>
13.5 ish MHz
<azonenberg>
13.56 interestingly enough, lol
<azonenberg>
but i think that's coincidental as i got the same garbage measuring the LF oscillator
<azonenberg>
rqou: also when you're around
<azonenberg>
i wanted to discuss your progress on the coolrunner effort and figure out how we want to move forward
<lain>
can't say I'm pleased by the llvm code style, but at least it's consistent
kuldeep is now known as y0u
y0u has quit [Disconnected by services]
kuldeep has joined ##openfpga
Ardeshir has joined ##openfpga
Ardeshir has quit [Quit: Leaving]
<lain>
this cpu is a pain
<lain>
why am I doing this to myself :|
* azonenberg
would suggest drop it
<azonenberg>
say there will be no future s/w releases
<lain>
nah
<azonenberg>
and do futrue dev on stm32 or so
<cr1901_modern>
world needs less ARM IMO.
<lain>
future dev will be arm
<lain>
because avr32 needs to die
<lain>
but I don't feel ok abandoning my existing customers
<lain>
they are numerous.
<azonenberg>
yes but how many of those customers need new code?
<lain>
azonenberg: all.
<azonenberg>
it seems like isostick is a pretty stable product, no?
<lain>
no
<lain>
lol
<lain>
there's.. outstanding issues
<azonenberg>
oh?
<lain>
which I've been meaning to fix for uh
<lain>
4 years
<lain>
give or take
<lain>
burnout, etc
<balrog>
Thoughts on atmel sam?
<lain>
balrog: as a rule, I avoid atmel nowadays unless they have something unique I need (and it's arm). their sam series seems good, I have a sam3u devkit lying around somewhere and it's nice
<lain>
the vendor libs are, predictably, godawful though
* felix_
doesn't like the sam3u very much
<lain>
oh?
<felix_>
sure, it's cheap
<felix_>
but the gpio pins (including the external memory interface) are slow
<felix_>
can't push data from an fpga to the usb interface on the sam3u at full usb2 speed
<felix_>
so if you want to use the chip in a project using the external memory interface or any faster gpio stuff make sure to have a look at the timing stuff of the gpio and memory interface...
<lain>
that's what cypress and ftdi are for
<lain>
;)
<balrog>
How is SAMD21?
<azonenberg>
no, that's what RGMII is for :P
<felix_>
my go to chip for reasonably fast usb interfaces is the ft601; not too expensive either. but only a set of data pipes
<lain>
whitequark: roughly how long would it take you to add support for a new arch in llvm? asking so I can 5x it and guesstimate how fucked I am :P
<felix_>
never used the smaller sam microcontrollers
<lain>
so far llvm is pretty straightforward, just lots of boilerplate and tables ahead of me...
<felix_>
well, ethernet is more complex than just pushing some data into a usb3 fifo ;P
<balrog>
I've been playing with it (LoRAHam project) and they're not bad
<lain>
we'll see what's on the other side after that though
<lain>
oooh LoRaWAN stuff?
<balrog>
Also someone should upstream PIC24/32 ;)
<balrog>
lain: no. #loraham
<balrog>
Something @travisgoodspeed started
<cr1901_modern>
PIC32 is a MIPS. Yamn.
<lain>
balrog: is that like lorawan at all?
<cr1901_modern>
Yawn* :P
<balrog>
A lot simpler intended for ham use
<balrog>
cr1901_modern: there's additions that have not been up streamed
<felix_>
oh and what also bite us when were porting a usb2 stack to the sam3u was that its watchdog timer is enabled by default. took quite some time to find that out...
<lain>
neat
<cr1901_modern>
Oh I'm sure I'm oversimplifying
<lain>
felix_: lool
<lain>
the sam3u vendor usb lib is so baaaad
<lain>
sobad.
<lain>
it's like layers upon layers of needless indirection and complex nonsensical "object models"
<lain>
I'm all for OOP, but that wasn't OOP, it was an abomination
<felix_>
i think the person working on that only looked at some parts of the vendor lib to find out some stuff that wasn't clear from the datasheet
<cr1901_modern>
like the iapx 432 (which also had built in OOP in the arch level... don't ask me how)?
<cr1901_modern>
oh vendor LIBRARY, not h/w
<lain>
heh. that reminds me of that time I was writing a usb stack for an older atmel chip (this was ca. 2005) and after months of banging head against desk to no avail, I finally checked some 3rd party code....
<lain>
printed it out, printed mine out, had a nice sit down for a few days going over it line by line, comparing it all exactly
<lain>
and finally I found the ONE DIFFERENCE
<lain>
a PLL setting.
<lain>
the datasheet was wrong.
<felix_>
the layers on layers of indirections sounds quite uefi-like ;P
<lain>
I notified atmel of this typo, a 1 instead of a 0 in the pll register settings. silence.
<azonenberg>
lain: you make it sound like datasheet errors are a rare occurrence
<lain>
several months later I notified them again. "thank you for bringing this to our attention..."
<lain>
years went by
<lain>
I don't think it was ever fixed
<cr1901_modern>
I destroyed a number of LM2907's b/c the max voltage on the datasheet was wrong and I kept applying too much voltage to the rails (but not above datasheet max)
<lain>
lol
<azonenberg>
you *have* seen some of mine, right? :p
<qu1j0t3>
lain: :(
<lain>
azonenberg: yeah, but man... not fixing it... when it's a critical-to-function setting (you have to put the pll in "usb mode" to enable the usb clocks, and they gave the wrong bits for that)
<lain>
iirc some of atmel's sample code also used this invalid setting
<azonenberg>
lol
<lain>
I mean ok, now I know to check the vendor libs first and foremost
<azonenberg>
ouch
<lain>
but I didn't back then :P
<azonenberg>
Lol yeah
<azonenberg>
i've now learned which parts of silego's docs are generally authoritative in case of a contradiction
<balrog>
On the other hand microchip had those stack bugs
<lain>
actually iirc I was avoiding the vendor libs because I discovered their usb implementation was against usb spec in a lot of ways
<azonenberg>
(appendix A is normally pretty good, the chapter on each peripheral often has serious errors)
<rqou>
for a while I was using a "scene" patched Ollydbg that had debug hiding patches
<rqou>
iirc it was called "SND"
<lain>
if/when I finish this intel motherboard, I wonder if I'll be able to attach a hardware debugger and just bypass all that :P
<rqou>
this was also the winxp era where there were all sorts of near-rootkit kernel patching bullshit to hide ollydbg
<lain>
there's a game I'd like to RE the netcode for, to see why it's so awful... but it's protected by Themida, which is just... I don't have the time :P
<rqou>
"scene" code is scary
<rqou>
Themida still exists?
<lain>
yeah
<rqou>
that brings back memories
<balrog>
What game?
<lain>
I had never heard of it until I poked this game
<lain>
balrog: Ghost in the Shell: First Assault
<rqou>
nProtect GameGuard in my case
<balrog>
Someone used it to "protect" an extremely sketchy fork of MAME that added PGM2 support
<lain>
lol
<rqou>
I actually factored their old RSA key
<azonenberg>
i was asked by someone, i forget who, to crack some themida-encrypted anticheat thing a while ago
<azonenberg>
said no
<azonenberg>
so i never really had a chance to study it in detail
<azonenberg>
but it still existed as of a few years back
<rqou>
probably nProtect GameGuard :P
<lain>
this is like... BlackCipher.aes?
<lain>
which uses Themida
<lain>
or something
<lain>
it's such a departure from big-$$$$ commercial software, which is "protected" by the equivalent of a "please don't" sign
<rqou>
lool
<azonenberg>
lain: well it makes sense
<azonenberg>
low-end stuff has to stand on its own
<lain>
azonenberg: yeah, their revenue is tied to the game being not-hacked, for multiplayer anyway
<azonenberg>
they dont have the budget to pursue infringers, plus there's a bazillion potential users
<lain>
if people can cheat, that ruins the experience
<lain>
and then people won't play
<azonenberg>
But on the other hand
<cr1901_modern>
balrog: How does one "protect" a fork?
<azonenberg>
for high-end commercial stuff
<cr1901_modern>
Besides stabbing someone with it
<azonenberg>
there's only a few users and its usually not hard to tell that somebody used your app and didn't pay for it
<balrog>
Add private crap to it and then encrypt the binary
<lain>
yeah
<rqou>
I've even seen Themida+Y0da
<azonenberg>
at which point you can sue them because you have money, and they have money t otake
<lain>
I don't even know what Y0da is
<lain>
I'm totally unfamiliar with protection schemes outside of like flexlm
<lain>
flexlm is just trivial to bypass :<
<rqou>
some other random exe cryptor
<rqou>
so it was nested :P
<lain>
in PADS they just run all the flexlm codes through a single unsigned dll
<lain>
I kept forgetting my usb dongle
<lain>
so I just patched out the check :P
<rqou>
I also recall hiding my exe that was false-positive-ing Norton AV by just throwing it into PECompact
<rqou>
:P
<lain>
haha
<balrog>
lain: do they do any phoning home for antipiracy?
<rqou>
it was a thing that I did to learn ASM
<balrog>
Some companies do that and then you get a letter from their lawyer (or your ISP does)
<rqou>
a "scene"-style no-import-table hello world
<lain>
balrog: none that I could detect, but I wrote a script to apply the patches and then apply windows firewall rules to disallow any file within the PADS installation from ever reaching the internet :P
<rqou>
also exes with no imports on Windows really is _weird_
<rqou>
because Windows doesn't have consistent syscall numbers
<azonenberg>
lol yeah no imports at all is a red flag for something beign heavily packed
<azonenberg>
usually even packed stuff will have imports for like LoadLibrary() and GetProcAddress()
<cr1901_modern>
imports in the DLL sense?
<cr1901_modern>
Even tho I use Windoze, tbh I know rather little about how binaries run on it
<rqou>
yeah, DLL imports
<openfpga-github>
[openfpga] azonenberg pushed 2 new commits to master: https://git.io/vMto7
<openfpga-github>
openfpga/master b069ded Andrew Zonenberg: gp4par: DRC: Verify DCMPs all have same power-down setting
<openfpga-github>
openfpga/master 0946306 Andrew Zonenberg: greenpak4: DCMP no longer writes power-down mux if unconnected
<rqou>
the hack that I was using was that you would assume that the return address at your exe entry point was somewhere within kernel32.dll
<cr1901_modern>
The guy who put his initials in the MZ file format
<rqou>
Mark Zbi<mumble mumble can't spell>
<rqou>
:P
<azonenberg>
rqou: ;p;
<azonenberg>
yep
<azonenberg>
lol*
<cr1901_modern>
My answer's not wrong either
<cr1901_modern>
Just useless ;)
<azonenberg>
welp, my HiL tests are moving along
<rqou>
anyways, another "scene" way to avoid inputs was to look at the TIB at fs:[0], get the PIB, and look at the loaded module list
<rqou>
*imports
<azonenberg>
yes thats more what i'm used to
<azonenberg>
i've seen malware doing that
<lain>
found out something cute about SpinRite.exe, when you run that in windows you get a little window that lets you create a bootable flash drive or iso... that exe is the exact same one it puts in the iso/flash drive to run in FreeDOS
<azonenberg>
And i can confirm I have the DCMP block working in comparator mode (not yet set up for PWM)
<azonenberg>
next up is to implement DCMP inputs from counters
<cr1901_modern>
The guy who wrote SpinRite is a bit of a conspiracy theory loon
<lain>
since apparently when they extended the exe format to do windows stuff, they left an executable section for non-windows... that's what runs and prints out "This program requires Microsoft Windows" or whatever it says when you run a windows app in dos
<azonenberg>
And then i can finally have a useful subset of the DAC working
<azonenberg>
lain: yep
<lain>
so he just
<lain>
wrote spinrite in that bit
<lain>
and put a gui app in the other bit
<lain>
and it's all like 30kB or something because assembly :P
<cr1901_modern>
lain: Many pieces of Windows software do that tho :P
<azonenberg>
so in principle its totally possible to have a windows and dos app in the same PE/MZ executable
<cr1901_modern>
there's a linker option to change the stub
<lain>
azonenberg: exactly, that's what he did
<azonenberg>
i think i've seen that in some windows system utility?
<rqou>
so he's insane like nocash? :P
<azonenberg>
cant recall which one
<azonenberg>
but it's been done
<lain>
cr1901_modern: I think he's mostly over that, but he is a bit alarmist still about certain things
<cr1901_modern>
nocash isn't insane. He's just a luddite
<cr1901_modern>
not without reason either
<rqou>
apparently nocash lives in Hamburg
<rqou>
I wonder if he attends/sneaks into CCC?
<lain>
he does the Security Now podcast (Steve Gibson, the SpinRite author), which is a fun podcast. sometimes they get stuff wrong, but it's a convenient news source when I'm driving around :P
<balrog>
NoCash dude is not a crank
<balrog>
rqou: considering that he's always broke I doubt it
<rqou>
sneaking in doesn't require money :P
<cr1901_modern>
balrog: I was talking about the spinrite author
<cr1901_modern>
he's a loon, not nocash
<cr1901_modern>
nocash just likes to hold out against Wirth's Law
<lain>
for any sufficiently complex software, you can't beat the compiler
<lain>
I'll put money on that :P
<lain>
at least, not for any modern cpu
<lain>
for simple risc machines, sure.
<azonenberg>
you dont have to beat the compiler
<azonenberg>
you just have to not write your software in horribly bloated fashion
<lain>
right, that too
<azonenberg>
and expanding to fill all available cpu power and memory :p
<lain>
you can write good high-level-language code
<lain>
just most people don't
<cr1901_modern>
Never once did I say we should write everything in assembly :P. What I *am* concerned about is our willingless to shove the complexity in regions such that only a few people know how to handle it
<lain>
either because they don't know how, or they don't care
<cr1901_modern>
as opposed to sharing the burden with users
* cr1901_modern
thinks about systemd and cries a bit
<rqou>
eh I don't really care about systemd one way or another
<lain>
I have no strong opinions either
<lain>
but I'm a windows and freebsd user, mostly, so systemd hasn't affected me :P
<felix_>
lots of stuff is better than the pile of bash scripts called init system we had before ;P
<lain>
that's the impression I get, yeah
<cr1901_modern>
I can at least fix bash scripts
<cr1901_modern>
systemd would take a week or more to figure out how to fix.
<lain>
freebsd's init is pretty sane, I've found it easy to extend and configure... it's probably not as nice as systemd from a sysadmin perspective, but yeah
<cr1901_modern>
rc.conf is pretty well-behaved
<lain>
yeah
<cr1901_modern>
it's able to figure out the order to do everything too
<lain>
yep, and you just specify dependencies and such in the init script, and variables, and it provides you a toolkit of functions... and it's all documented in the handbook...
<lain>
no complaints really
* felix_
had to debug some weird bug that was caused by some sort of race condition in the old sysv-init. might have been due to some debian-specific stuff though; i don't really remember that any more
<lain>
debian's init was annoying :/
<rqou>
in my experience Linux boot always had a fuckton of bugs and race conditions
<lain>
yeah
<rqou>
I just make it so that I win the race the majority of the time
<lain>
what finally kicked me to freebsd was kernel devs putting religion above code
<rqou>
:P
<lain>
rqou: lol
<felix_>
having some productive system which is only reboot-safe in about 70% of the time isn't fun :/
<rqou>
"the thing that reads /etc/network/interfaces" (on Debian) loves to race both itself and other daemons
<lain>
lol
<rqou>
but if you lose the race the upstream link will usually come up still
<rqou>
only the "internal" side will fail
<rqou>
(this is on a router)
<rqou>
on my system iirc I fixed it so I basically always won the race except with smbd/nmbd which are non-critical
<rqou>
I don't get why this is such a difficult problem
<lain>
in freebsd this is just a matter of adding a dependency to the file, it's part of the start of the script
<lain>
then `rcorder' will order it appropriately
<rqou>
the /etc/network/interfaces can't express dependencies within itself
<rqou>
or with "something else" inserted in the middle
<lain>
can you make the network script block until it's up? or did I misunderstand the problem
<rqou>
e.g. a br0 that requires a tap0 that requires an OpenVPN to launch first
<lain>
ahh
<lain>
I think in freebsd that would be like... openvpn would have its own rc script, which could depend on the network interfaces. then other things could depend on openvpn.
<lain>
or etc
<lain>
I should sleep
<rqou>
my favorite was iirc a br0 that depends on hostapd that depends on wlan0 in the config file
<lain>
XD
<rqou>
all this is also racing with dnsmasq in the meantime
<rqou>
:P
* lain
passes out
<lain>
see you folks next year!
<lain>
:P
<rqou>
hmm only 22:34 here
<rqou>
going to hopefully see some fireworks here in Amsterdam
<lain>
16:38 here
<cr1901_modern>
I'm prob gonna watch speedrunners do a race while waiting for the Hell Year to die
<cr1901_modern>
lain: Before you go to bed
<cr1901_modern>
if you are building Clang on Windows, chances are you will need a patch unless you're targeting trunk
<cr1901_modern>
erm, s/trunk/master/
<rqou>
building on Windows? masochist :P
<cr1901_modern>
I'm not about to move all my shit to a Linux system, and my NetBSD installation is borked currently
<cr1901_modern>
and too lazy to post on mailing list on "unborking-procedures"
<cr1901_modern>
other than "it can be done, so why don't I put it off and make it harder"
<rqou>
I only really work on Linux nowadays
<rqou>
too tired of dealing with driver bullshit on other operating systems
<cr1901_modern>
I know :). You make a point to bring that up every time I complain about Windows
Bike has joined ##openfpga
<felix_>
if just someone would pay some good ui designer to improve the ui situation on linux...