lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs
kiwichris has joined #milkymist
kiwichris has quit [Client Quit]
kiwichris has joined #milkymist
methril has quit [Remote host closed the connection]
gbraad has joined #milkymist
gbraad has quit [Changing host]
gbraad has joined #milkymist
kristianpaul has quit [Ping timeout: 264 seconds]
kristianpaul has joined #milkymist
kristianpaul has joined #milkymist
jimmythehorn has quit [Quit: jimmythehorn]
mumptai has joined #milkymist
gbraad has quit [Ping timeout: 264 seconds]
kilae has joined #milkymist
gbraad has joined #milkymist
gbraad has joined #milkymist
gbraad has quit [Changing host]
sb0 has joined #milkymist
mumptai has quit [Read error: Connection reset by peer]
mumptai has joined #milkymist
Gurty has quit [Ping timeout: 260 seconds]
kilae has quit [Ping timeout: 246 seconds]
Gurty has joined #milkymist
<GitHub191> [milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/JFsotQ
<GitHub191> milkymist-ng/master 9f02ced Sebastien Bourdeauducq: dvisampler: add clocking and phase detector
<larsc> sb0: I added a print(sig.huid) to the loop, and they are always in the same order, so I guess it only worked because of some stange side effects.
<larsc> sb0: what isn't sorted the same way each time is the result of _bins()
<sb0> ok, thanks for the heads-up... will continue a bit on the video mixer now, and then fix that, unless you beat me to it
Gurty has quit [Ping timeout: 260 seconds]
Gurty has joined #milkymist
sb0 has quit [Quit: Leaving]
lekernel has joined #milkymist
<larsc> you know the code much better than I do
<larsc> but I sent you a pull request on github for some other things
<lekernel> ah
<lekernel> for some reason github doesn't send me notifications for those
<lekernel> if (key < 0): ==> if key < 0:
<lekernel> it's not C :)
<larsc> right
<Fallenou> :)
<Fallenou> hi !
<Fallenou> does anyone here knows the difference-between/reason-for libgcc1 and libgcc2?
<Fallenou> it (afaik) seems (obiously) undocumented anywhere
<lekernel> btw for shifting registers there is << and >>
<lekernel> they do arithmetic shifts though - your Cat(Replicate(0, n), reg[-n:]) does a logical shift
<GitHub47> [migen] sbourdeauducq pushed 3 new commits to master: http://git.io/gfoRTg
<GitHub47> migen/master 72579a6 Lars-Peter Clausen: Add support for negative slice indices...
<GitHub47> migen/master 2a4cc38 Sébastien Bourdeauducq: Merge pull request #6 from larsclausen/master...
<GitHub47> migen/master dea4674 Lars-Peter Clausen: Allow SimActors to produce/consume a constant stream of tokens...
<lekernel> thanks!
<GitHub105> [migen] sbourdeauducq pushed 1 new commit to master: http://git.io/p7cIoQ
<GitHub105> migen/master b6fe3ac Sebastien Bourdeauducq: fhdl/structure: style fix
Gurty has quit [Ping timeout: 260 seconds]
<Fallenou> gcc is making me crazy
<antgreen> Fallenou: what's the problem?
<Fallenou> when I'm compiling netbsd kernel, everything is fine while compiling each .c to .o object file
<Fallenou> and then, at the end, for the final link, it blows
<Fallenou> gcc generates calls to _mulsi3 and such functions (which are additions/multiplications/divisions on integers and floating point numbers)
<Fallenou> but at the link time it seems gcc does not provide them
<Fallenou> so I get a huge number of undefined symbols "__mulsi3" and others like this one
<larsc> those are in libgcc
gbraad has quit [Ping timeout: 256 seconds]
<Fallenou> that's what I thought
<larsc> since the kernel is not linking against libgcc you wont see them
<Fallenou> and indeed those are defined in libgcc/config/lm32/*.{c,S}
<larsc> in Linux we have a copy of those functions from libgcc
<Fallenou> oh, right ok
<larsc> I bet other architectures on netbsd do the same
<larsc> just grep for __mulsi3
<Fallenou> I did that, a lot
<Fallenou> it's hard to get a "general idea" about this issue
<Fallenou> it seems each arch has its solution for this problem
<Fallenou> sh3 architecture seems to be doing what you say, define those symbols in the kernel source tree
<larsc> on Linux we just compile this file into the kernel https://github.com/milkymist/linux-milkymist/blob/ng/arch/lm32/lib/libgcc2.c
<Fallenou> sun68k seems to refer to those .c and .S files in its kernel Makefile by using relative paths
<Fallenou> ah yes, mulsi3 is in the second one
<Fallenou> but indeed I get unknown symbols for all of this kind of functions
<Fallenou> I tried to add them in LIB2ADD in makefiles in gcc/config/lm32 ... but it didn't help
<Fallenou> I think I will add them in the kernel like in Linux (and like sh3 arch)
<Fallenou> but for the other archs, it remains mysterious for me how it works
<Fallenou> for m68k, x86, mips, arm etc
<Fallenou> I don't see those symbols referenced *at all* in the kernel source tree
<Fallenou> not in Makefiles, not in .c or .S or any file
<Fallenou> so they somehow are able to define them in gcc .... or maybe in libkern
<Fallenou> thanks for the hint :)
* Fallenou wanted to avoid duplicating those files from gcc tree to kernel tree
<Fallenou> but fighting against gcc makefiles is killing me
* Fallenou will add those files to libkern.o
<lekernel> Fallenou, the milkymist lm32 implementation has a hardware multiplier, you don't need __mulsi3
<lekernel> if you do use __mulsi3 you will have a slow system
<lekernel> make sure you compile with --mmultiply-enabled (and the other similar flags)
<larsc> yea, that too
<larsc> on Linux we use -mmultiply-enabled -mdivide-enabled -mbarrel-shift-enabled -msign-extend-enabled
<Fallenou> I have this flag activated in my t-lm32 gcc file
<Fallenou> larsc: ok your solution partially fixed my problem
<Fallenou> now it does not complain anymore about mulsi3 since it's in libkern.o
<lekernel> if you have -mmultiply-enabled, then gcc should never try to use multi3
<lekernel> mulsi3
<lekernel> are you sure you are passing the flags correctly?
<Fallenou> but it does complay about a few remaining symbols :
<Fallenou> lekernel: maybe not, I will have a look
<Fallenou> mutex_* it's my fault, I will need to define those
<Fallenou> but muldi ucmpdi2 etc
<Fallenou> __ashrdi3
<Fallenou> lekernel: oh, maybe I should add those to kernel makefile "CFLAGS"
<larsc> __ashrdi3, hu?
<Fallenou> (-mmultiply-enabled etc)
<Fallenou> larsc: yes it complains about this one
<Fallenou> cf my pastebin
<larsc> sorry, mixed up left and right ;)
<lekernel> there are indeed some symbols that libgcc should define
<lekernel> btw in the bios etc. we are using compiler-rt instead of libgcc
<Fallenou> lekernel: the thing is the kernel does not link against libgcc :/
<lekernel> then make it link against libgcc or an equivalent library
<Fallenou> and in libgcc anyway I don't have this symbol ()
<lekernel> which one?
<antgreen> for my moxie kernel port I have copies of the libgcc routines in the kernel soruces
<Fallenou> __ashrdi3
<lekernel> 64-bit arithmetic shift right? it should be in libgcc
<larsc> I don't think it is
<Fallenou> it's not, at least not in netbsd libgcc (which should be the 4.5.3 one)
<antgreen> it is
<lekernel> compiler-rt has it too
<Fallenou> it was not in the "lm32 specific" directory of libgcc anyway
<Fallenou> ok so I can get a generic one
<Fallenou> dist/gcc/libgcc2.c
<Fallenou> ok got it
<Fallenou> copy pastig those things really is not clean :(
<Fallenou> but that will do it ...
Gurty has joined #milkymist
<lekernel> anyone knows how to fix the fpga editor segfault at startup bug?
<lekernel> s/fix/work around
<lekernel> with a message
<lekernel> Wind/U Error (193): X-Resource: DefaultGUIFontSpec (-adobe-courier-medium-r-normal--12-*-*-*-p-*-*-*) does not fully specify a font set for this locale
<lekernel> but I'm not sure if that's related, the segfault happens several seconds later
<lekernel> and it prints "Release 14.4 - fpga_editor P.49d (lin64)" after ...
<Fallenou> can you enable core dumps and get the dump (and then the stack trace) ?
<Fallenou> maybe by miracle the binary is not stripped :)
<larsc> hm, I get /opt/Xilinx/14.4/ISE_DS/ISE/bin/lin64/_fpga_editor: error while loading shared libraries: libXm.so.3: cannot open shared object file: No such file or directory
<lekernel> 0x00007fffe265c722 in wuGetTextExtent ()
<lekernel> from /opt/Xilinx/14.4/ISE_DS/ISE//lib/lin64/libgdi50.so
<lekernel> motif is already a steaming pile of crap... but wind/u + motif ... omg
<lekernel> larsc, yeah you need to install openmotif ...
<Fallenou> maybe I'm terrible wrong here but, isn't it possible to use the 32 bit version, even on a 64 bit system ?
<larsc> and libstdc++5...
<lekernel> yes, welcome to the world of xilinx software
<Fallenou> the stack trace seems like a real evil bug
<Fallenou> not sure if something can be done to improve the situation ...
<Fallenou> ahah nice issue
<lekernel> oh yeah, this one is famous
<lekernel> "These messages are brought to you by a questionable toolkit called Wind/U that is used to port Windows software to operating systems. Most of these messages can be ignored without lasting effect on the quality of your life. The last line, however, is a real problem. As it turns out, the toolkit ports the deficiencies in standard conformance from the Microsoft world to the target system: It cannot handle the standard display coordinates
<lekernel> of 0.0. "
<larsc> ok, it took like half a minute to start, but it does not crash
<larsc> and no messages about missing fonts
<lekernel> can you trust user interface designers with a logo like that? http://www.opengroup.org/openmotif/banner3.jpg
<lekernel> now add a think layer of wind/u crap on top of that
<lekernel> thick
<Fallenou> omg
* Fallenou got the -mbarrel-shift-enabled -mmultiply-enabled -mdivide-enabled -msign-extend-enabled to be added to CFLAGS |o/
lekernel has quit [Quit: Leaving]
lekernel has joined #milkymist
<lekernel> ah, installing the old x11 bitmap fonts fixes it
<lekernel> it starts now
<Fallenou> pfew
<antgreen> Fallenou: you should probably just create an milkymist-elf toolchain configuration
<lekernel> it doesn't exit without a signal 15 however, but that's a lesser problem
<Fallenou> antgreen: I prefer keeping only one toolchain not to mess everything up
<Fallenou> and then add my special flags etc in the netbsd build environment
<lekernel> phew, 10.1ns routing delay with a fanout of 7
<lekernel> spartan6 silicon is so slow...
<Fallenou> the fanout of an element will increase the propagation delay?
<Fallenou> how does it affect timings?
<lekernel> fanout makes routing more difficult, since the net has to reach many places, possibly spread all over the chip
<lekernel> here it has only to reach 7 places and it takes 10.1ns to reach them all
<lekernel> RATP would love this
<Fallenou> =)
antgreen_ has joined #milkymist
antgreen has quit [Ping timeout: 245 seconds]
<lekernel> meh, how come the output of a global clock buffer is unroutable to the CLK pins of IODELAY2
<lekernel> wtf
<lekernel> WARNING:Route:436 - The router has detected an unroutable situation for one or more connections. The router will finish the rest of the
<lekernel> design and leave them as unrouted. The cause of this behavior is either an issue with the placement or unroutable placement constraints.
<lekernel> To allow you to use FPGA editor to isolate the problems, the following is a list of (up to 10) such unroutable connections:
<lekernel> Unroutable signal: sys_clk pin: IODELAY2_1/CLK
<lekernel> I did that on the old soc and it worked...
sh4rm4 has quit [Ping timeout: 276 seconds]
<lekernel> ah, seems it's because the placer messes up the bufg placements...
<lekernel> right, let's move the bufgs around with fpga editor until it works...
<lekernel> I don't understand why xilinx doesn't recommend using fpga editor. it seems you need it to get anything non-trivial done...
<Fallenou> fpga editor lets you edit placement?
<Fallenou> or even netlist?
<lekernel> yes
<Fallenou> nice
<Fallenou> never used it though, never had to deal with such complex things
<lekernel> actually you can build complete designs with fpga editor, if you have patience (especially since it crashes every 30min on average)
<lekernel> and the UI is horrid
sh4rm4 has joined #milkymist
<lekernel> in part 2 he explains how to add logic elements and nets
jimmythehorn has joined #milkymist
mumptai has quit [Read error: Connection reset by peer]
<Fallenou> thanks !
<lekernel> meh, it seems only a limited number of clocks may enter a IOB
<lekernel> can't find doc about that though
<lekernel> let's see what xdl says
azonenberg has quit [Remote host closed the connection]
<lekernel> and the IODELAY CLK is limited to 180MHz, which, if you are using the ISERDES in single ended mode, in turn limits your data rate to 720Mbps to be able to route all clocks
<lekernel> welcome to fpga slowland
azonenberg has joined #milkymist
<lekernel> meh, yes, if I read the xdl right there are only 2 local clock distribution networks in a IOB
<lekernel> and if you use the IOSERDES, you use them all for CLK0 and CLKDIV...
<lekernel> and if you want to use the variable IODELAY, then you must have CLK=CLKDIV, which limits it to 180MHz
<lekernel> meanwhile, NVIDIA ships GPUs with 5000+MHz IO...
<Fallenou> but they don't have useless routing switches and use 28 nm technology
mumptai has joined #milkymist
<Fallenou> larsc
<Fallenou> I can see in the linux file you linked :
<Fallenou> extern UDWtype __umoddi3 (UDWtype, UDWtype);
<Fallenou> extern DWtype __moddi3 (DWtype, DWtype);
<Fallenou> do you know where those are defined?
<Fallenou> nevermind, I have them anyway
<Fallenou> macbook is down, wont boot ...
<Fallenou> and obviously weeks of headaches on netbsd still not pushed lying in the dead macbook
<Fallenou> yay
<lekernel> but even apple uses standard hdd afaik...
<lekernel> it might be a bit annoying to extract it from the laptop though
<Fallenou> a few weeks ago I put a samsung 840 pro SSD inside the laptop
<Fallenou> I will try to extract it, connect it to another mac book and use the disk repair utility
<Fallenou> Hope it will work
<balrog> apple uses standard hdd in non-macbook airs and non-retina machines
<balrog> macbook airs and retina models use an ssd card
<Fallenou> I'm using macbook pro from late 2010
<balrog> fairly easy to extract the hard drive on unibody models
<Fallenou> I just need Torx T6 and another small screwdriver
<balrog> remove the bottom cover, remove the phillips screws that hold the hard drive retainer
<balrog> the T6 is necessary to remove the four "anchor" screws that stay in the drive
<Fallenou> yep, I know I already replaced the original HDD twice
<balrog> aah ok
<lekernel> just stick it into a USB enclosure and you should be able to get your data back
<Fallenou> at first I put a Crucial RealSSD C300, then a samsung 840 pro
<Fallenou> yes, if I connect it to another mac
<Fallenou> since it's UFS
<lekernel> you can mount it under linux I think
<lekernel> at least read only
<Fallenou> ok I will try that
<balrog> Fallenou: UFS?
antgreen_ is now known as antgreen
<balrog> Macs use HFS+; Linux has a kernel driver for it
<balrog> UFS hasn't been used for ages
<balrog> it's archaic and strange :P
<Fallenou> HFS+**
<Fallenou> sorry typo
<Fallenou> Linux has a kernel driver for it < great !
Hawk777 has quit [Quit: Coyote finally caught me]
Hawk777 has joined #milkymist
Gurty has quit [Ping timeout: 264 seconds]
<lekernel> couldn't they think of a more confusing behaviour? just lost 2+ hours to this :(
<lekernel> (what you connect at one *output* of BUFPLL alters what another output does)
<Fallenou> ...
<Fallenou> isn't it that a part of the design is being optimized out ?
<Fallenou> like the lock signal
<lekernel> it may optimize away the BUFPLL, but then it connects the LOCK signal to 0
<lekernel> in the end, what you see is if you disconnect the output of BUFPLL, what happens to another output changes
<lekernel> if for whatever reason, they have to remove BUFPLLs with a disconnected output, it would have been much better to connect LOCK to the PLL LOCKED input instead of 0 ...
<Fallenou> yes it would make more sens
<Fallenou> sense*
lekernel has quit [Quit: Leaving]
<azonenberg> lol, wow
<azonenberg> Also, i think i know that guy
<azonenberg> (the OP)
<azonenberg> he went to my school and was talking to me a year or so ago about doing HDMI on an Atlys
mumptai has quit [Ping timeout: 240 seconds]