Thorn has quit [Remote host closed the connection]
mumptai has quit [Ping timeout: 240 seconds]
mumptai has joined ##openfpga
mumptai has quit [Remote host closed the connection]
emeb has quit [Quit: Leaving.]
Degi has quit [Ping timeout: 240 seconds]
Degi has joined ##openfpga
NorthStar has left ##openfpga [##openfpga]
Hoernchen has quit [Quit: meh.]
Hoernchen has joined ##openfpga
Bike has quit [Quit: Lost terminal]
OmniMancer has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
jeanthom has joined ##openfpga
Asu has joined ##openfpga
X-Scale` has joined ##openfpga
X-Scale has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
kristianpaul has quit [Read error: Connection reset by peer]
kristianpaul has joined ##openfpga
Zorix has quit [Read error: Connection reset by peer]
Zorix has joined ##openfpga
jeanthom has quit [Ping timeout: 260 seconds]
Thorn has joined ##openfpga
OmniMancer has quit [Read error: Connection reset by peer]
OmniMancer has joined ##openfpga
egg has quit [Disconnected by services]
oeuf has joined ##openfpga
_whitelogger has joined ##openfpga
eightdot has quit [Ping timeout: 256 seconds]
s_frit has joined ##openfpga
Bike has joined ##openfpga
eightdot has joined ##openfpga
emeb has joined ##openfpga
OmniMancer has quit [Quit: Leaving.]
jeanthom has joined ##openfpga
<scientes>
[Common 17-55] 'set_property' expects at least one object.
<scientes>
Resolution: If [get_<value>] was used to populate the object, check to make sure this command returns at least one valid object.
<scientes>
This is the single "error" I get (I assume critical warnings don't prevent it from building), and I have ABSOLUTELY no idea what it is talking about
<scientes>
and there is no context
<scientes>
source Top_wrapper.tcl -notrace
<scientes>
ahh context
<q3k>
sounds like a xdc issue
<q3k>
too bad it doesn't tell you the file name and line number
<scientes>
WARNING: [Vivado 12-818] No files matched '/home/shawn/git/NiteFury-and-LiteFury/Sample-Projects/Project-0/FPGA-A100T-2-bak/project/project.srcs/sources_1/bd/Top/ip/Top_util_ds_buf_0/Top_util_ds_buf_0_board.xdc'
<scientes>
that?
<scientes>
This is just me trying to build directly from that git repo (the -bak is because Vivado likes to change a bunch of stuff)
<q3k>
i don't remember much from vivado so i don't know, sorry :/
<q3k>
i only know set_property is an xdc thing
<scientes>
I always just git for all development, and it is never a good sign when things change when you try to build a project
<q3k>
yeah, all the big fpga suites just love creating/touching files when building
<q3k>
it's obscene
<scientes>
and even with my Fomu the developers are like "we shipped a blob, because you have to do a couple of runs to find a PRNG seed for nextpnr that works"
<vup>
scientes: I think to have any chance it getting help with the error you need to atleast put the full log somewhere
<vup>
s/it/at/
<scientes>
and when I looked at the file, it is autogenerated by the build process
<scientes>
and also uses absolute paths
<scientes>
vup, I am frustrated because it really isn't my bug--there should be something that can be built for this platform in a deterministic way---I can't fix anything if I don't have a working starting point which serves as a smoke-test
<vup>
you probably still need to bootstrap that by loading a initial bitstream to the SPI flash manually / or flashing the fpga with any of the other supported methods
<daveshah>
You also need to be careful, as unless there is some kind of multiboot arrangement going on if you program in a bitstream without the SPI bridge working, you'll need JTAG to recover it
<scientes>
daveshah, yeah, I ran into that with my Fomu, where it does load into the bootloader first, but I don't know how to interrupt it as the main software doesn't respond to USB
<whitequark>
you re-plug it
<scientes>
it is too fast
<whitequark>
well, if i was writing host software for a bootloader like that, i'd include a --wait option that listens to hotplug events
<whitequark>
idk if fomu does
X-Scale` has joined ##openfpga
<vup>
hmm last time I use fomu it didn't autoboot
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
<scientes>
vup, oh wow, I just run dfu-util -e and it worked!
<scientes>
vup, so the bootloader that it shipped with did autoboot, and then it didn't autoboot after I upgraded the bootloader (although I could not do that on my computer because of the autoboot problem, however on another computer which only had usb 2.0 for some reason it didn't autoboot and i could upgrade the bootloader)
<scientes>
**Note that, like Toboot, the program will auto-boot once it has finished loading.**
<scientes>
hmmmm
<scientes>
nah still doesn't autoboot
<vup>
not sure I follow, with autoboot I am talking about automatically loading a bitstream when plugged into the usb port
<scientes>
yeah
<vup>
it should not do that afaik (as that would make it possible to easily brick it)
<scientes>
an older bootloader had a problem
<scientes>
as it would autoboot in some cases
<scientes>
and the ones they are selling still have the older bootloader
<vup>
interesting
<scientes>
so I just now figured out about dfu-util -e after unbricking it
<scientes>
hmmm, blink.v is still broken though
<scientes>
// Assign USB pins to "0" so as to disconnect Fomu from
<scientes>
assign usb_dp = 1'b0;
<scientes>
// the host system. Otherwise it would try to talk to
<scientes>
assign usb_dn = 1'b0;
<scientes>
// us over USB, which wouldn't work since we have no stack.
<scientes>
assign usb_dp_pu = 1'b0;
<scientes>
this is grounding the usb pins, which confuses the host
<scientes>
which was the problem i was having
<scientes>
it means that dfu-util can't reboot the fomu
<vup>
what does confuse mean here?
<scientes>
it confuses the host usb drivers
<scientes>
to thinking that there is a device there
<scientes>
because those pins are grounded
<scientes>
needs to be 1'bx
<vup>
hmm it sets the pullup to low, so it should be the same as unplugging it
<scientes>
no, that is grounded to low
<scientes>
rather than 1'bx which is electrically non-conductive
<whitequark>
that code is correct
<scientes>
hmm, ok
<whitequark>
the only important part is `usb_dp_pu` being disabled
<scientes>
> In system verilog X is treated like unconnected wire and Z is Weak HIGH.
<scientes>
whitequark, that code confuses linux
<zyp>
driving the pins low is wrong, they should be tristated
<whitequark>
there is no difference between x and z in synthesis
<scientes>
ok, 1'bz
<whitequark>
(in this context)
<scientes>
whitequark, but that is a 0
<whitequark>
the normal state of a USB bus is "both lines pulled to 0 by the host"
<whitequark>
*the state of a USB bus with no device connected to it
<scientes>
this is the gadget, not host
<scientes>
device
<whitequark>
driving them actively to 0 at the device makes no difference
<whitequark>
so if that code confuses linux, the issue is somewhere else
<scientes>
with that code lspci -vvv was stalling
<scientes>
and no less than gregkh said "the device is having issues"
<whitequark>
hm, that makes no sense
<scientes>
*lsusb -vvv
<zyp>
whitequark, but this is not a usb port with no device connected
<zyp>
whitequark, this is a device switching modes from bootloader, i.e. going from connected to driving the bus low
<scientes>
^^^^
<whitequark>
nothing you can do with the USB port should hang PCI transactions
<whitequark>
so it's a buggy host
<scientes>
whitequark, lsusb -vvv, my error
<whitequark>
okay, still a buggy host though
<whitequark>
what host controller is that?
<scientes>
Thinkpa00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)
<whitequark>
interesting
<whitequark>
i have the same HCD and a Fomu, i might be able to try and figure out why it behaves oddly
<scientes>
whitequark, hmm, with the newer bootloader, after booting into the blink program it deenumerates from the usb host, with either 1'b0 or 1'bz
<scientes>
so for now its a hinderbug
<scientes>
*heisenbug
<whitequark>
scientes: i think what happens isn't a heisenbug
<scientes>
you have a guess?
<whitequark>
driving 0 on both D+D- is driving SE0 in terms of USB
<whitequark>
if this happens when the bus is idle, it shouldn't cause any issues
<whitequark>
however, if the device reenumerates in the middle of a transaction, that might hang the bus
<scientes>
I believe I was using usb mouse, but that is 2.0
<scientes>
*that might be different bus
<whitequark>
mice are usually FS or LS devices
<whitequark>
fomu is FS, iirc
<scientes>
anyways, I am happy that I can try to do something with this fomu
<scientes>
but just getting up a usb stack so i can communicate with the host is non-trivial
<scientes>
are there any usb stacks that have ethernet mode?