<pointfree>
nats`: That's an idea. I could just have an (address,value) pair set the timer and then I wouldn't need a new record type.
Bike has quit [Read error: Connection reset by peer]
Bike_ has joined ##openfpga
Bike_ is now known as Bike
<cyrozap>
pointfree: This is going to be interpreted by some kind of loader, right? Why not just use a constant delay?
<cyrozap>
Also, no need to update the wiki yet since I'll be making more changes and it'll probably be merged into master within the next few weeks, anyways.
<pointfree>
cyrozap: I'm implementing a PSoC 5LP usb-uart driver and there are various delays needed in various places during setup of the clocking and usb configuration.
<pointfree>
I'm trying to stuff more of the setup into the configuration area (config.hex --> 0x48000000) so that I don't need ldr r0,=addr... mov r1,#val... strb r1, [r0] everywhere.
<pointfree>
So yes, a loader, but the loader needs to know where to wait and for how long...
<pointfree>
Setting the timer from the config array seems like a good way to avoid expanding the format spec. The loader will mind the timer when it loads the configuration.
<cyrozap>
pointfree: Be aware that the 5LP flash driver in OpenOCD mostly ignores the config area, and the PSoC already has 256k of flash. I think the old rule applies here: Don't start optimizing until you need to.
<pointfree>
cyrozap: Indeed. I'm trying to get USB talking properly first and at all. My USB driver sets the registers individually with ARM assembly... but it gets tedious at times so I'm thinking ahead just a little bit.
<pointfree>
cyrozap: can openocd flash to the config area?
<cyrozap>
Oh, yeah, USB is definitely important, but I'm just saying if you need more space, a $1, 16 MiB SPI flash chip is much less expensive than the time spent engineering a clever solution :)
<pointfree>
I'm writing the USB driver in assembly for my forth...possibly to be translated into forth later... but it shouldn't be hard to write a USB driver in C for libopencm3 etc, once I've found all the trappings.
promach has joined ##openfpga
<pointfree>
cyrozap: I don't think I'll need more space. Cypress and kiml use 0x48000000 for a startup config array and I figure it's not a bad idea or particularly difficult to do the same, unless it's needed as flash ECC space.
<pointfree>
It's less about cost and more about cutting out ugly verbosity.
digshadow has quit [Quit: Leaving.]
<pointfree>
I'm having difficulties setting the value of USB_CR0.usb_enable (0x40006008=0x80) ...
<pointfree>
"The IMO frequency should be set to 24MHz before USB is enabled. This register is clocked with 48 MHz USB Clock"
<cyrozap>
pointfree: Regarding OpenOCD and 0x48000000, the short answer is "No, it can't flash to that region." The long answer is, that region is actually just 32 bytes at the end of each flash row, but OpenOCD assumes each flash region is contiguous by row and wants to flash each region one-at-a-time, and the 5LP only supports writing to each 288-byte row at a time and can flash neither the 256 bytes nor the
<cyrozap>
32 bytes separately. Also, whether or not ECC is enabled is controlled by NVL latches.
amclain has quit [Quit: Leaving]
<cyrozap>
To compound this issue, Cypress decided for whatever reason to make their generated hex files put the data for 0x48000000 at 0x80000000.
<pointfree>
hm
<cyrozap>
This could potentially be worked-around by doing a sort of flash-row read-modify-write when flashing the 0x48000000 bytes (read 288-byte row, preserve 256 data bytes but append 32 bytes of config data, then flash the modified row) but that would double the number of flash writes per flash.
<cyrozap>
Ideally, OpenOCD would support arbitrary memory-region->flash-row-byte/bank mapping, but that would require an API rewrite.
<cyrozap>
Also, there are considerations for when you erase a row--do you erase the whole row, killing the config region bytes in the process? Or do you do a slow read-modify-write?
<pointfree>
So is there anything physically unique about those 32 bytes at the end of a row?
<cyrozap>
What do you mean by that? They're mapped to that other memory region (0x48000000), but that's about it. Flash can only be written/programmed by row.
<pointfree>
So only the fact that they're mapped to 0x48000000
<cyrozap>
Also, the fact that they can be ECC bytes means that when ECC is enabled, you can't write to that region, so somehow OpenOCD would need to know about that, too.
<pointfree>
right
<cyrozap>
It's a really tricky situation, and the driver author has chosen not to fix this issue for now, which I think is the right course of action. Better to get a mostly-working driver merged that can get code running on the chip than to have it sit around in code review forever.
<pointfree>
thanks for the links... yeah, I think merging is for the best... we don't want it to diverge hopelessly from upstream.
digshadow has joined ##openfpga
deepbook5broo has joined ##openfpga
deepbook5broo has left ##openfpga [##openfpga]
indy has quit [Ping timeout: 240 seconds]
indy has joined ##openfpga
azonenberg_work has joined ##openfpga
<pointfree>
hmm... the usb_bus_reset isr gives me an "Invalid state UsageFault" ..... "1 = the processor has attempted to execute an instruction that makes illegal use of the EPSR."
<pointfree>
EPSR, if I remember correctly, has something to do with the thumb state?
<azonenberg_work>
pointfree: are you trying to jump to an even or odd address?
<azonenberg_work>
you need an odd address (ptr+1) to jump tothumb code
<azonenberg_work>
just a guess, dont know if that's your problem
<rqou>
(sorry, haven't read all the backlog)
<rqou>
if this is a cortex-m with an nvic
<rqou>
the vector addresses also need the +1
<pointfree>
"00000288 <usb_bus_reset>:"
<azonenberg_work>
pointfree: so your vector should point to 0x00000289
<azonenberg_work>
if usb_bus_reset is thumb code
<pointfree>
I'm using UAL/thumb2
<rqou>
thumb2 needs the low bit set as well
<rqou>
also, according to the interwebs basically nobody still remembers or used the old non-unified thumb1 syntax :P
<rqou>
unless you were a gba homebrew-er? :P
<pointfree>
So it looks like I did indeed need to add +1 to that line in the vector table. Thanks guys!
<pointfree>
usb_bus_reset appears to work now!
DocScrutinizer05 has quit [Disconnected by services]
<rqou>
because the dreamcast is new enough that people widely had internet access, you end up with a mix of modern results and early-2000s results
<rqou>
unlike e.g. c64 hacking, which is all modern results
<qu1j0t3>
rqou: this is an 8 x 3GHz
<rqou>
300W idle? :P
<rqou>
this is a core2-era machine, right?
<qu1j0t3>
Xeon
<rqou>
yes, a but a core2-generation xeon, right?
<jn__>
xeon doesn't say much
<rqou>
i mean, my workstation is a xeon
<rqou>
(broadwell xeon in this case)
<qu1j0t3>
X5365
<qu1j0t3>
but newer models are cheap as well. i keep an eye on prices
<rqou>
ah, so it is the core2-era xeon
<rqou>
not bad
<rqou>
my old workstation that i replaced was a q6600
<rqou>
in some crappy hp oem motherboard
<qu1j0t3>
even a 1,1 Pro can run El Capitan. this one's a 2,1
<rqou>
can it run sierra?
<qu1j0t3>
untried, but possibly not. you could select a model that does.
<qu1j0t3>
3,1 may
<rqou>
intel ARK doesn't list if that cpu has sse4.1 or not
<qu1j0t3>
right.
<rqou>
ah, it doesn't
azonenberg_work has quit [Ping timeout: 260 seconds]
<rqou>
but anyways, i don't need yet another piece of junk sitting around :P
<rqou>
too much stuff already
<qu1j0t3>
yes they're a little large.
<qu1j0t3>
but it does stop my desk blowing away in the wind
<rqou>
i just use my three monitors for that :P
<qu1j0t3>
same
<jn__>
i just close my window :P
<qu1j0t3>
and a couple of network switches
<rqou>
oh yeah btw did i mention that my imac g3 is running off of an "ssd?" :P
<jn__>
rqou: a CF card and IDE/CF adapter?
<rqou>
yeah
<rqou>
much better than the factory 6gb hard drive :P
<rqou>
apparently cf cards used this way don't last very long though
<rqou>
i don't really care though because its a cheap kingston
plaes has left ##openfpga [##openfpga]
m_t has quit [Quit: Leaving]
<lain>
hmm
<lain>
my request has been approved
<lain>
I can run wireless backhaul from the datacenter to my house
<lain>
:>
<rqou>
i hate you :P
<lain>
unfortunately my ipv6 request was denied, they won't give me a /56, or anything more than a /64 :P
<lain>
still better than nothing
<rqou>
wtf
<rqou>
even comcast will
<lain>
yeah
<lain>
I think he's just being stingy :P
<rqou>
comcast gives a rather unusual allocation of a /60
<lain>
yeah I thought about asking for a /60
<rqou>
just say "even everybody's least favorite isp does it"
<rqou>
:P
<lain>
I mean really even a /64 is way more than plenty, the only reason I want more is because a /64 is the smallest supported subnet size, and I have multiple vlans
<lain>
I'll play with splitting the /64 across different vlans to see how fucked it makes things... that will break SLAAC, but if I employ DHCPv6 it might be okay? I dunno
<balrog>
lain: nice!!
<lain>
:> :> :>
<lain>
of course, I haven't actually tested to make sure I can get a link yet
<rqou>
no, i've done that before
<rqou>
it doesn't work so great
<lain>
but the ubnt link estimator says I can
<lain>
rqou: I was afraid of that :P
<lain>
oh well
<rqou>
clients are free to not acknowledge your request for dhcpv6
<rqou>
linux will work
<rqou>
idevices/toys/etc. probably don't :P
<lain>
most of my stuff is freebsd/windows
<lain>
with a linux here and there for various compat
<rqou>
idk if windows works or not
<rqou>
bsd/linux should work
<rqou>
my server has some containers on a /112, but their addresses are all manually assigned
amclain has joined ##openfpga
<jn__>
rqou: you could do NAT and offer /16 ipv4 addresses to the containers :P
<rqou>
i have that too
<rqou>
it's a mess
<rqou>
feel free to look at my "miscellany" repo on github and offer suggestions
<rqou>
i'm actually quite impressed by ipv6 slaac/RAs/ND when they work
<rqou>
although they're immensely frustrating when they don't, especially since tool support is a bit lacking
<rqou>
ime dnsmasq of all things is currently the most "do what i mean" ipv6 tool
scrts has quit [Ping timeout: 240 seconds]
scrts has joined ##openfpga
Hootch has joined ##openfpga
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 268 seconds]
Bike has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
laintoo has quit [Ping timeout: 245 seconds]
scrts has quit [Ping timeout: 255 seconds]
scrts has joined ##openfpga
landley has joined ##openfpga
Hootch has quit [Quit: Leaving]
mifune_ has joined ##openfpga
pie___ has quit [Ping timeout: 260 seconds]
pie___ has joined ##openfpga
GenTooMan has quit [Ping timeout: 258 seconds]
m_w has joined ##openfpga
GenTooMan has joined ##openfpga
mifune_ has quit [Ping timeout: 260 seconds]
mifune_ has joined ##openfpga
mifune_ has quit [Quit: Leaving]
mifune has joined ##openfpga
mifune has joined ##openfpga
mifune has quit [Changing host]
<rqou>
so, after me f*cking around with a virtual os x, i discover:
<rqou>
>Good news. Apple open sourced the TAPI library.
<rqou>
no osx required
mifune has quit [Read error: Connection reset by peer]