<wolfspraul>
supposedly it's easy, but I am unable to successfully login, it keeps complaining about my password even though I successfully reset it with their own server etc. stupid.
<kristianpaul>
mom
<kristianpaul>
You do not have permission to access this content. You can choose to register to gain access to the protected content, or you can return to your originating page.
<kristianpaul>
(i already loged in with my xilinx user)
<kristianpaul>
illregister, let see
<kristianpaul>
oh, i acept a doc about XILINX CONFIDENTIAL ;-)
<wolfspraul>
if you don't want to, don't do it
<kristianpaul>
got it :-)
<wolfspraul>
this zip file contains some source snippet that lekernel was considering using in the Milkymist SoC
<wolfspraul>
the problem is that the source comes with restrictions that do only allow redistribution in binary format inside a binary bitstream
<wolfspraul>
so anybody who would want to build the Milkymist SoC from source would need to download the zip file from Xilinx first, which I am currently unable to do even
<wolfspraul>
so it looks like that would create quite a high barrier of entry for contributors, in reality I would think you loose 80% of people over a step like this :-)
<kristianpaul>
heh
<kristianpaul>
check your mail
<wolfspraul>
but then Sebastien has to weigh the benefits of that code to Milkymist today...
<kristianpaul>
an not yet
<wolfspraul>
best is if more Verilog hackers join and help on the hundreds of things that can be improved :-)
<kristianpaul>
still need to learn more verilog..
<kristianpaul>
but yes
<kristianpaul>
i dont see bitstreams..  actually there is source code
<kristianpaul>
at least is all blobs embeded in .v files ;-)
<kristianpaul>
haha, lekernel want to drop its hpdmc :-), what nasa will say now ..
<kristianpaul>
(kidding of course)
<kristianpaul>
now check email wolfspraul
<wolfspraul>
we were just discussing the implications of using a source like this in Milkymist
<wolfspraul>
everything has pros and cons. Sebastien is the only one with deep overview of the Milkymist SoC architecture today and how it could evolve in the future, right now.
<kristianpaul>
sure,hes is the only one as always.. :)
<wolfspraul>
this source snippet which Xilinx created to support its customers would clearly raise the barrier of entry for new contributors, but I guess it would also improve performance
<wolfspraul>
it would make us depend on proprietary Spartan-6 specific features
<kristianpaul>
yeah,it seems (performance)
<kristianpaul>
well, take advantage is hardware is good
<wolfspraul>
but then I do share Sebastien's belief that we have to make great functioning products today, and not just theoretically 'free' but crappy and uncompetitive stuff
<kristianpaul>
:-)
<wolfspraul>
the best would be as I said if more developers join and help lift the free parts up, no doubt.
<kristianpaul>
may be you can ask to Northwest Logic, Inc, for let you distribute the DDR2 controoler
<wolfspraul>
unlikely that we ever get a response
<wolfspraul>
you can email them too :-)
<kristianpaul>
:-)
<wolfspraul>
it's not even because they are bad or anything, but simply because no other of their important customers ever has a request like that
<kristianpaul>
well, i dont complain yet about ddr controller made by sebastien :-D
<wolfspraul>
and at the volume we are buying chips at, all of these companies would be out of business tomorrow, so they are wise to ignore our strange requests :-)
<kristianpaul>
sure
<kristianpaul>
i agree that take advange of our hardware is the best
<kristianpaul>
sadlt the only way is using xilinx specific libraries for their propietary software,
<kristianpaul>
like then using specific intel instructions, etc...
<wolfspraul>
it will be a middle path for a long time
<kristianpaul>
so the only practical problem, distribution for profit
<wolfspraul>
copyleft hardware is clear to me ;-) push 100% free software and tools to the point that all remaining parts can be sourced from 2 or more independent parties
<wolfspraul>
but that's a long term goal
<kristianpaul>
yeah, sure
<kristianpaul>
the concern now a fast and fool prove Milkymist One, i understand :)
<lekernel>
we're not using the NWL DDR controller, just the PHY, i.e. some non-portable spartan6-specific design they made to tame the pesky I/O and clocking system of that particular FPGA
<lekernel>
you can read the spec document of the PHY ...
<Alarm>
I can not find "sys/ioct1.h" ?
<roh>
wolfspraul: maybe we are looking at this the wrong way around.. why is xilinx again not sponsoring sebastien?
<GitHub88>
[flickernoise/master] Do not include curl/types.h - Sebastien Bourdeauducq
<lekernel>
omg... lm32 is so so broken in rtems head
<lekernel>
semaphores are fucked up, interrupts are probably fucked up, termios is fucked up, ... upstreaming wtg ...not
<lekernel>
and of course, everything works in QEMU or when you add printk() to track down issues
<larsc>
time to switch to linux, i guess ;)
<kristianpaul>
:-)
<lekernel>
haha, don't tell me such things do not happen all the time with linux :)
<larsc>
sometimes
<larsc>
took me almost a day to figure out why the rootfs could not be mounted anymore with 3.0
<larsc>
turns out there is a function called user_strnlen, which returns the number of characters in a string including the null byte. somebody accidentally changed it to not include the null byte
<larsc>
and thus the last byte was always truncated when copying the rootfs path
<Alarm>
lekernel: I can not find "sys/ioct1.h" ?
<mwalle>
lekernel: components arrived
<mwalle>
i guess the middle pin of the ir receiver is GND :)
<lekernel>
mwalle, just drop it instead of the existing sensor
<lekernel>
it's the same P/N
<lekernel>
you shouldn't need to care about pinout
<lekernel>
Alarm, it works for me (and everyone else). please give more information.
<mwalle>
lekernel: na because the heat is sucked up by the plane :)
<lekernel>
also, flickernoise does use this include file, and you said you were able to recompile it... so have a look at how it's done
<lekernel>
e.g. check compiler command like
<lekernel>
also, it's <sys/ioctl.h> and not "sys/ioct1.h" (l != 1; " != <)
<lekernel>
the internal interrupt/context switch management API was changed in RTEMS and broken for LM32, which created all sort of problems (stack corruption etc.)
<lekernel>
I have copied the current Nios code and added _exception_stack_frame
<mwalle>
lekernel: whats the difference between this and the old handling?
<mwalle>
#if( CPU_HAS_SOFTWARE_INTERRUPT_STACK == TRUE) << shouldnt this be always true?