sb0 changed the topic of #m-labs to: https://m-labs.hk :: Mattermost https://chat.m-labs.hk :: Logs http://irclog.whitequark.org/m-labs
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
jevinskie has joined #m-labs
mumptai_ has joined #m-labs
sb0 has joined #m-labs
mumptai has quit [Ping timeout: 258 seconds]
<sb0> whitequark: the board silkscreen for the JTAG jumpers does not match the schematics in the documentation. which one is correct?
proteusguy has quit [Ping timeout: 245 seconds]
<sb0> on ecp5 versa
<whitequark> sb0: uh, never noticed that
<whitequark> give me a few minutes and i'll grab the board
<sb0> so the schematics says this:
<sb0> with the default jumper settings which also do not match the doc
<sb0> whitequark: btw android app support in sailfishos seems to work correctly. despite mediocre UI, sailfish seems to be generally bug-free, unlike lineageos which is more like conda
<sb0> for example, OTA lineageos updates essentially brick my phone, since it fails to load firmware from one of the two system partitions for some reason
<sb0> of course, this happens after the phone has booted, so the bootloader marks the broken partition as functional and you need to go back to fastboot and this TWRP trash to unfuck it
<whitequark> sb0: i'm not married to lineageos, it's more that it worked for me and i really don't want to fuck with mobile OSes any more than necessary
<sb0> the only actual problem I've had with sailfish so far is the phone bootloader reports a wrong model number to fastboot, and this breaks the sailfish flashing script. but this is more like a bootloader bug than a sailfish bug
<whitequark> if sailfish works that sounds great
<whitequark> sb0: the default jumper settings (all 3 in parallel) look definitely wrong to me
<whitequark> i've never used those
<sb0> yep. the board came like that...
<whitequark> no, mine had a different one
<whitequark> not sure which exactly
<whitequark> btw on some boards they accidentally solder the non-5G chip
<whitequark> i have no idea how you manage to do that, or how you miss it during QA, it has a different IDCODE
<sb0> I didn't buy the 5G version
<whitequark> ahh
<whitequark> wait, it might have different jumper settings then
proteusguy has joined #m-labs
<whitequark> i'm not sure what's the difference between versa and versa-5g are
<sb0> it seems QA is a bit lacking on those boards. I also found solder flakes that were just waiting to create short circuits...
<whitequark> sb0: so, do you want to use the ispclock chip, or?
<sb0> no, I wasn't in the lab and didn't have access to the jumpers
<sb0> the sailfish android app support also disables this pesky whatsapp popup "you have a custom ROM installed, no support available", which is nice
<sb0> whitequark: seems the board silkscreen is the correct one
<sb0> and with the ispclock disabled the bitstreams work
cedric has quit [Ping timeout: 255 seconds]
cedric has joined #m-labs
cedric has quit [Changing host]
cedric has joined #m-labs
balrog has quit [Ping timeout: 246 seconds]
rohitksingh has quit [Ping timeout: 250 seconds]
<whitequark> ok
rohitksingh_work has joined #m-labs
balrog has joined #m-labs
<sb0> whitequark: is indexing a signal with another supposed to work with nmigen?
<sb0> e.g. register[bit_select]
<sb0> whitequark: could you try this on your ECP5 board?
<sb0> I'm getting corrupted data, but the data is always corrupted in the same way no matter what the baudrate is
<sb0> it also doesn't seem to be a clocking problem, since when I toggle a FF on the 100MHz clock and look at the output on the scope it is correct
<sb0> the same code also works on the kc705 with vivado
balrog has quit [Ping timeout: 246 seconds]
<whitequark> > register[bit_select]
<whitequark> no, like in migen, that requires ARray
<whitequark> or Part
<whitequark> sb0: ok, let me dig out my versa then
<whitequark> sb0: oh, your bug (?) reminded me of something you need to know about ice40
<whitequark> for a short time after loading a bitstream via SRAM (not sure about flash) the BRAMs will all read garbage
<whitequark> so a reset is mandatory for anything that uses BRAMs
<mtrbot-ml> [mattermost] <sb10q> the bug is also present when hardwiring the uart core data input to some value
<mtrbot-ml> [mattermost] <sb10q> so it's not BRAM
<whitequark> that's for ice40, not ecp5
<whitequark> ecp5 doesn't have this bug afaik
<whitequark> sb0: ugh, can't find a microusb cable
<mtrbot-ml> [mattermost] <sb10q> it's mini USB
<whitequark> yes, miniusb, i meant
<whitequark> anyway, found everything, checking out your code
<whitequark> sb0: which commands are you using to build and load?
<whitequark> ah, there is a nix file
<mtrbot-ml> [mattermost] <sb10q> yes. you can also run the commands. manually, it's not a complicated thing to build
<whitequark> yeah. rebuilding nextpnr now, something about boost libraries changed
balrog has joined #m-labs
<mtrbot-ml> [mattermost] <sb10q> using nix?
<whitequark> no, just my own setup, with nextpnr in /usr/local
early has quit [Quit: Leaving]
early has joined #m-labs
_whitelogger has joined #m-labs
<whitequark> sb0: ok, everything built
<whitequark> sb0: I get "Hello, World!\n" in a loop from /dev/ttyUSB1 at 115200.
<whitequark> no apparent errors or corruption or anything
<sb0> whitequark: can you build for non-5g and send me the svf file?
_whitelogger has joined #m-labs
<whitequark> sb0: ohhhhhh
<whitequark> sb0: make it pause for 1 byte time
<sb0> whitequark: 1 byte time doesn't solve the problem, but a longer delay does
<whitequark> yeah. the UART bitstream is not self-synchronizing
<whitequark> how much did you need to add, 2 byte times?
<sb0> something like 250ms
<whitequark> wtf, FTDI
<sb0> self-synchronizing?
<whitequark> well
<sb0> idk what the minimum delay is, I just tried a very long value
<whitequark> a data 0 can be misinterpreted as a start bit
<whitequark> and if you never stop sending a pattern then the receiving end might never end up locking to the real start bit
<whitequark> just receiving garbage constantly
<sb0> ah, i see
<whitequark> it's funny, this is the kind of thing i think a lot about for glasgow
<whitequark> how to make reliable uart autobaud
<whitequark> or how to make reliable floppy drive controller
<whitequark> (floppies use what i'd call 1b2b, though people call it MFM as it predates systematic study of line codes)
<sb0> somehow I had missed out that the RS232 protocol has this problem, until now
<sb0> and strangely enough it works correctly on the kc705
<sb0> maybe because the FPGA there comes out of reset cleanly and ecp5 does not?
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
_whitelogger has joined #m-labs
urkk has joined #m-labs
urkk has quit [Ping timeout: 244 seconds]
m4ssi has joined #m-labs
mumptai_ has quit [Remote host closed the connection]
urkk has joined #m-labs
urkk has quit [Ping timeout: 246 seconds]
futarisIRCcloud has joined #m-labs
<sb0> for shits and giggles I installed nix and heavyx on sailfishos; amazingly, it works and it builds ecp5 bitstreams in reasonable time on my phone
<whitequark> phones and laptops have more or less converged at this point
<whitequark> so it's not surprising
<elmarco> whitequark: what does it mean for smoltcp to not need heap allocation?
<elmarco> whitequark: Vec<> is heap allocated no?
<elmarco> I am trying to replace pub dns_servers: Option<[Option<Ipv4Address>; 3]>, with something more flexible
<whitequark> elmarco: you don't need Vec<> to use smoltcp, correct
<elmarco> whitequark: how do you ensure that no heap allocation is used?
<whitequark> #![no_std] does that
X-Scale has quit [Ping timeout: 244 seconds]
sb0 has quit [Quit: Leaving]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
X-Scale has joined #m-labs
rohitksingh_work has quit [Read error: Connection reset by peer]
<lkcl> sb0: that's hilarious. you remember the motorola atrix lapdock? the modern (generic) version is nexdock.
rohitksingh has joined #m-labs
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rohitksingh has quit [Ping timeout: 258 seconds]
rohitksingh has joined #m-labs
m4ssi has quit [Remote host closed the connection]
rohitksingh has quit [Ping timeout: 246 seconds]
rohitksingh has joined #m-labs
rohitksingh has quit [Ping timeout: 258 seconds]
rohitksingh has joined #m-labs
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 250 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #m-labs
rohitksingh has quit [Ping timeout: 246 seconds]
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 255 seconds]
urkk has joined #m-labs
lkcl has quit [Read error: Connection reset by peer]
lkcl has joined #m-labs
mumptai has joined #m-labs
X-Scale has quit [Ping timeout: 246 seconds]
keesj has quit [Ping timeout: 268 seconds]
keesj has joined #m-labs
urkk has quit [Ping timeout: 268 seconds]
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #m-labs